The instinct when starting AI governance documentation is to write a lot of it, and that instinct is wrong in a specific way. Documentation nobody maintains is worse than documentation that does not exist, because it creates a false record that an auditor or a customer will eventually test. Every template here earns its place by being legally necessary, commercially necessary or operationally load-bearing. Each has exactly one owner named as a role, and each is produced by doing the work rather than written about the work afterwards.
Three fields recur as the ones people leave out and later need urgently. Each turns a claim into something somebody else can check.
In the register these are the two fields most often skipped. The first is what you filter on when a provider discloses an incident. The second is what you filter on when a customer asks which systems touch their data. Both questions arrive with a deadline and neither is answerable by reading code.
In the human oversight design, these two reveal nominal oversight faster than anything else. A reviewer with eight seconds per case and a throughput target is not oversight, whatever the process document says. Writing both honestly is uncomfortable and is the single most valuable thing that template does.
In the system card this is the section enterprise reviewers read first, and its absence tells them nobody has characterised the system. Write at least three. A card with no limitations is a worse signal than any individual limitation you could have written down.
Sixteen fields including upstream vendors and data classes. Everything else in the programme derives from it, and it is the only genuinely urgent one.
Even if most rows say missing. Begun early it costs minutes a week; reconstructed before an audit it costs a quarter, and it is the one artifact that cannot be caught up.
Append-only, capped at about 150 words an entry, with a field for who disagreed and why. You are already making decisions and the reasoning is being lost.
System cards, impact assessments and oversight designs per system rather than in a batch, and the response pack built from questions customers have already asked.
Eight. A system register, a system card per elevated-risk system and above, an impact assessment for high-risk systems, a human oversight design, a decision log, risk acceptance records, an evidence index, and a customer response pack. Everything beyond those tends to be written once and abandoned, which is worse than not writing it.
Purpose, intended use, out-of-scope use, users and affected people separately, how it works, data with provenance and legal basis, acceptance criteria, evaluation with the most recent results and date, known limitations, human oversight, disclosure with a screenshot, monitoring, fallback with its test date, and change history.
Week one the register schema, because everything depends on it. Week two the evidence index, even if most rows say missing. Week three the decision log, since you are already making decisions and losing the reasoning. Then system cards, impact assessments and oversight designs per system as they come through the gates.
No, high-risk only, plus anything a statute or customer contract requires. Applied uniformly it becomes a form-filling exercise that degrades until it is worthless. The section worth writing honestly even when awkward is the alternative considered, because assessments presenting AI as unambiguously superior read as advocacy and get the whole document discounted.
Register entries indefinitely, never deleting retired systems. System cards and impact assessments for the life of the system plus your retention period, longer where a statute specifies. Decision log and risk acceptance records indefinitely. Evidence index current plus two years. Statutory and contractual obligations take precedence.
Because an editable log always agrees with the present, which is exactly what an auditor is trained to distrust. If a decision changes, write a new entry referencing the old one. The most valuable field is who disagreed and why, and editing it away destroys the only evidence that judgement was exercised.
Drop your details and we'll send AI Governance Documentation Template straight to your inbox - no spam, unsubscribe anytime.
It is the only artifact in the set that genuinely cannot be caught up later. Work through your documentation set with our engineering leads. A working session, not a sales pitch. SECTION 7 - FAQ - 5 to 8 questions
Talk to our engineers