Policies are not governance
Almost every organisation deploying AI now has an AI policy. Many have several: an acceptable use policy from IT, an ethics statement from the communications team, a model risk standard from the risk function, and a procurement checklist that mentions AI somewhere in its third annexe.
What far fewer organisations have is the ability to answer a simple question: for a given AI system in production, who decided it was acceptable, on what evidence, and against which criteria?
That question is the difference between having policies and having governance. A policy states an intention. Governance is the machinery that turns the intention into a decision, the decision into a control, and the control into evidence that someone independent can examine.
The traceability test
A useful way to assess governance maturity is to pick one AI system and trace it in both directions.
Trace downward from the board. The board has approved some statement of risk appetite for AI. Can you follow that statement to a specific threshold, applied to a specific model, checked at a specific point in the lifecycle? In most organisations the trail goes cold within two steps.
Trace upward from the system. A model in production produces performance metrics, fairness test outputs, and drift monitoring data. Does any of that reach a governance forum with the authority to act on it? Usually the data exists and stops at the team that generated it.
Governance is what closes both directions. Without it, the board governs an abstraction and the engineers govern a system, and neither is governing the same thing.
Four things a working system needs
Defined decision rights. Someone must be accountable for approving each AI system into production, and that person must be distinct from the team that built it. Ambiguity here is not a minor process gap; it is the reason risky systems ship.
Proportionality. Applying the same governance intensity to a document classifier and a credit decisioning model wastes effort on one and under-protects the other. Calibrating controls to risk is what makes governance sustainable rather than performative.
Evidence that outlives the people who produced it. If the justification for a deployment decision lives in a meeting someone remembers, it does not exist. Governance evidence must be recorded in a form an auditor can evaluate two years later.
A route for uncomfortable findings. If bias testing surfaces a problem late in delivery, is there a path for that finding to stop the launch? If not, the testing is theatre.
The orchestration problem
The hardest part of AI governance is not any single discipline. Risk teams know how to assess risk. Security teams know how to threat model. Privacy teams know data protection law. Audit knows how to test controls.
The difficulty is that AI systems fail across all of these domains at once, and organisational structures rarely have anyone whose remit spans them. A model can be secure and still unfair. It can be lawful and still unreliable. It can pass every individual review and still be inappropriate for the decision it has been given.
Someone has to hold the whole picture. That role is a knowledge problem before it is a structural one, which is why professional competence across the full governance landscape matters more than any particular reporting line.
Where to start
Organisations early in this work often try to build the complete architecture first. That rarely survives contact with delivery pressure.
A more reliable sequence is to establish an inventory of AI systems, classify them by risk, define what "approved for production" means for the highest-risk tier, and then work outward. An inventory is unglamorous, but you cannot govern a portfolio you cannot enumerate.
The RESAIA Framework describes the full architecture, and the Body of Knowledge sets out how the governance domains connect. Both are worth reading before designing a governance function, if only to avoid rebuilding something that already has a well-tested shape.
