How to Build an AI Governance Policy: Template

1. EU AI Act Article 17 requires providers of high-risk AI systems to establish a quality management system covering risk management, technical documentation, data governance, and monitoring. Applicable from 2 August 2026.
2. UK GDPR Article 22 applies to AI systems making solely automated decisions producing legal or similarly significant effects on individuals. Organisations must provide the right to human review, to express a view, and to contest the decision.
3. Under SM&CR, named Senior Managers bear personal accountability for AI governance failures where AI systems influence regulated financial services activities.
4. ISO 42001:2023, published December 2023, is the first international management system standard for AI. It provides a certifiable governance framework applicable to any organisation using AI, in any sector.
5. EU AI Act penalties for violations of prohibited AI provisions (Article 5): up to EUR 35 million or 7% of global annual turnover, whichever is higher.

An AI governance policy does five things for an organisation. It establishes scope: which AI systems, use cases, and parts of the organisation are covered. It defines accountability: who owns governance decisions at each level. It sets the risk appetite: what AI uses are acceptable, conditionally acceptable, or prohibited.

It creates a process: how systems are approved, monitored, and decommissioned. And it provides an evidence trail that regulators and auditors can inspect.

The policy is the governance layer. It sits alongside data protection, information security, and employment policies rather than above them. Its value is in what it makes possible operationally: a consistent basis for making, documenting, and reviewing decisions about AI across the organisation. Day-one exhaustiveness matters less than day-one credibility.

Each element maps to a governance requirement that regulators and auditors will look for. An organisation that can evidence all seven has the foundation for a defensible position under scrutiny.

Scope: The Most Commonly Underspecified Section

Scope is where most first-draft policies are weakest. A statement like "this policy applies to all AI systems" fails if the policy does not define what counts as an AI system, which business units are covered, or whether third-party tools fall within scope. Your scope section should address four things: a definition of AI for the purposes of this policy (including whether it covers narrow or task-specific AI, generative AI, and automated decision-making systems); organisational coverage (which legal entities, subsidiaries, or functions); third-party AI (vendor-supplied tools and SaaS products); and any exclusions, with reasons documented.

The gap that costs most: policies covering internally developed AI that say nothing about the AI embedded in the procurement, HR, and finance platforms already in daily use. That is where most regulatory exposure sits, and it is what auditors look for first.

Risk Classification That Actually Works

AI systems carry different levels of risk. A classification framework allows the organisation to apply governance proportionate to that risk: lighter-touch oversight for low-risk tools, rigorous controls for high-risk applications. The process should scale accordingly: a meeting transcription tool needs lighter scrutiny than an AI-assisted lending decision engine. A three-tier model works for most organisations.

Whatever tiers you use, they need to be operationally useful: a team requesting approval for a new AI tool should be able to self-assess which tier applies, and that assessment should be defensible if questioned.

Naming Who's Accountable (and Who Can Act)

Accountability structures fail when they describe oversight without assigning authority. The accountability section should define: who holds overall policy ownership (the CISO, CRO, or a designated AI governance lead); board or executive-level accountability, including whether there is a formal AI governance committee; business unit responsibilities (who is accountable for AI use within each function); technical accountability (who owns model quality, data quality, and deployment decisions); and what is expected of any employee using AI tools.

For regulated organisations, this section needs to map to existing frameworks. Under SM&CR, AI-related risks influencing regulated activities may need to be assigned to an approved person. The specific decision rights are what make accountability functional: who can approve a Tier 1 system, who can escalate a governance concern, and who can suspend use pending investigation.

The AI Use Approval Process

The approval process is the gate an AI system must pass before deployment, proportionate to its risk tier. A credible process covers seven stages:

1. Initial triage: classify the system against the risk tiers.
2. Impact assessment: document intended use, affected individuals or decisions, data inputs, and potential failure modes.
3. Legal and compliance review: confirm alignment with UK GDPR, sector regulation, employment law, and applicable AI-specific rules.
4. Security and data governance review: confirm data handling, access controls, and vendor due diligence where applicable.
5. Approval decision: documented by the appropriate authority with rationale.
6. Conditions of use: any restrictions, mandatory human oversight requirements, or monitoring obligations.
7. Registration: addition to the AI register.

For Tier 3 systems, steps 2 through 4 can be compressed into a short self-assessment form. For Tier 1, each step requires formal documented sign-off.

The failure mode to avoid: an intake stage with no recorded output. Teams submit an assessment form, but there is no decision, rationale, or conditions attached. That produces a paper trail that looks like governance but will not support an audit.

Maintaining an AI Register

An AI register is the single source of truth for what AI systems are in use across the organisation. Without one, there is no basis for risk reporting to governance bodies and no reliable way to confirm that all AI in use has been approved. The register should capture: system name and version; owner; risk tier; approval date and the authority that granted it; conditions of use; scheduled review date; and current status.

When a system is retired or replaced, the register entry should reflect that with the deregistration date and reason. An AI register that grows without deregistration stops being a live inventory and becomes a historical log; the two serve different governance purposes.

Audit, Evidence, and Ongoing Monitoring

An approval event creates governance at the moment of deployment. Ongoing monitoring creates governance across the lifecycle. Both are what regulators and auditors assess. This section of the policy should specify: what must be logged (decisions made by or with AI assistance, human review actions, model updates, and data changes); how long logs are retained, aligned with your data retention policy and applicable legal requirements; who reviews audit outputs and how frequently; and what triggers an out-of-cycle review.

Triggers for out-of-cycle review include significant model changes, data drift, complaints, or regulatory developments. For high-risk AI systems, build in a periodic performance review against defined fairness and accuracy benchmarks. The ICO expects to see evidence that monitoring findings are reported to governance bodies and acted on, not just recorded.

Responding to AI Incidents

AI systems fail in ways that are harder to predict and diagnose than traditional software. An incident response section should cover what happens when something goes wrong, including near-misses and suspected failures. Define: what constitutes an AI incident (discriminatory outputs, unexplained decisions, data exposure, and model manipulation); how incidents are reported, to whom, and within what timeframe; initial response actions, including whether the system should be suspended pending investigation; investigation process, evidence preservation, and findings documentation.

Include the regulatory notification circumstances (UK GDPR, financial regulation, or AI-specific rules) and require a post-incident review with documented findings. The section most often copied from IT security policies with AI-specific failure modes stripped out: AI incidents often accumulate slowly from decisions rather than presenting as a discrete event. The incident definition needs to reflect that.

An AI governance policy that is not regularly reviewed becomes a liability. The AI regulatory landscape, the risk profile of AI systems, and the tools themselves change faster than most governance cycles anticipate. Review the policy at minimum: annually as a scheduled review covering all sections; when significant new AI systems are deployed or retired; when relevant regulation changes (including guidance updates from the ICO, FCA, or EU bodies); and following a material AI incident.

Document the review process: who conducted it, what changed, and why. A policy with a revision history demonstrates active governance. Organisations waiting for a fixed annual date to review should also build in a standing agenda item on the AI governance committee's quarterly cycle, covering any significant changes to the AI landscape since the last full review.

These are the gaps that emerge most often when organisations build their initial AI governance policy.

Adapt this template for your organisation. Involve your legal, compliance, and risk teams before finalising. Each section below includes guidance on what to cover and, for Section 1, sample text you can edit directly.

Document Control

Section 1: Purpose and Scope

Describe why this policy exists, what it governs, and its relationship to other policies. Define "AI system" for your organisation's context.

List which entities, subsidiaries, or functions are in scope. State whether vendor-supplied AI tools fall within scope. Include any exclusions.

Sample text: "This policy governs the deployment, use, and oversight of artificial intelligence systems within [Organisation Name]. For the purposes of this policy, an AI system is any machine-based system that processes inputs to generate outputs (including predictions, recommendations, decisions, or content) using techniques such as machine learning, deep learning, or large language models. This policy applies to [list entities/functions in scope] and covers both internally developed systems and AI capabilities supplied by third parties."

Section 2: Risk Classification

Define your risk tiers. A three-tier model (High, Medium, Low) works for most organisations. Map each tier to its governance requirements.

Provide enough description that a team can self-assess their AI use case. Reference the EU AI Act prohibited and high-risk categories where relevant.

Section 3: Accountability and Governance Structure

Assign ownership by role, not individual. Define the governance body responsible for policy oversight. Specify decision rights at each level: who can approve a high-risk AI system, who can escalate, who can suspend use.

Include employee responsibilities. For SM&CR firms, map AI-related risks to approved persons where AI influences regulated activities.

Section 4: AI Use Approval Process

Describe the process an AI system must pass through before deployment. Specify what is required at each of the seven stages and what documentation must be produced. Differentiate the process by risk tier. The output of approval must be a documented decision, conditions of use, and registration in the AI register.

Section 5: AI Register

Specify that an AI register must be maintained and define what it must contain: system name, owner, risk tier, approval date, conditions of use, review date, and current status. State who is responsible for maintaining it. Include a requirement for deregistration when systems are retired.

Section 6: Audit and Monitoring

Define what must be logged, how long logs are retained, and who reviews them. Specify review frequency by risk tier. Define what triggers an out-of-cycle review. Specify how monitoring findings are reported to governance bodies and what follow-up is required.

Section 7: AI Incident Response

Define what constitutes an AI incident, including gradual failures and disputed outputs. Specify reporting channels and timescales. Define initial response actions and the investigation process. Include regulatory notification requirements and mandate a post-incident review with documented findings.

Section 8: Employee Responsibilities and Acceptable Use

Define what is expected of employees using AI tools: approved tools only, prohibited use cases (such as entering personal data into public AI tools), and responsibilities for reporting concerns. Reference your training and awareness programme and specify consequences for policy breaches.

Section 9: Policy Review

State review frequency, triggers for out-of-cycle review, who conducts the review, and how changes are communicated. Require version control and a revision history. A policy with a documented revision history demonstrates active governance rather than a document written once and left unchanged.

A well-structured AI governance policy does not require building an entirely new infrastructure. For organisations that already operate a GRC programme, the foundations are in place: risk registers, control libraries, evidence collection, audit trails. AI governance extends that infrastructure to a new risk domain.

Building an auditable, defensible AI governance framework covers the operational controls that sit behind the policy: what an AI inventory looks like in practice, how pre-deployment assessments are run, and what audit trail structures satisfy regulatory scrutiny. The AI governance regulations article maps the specific obligations under the EU AI Act, FCA guidance, and ICO requirements that your policy needs to address.

ISO 42001:2023, the international management system standard for AI governance, provides the most structured implementation pathway for organisations that want their policy backed by a certifiable framework. Its clause structure maps directly to the seven policy elements above, and certification provides independent verification of governance maturity.

Gracie AI Agents with Personas and Skills automates the evidence collection and monitoring work that an AI governance policy demands at scale. On SureCloud's compliance management platform, AI register entries run as risk register items, approval workflows are tracked against control objectives, and monitoring outputs are captured as continuous control evidence with the audit trail built into the workflow from day one.