AI governance: the four records you will be asked for
Whatever jurisdiction you operate in, and whether or not a statute binds you, the questions that arrive are versions of the same four. What are you running. How consequential is each one if it is wrong. Who owns it. And what have you decided you will not do. Europe and South Korea ask these through risk-based law, Singapore through detailed voluntary guidance, and a customer's procurement questionnaire asks them with no legal basis at all. The practical conclusion is that building the four records once is cheaper than tracking each regime separately, and that they have to be written while the work happens. Reconstructing them afterwards produces a document that is technically accurate and obviously retrospective, and the people reading it can tell, because the honest answer to who decided this is either a name and a date or nothing.
One: an inventory of what is running
A table. What the system is, what it does, where it runs, what data it touches, and when it was last reviewed. Nothing more elaborate.
Most organisations cannot produce this, and building it for the first time is itself the finding: it typically surfaces several systems the centre did not know about, built by teams who were not being secretive and simply had no reason to tell anyone. That discovery is worth the exercise on its own.
The maintenance problem is real and has one workable answer: the inventory entry is part of shipping, not a periodic survey. Surveys go stale between rounds and nobody believes them.
Two: a classification by consequence
One column in the same table. If this system is wrong, what happens, and to whom. Three levels is enough for most organisations: it inconveniences someone internally, it affects a customer's experience, or it affects a decision about a person.
That last category is where the heavier obligations concentrate in every regime that has one, and it is worth identifying whether or not you are subject to such a regime, because it is also where reputational damage lives.
The classification has to happen before the architecture, not after. A system whose class requires a human to be able to review and override an outcome has to be built so the reviewer can see the basis for it, which is a different retrieval and logging design from one that simply returns an answer.
Three: a named owner per system
A person, not a team and not a function. Systems owned by teams decay, because watching them is nobody's Tuesday and the evaluation run that would catch a degradation is nobody's responsibility in particular.
The owner's job is small and specific: know that the system is still working, know when it was last checked, and know who to tell if it is not. It is perhaps an hour a month per system, and its absence is the single best predictor of a system that has quietly got worse.
Four: what is not permitted
The only one that has to exist before the first deployment, and the one most often written badly by being written at length.
Three specific prohibitions everyone knows are worth more than twelve pages nobody opens. The ones most organisations need: no system takes an irreversible action without a person approving it, no customer or employee data leaves the environments on this list, and no system participates in a decision about a person without being classified first.
Specific and enforceable beats comprehensive. A prohibition that engineers cannot apply without asking a lawyer will be applied by not asking anyone.
What changes once a system can act
Everything above assumes a system that produces output a person reads. Once it takes actions, two things have to be added to the record: what the system is permitted to do, and which of those actions cannot be undone.
Singapore extended its published framework to agentic systems from January 2026, which is a reasonable signal about where expectations are heading everywhere. The practical requirement is unglamorous: for each system that can act, a written list of its permissions and an explicit decision about irreversible actions, with a name and a date on it.
The failure mode: governance as a gate
A function that exists to approve things, and that is slow, gets routed around. Work continues, systems ship, and nothing reaches the people whose job is to know. The organisation then has worse visibility than one with no governance function, because it believes it has coverage.
What works is making the compliant path the fast path. A default architecture that is pre-approved, a short form for the ordinary case, and a real conversation reserved for the genuinely unusual. Teams take the fast path because it is faster, and that is the only enforcement that scales.
The test is simple and uncomfortable: ask three engineers what the rules are. If they can answer, governance is working. If they say they would have to look it up, it is not, whatever the policy document contains.
Start with the inventory
If you are not sure what your organisation is running, that is the first conversation and it is usually shorter than people expect. We will tell you what we would want in place before deploying anything else.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
