Why Your CTO Should Own the Agentic AI Governance Conversation

Governance decisions are often embedded in the build before compliance has a chance to review them. By then, engineering may already have defined what your AI underwriting system can approve automatically, what it must escalate to a human reviewer, and what evidence it records for each decision.

Compliance can still identify gaps. However, closing those gaps would be expensive as it would likely require redesigning workflows, permissions, decision thresholds, and audit infrastructure.

The Costly Mistake: Retrofitting Governance After Launch

The costly mistake is not failing to write an AI governance policy. It is discovering, after launch, that your AI underwriting system cannot apply that policy consistently.

By then, the system may already be processing lower-risk applications automatically, routing exceptions through an inadequate review process, or producing decision records that cannot explain why an outcome occurred. Correcting those gaps can mean redesigning workflows, changing permissions and decision thresholds, and rebuilding audit infrastructure—all while the product is live and customers, auditors, or enterprise buyers are asking for evidence.

Singapore's Monetary Authority published a useful reference point on July 3, 2026. Safeguards for Agentic Finance at Runtime (SAFR), developed under MAS's BuildFin.ai initiative with industry participants, describes a governance layer that sits between an AI system's proposed action and the systems it can act on. SAFR is not a binding regulation or supervisory requirement. It is an industry reference model for assessing whether an action is authorized before execution.

SAFR places a decision checkpoint between an AI system and the action it wants to take. Called a disposition engine, it checks the proposed action against the firm's rules and decides whether to block it, send it to a human reviewer, allow it to proceed automatically, or allow it while flagging it for monitoring.

The framework also calls for the system to verify the AI agent's identity, retrieve the applicable controls, and create a tamper-evident record of the decision.

Governance Is Built Into the System

An AI underwriting or KYC system does not make one decision. It makes a sequence of them: whether to verify an identity, request more documentation, flag an income discrepancy, route an application to human review, or permit the workflow to continue.

Each step needs a defined control. The system must know which AI component is acting, what it is authorized to do, which conditions require escalation, and what evidence it must retain. SAFR describes this as a runtime governance layer: the proposed action is associated with a registered agent identity, evaluated against a controls repository, assigned an outcome by the disposition engine, and recorded in a tamper-evident audit log before execution.

This is where the architecture matters. Risk and compliance teams should set the policy boundaries. For example, which decisions require human review, which conditions must stop an action, and which records the firm must preserve. Engineering then has to translate those requirements into permissions, thresholds, decision routes, and logging. The controls only work if the system applies them at the point of action.

That is why late compliance review creates expensive rework. If the team has already built the workflow without a reliable identity layer, policy-based routing, or sufficient decision records, identifying the gap is only the first step. Closing it may require redesigning the product and its underlying infrastructure.

The Evidence Gap

Many firms can show that they log AI decisions. Far fewer can show that those records are reliable enough to support an investigation, audit, or regulatory review.

A 2026 survey of 720 senior professionals across nine Asia-Pacific markets found that 68% of financial-services organizations maintain audit trails of AI decisions. Across all sectors surveyed, however, only 38% reported having a tamper-proof audit trail.

This gap matters. While a standard log tells you that an event happened, a tamper-evident record helps establish trustworthiness. If a customer, auditor, or regulator asks why an AI system approved, declined, or escalated a case, the organization needs to reconstruct not only the outcome, but also the controls applied, the information available at the time, and any human intervention.

Industry guidance is becoming more specific about these risks. FINOS's AI Governance Framework v2.0 expanded its coverage to 46 risks and mitigations, and maps them against seven existing frameworks, including the EU AI Act and OWASP guidance. Its agentic-AI additions address risks such as prompt injection, memory poisoning, persistent agent compromise, chain-of-thought leakage, and supply-chain tampering.

The frameworks are available. The harder task is building controls, maintaining evidence trails, and monitoring the delivery process that ships AI features.

A governance policy written after the product is designed cannot, by itself, create the permissions, checkpoints, and audit records the system needs to operate under control.

What Good Looks Like

Good governance does not mean eliminating automated decisions. It means being able to show that the system operates within defined limits and that its performance can be measured against an appropriate baseline.

Upstart offers a useful, but limited, illustration. As of October 2023, its model approved 44.28% more borrowers than a hypothetical traditional model at 36% lower APRs. This is a performance claim, not independent proof that any underwriting model is compliant, fair, or appropriate for another lender. Still, it demonstrates the type of measurable outcome a company should be prepared to substantiate.

For an AI underwriting or KYC system, the defensible evidence may include:

• Approval, referral, and decline rates against a human-reviewed or legacy-process baseline

• Error and false-positive rates, including the percentage of cases later overturned

• Exception volume and escalation rates by risk category

• The time from an AI-generated flag to a human review decision

• Fair-lending, bias, or disparate-impact testing where applicable

• A complete record of the system's proposed action, the controls applied, the resulting outcome, and any human override

Though the exact measures will depend on the product and applicable obligations, the principle is consistent: compliance and risk can specify what the firm must evidence, but engineering must make the evidence possible. Without reliable identity, control, routing, and logging mechanisms, a performance claim becomes difficult to verify and even harder to defend.

What Leaders Should Do Now

The immediate question is not whether your company has an AI governance policy. It is whether the policy can control the system while it operates.

Before expanding an AI underwriting, KYC, or other high-impact workflow, leaders should be able to answer:

• Which actions can the system take without human approval?

• Which conditions require escalation, and who receives the case?

• Which actions must be blocked entirely?

• Who can change a permission, threshold, or decision rule?

• Can you reconstruct a specific decision and show the controls that produced it?

• Can you demonstrate that the resulting records have not been altered?

SAFR is not a binding MAS rule. But its proposed model makes the operating expectation clear: a system that can act autonomously needs defined authority, pre-execution checks, and evidence of what occurred.

The companies that treat those requirements as product architecture will have more than a policy for an auditor or enterprise buyer. They will have a system designed to apply its controls consistently, generate evidence as it operates, and change safely when risk requirements evolve.

Published by NexLayer Content. We write evidence-led thought leadership for B2B FinTech, RegTech, and technical-infrastructure companies.