Ask three people in the same organisation what is required before an AI tool can go live and you will get three different lists. Ask when the work should start and almost everyone says earlier than it did.
Governance is the most common cause of a stalled AI roll-out, and it is rarely because the work is hard. It is because nobody enumerated it at the start, the documents were produced in sequence when most could have run in parallel, and each one revealed a dependency on the last.
So here is the enumeration. Nine documents, what each covers, who owns it, and what it blocks.
The nine
1. Data protection impact assessment. Owned by the data protection officer, with substantial input from the service. Covers the data flows, the lawful basis, necessity and proportionality, risks to individuals and the mitigations applied. This is the document most organisations think is the assurance pack. It is roughly a fifth of it.
2. AI-specific risk assessment. Distinct from the DPIA and frequently missing. Where the DPIA asks whether processing personal data is lawful and proportionate, this asks how the system behaves: accuracy in your conditions, known failure modes, performance variation across different user and speaker groups, what happens when it is wrong, and how human oversight is designed to catch it. Owner is usually a risk function or an AI governance lead.
3. Security assessment and supplier due diligence. Certifications, penetration testing evidence, the sub-processor list, processing and storage locations, encryption, access control, and what the supplier's own staff can reach under what circumstances. Owned by information security.
4. Accessibility assessment. An independent conformance assessment with a date on it and a list of known gaps, plus your own testing with disabled and neurodivergent colleagues on the actual task. Owned by an accessibility lead where one exists, and orphaned where one does not, which is why it is so often late.
5. Records and retention decision. Owned by records management. What is the record, what is transient, how long each is kept, and - for anything involving captured audio or source material - whether the source is retained at all once the output is approved. Retention decisions have cost and disclosure consequences, so this is not administrative tidying.
6. Entitlement and access model. Who can use the tool, on whose data, for which workloads, and how that is enforced rather than merely stated. Owned jointly by IT and the service. This is the document that gets thinnest and causes the most trouble later.
7. Model change and revalidation policy. What happens when the underlying model version changes: who is notified, what is retested, against what criteria, and who accepts the change. Almost nobody writes this, and it is the difference between a controlled system and one whose behaviour shifts without your knowledge. Owned by whoever will own the service after go-live.
8. Acceptable use and scope statement. What the tool may and may not be used for, in plain language people will actually read. Scope creep is how a narrowly assured deployment becomes an unassured one, and the statement is what makes that visible.
9. Incident, challenge and redress route. What happens when the system gets something wrong and someone contests it - how the challenge is raised, who investigates, what can be reconstructed, and how a correction propagates. In any setting where outputs affect people, this is the document a regulator or ombudsman will ask for.
Alongside those, a benefits and measurement plan, because the baseline has to be taken before deployment and is therefore governed by the same timetable.
What actually blocks what?
Most of this can run concurrently. The dependencies are fewer than the sequencing usually implies.
Start first, because everything references them: the data flow mapping and the entitlement model. Almost every other document restates or depends on these two, so producing them once, properly, saves duplicated effort across the rest.
Run in parallel: DPIA, AI risk assessment, security due diligence and accessibility assessment. These involve different people and different evidence. Running them in series is the single most common cause of a six-month governance timeline, and there is rarely a reason for it beyond nobody having said they could overlap.
Depends on a real decision, not a document: retention. You cannot write the retention schedule until someone decides whether source material is kept, and that is a leadership decision with cost and risk implications rather than a records-management formality.
Can be drafted late but not omitted: model change policy, acceptable use, incident and redress. These describe the operating state rather than the deployment, so they can be written during the pilot - but if they are not in place at go-live you have deployed something nobody knows how to run.
Who signs, and when
The practical failure is not that sign-off is slow. It is that the sign-off route is discovered late.
Establish at the outset which forum approves what, who can approve alone, who requires a committee, and when those committees meet. A monthly board with a papers deadline can add six weeks to a timeline that everyone assumed was a week - and that delay is entirely avoidable if the calendar is known in advance.
Two things worth insisting on. Approvers should see the pack as a set rather than as isolated documents arriving over months, because the risks interact. And approval should be conditional and time-bound, with defined review points - an open-ended sign-off obtained once, for a system whose behaviour changes with every model version, is not a control.
The reuse dividend
This is the argument for doing it properly the first time.
The first assurance pack in an organisation is genuinely slow, because you are inventing the pattern as well as completing it. The second should be considerably faster, and the tenth should be routine - but only if the first was built as a reusable structure rather than a one-off response to one deployment.
Organisations that treat each AI deployment as a fresh governance negotiation do not get faster with practice. The ones that build a standing pattern - template documents, established approval routes, a known evidence set to request from suppliers - find that governance stops being the critical path somewhere around the third deployment. That is a compounding return on unglamorous work, and it is the difference between an organisation that can adopt AI at pace and one that can adopt it once.
At VE3 we work with organisations on the governance, assurance and integration work behind AI deployment at scale. If governance is currently your critical path, we are happy to talk it through. Get in touch with us.
