Key Takeaways
- MAS issued its Guidelines on AI Risk Management on October 7, 2026. They apply to all financial institutions, cover all forms of AI including embedded, third-party and agentic AI, and are calibrated to each use case’s risk materiality.
- Implementation is phased: oversight, AI identification, inventory and risk materiality from October 7, 2027; lifecycle controls and capabilities by October 7, 2028.
- After the oversight sections, almost every expectation is a data question. Data controls are the one family that applies across the whole AI portfolio, even for low-risk copilots.
- AI touches data on three surfaces: data flowing into AI, data flowing through AI, and data touched by autonomous agents. The Guidelines set expectations on each.
- The Guidelines frame controls in terms of what an institution can show. The most reliable evidence is generated by controls that operate on the data itself, not assembled by hand.
- No data security platform satisfies the Guidelines on its own. What the data layer can do is make the inventory accurate, the materiality rating evidence-based, and the monitoring record complete.
On October 7, 2026, the Monetary Authority of Singapore (MAS) issued its Guidelines on Artificial Intelligence Risk Management. They are guidelines, not statute. But they set supervisory expectations, and how well an institution observes them can shape how MAS assesses that institution’s overall risk.
I read the Guidelines the way a product team reads a specification. The first sections ask who is accountable for AI. Almost everything after that asks a data question. What data feeds the model? Who can see what it returns? Can you prove what happened afterward?
That is the argument of this piece. AI governance programs that start at the model will spend the next two years assembling evidence by hand. Programs that start at the data will find much of that evidence is produced as a by-product of controls they should be running anyway.
Related Reading: If you want to go beyond the Singapore specifics, The Mage Data Guide to AI Data Security is a good next read.
What MAS actually set out
The Guidelines follow a consultation MAS opened in November 2025. They apply to all financial institutions in a proportionate manner, according to their size and risk profile (para 2.1). Paragraph references below are to the Guidelines dated October 7, 2026. The scope is deliberately wide:
- All forms of AI. Machine learning (supervised, unsupervised and reinforcement), deep learning, NLP, computer vision, generative AI and AI agents, including multi-agent systems. Only tools whose outputs rest solely on predefined rules fall outside (para 1.3, footnote 6).
- Embedded and third-party AI. Identification should cover, at minimum, AI in services from material third-party providers, including SaaS not explicitly sold as AI (para 4.2, footnote 21). The institution retains primary accountability for third-party AI it uses (para 5.11).
- A proportionate floor. Institutions whose AI use is unlikely to cause material adverse impact may run a basic set of policies (para 2.3). Even that floor includes prohibited uses, such as inputting confidential, proprietary or client information into public AI tools (para 2.5(b)).
- Risk materiality per use case. Each use case is assessed on impact, complexity and reliance. The impact dimension explicitly considers the nature and sensitivity of the data processed (para 4.12(a)).
- Lifecycle controls. Data management, transparency and explainability, fairness, human oversight, third-party AI, selection, evaluation and testing, technology and cybersecurity, reproducibility and auditability, pre-deployment review, monitoring and change management, each calibrated to materiality (Section 5).
The Guidelines take effect on October 7, 2027, and implementation is phased (para 1.8). Oversight, AI identification, inventory and risk materiality expectations (Sections 3 and 4) apply from that date. Lifecycle controls and capability expectations (Sections 5 and 6) are to be met by October 7, 2028. In its accompanying media release, MAS also said it intends to consult the industry on further guidance for agentic AI in 2027.
Reading the Guidelines as an engineer
AI does not create new data. It moves, transforms and recombines the data an institution already holds. The Guidelines recognize this in a footnote that is easy to miss. Controls on transparency, explainability and fairness matter most for decisioning use cases, and some testing may be less relevant for a writing copilot. But controls relating to data management, safety and cybersecurity “would be relevant and should be applied in a proportionate manner” even there (footnote 12). Data controls are the one family that applies across the whole portfolio.
That gives AI three data surfaces, and the Guidelines touch each of them.
Data flowing into AI. Training sets, fine-tuning corpora and retrieval pipelines are assembled from bulk copies of enterprise data, usually outside the governance that protects the source systems. Paragraph 5.4 asks for data that is fit for purpose, representative, of high quality and governed, and names seven areas: fitness, representativeness, quality, classification, security, privacy, and auditability and lineage. It also expects consent where sensitive personal data is used to train models, and timely destruction or sanitization of training data once no longer required (para 5.4(e)–(f)). Here is the engineering tension worth naming: de-identification and representativeness can pull against each other. Masking that breaks distributions, formats or cross-table relationships produces safe data that no longer reflects reality, and test datasets should be representative of the institution’s context of use (para 5.14(b)). The requirement is de-identification that preserves utility, and a validation step that proves it.
Data flowing through AI. Every prompt is a data transfer, and most happen in interfaces traditional DLP was never built to inspect. MAS names the risk directly: leakage of confidential or customer data through third-party generative AI services, and the use of shadow AI (para 1.10(b), (f)). Where shadow AI cannot be fully identified, the suggested mitigants include data loss prevention and network monitoring (footnote 22). Paragraph 5.4(e) goes further and asks for “securing the inputs and outputs” of the AI itself. On the output side, a vendor copilot inherits whatever permissions it was granted, and the institution usually cannot modify the vendor’s model or interface. Control has to sit at the response, not inside the product.
Data touched by autonomous AI. MAS warns that compromised agents with access to internal systems could exfiltrate sensitive data at scale (para 1.11). For agents, the inventory may capture the tools and systems each agent can access (footnote 25); monitoring should cover reasoning processes, actions taken and tools used (para 5.23(a)); and logging of prompts and model responses could be considered (para 5.23(d)). Pre-deployment reviews expect access controls based on least privilege (para 5.22(a)). That is an identity and entitlement problem before it is a model problem. An agent running on its builder’s credentials can reach data no one scoped for it, and its reads leave no attributable record.
Across all three, the Guidelines frame controls in terms of what an institution can show. Local senior management should be able to demonstrate to MAS how it discharges oversight (para 3.6). Access to models, training data, pipelines and configuration files “should be strictly controlled and logged” (para 5.23(d)). Demonstration needs evidence, and the most reliable evidence is generated by controls that operate on the data itself.
The research points the same way
MAS is setting expectations for a curve that is already steep, and the data exposure it addresses is measurable today.
IBM’s 2026 report adds the cost side. In ASEAN, the average breach reached a record US$4.12 million, and financial services carried the region’s highest cost at US$6.53 million (IBM ASEAN). The ASEAN sample is 26 organizations across six countries, so treat these as regional indicators rather than Singapore figures. Globally, AI-enabled malicious breaches averaged about $6 million, roughly $1 million above the all-breach average. More than 20% of organizations reported a breach targeting AI models or applications, most often through weaknesses in the surrounding systems: compromised APIs, applications or plug-ins, and cloud misconfigurations affecting AI workloads, each cited in 27% of cases. Only 37% of breached organizations said they encrypt sensitive data both at rest and in transit.
Policy alone will not close the gap. In BCG’s AI at Work 2025 survey, 54% of employees said they would use AI tools even if not authorized. That is the population a paragraph 2.5(b) prohibition has to reach, and why footnote 22 points to technical controls such as data loss prevention.
Gartner’s guidance converges on the same layer. Gartner predicts that by 2027 more than 40% of AI-related data breaches will stem from improper cross-border use of generative AI, a live issue for Singapore institutions operating inside global groups (para 1.5). Its recommended responses include anonymization, prompt filtering and redaction, and synthetic generation of unstructured data, all of which operate on the data rather than the model.
Mapping the expectations to data controls
The table below maps each MAS expectation to the data control it implies and the Mage Data capability that addresses it. Coverage is stated plainly: Direct means the capability performs the control; Supporting means it supplies evidence or inputs, while the institution still owns the decision; Outside scope means data-layer tooling is not the answer.
| MAS expectation (para) | What it requires at the data layer | Mage Data capability | Coverage |
|---|---|---|---|
| 1. Identify AI use, including embedded and shadow AI; mitigate what cannot be identified, e.g., with DLP or network monitoring (4.2–4.4, fn 22) | Detect unsanctioned AI tool use and the sensitive data flowing to it | AI Usage Guardrails; Activity Monitoring for AI | Direct |
| 2. AI inventory records data used; link to data inventories via consistent data asset identifiers (4.6–4.7, fn 23) | Know which sensitive data each AI system, pipeline and agent can reach | Sensitive Data Discovery & Classification; User & Agent Discovery | Supporting |
| 3. Risk materiality: impact considers nature and sensitivity of data processed (4.12(a)) | Classification evidence per data source, not self-attestation | Sensitive Data Discovery & Classification | Supporting |
| 4. Basic policy: no confidential, proprietary or client information into public AI tools (2.5(b)) | Detect and mask sensitive content in prompts and uploads before it leaves the device | AI Usage Guardrails | Direct |
| 5. Data classification guiding use by criticality and sensitivity (5.4(d)) | Consistent classification across structured and unstructured stores | Sensitive Data Discovery & Classification | Direct |
| 6. Data security, including securing the inputs and outputs of the AI (5.4(e)) | Mask what enters prompts; mask, redact or block what responses return | AI Usage Guardrails; Dynamic Data Masking for AI; AI Development Guardrails | Direct |
| 7. Data privacy and representativeness of training and test data (5.4(b), (f); 5.14(b)) | De-identify training, fine-tuning and retrieval data while preserving formats and referential integrity | Training Data Guardrails; Static Data Masking; Synthetic Data | Direct for protection; Supporting for representativeness and consent |
| 8. Third-party AI: institution stays accountable; test with its own data; restrict data exposure (5.10–5.11, 5.16(c)) | Control what a vendor copilot returns without modifying it; provide de-identified copies of own data for vendor testing | Dynamic Data Masking for AI; Static Data Masking | Direct |
| 9. Agents: record tools and systems they can access; least-privilege access (fn 25, 5.22(a)) | Scope each agent session to the end user’s entitlements | AI Development Guardrails (SDKs, MCP Server); User & Agent Discovery | Direct |
| 10. Monitoring and logging of actions, tools used, prompts and responses; access to training data logged (5.23(a), (d)) | Attributable record of who asked what, which tool, what was masked and the policy outcome | Activity Monitoring for AI; Database Activity Monitoring | Direct |
| 11. Data lineage and reproducibility of development and testing (5.4(g), 5.17(a)) | Documented data sourcing and processing; repeatable de-identified test datasets | Static Data Masking; Test Data Management | Supporting |
| 12. Technology and cybersecurity controls, read with MAS TRM Guidelines (5.16, 5.22) | Monitoring and enforcement at the data tier, whoever or whatever issues the query | Database Activity Monitoring; Database Firewall | Supporting |
| 13. Board oversight, risk appetite, materiality methodology (Section 3; 4.10–4.13) | Governance decisions | None | Outside scope |
| 14. Fairness, explainability, human oversight, independent validation (5.5–5.9, 5.18–5.21) | Model risk management disciplines | None (de-identified data can feed testing) | Outside scope |
The last two rows matter as much as the first twelve. No data security platform satisfies the Guidelines on its own, and any vendor claiming otherwise is misreading them. What the data layer can do is make the inventory accurate, the materiality rating evidence-based, and the monitoring record complete.
Where to start before October 2027
The first deadline is about records: an inventory and a materiality rating for every AI use case. The order of work below follows that logic.
- Classify the data under your AI before you rate the AI. An inventory field that says “data used: customer data” is an assertion. A classification scan that shows which tables and documents contain personal or regulated data is evidence. Link data asset identifiers to the AI inventory so the two stay in step.
- Rate inherent and residual risk, honestly. The Guidelines ask for both ratings, and residual risk must sit within appetite before deployment (para 4.11). Data sensitivity is one of the fastest ways a use case moves into the high tier.
- Make the basic-policy prohibitions enforceable. If the policy says client data does not go into public AI tools, put a control at the prompt that masks it, and keep the record.
- De-identify before you train, then validate. Masking a training corpus is the cheapest residual-risk reduction available. Then test that the masked data still behaves like production, because representativeness is also an expectation.
- Put response-level controls in front of copilots you cannot modify. Third-party accountability does not wait for the vendor’s roadmap.
- Treat every agent as an identity. Discover it, scope it to the entitlements of the person it serves, and log what it touches.
- Build the evidence trail now. By October 2028 the question will not be whether controls exist, but whether you can show they operated.
The institutions that will find these Guidelines easiest are not the ones with the most AI policies. They are the ones that already know where their sensitive data is, and can show who and what has touched it.
About Mage Data
Mage Data is a leader in data security and privacy software for global enterprises. Recognized as a Champion in Test Data Management (Bloor Research), Leader in Data Security Platforms (Kuppinger Cole) and Strong Performer in Dynamic Data Masking (Forrester), Mage Data’s award-winning and patented platform enables global organizations to navigate privacy regulations while ensuring robust security. Mage Data is also the highest-ranked vendor on Gartner Peer Insights for “Test Data Management” and “Data Masking and Synthetic Data” over the past 12 months, reflecting strong customer validation of its capabilities and impact. Mage Data’s client roster includes Fortune 500 companies, Ivy League universities, and leaders in the financial and healthcare sectors, all of whom rely on Mage Data’s platform for effective data privacy and security solutions.
For more information, visit www.magedata.ai
Sources (as of Oct 8, 2026)
- MAS, Guidelines on Artificial Intelligence Risk Management, October 7, 2026 (PDF supplied)
- MAS media release, October 7, 2026
- Baker McKenzie: MAS consultation paper on AI risk management (November 2025)
- RegReportingDesk: MAS AI Risk Management Guidelines analysis
- McKinsey, The state of AI in 2026: On the road to ROI (August 2026)
- IBM, 2026 Cost of a Data Breach Report press release (July 29, 2026)
- Gartner, Predicts 40% of AI Data Breaches Will Arise from Cross-Border GenAI Misuse by 2027 (February 17, 2025)
- BCG, AI at Work 2025 press release (June 26, 2025)
- KuppingerCole vendor page: Mage Data
- Mage Data launch release, August 31, 2026 (CIO Influence)