An AI governance framework is a lifecycle, risk-based operating model that embeds policies and enforceable controls into engineering pipelines, not a document that sits beside them. The immediate move for most organisations is to adopt a structure aligned to the NIST AI Risk Management Framework, the OECD’s due diligence guidance, and the EU AI Act where relevant, then wire it directly into agentic development workflows.
What do the major AI governance frameworks actually require?
Five reference points dominate serious governance discussions, and each one tells you something different about what enterprises are expected to do.
The OECD Due Diligence Guidance for Responsible AI sets out a six-step process for identifying harms, mitigating them, and communicating what was done about it. The NIST AI RMF organises risk management into four functions, voluntary in design but adaptable across sectors. Regulation (EU) 2024/1689, the EU AI Act, is the outlier in the group: mandatory, risk-classified, and backed by documentation and transparency obligations with real penalties attached. ISO/IEC 42001 gives organisations a certifiable management-system standard for AI, the same logic ISO applies to quality and information security. Singapore’s Model AI Governance Framework translates these principles into operational recommendations for internal governance and stakeholder communication.
Read across all five and a shared architecture emerges:
- A risk-based approach that scales controls to the harm a system could cause
- Documentation and record-keeping that can survive external scrutiny
- Defined human oversight at points where machine output carries consequence
- Data governance covering provenance, quality, and lawful use
- Transparency towards the people and businesses affected by the system
The practical implication is unglamorous but decisive: change what evidence you keep, not just what policy you write. An auditor does not want your intentions. They want your logs.
What are the four core functions of AI governance?
NIST’s structure, GOVERN, MAP, MEASURE, MANAGE, gives you something most policy documents lack: a way to check whether governance is actually happening, rather than merely declared.
- GOVERN establishes accountability before anything is built. The artefact is a responsible-use policy with named owners, approval points, and escalation paths, structured along the lines the National AI Centre’s policy guidance recommends.
- MAP identifies context and risk for a specific use case. The artefact is a risk register that classifies each AI system by the harm it could cause if it fails.
- MEASURE quantifies whether the system behaves as intended. The artefacts are test logs, fairness checks, and model cards that record what was evaluated and when.
- MANAGE operationalises response. The artefact is an incident playbook defining what happens when a model drifts, an agent oversteps its remit, or a review gate is bypassed.
None of these functions runs once. NIST is explicit that governance is cross-cutting: it should inform mapping, measurement, and management continuously, not sit upstream of them as a one-off approval. Good governance, in NIST’s framing, is less a checklist and more a standing accountability structure that gets exercised every time a system changes.
Pro Tip: Assign each of the four functions to a named role, not a team. “Engineering” owning MEASURE means nobody owns it. A named steward who signs off test logs every release means somebody does.
How do you stop vibe code drift from occurring in agentic pipelines?
Standalone policies fail against agentic development for a simple reason: an agent does not read your handbook before it opens a pull request. If governance lives only in a PDF, it has no mechanism to intercept what the agent actually does. That gap is where vibe code drift creeps in, machine-generated code accumulating small deviations from your standards until nobody can say with confidence what shipped or why.
The fix is policy-as-code: rules expressed as automated checks that fire regardless of whether a human or an agent produced the change under review. Four controls do most of the work:
- Review gates that apply the same acceptance criteria to agent-generated pull requests as to human ones
- Automated policy checks in CI that block merges failing security, licensing, or style rules before a reviewer ever looks
- Provenance logs that record which agent, model version, and prompt produced a given artefact
- Drift detection that flags when model or agent behaviour diverges from its validated baseline
Human oversight thresholds should scale with risk rather than apply uniformly. A low-risk internal tool might tolerate autonomous merges with post-hoc review. A payments-adjacent service should require human sign-off before any agent-authored change touches production, with automated escalation the moment a change exceeds a defined risk score.
Pro Tip: If your CI pipeline cannot tell you which commits were agent-authored, you do not have oversight, you have a blind spot with a dashboard. Our architecture piece on governance-first agentic patterns covers how to instrument this without slowing delivery to a crawl.
What documentation do regulators and auditors expect?
The EU AI Act’s obligations scale with a system’s risk classification, and high-risk systems carry the heaviest burden: technical documentation, a public-facing summary, and evidence that fundamental-rights protections were considered before deployment, not retrofitted after a complaint. Our breakdown of the Act’s practical obligations covers how engineering teams map their existing work against it.
Three artefact categories matter most in practice:
- Model cards recording training data sources, known limitations, and intended use boundaries
- Data provenance records tracing where inputs came from and under what licence or consent basis
- Test logs showing what was evaluated, by whom, and against which acceptance thresholds
Human oversight needs to be visible, not assumed. If a reviewer signed off a model update, that approval should exist as a timestamped record an auditor can pull without asking engineering to reconstruct it from memory.
How do you start an AI governance programme this quarter?
Momentum beats perfection here. A governance programme that launches with a narrow pilot and real evidence outperforms one still drafting its charter in month six.
- Assign ownership. Name a governance sponsor, a risk owner, and an engineering steward, three distinct people, not one person wearing three hats.
- Draft the policy. Write a responsible-use policy covering approved tools, approval points, and escalation paths.
- Pick a pilot. Choose one use case, low enough stakes to tolerate mistakes, real enough to generate genuine evidence.
- Set KPIs. Define acceptance criteria before the pilot starts, not after you see the results.
- Instrument the pipeline. Add review gates and provenance logging so evidence accumulates automatically.
- Run, capture, scale. Execute the pilot, document outcomes, then expand based on what the evidence shows.
| Step | Owner | Primary artefact |
|---|---|---|
| Assign roles | Executive sponsor | Governance charter |
| Draft policy | Risk owner | Responsible-use policy |
| Run pilot | Engineering steward | Pilot scorecard |
| Scale | Governance sponsor | Programme roadmap |
What does governance-first agentic delivery look like in practice?
Dedicated engineering teams are built to treat governance as a build requirement, not an afterthought bolted on before an audit. This involves review gates applied uniformly regardless of whether code was human- or agent-generated, policy-as-code enforced in the pipeline rather than described in a wiki, and visibility into what agents did at every stage of the SDLC, from requirements through deployment.
The engagement path may be sequenced as:
- Consultancy to understand technical stacks, compliance obligations, and high-value agentic AI use cases
- A pilot to demonstrate performance under real constraints before scaling
- Embedding team structure and guardrails into existing workflows
- Scaling from evidence with the option for direct ownership once proven
Our case study on AI across the engineering SDLC walks through how this sequencing plays out on a live delivery pipeline.
Where does AI governance usually go wrong?
Most failures share a shape: a policy document exists, but nothing in the pipeline enforces it. Ownership sits with a committee that meets quarterly, which means the gap between an incident and a response can run to months.
Three durable practices fix most of this. Fold AI governance into risk structures you already run, rather than inventing a parallel bureaucracy. Automate enforcement wherever possible, because a rule a human has to remember to apply is a rule that gets skipped under deadline pressure. Measure outcomes, not intentions, so you can tell whether the programme is working rather than merely existing.
Three red flags are worth watching for specifically. Nobody can name who owns a specific risk category. Review gates exist for human-written code but not for agent output. Incident response depends on someone noticing a problem rather than a system flagging it automatically. Any one of those three, on its own, means the framework is decorative.
— Cleverbit
How does Cleverbit help you operationalise this?
There are other routes to AI governance, in-house policy teams, generic consultancy engagements, or standalone audit exercises that produce a report and leave enforcement to you. Cleverbit takes a different route: we build the engineering team and the guardrails together, so governance is not a separate workstream competing for the same sprint capacity as delivery.
That means governance-first agentic teams structured around your existing engineering standards, review gates that apply identically to agent and human output, and a pilot-first path that proves the model before you commit to scaling it. Our AI Engineering Maturity Scorecard gives you a starting benchmark of where your current pipeline stands against these controls.
If you are weighing whether to build this in-house or bring in a team that has already solved the enforcement problem, start with our AI Software Delivery page and request a consultation to map your specific pipeline against the controls this article covers.
Sources
For primary-source verification, consult the EU AI Act text, the NIST AI RMF, the OECD due diligence guidance, and Singapore’s Model AI Governance Framework. For the productivity case behind governed AI adoption, see this analysis of AI’s measured returns for agencies.
- OECD — Due Diligence Guidance for Responsible AI (Feb 2026)
- NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- European Parliament — EU AI Act (Regulation (EU) 2024/1689)
- IMDA — Model AI Governance Framework (Second edition)
- National AI Centre (Australia) — Create an AI policy