AI governance checklist: audit-ready for SOC 2, ISO 42001, EU AI Act
Most teams assemble AI governance the week a regulator, customer, or board asks, and by then the finding is already written. Here is what SOC 2, ISO 42001, and the EU AI Act actually want, and the checklist that keeps you ready before the question comes.
5 min readBy Arun Saravanan
The exposure is not that AI makes mistakes
Every model makes mistakes; that is priced in. The exposure that ends careers is different: when a regulator, an enterprise customer, or a board member asks how a specific decision was reached, nobody can answer. The absence of an answer is the finding. It does not matter that the decision was probably fine. Governance is being able to account for it, on demand, in writing.
So the real question is not whether your AI is accurate. It is whether, on the day you are asked, you can produce the record: what was running, what data it saw, what it decided, who was accountable, and what stopped it from doing something it should not. If that record has to be assembled after the question, you have already lost the argument.
What SOC 2, ISO 42001, and the EU AI Act actually ask for
The three frameworks people worry about are asking for the same underlying thing in different vocabularies. SOC 2 is about controls: which ones you operate around access, change, and monitoring, and evidence that they held over a period. It cares less about your AI being clever and more about whether the controls around it are real and documented.
ISO/IEC 42001 asks for an AI management system: a governed, repeatable way of deciding what AI you deploy, how you assess its risks, who is accountable, and how you review it over time. It rewards a system, not a memo written the night before.
The EU AI Act is risk-tiered. Many business uses are limited or minimal risk with light transparency duties, but higher-risk uses carry real obligations: documentation, risk management, human oversight, logging, and traceability. The through-line across all three is the same, an evidence trail that already exists when someone asks for it.
Governance assembled after the fact is theatre
The common pattern is a scramble. The week before a review, a team reconstructs what its AI systems do from memory, screenshots, and hope. What they produce is a snapshot, not a control. It describes what the system was that week, not what it does, and an auditor who has seen it before knows the difference.
The alternative is to make the record a byproduct of running the system rather than a project. An inventory that updates as systems ship. A written basis for each decision, kept current. Runtime controls that actually intervene, so policy is enforced rather than filed. Logs and approvals assembled continuously, so an audit becomes a query against evidence that already exists.
An AI governance checklist you can keep current
You do not need all of this on day one. You need each item to be a byproduct of running the system, not a document you regenerate under pressure.
- A live inventory of every model in use, the data it touches, and the decisions it influences.
- A written, current basis for how each system decides, and what it is explicitly not allowed to decide.
- Risk classification per use case, mapped to the obligations that tier actually triggers.
- Human oversight and escalation built in, so high-stakes decisions route to a person by design, not by luck.
- Runtime controls that enforce policy at the moment of the decision, not a policy document that describes it.
- Continuous logging of inputs, outputs, approvals, and overrides, retained and queryable.
- Rollback, so any automated action can be reversed and re-run under review.
- A named owner for each system and each control.
What a governable AI system looks like
Put simply, a governable system does four things. It knows what is running: a live register of every model, the data each touches, and the decisions each influences. It can explain itself: a plain-language account of how each system decides and what it is not permitted to decide. It escalates: the decisions it should never make alone route to a human by design. And it is reversible: every automated action is logged and can be rolled back.
This is the layer our AI governance system stands up, and it is the same governance layer every Stallwart system ships with. Governance you can produce on the day you are asked is the only kind that counts.
The short version
- The costly exposure is not that AI errs; it is being unable to account for a decision when asked.
- SOC 2, ISO 42001, and the EU AI Act reward the same thing: an evidence trail that already exists.
- Governance assembled the week of a review is a snapshot, not a control, and auditors can tell.
- A governable system knows what is running, explains itself, escalates, and is reversible.
Questions this raises
- When should a company set up AI governance?
- Before it is asked, not after. Governance assembled the week of a review is a snapshot, not a control, and an experienced auditor can tell the difference. The evidence trail has to be a byproduct of running the system, so it already exists when a regulator, customer, or board asks.
- What do SOC 2, ISO 42001, and the EU AI Act have in common for AI?
- They reward the same thing: an evidence trail that already exists. SOC 2 asks which controls you operate and whether they held, ISO/IEC 42001 asks for a managed AI management system, and the EU AI Act asks for documentation, risk classification, human oversight, and logging for higher-risk uses.
- What belongs on an AI governance checklist?
- A live model inventory, a written basis for how each system decides and what it may not decide, per-use-case risk classification, human oversight and escalation, runtime policy enforcement, continuous logging of inputs, outputs, and approvals, rollback, and a named owner for each system and control.
- Does the EU AI Act apply to my AI system?
- It depends on the use case, because the Act is risk-tiered. Many business uses are limited or minimal risk with light transparency duties, while higher-risk uses carry documentation, risk-management, human-oversight, and logging obligations. The practical move is to classify each use case early and map it to the obligations that tier triggers.
- What makes an AI system governable?
- Four properties: a live inventory of what is running, a written basis for how each system decides, escalation of decisions it should not make alone, and reversibility so every automated action is logged and can be rolled back.
Recognize this in your own operation?
Bring us the version of it happening in your business and we will tell you which part a system can take over.