AI governance in practice — the operational, engineering-facing companion to AI Governance for Engineers (which covers the concepts): how to make governance actually run. The governance operating model (governance fails from an ownership gap, not missing principles; decision rights and accountability via the three lines of defense; named roles laddering to an executive owner; the mechanisms that give them teeth — an AI system registry, risk tiering, lifecycle gates), model risk management for AI (borrowing finance's proven MRM/SR 11-7 lifecycle — documented development, independent validation, risk-tiered approval, ongoing monitoring, revalidation/retirement — reframing each AI system as a managed risk position, and how AI stresses it with opacity, un-inspectable foundation models, open-ended generation, and scale), governing agentic AI (when the model can act, a wrong action escapes into the world; least privilege for tools/data, human-in-the-loop for consequential actions, bounded execution, agent identity, fail-safe defaults, action audit trails), governance as code (a policy in a PDF is advisory and fails at scale; make it imperative — version-controlled executable rules that run automatically and fail closed; a policy engine like OPA; what to encode as gates vs what needs human judgment), evaluation gates and evidence (can you stop a failing system, and can you prove the checks happened? gates that fail closed with teeth and legitimacy, and the automatic audit trail governance-as-code produces for regulators, auditors, and incidents), the EU AI Act in practice (a risk-based law — classify first, then high-risk obligations translate into concrete controls a mature program already runs; read the law as a specification, not theater; build to principles so you generalize to NIST RMF and future laws), monitoring and accountability in production (governance can't stop at deployment — drift, continuous bias, safety violations, with thresholds tied to action; durable owners, AI incident response, traceability, and redress for affected people), and standing up a governance function (from zero: visibility first — inventory, risk-tier, minimal owner-assigning policy — then controls highest-leverage-first in runnable layers, making governance an enabler that accelerates trustworthy AI). Grounded in Wikipedia (three lines of defence, regulation of artificial intelligence, model risk, algorithmic accountability, software agent, AI safety, infrastructure as code, audit trail, Artificial Intelligence Act, concept drift).
AI governance fails most often not because an organization lacks principles, but because nobody owns them. Fairness, safety, and accountability are everyone's job in the abstract and no one's job in practice, so they fall through the cracks between data science, legal, risk, and engineering. This series is about governance as an operating model you can actually run — and it starts with the unglamorous foundation: clear ownership, defined roles, and the mechanisms that turn good intentions into enforced practice.
AI governance fails from an ownership gap, not an absence of principles. The operating model: decision rights and accountability via the three lines of defense, named roles laddering to an executive owner, and the mechanisms that give them teeth — an AI system registry, risk tiering, and lifecycle gates.
Banks have managed the risk of models being wrong for decades, under a formal discipline called model risk management. AI didn't invent the problem of a model that's confidently incorrect — it industrialized it. The good news is that a mature, battle-tested framework already exists, and adapting it to machine-learning and LLM systems is one of the highest-leverage moves in AI governance. This post is about treating "the model might be wrong" as a managed risk, not a hope.
Banks have managed 'the model might be wrong' for decades under model risk management (SR 11-7). Its lifecycle — documented development, independent validation, risk-tiered approval, ongoing monitoring, revalidation/retirement — maps onto AI, which then stresses it with opacity, un-inspectable foundation models, open-ended generation, and scale.
Governing a model that answers questions is hard; governing one that takes actions is a different problem entirely. Agentic AI — systems that plan, call tools, and execute steps toward a goal with limited human oversight — moves AI from producing outputs to producing consequences. The governance frameworks built for predictive models and even for chatbots don't fully cover an agent that can send an email, move money, or modify a system. This post is about the controls that specifically matter when AI can act.
Governing a model that answers is hard; governing one that acts is a different problem — a wrong action escapes into the world. Why agents break the usual frameworks, and the controls that bound authority and consequences: least privilege, human-in-the-loop for consequential actions, bounded execution, agent identity, and fail-safe defaults.
A governance policy written in a PDF is a suggestion; a policy written as code is a control. The difference between the two is the difference between hoping teams comply and knowing they do, because the policy runs automatically and blocks what violates it. Governance as code applies the lessons of infrastructure-as-code and policy-as-code to AI governance — turning principles into executable, version-controlled, automatically-enforced checks. This post is about making governance something the system does, not something a document asks for.
A policy in a PDF is a suggestion; a policy as code is a control. Governance as code makes policy imperative — version-controlled, executable rules that run automatically at deploy, at runtime, and at registration, failing closed on what matters. What you can encode as gates, and what still needs human judgment.
Two questions separate real AI governance from theater: can you stop a model that fails its checks from reaching production, and can you prove, after the fact, that the checks were done? The first is an evaluation gate; the second is evidence. Together they turn governance from a set of good intentions into something enforceable and auditable. This post is about the mechanics of gating AI systems on quality and automatically capturing the proof that it happened.
Two questions separate governance from theater: can you stop a model that fails its checks, and can you prove the checks happened? Evaluation gates that fail closed (with teeth and legitimacy), and evidence — the automatic audit trail that governance-as-code produces for free — for regulators, auditors, and incident reconstruction.
The EU AI Act is the world's first comprehensive AI law, and for engineers it is neither as scary nor as vague as it first appears. Underneath the legal language is a risk-based structure that translates into a concrete checklist of engineering obligations — and most of them are things a good governance program (this series) already does. This post is about reading the Act the way an engineer should: not as compliance theater, but as a specification of controls you can implement.
The EU AI Act is risk-based, so your first job is classification — then the high-risk obligations translate into a concrete checklist most mature governance already does: risk management, data governance, documentation, logging, human oversight, robustness, conformity assessment. Read the law as a specification of controls, not compliance theater.
Governance that stops at deployment governs the wrong moment. An AI system's real behavior — and its real risks — emerge in production, over time, as the world drifts and users do things no test anticipated. Post-deployment governance is the discipline of watching systems in the wild, catching when they go wrong, and maintaining a clear line of accountability for what they do. This post is about governance as an ongoing operational practice, not a launch checklist.
Governance that stops at deployment governs the wrong moment — risk emerges in production as the world drifts and users find the edges. Monitoring the governance-relevant signals (drift, continuous bias, safety) with thresholds tied to action, plus accountability for a system's whole life: durable owners, AI incident response, traceability, and redress.
Every idea in this series is worthless until someone builds the function that runs it. The most common failure in AI governance isn't picking the wrong framework — it's never getting past the framework to an operating capability, or building such a heavy one that the organization routes around it. This closing post is a practical path from zero: what to build first, how to make governance an enabler rather than a blocker, and how to grow the function as AI adoption grows. It turns the series into a plan.
Every idea in the series is worthless until someone runs it. A practical path from zero: start with visibility (inventory, then risk-tier, then a minimal owner-assigning policy), build controls highest-leverage-first in runnable layers, and make governance an enabler — the easy path — so it accelerates trustworthy AI rather than blocking it.
This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.