AI policy template for organisations

Use it as a controlled drafting base, not a document to paste into circulation unchanged. The useful output is a policy whose rules have named owners, supporting procedures and records, and clear triggers for a fresh decision.

Before you copy the template, confirm the following:

• Scope: which AI uses, tools and users are covered?
• Accountable owner: who is responsible for this policy?
• Approved-use process: how are new uses assessed and authorised?
• Risk model: what tiers or criteria apply?
• Data categories: what information may and may not enter AI tools?
• Provider requirements: what security, privacy and contract terms apply?
• Human-review rules: what must be reviewed before output is used?
• Legal and contract duties: what obligations exist in your jurisdictions?
• Incident path: who is notified and what is the response timeline?
• Review triggers: what events require a policy update?

If an answer is not yet known, keep the placeholder visible and assign someone to resolve it. Vague wording can make a draft look finished while leaving staff and approvers to make inconsistent decisions later.

What is an AI policy?

An AI policy is the organisation-wide document that sets the rules for how AI is used. It covers purpose, scope, approved and restricted uses, data handling, human oversight, transparency, security, incidents, exceptions and review. It is an operational artefact that translates governance decisions into actionable rules.

The NIST AI RMF Core supports documented requirements, risk tolerance, defined roles, executive accountability, inventories and third-party risk work. A policy is one way to document those requirements, but a signed policy is not evidence that its controls operate.

The policy should be distinct from the governance framework (which defines the operating model) and from the acceptable-use policy (which sets day-to-day user rules). This template is the umbrella document that connects both.

Decisions to make before using the template

The template contains visible placeholders for organisation-specific choices. Before adapting it, your organisation should decide:

• Which AI tools and services are approved, restricted or prohibited.
• What data categories may enter each tool.
• What level of human review is required for different use types.
• What disclosure or transparency obligations apply.
• What records must be kept and for how long.
• What incident response steps apply.
• What training is required and how often.
• What exceptions process applies.
• What counts as a material change to a tool, provider, data flow or use case.
• Who may accept residual risk or impose conditions at each locally defined level.

No universal list of prohibited data, approved tools, retention periods or review intervals exists. These are local decisions.

A simple decision sheet can make adaptation faster. For each placeholder, record the proposed wording, decision owner, evidence consulted, approval date and change trigger. That gives the policy approver something concrete to review and gives the future policy owner a trail back to the reasoning behind each rule.

Copy-and-adapt AI policy template

The following template is an editorial synthesis. It requires tailoring and is not an official regulator or standards body document.

Purpose and principles

This policy sets the rules for the use of artificial intelligence (AI) tools and services within [Organisation Name]. It applies to [all employees, contractors, and authorised users / specific groups].

The organisation is committed to:

• Using AI in ways that are lawful, ethical and proportionate.
• Protecting personal data, confidential information and intellectual property.
• Maintaining human oversight and accountability for AI-assisted decisions.
• Being transparent about AI use where required.
• Reviewing and updating this policy as AI use and regulation evolve.
• Applying controls that match [Organisation Name]'s defined risk criteria and approved purposes.
• Recording responsibility for AI-assisted work rather than transferring accountability to a tool or provider.

Scope and definitions

This policy applies to:

• All AI tools and services used by [Organisation Name] or its authorised users.
• All data and documents that enter or exit an AI tool.
• All in-scope decisions that are assisted or influenced by AI output.

Out-of-scope uses: [list any excluded research, testing, personal or embedded-product uses and explain which alternative rules govern them].

Key definitions:

• AI tool: [define: e.g., any software system that uses machine learning, natural language processing or generative AI]
• Approved tool: [define: tools listed in the approved tools register]
• Sensitive data: [define: reference your data classification policy]
• Human oversight: [define: the level of review, verification or approval required]
• Use-case owner: [define: the person accountable for the intended use and its operation]
• Material change: [define: changes that require reassessment or approval]

Roles and accountability

• [Executive Sponsor]: accountable for this policy and its implementation.
• [Policy Owner]: maintains the policy, manages updates and answers queries.
• [Use-case Owners]: responsible for AI use within their function.
• [Data Protection Officer / Privacy Lead]: advises on data-protection requirements.
• [Security Lead]: advises on security requirements and controls.
• [Procurement Lead]: manages provider assessment and contract terms.
• [Approval Authority]: accepts, conditions, rejects or escalates uses within [defined authority].
• [Authorised Users]: follow the supporting procedures and report incidents, unexpected behaviour and material changes.

Use the separate governance work to set the policy's governance and decision rights, then insert the locally approved roles here.

Approved tools and use cases

The following tools are approved for use: [list or reference approved tools register].

The following use cases are approved: [list or reference approved use cases].

The following uses are restricted and require prior approval: [list or reference].

The following uses are prohibited: [list or reference].

Each approved entry must identify [service, relevant version or configuration, permitted users, purposes, data categories, conditions, owner and review trigger]. A material provider, model, integration or data-flow change requires [reassessment route] before continued use.

Risk assessment and approval

Before a new AI use is deployed, a risk assessment must be completed. The assessment should cover: intended purpose, affected people, data inputs and outputs, provider and dependencies, plausible harms, inherent risk, controls, residual risk, and decision.

To attach an AI risk assessment, use the organisation's own criteria and keep the assessment record with the eventual decision.

Approval authority: [define who approves at each risk tier].

The decision must state [approved / approved with conditions / redesign required / rejected], the accountable authority, conditions, unresolved risks, evidence relied upon and triggers for reassessment. Completion of the assessment does not itself grant approval.

Data, documents and confidentiality

• Only data classified as [classification level] or below may enter [specific tools].
• Personal data must be minimised: include only what is necessary for the task.
• Confidential and restricted information must not be entered into [specific tools] without prior approval.
• Documents entering an AI workflow must be classified and authorised before use.
• Output containing sensitive data must be handled according to the data classification policy.
• Users must check the current tool-specific handling rules before moving information between systems.
• A change to the document, purpose, recipient or provider triggers [defined review step], including reclassification or reauthorisation where required.

Use the classification template to align the AI policy with your data classification policy and replace the generic labels above with recognised organisational levels.

Human oversight and output verification

• For [defined uses or outputs], AI output must be reviewed by a named human before it is used in [decisions, communications, publications, etc.].
• The level of review depends on the risk tier: [define levels].
• Disclosure or attribution must follow [define legal, contractual and organisational rules].
• Users must flag uncertain, incomplete or potentially harmful output for further review.
• The reviewer must check [accuracy, source support, completeness, bias, rights, safety or other locally relevant criteria].
• The record must identify [reviewer, date, checks performed, outcome and any follow-up].
• Human review does not override specialist approval or testing required elsewhere in this policy.

Transparency, disclosure and records

• Where required by law, contract or organisational policy, AI use must be disclosed to [affected parties, customers, etc.].
• Records of AI use, assessments, approvals and incidents must be retained for [period].
• The [Governance Coordinator] maintains the AI inventory and assessment records.
• The inventory records [purpose, owner, provider, data categories, lifecycle status, approval conditions and review trigger].
• Access to records is limited according to [classification, legal and operational requirements].

An inventory entry records that a use is known. It does not by itself show that the use was assessed, approved, controlled or successful.

Third parties and intellectual property

• AI providers must be assessed before use. The assessment should cover data handling, security, model controls, incident response and contract terms.
• Intellectual-property and licensing checks must follow [define ownership, permitted-use and escalation rules].
• AI output intended for use must be checked for accuracy; third-party content must also be checked against applicable ownership and licensing rules.
• Provider subprocessors, material service changes and incident notifications must follow [procurement and reassessment procedure].
• Approval of a provider does not approve every proposed use of its service.

Security, incidents and escalation

• AI tools must meet the organisation's security requirements: [reference security standards].
• Incidents involving AI (data breach, harmful output, system failure) must be reported to [incident lead] within [timeframe].
• Escalation path: [define levels and contacts].
• Post-incident review must identify root cause and any policy or control updates needed.
• The incident lead may [pause, restrict or isolate the affected use] within defined authority while facts are established.
• Relevant logs, versions, inputs, outputs and decision records must be preserved according to [incident and retention procedure].

Exceptions, training and review

• Exceptions to this policy may be granted by [authority] for a defined period with documented justification.
• Every exception must record [scope, owner, compensating controls, expiry date and review trigger].
• All relevant staff must complete AI awareness training within [timeframe] of starting or changing role.
• This policy is reviewed [at a locally defined interval] and after any material change in AI use, regulation or incident.
• Expired exceptions cease to authorise use unless the named authority records a fresh decision.

How to tailor the template by role and risk

The template is a starting structure. Tailoring means:

• Replacing every placeholder with a local decision.
• Confirming each requirement against applicable law, contract and sector rules.
• Adjusting the level of detail to match your organisation's size and risk.
• Adding role-specific annexes where needed (e.g., for HR, legal, engineering).
• Defining the approved tools register and use-case list.
• Setting the risk tiers and approval authorities.

A small organisation may use a single-page policy with a few annexes. A larger organisation may need a multi-section document with role-specific procedures. The key is that every rule is actionable, every placeholder is completed or explicitly marked not applicable, and every requirement is supported by a procedure or record.

Work through one realistic use case before seeking final approval. Ask what a user would do, what an approver would need, which control owner would act and which record each person would leave behind. If the answer depends on tribal knowledge, add a procedure or make the clause more specific. If the same clause gives conflicting answers for different teams, move the detail into a role- or tool-specific annex while keeping the top-level rule consistent.

Connecting the policy to acceptable-use rules

The organisation-wide AI policy sets the strategic rules. The acceptable-use policy translates those rules into day-to-day behaviour for employees and contractors. The acceptable-use policy should reference the AI policy and provide specific guidance on:

• What is allowed, what needs approval, and what is prohibited.
• What information may enter each tool.
• When to stop or escalate.
• How to handle output.

Write detailed AI acceptable-use rules after the organisation-wide decisions above are approved.

Implementing the policy with procedures and evidence

A policy is only effective if it is implemented. Implementation requires:

• Procedures that translate each policy rule into a day-to-day action.
• Training that ensures staff understand their responsibilities.
• Records that show which decisions and actions occurred under the policy.
• Monitoring that tests agreed controls and reviews defined outcomes and emerging risks.
• Review that keeps the policy current.

This implementation map is an editorial synthesis and should be adapted to the organisation's processes:

Policy requirement	Supporting procedure	Evidence of operation	Review signal
Use only approved tools	Tool-request and approval process	Dated decision with scope and conditions	Unapproved-use reports, material service changes
Assess new use cases	Use-case assessment process	Assessment plus authorised decision	Conditions missed, context or data-flow change
Apply information rules	Classification and handling procedure	Classification and authorisation record	Misrouting, access change, new data category
Review important outputs	Role-specific verification procedure	Reviewer, checks and recorded outcome	Error pattern, incident or changed use
Report and respond to incidents	Existing incident process with AI routing	Triage, decision and follow-up records	Recurrence, delayed reporting, control gap

The document, procedure, control evidence and observed outcome answer different questions. A signed policy records that a rule was approved. It does not prove that the rule was followed or that the resulting control was effective.

The NIST AI RMF Playbook provides suggested implementation actions and documentation for RMF outcomes. It is a living, voluntary resource; organisations need not implement every suggestion.

The UK Government AI Playbook supports named ownership, a live inventory, lifecycle assessment, assurance, testing, escalation and change control. It was published in February 2025 for government organisations; private organisations may adapt its patterns.

Document checkpoints in approved AI workflows

Where documents enter an in-scope AI workflow, the policy's document clause should require classification, authorisation, minimisation and provider-specific controls without mandating a specific product. The organisation decides which controls to implement based on its risk assessment.

Once those controls are in place, a document-level checkpoint can provide evidence about a specific document version before it enters an AI workflow. This is a narrow, technical control that supports the wider governance process.

.mdSiren is a document security workspace for AI, coming soon. Its Standard Scan will check the exact document version before AI use, route that version to Approved, Needs review or Quarantine, and keep Approved versions in a private Library for dependable reuse. The result is limited to the reported checks and scan policy in force; it does not approve a tool or use case, enforce this policy, detect every risk, certify compliance or replace data-loss-prevention controls.

You can see how an exact-version document check works after the wider policy, approval and provider requirements have been addressed.

Frequently asked questions

What should an AI policy include?

A practical AI policy will usually cover purpose and principles, scope and definitions, roles and accountability, approved and restricted uses, risk assessment and approval, data handling, human oversight, transparency and records, third-party and IP rules, security and incidents, exceptions, training and review. The specific content depends on your organisation's context.

Is an AI policy required by law?

The answer depends on jurisdiction, the organisation's role, the AI system and the use. Do not assume that every AI use creates the same documentation duty, or that a generic policy satisfies duties that do apply. For the EU AI Act, start with scope, role, classification and applicable date in the consolidated legislation. The European Commission AI-literacy Q&A notes that where Article 4 applies, providers and deployers take context-sensitive AI-literacy measures for relevant staff and operators; it does not prescribe one course, certificate or universal staff test.

Who should own an AI policy?

The policy should have a named accountable owner, typically an executive or senior leader. Day-to-day maintenance may be delegated to a policy owner or governance coordinator. The accountable owner oversees implementation and review; policy, control and use-case owners remain responsible for their defined work.

Should an AI policy ban confidential data?

The policy should define what data may and may not enter each tool, based on classification, risk and provider terms. A blanket ban may be appropriate for some tools and data categories; a risk-based approach may be more proportionate for others. The decision is organisation-specific.

How often should an AI policy be reviewed?

There is no universal review interval. The policy should define its own review triggers: periodic review at a locally defined interval, plus event-driven reviews triggered by material change, incident, regulatory change, or audit finding.