By 2026 most legal teams have an AI use policy - rules for individuals about approved tools and verification. Far fewer have an AI governance policy: the organisational layer that says who owns the tool inventory, how a new system gets classified and approved, who watches for incidents, and how the whole arrangement is evidenced to a regulator, a client audit, or an insurer. The EU AI Act makes that layer worth writing down now - its duties land on the organisation, not the individual. This guide, a spoke of our EU AI Act timeline pillar, walks a template you can adapt section by section.
This template is legal information, not legal advice, and a starting point rather than a finished policy - adapt it with advice on your own regulatory position.
Governance policy vs use policy: you need both
The direct answer to "what should an AI governance policy include": eight sections - purpose and scope, roles and ownership, the system inventory, classification and approval, data and confidentiality rules, oversight and verification, literacy and training, and incidents plus review. Each section exists to evidence a duty someone else will one day ask about.
Keep the governance policy distinct from the use policy. We covered the individual-facing document in our AI use policy walkthrough; that document is short, behavioural, and read by everyone. The governance policy is structural and read by the people who run the programme. Merging them produces a document too long for daily use and too shallow for audit - the classic failure mode of first-generation AI policies.
Why the policy is due now, not December 2027
Three clocks argue against waiting for the high-risk wave. First, two AI Act duties already bind every deployer: the prohibited-practices screen and the Article 4 literacy duty, both in force since February 2025 - a governance policy is where those live. Second, from 2 August 2026 the Act's enforcement machinery goes live and Article 50 transparency attaches to client-facing chatbots and published AI content; somebody has to own those duties by name. Third, the questions are already arriving from the market: client outside-counsel guidelines and vendor audits increasingly ask for the firm's AI governance documentation, and professional-duty guidance points the same way - see our survey of bar guidance on competence and supervision.
The Digital Omnibus's deferral of high-risk duties to December 2027 changes the deadline for the heaviest section of the policy, not the existence of the policy. Writing it now, with the high-risk provisions drafted and dormant, is cheaper than writing it under a regulator's letter.
The template: eight sections that do the work
- 1. Purpose and scope. One paragraph: the policy governs all AI systems used in the organisation's work, including AI features inside existing software, across all offices - with the EU footprint called out.
- 2. Roles and ownership. A named senior owner; a standing group covering risk, IT or security, data protection, and practice; and the rule that no AI system enters use without passing through this policy.
- 3. System inventory. A living register: system, vendor, role (provider or deployer), intended purpose as documented, users, data touched, and classification. The inventory is the policy's foundation - every other section refers to it.
- 4. Classification and approval. The screening sequence from our classification guide: prohibited-practices check, Annex III mapping, Article 50 flags, recorded conclusion per system, and the approval gate for new tools and new uses of old tools.
- 5. Data and confidentiality rules. What client and personal data may enter which systems, on what legal basis, with vendor commitments (training use, retention, residency) recorded per system.
- 6. Oversight and verification. The human-in-the-loop rules: outputs verified against sources before reliance, named oversight for anything consequential, and escalation paths with authority to suspend a system.
- 7. Literacy and training. Role-tiered training mapped to actual use, with completion recorded - the Article 4 evidence file.
- 8. Incidents, logging, and review. What counts as an AI incident, who is told, what logs are kept and for how long, and the review cycle for the policy and its registers.
Two drafting rules keep the document alive. Every section names an owner - a policy without names is a wish. And every section produces an artefact (a register, a record, a report) so that compliance is checkable without interviewing anyone.
Mapping policy sections to AI Act duties
The point of the structure is that each section evidences a legal duty. The mapping below is the one to keep in the policy's annex.
| Policy section | AI Act duty it evidences | In force |
|---|---|---|
| Classification and approval | Article 5 screen; Annex III mapping; Article 25 role control | Prohibitions since Feb 2025 |
| Literacy and training | Article 4 AI literacy measures | Since Feb 2025 |
| Oversight and verification | Article 26 human oversight (high-risk); professional duties generally | Dec 2027 for Annex III |
| Data and confidentiality | GDPR alignment; Article 26 input-data duty | GDPR now; Dec 2027 |
| Incidents, logging, review | Article 26 monitoring, incident reporting, six-month log retention | Dec 2027 for Annex III |
| Inventory; roles | The evidence layer every duty above depends on | Now, in practice |
Legal departments inside banks, insurers, and public bodies should add a ninth section: fundamental rights impact assessments, which their sectors will actually owe - the triggers are in our FRIA vs DPIA guide.
Borrowing from ISO 42001 and the NIST AI RMF
Two frameworks save drafting time. ISO/IEC 42001, the AI management-system standard, supplies the organisational skeleton - policy, roles, risk assessment, operational controls, continual improvement - and is increasingly cited in client audits; certification is a later decision, but aligning the policy's structure costs nothing. The NIST AI Risk Management Framework contributes the risk vocabulary - govern, map, measure, manage - useful for firms with US clients who ask questions in NIST terms.
Neither substitutes for the AI Act mapping: the frameworks are voluntary management scaffolding, the Act is law. The strongest position is a short policy in the firm's own voice, structured so an auditor can trace any section to ISO 42001, NIST, or an AI Act article without translation.
Rollout: making the policy operational
A governance policy becomes real through three mechanics. Populate the inventory first - a week of asking every practice group what tools they actually use, including the unofficial ones, produces the register everything else needs. Run the approval gate on the existing stack, not just new purchases: every current tool gets a classification record, and anything that fails the screen gets a remediation owner and date. Schedule the rhythm: quarterly register refresh, six-monthly policy review, and event-triggered reviews on new tools, new uses, vendor changes, and regulatory milestones - the next being the Article 50 wave on 2 August 2026 and the Annex III wave on 2 December 2027.
Then socialise it. The governance policy earns its keep when a partner can answer a client audit in a day by exporting the inventory and approval records - which is also the moment the effort becomes visibly worth it internally.
Expect the audit pressure to keep rising. Outside-counsel guidelines added AI questions through 2025 and 2026, insurers began asking about AI governance at renewal, and the AI Act gives both a statutory vocabulary to ask in. A policy that maps cleanly to the Act's articles - the table above - lets the firm answer in the asker's own terms, which is the difference between a one-day response and a negotiated questionnaire cycle.
How Judicio supports AI governance
Governance is easier when the tools produce the evidence. Judicio's workspace gives a legal team role-based access with Owner, Editor, and Viewer roles, project-scoped sharing, and an activity trail of who ran what on which files - the raw material of the oversight and monitoring sections. Outputs carry citations to sources so the verification rule in section six is a click rather than a re-research exercise, and client documents are not used to train models, which simplifies the data section. The full feature set is documented alongside our security controls and methodology.
Pair this template with the deployer obligations map for the duties calendar, and with our vendor security questionnaire when section five meets procurement. To see the governance surface first-hand, start a free trial or book a demo; EU-specific context is on the Europe hub.