Build AI governance into the delivery control plane

AI governance fails when it exists only as a policy document reviewed before launch. Controls must be attached to the same delivery path that versions models, prompts, data, tools, permissions, and application code.

Inventory the system

Maintain a record for each AI-enabled capability: owner, purpose, affected users, model and provider, data classes, retrieval sources, tools, evaluation suite, human oversight, risk tier, and current deployment. The inventory should describe the complete application, not only a model identifier.

Connect that record to source, build artifacts, approvals, incidents, and production telemetry. Evidence should be generated by normal engineering work rather than reconstructed for an audit.

Match controls to risk

A private drafting assistant and an automated eligibility decision should not share the same review path. Define tiers using impact, autonomy, data sensitivity, scale, reversibility, and external obligations. Higher-risk systems may require independent evaluation, security testing, legal review, explicit human decision authority, or stronger release gates.

The NIST AI Risk Management Framework provides a useful structure through Govern, Map, Measure, and Manage. Translate those functions into named owners and executable controls within the organisation.

Enforce at delivery time

CI can verify that required metadata exists, approved model endpoints are used, evaluations meet thresholds, dependencies are scanned, and policy exceptions have not expired. Runtime gateways can enforce identity, allowed models, data-handling rules, rate limits, logging, and emergency disablement.

Controls must preserve developer feedback. A failed gate should state what evidence is missing, why it matters, and how to resolve or appeal it. Opaque governance encourages bypasses.

Monitor change

Models and external services can change without an application commit. Track provider versions, safety settings, retrieval data, tool definitions, and policy configuration. Define which changes trigger re-evaluation and who can approve them.

Record incidents and near misses in the same operational system as other production risks. Feed observed failures back into evaluation and policy.

Governance is strongest when it makes safe delivery routine. The control plane should provide traceability and proportionate constraints while leaving product teams with a clear, supported path to ship useful systems.

Define evidence by lifecycle stage

During discovery, record intended users, decision impact, data sources, and prohibited uses. Before development, assign a risk tier and control owner. Before release, attach evaluation results, threat model, privacy assessment, human-oversight design, rollback plan, and operational objectives. In production, retain version, incident, monitoring, and change evidence.

This evidence should be addressable by stable identifiers. A deployed capability can then point to the exact model configuration, prompt, retrieval index, tool set, evaluation run, approval, and application version that produced it.

Separate policy from enforcement

Policy states the required outcome—for example, sensitive data must not be sent to an unapproved model endpoint. Enforcement may occur through network controls, an AI gateway, data classification, CI policy, and runtime monitoring. Map each policy to one or more controls and each control to observable evidence.

Avoid a single central gateway becoming an unreviewed source of broad access. The gateway itself needs workload identity, tenant isolation, rate limits, versioned policy, failure behavior, and objectives.

Operate exceptions

An exception should name the unmet control, reason, affected system, compensating measures, approver, expiry, and remediation owner. Expired exceptions must fail visibly. Analyse repeated exceptions: they may reveal an impractical policy, missing platform capability, or risk the organisation has implicitly accepted without deciding.

Governance checklist

Confirm complete system inventory, explicit owners, risk classification, evidence-linked releases, approved data and model boundaries, independent review for high-impact use, runtime disablement, incident handling, change triggers, and time-bounded exceptions. Measure time to satisfy controls, recurring failure reasons, overdue reviews, and production outcomes—not only how many systems received approval.