From guidelines to plumbing: putting MAS's AI risk management guidelines to work at a Singapore wealth manager

The situation

A Singapore-based wealth manager served private and affluent clients across Asia. AI had arrived from every direction: a suitability scoring model built in-house, a vendor's generative AI assistant for relationship managers, a document tool that drafted client letters, transaction monitoring with machine learning inside, and an operations pilot using AI agents to reconcile statements. Risk kept a short spreadsheet of "AI models". Nobody believed it was complete.

Why now. The Monetary Authority of Singapore (MAS) issued its final Guidelines on Artificial Intelligence Risk Management on 7 October 2026¹³. Published summaries describe guidelines that cover all forms of AI, including generative AI and agents, on a risk-proportionate basis; that put boards and senior management in charge of AI risk appetite and oversight; and that keep the institution accountable for AI bought from vendors²³. Commentary reports transition periods into 2027 and 2028³. The authoritative text sits with MAS⁴. The board wanted to know what the firm actually used, how risky each use was, and how it would know when something went wrong.

What had to be true

• A complete, living inventory of AI, built and bought, including features inside vendor products.
• Risk tiers that change the controls: light for low-risk uses, rigorous for client-impacting ones.
• Vendor AI held to the same bar, with evidence proportionate to risk.
• Gates in the lifecycle: material AI cannot go live without evaluations and monitoring.
• Board reporting from live data, not quarterly heroics.

Architecture

The data flow, end to end

The hard part: finding the AI you did not build

Most of the firm's AI was inside products it had bought. Vendors had switched on generative features in CRM, document and communications tools, often by default. Interviews missed them. The team used three nets: every generative AI call from internal systems went through an LLM gateway, which logged the application and model; procurement and renewals now asked vendors to declare AI features and their data use; and a periodic scan looked for AI SDKs and API keys in code and configuration. Each find created a draft inventory entry for an owner to complete.

Monitoring had a consistency problem. Each tool reported AI activity differently, so dashboards were stitched together by hand. The team adopted the OpenTelemetry generative AI conventions as the firm's telemetry contract and checked conformance in CI, so a service that emitted the wrong attributes failed its build rather than quietly breaking reports. OpenTelemetry Weaver provides exactly that kind of live check against a registry of conventions⁵.

Agents needed their own treatment. The reconciliation pilot was low risk in impact but high in autonomy, so its tier was raised: every action logged, narrow permissions and a human approval step for anything that changed client records. See when agents become the user and evaluating AI agents.

How it ran

Key decisions and trade-offs

What I'd do again, and differently

Again: put the gateway in early. It quickly found AI uses the survey had missed. Differently: involve procurement from the start. Vendor features switched on at renewal were the largest source of new entries. Related: ISO 42001 and the NIST AI RMF, LLM observability with OpenTelemetry, an agent-ready marketplace in Southeast Asia and the Singapore page.

If you are putting MAS's AI guidelines into practice, see my AI architecture work, or analyse your challenge and bring the result to a call.