# AI Policy: [Organisation name]

> Top-level AI policy for an AI management system (AIMS), structured on
> clause 5.2 of ISO/IEC 42001:2023 and Annex A control objective A.2,
> with roles under clause 5.3 and a framework for AI objectives under
> clause 6.2. It states the organisation's commitments for developing,
> providing and using AI systems, the responsible AI principles, the
> prohibited and restricted uses (aligned with Article 5 of the EU AI
> Act, Regulation (EU) 2024/1689 as amended by Regulation (EU)
> 2026/1744), and the duties for risk and impact assessment, data, third
> parties, transparency, incidents and AI literacy. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice.

<!--
Guidance: How to use this template
- This is the governing policy for the whole AIMS. Rules for how staff
  use AI tools day to day belong in the AI acceptable use policy
  (ai-data/ai-usage-policy); link to it rather than copying it here.
- Have top management approve and sign the policy. Clause 5 places the
  policy with top management, so a policy approved only by a team lead
  fails the requirement.
- Keep commitments short and testable. Put procedures, thresholds and
  checklists in the documents listed in section 20.
- Check the consolidated text of the AI Act on EUR-Lex and current
  Commission guidelines before finalising section 8; the list of
  prohibited practices grew in 2026.
- Clause and control numbers refer to ISO/IEC 42001:2023; the wording
  here is original. Read the standard for the normative requirements.
-->

## Document control

<!-- Guidance: Record who owns the policy and who approved it. Auditors check that the approver is top management and that the version in circulation is the approved one. -->

| Field | Value |
|---|---|
| Document ID | [POL-AIMS-001] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@ai-governance-lead] |
| Approvers / reviewers | [@ceo], [@ai-governance-board], [@legal], [@ciso], [@dpo] |
| Last updated | YYYY-MM-DD |
| Classification | [Public / Internal] |
| Effective date | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Organisation's AI roles | [Provider / Deployer / Importer / Distributor / AI customer / AI producer] |
| AIMS scope statement | [SCOPE-AIMS-001] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief executive (top management) | [@name] | [Approve / Reject] | YYYY-MM-DD |
| AI governance board chair | [@name] | [Recommend for approval] | YYYY-MM-DD |
| Legal counsel | [@name] | [Reviewed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the CEO |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Section 8.2 updated for prohibitions added by Regulation (EU) 2026/1744 |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Purpose](#1-purpose)
2. [Scope](#2-scope)
3. [Policy statement](#3-policy-statement)
4. [How this policy meets clause 5.2](#4-how-this-policy-meets-clause-52)
5. [Responsible AI principles](#5-responsible-ai-principles)
6. [AI objectives framework](#6-ai-objectives-framework)
7. [Roles and responsibilities](#7-roles-and-responsibilities)
8. [Acceptable, restricted and prohibited uses](#8-acceptable-restricted-and-prohibited-uses)
9. [Risk and impact assessment](#9-risk-and-impact-assessment)
10. [AI system life cycle](#10-ai-system-life-cycle)
11. [Data for AI systems](#11-data-for-ai-systems)
12. [Third parties and customers](#12-third-parties-and-customers)
13. [Transparency and information](#13-transparency-and-information)
14. [Human oversight](#14-human-oversight)
15. [Incidents and concerns](#15-incidents-and-concerns)
16. [Competence, awareness and AI literacy](#16-competence-awareness-and-ai-literacy)
17. [Exceptions](#17-exceptions)
18. [Compliance and monitoring](#18-compliance-and-monitoring)
19. [Policy review](#19-policy-review)
20. [Related documents](#20-related-documents)
21. [Glossary and references](#21-glossary-and-references)

## 1. Purpose

<!-- Guidance: Say why the policy exists in two or three sentences. Tie it to the organisation's mission so it reads as "appropriate to the purpose of the organisation", which clause 5.2 expects. -->

This policy sets the direction and commitments of [Organisation name]
for the responsible development, provision and use of artificial
intelligence. It establishes the AI management system, gives the
framework within which AI objectives are set, and assigns accountability
so that AI systems create value for [customers, citizens, patients or
other beneficiaries] while risks to people, the organisation and society
are identified and kept within accepted limits.

*Example:* As a provider of customer service software, we use AI to
resolve customer requests faster. This policy makes sure that every AI
feature we build or buy is safe, lawful, transparent to the people who
use it, and supervised by accountable staff.

## 2. Scope

<!-- Guidance: Match the AIMS scope statement (clause 4.3). Name the AI roles the organisation plays, because duties differ for developers, providers and deployers. Pitfall: leaving out AI features embedded in purchased software. -->

This policy applies to:

- all AI systems that [Organisation name] designs, develops, trains,
  fine-tunes, provides, deploys, operates, buys or integrates, including
  AI features embedded in third-party software and general-purpose AI
  models used through an API;
- all employees, contractors, temporary staff and partners who work with
  those systems on the organisation's behalf;
- all locations and business units listed in [SCOPE-AIMS-001].

| AI role | Applies to us? | Examples in our organisation |
|---|---|---|
| Developer or provider of AI systems | [Yes / No] | *Example:* Support assistant sold to customers |
| Deployer or user of AI systems | [Yes / No] | *Example:* Fraud scoring tool used by the finance team |
| Integrator of third-party models | [Yes / No] | *Example:* Foundation model accessed by API in two products |
| Staff use of AI tools | Yes | Governed by the AI acceptable use policy [POL-AI-USE-001] |

Personal use of AI tools for work tasks is covered by the AI acceptable
use policy, which implements section 8 of this policy for individual
staff. Where the two conflict, this policy prevails.

## 3. Policy statement

<!-- Guidance: This is the part top management signs. Keep it to commitments, not procedures. -->

Top management of [Organisation name] commits to:

1. Develop, provide and use AI systems only for purposes that are
   lawful, documented and aligned with our values and this policy.
2. Meet the legal, regulatory and contractual requirements that apply to
   our AI systems, including the EU AI Act where it applies to us, data
   protection law and sector rules.
3. Identify, assess and treat AI risks and impacts before deployment and
   throughout the life of each system, and accept residual risk only at
   the authority level set in the risk methodology.
4. Keep meaningful human oversight proportionate to the risk of each
   system.
5. Be transparent with the people who use or are affected by our AI
   systems about the role AI plays and its limits.
6. Provide the resources, competence and AI literacy measures needed to
   run the AIMS.
7. Set, monitor and review AI objectives within the framework in
   section 6.
8. Continually improve the suitability, adequacy and effectiveness of
   the AIMS.

Signed: [@ceo], [Chief executive officer], YYYY-MM-DD

## 4. How this policy meets clause 5.2

<!-- Guidance: Auditors test the policy against clause 5.2 and the A.2 controls. This table shows where each expectation is met. The left column paraphrases the requirement; read the standard for the exact wording. -->

| Ref | Expectation (paraphrase) | Where met |
|---|---|---|
| 5.2 a | Policy suits the organisation's purpose | Sections 1 and 2 |
| 5.2 b | Policy gives a framework for setting AI objectives | Section 6 |
| 5.2 c | Policy commits to meeting applicable requirements | Section 3 item 2; section 18 |
| 5.2 d | Policy commits to continual improvement of the AIMS | Section 3 item 8; section 19 |
| 5.2 (documented information) | Policy is available as documented information | Document control; controlled document register |
| 5.2 (other policies) | Policy refers to related organisational policies where relevant | Section 20 |
| 5.2 (communication) | Policy is communicated within the organisation | Section 16 |
| 5.2 (interested parties) | Policy is available to interested parties as appropriate | *Example:* Summary published on the trust centre page |
| A.2.2 | AI policy documented | This document |
| A.2.3 | Other policies aligned with AI objectives | Section 20 alignment table |
| A.2.4 | AI policy reviewed at intervals and on change | Section 19 |

## 5. Responsible AI principles

<!-- Guidance: Pick principles your organisation will actually operate and attach a concrete commitment to each. ISO/IEC 42001 Annex C lists potential AI-related objectives (for example accountability, fairness, privacy, robustness, safety, security, transparency and explainability) that you can use as a checklist. Pitfall: a values list with no commitment a reviewer can test. -->

| ID | Principle | Commitment | Primary controls |
|---|---|---|---|
| PR-01 | Accountability | Every AI system has a named business owner and technical owner recorded in the AI system inventory | A.3.2, A.4.2 |
| PR-02 | Fairness and non-discrimination | Systems that affect people are tested for performance differences across relevant groups before release and at least [annually] | A.5.4, A.6.2.4, A.7.4 |
| PR-03 | Transparency and explainability | People are told when they interact with an AI system or receive AI-generated content, and can get an explanation proportionate to the decision | A.8.2, A.8.5 |
| PR-04 | Safety and reliability | Systems meet defined acceptance criteria before deployment and are monitored in operation | A.6.2.4, A.6.2.6 |
| PR-05 | Security | AI-specific threats such as prompt injection, data poisoning and model theft are part of threat modelling and testing | A.6.2.4, additional security controls |
| PR-06 | Privacy | Personal data in training, prompts and outputs is processed lawfully, minimised and protected | A.7.2, A.7.6 |
| PR-07 | Human oversight | The level of human control is set per system according to risk and documented | A.9.2, A.9.4 |
| PR-08 | Data quality and provenance | Data used for AI has documented origin, rights and quality criteria | A.7.3, A.7.4, A.7.5 |
| PR-09 | Environmental responsibility | Compute and energy use are considered when choosing models and infrastructure | A.4.5, A.5.5 |
| PR-10 | Contestability | People affected by AI-supported decisions can raise a concern or challenge the outcome | A.3.3, A.8.3 |

## 6. AI objectives framework

<!-- Guidance: Clause 6.2 expects objectives that are consistent with the policy, measurable where practicable, monitored, communicated and updated, with a plan for what, who, when, resources and how results are evaluated. This section sets the rules; the objectives themselves live in the objectives register. -->

AI objectives are set at least [annually] by the AI governance board,
proposed by owners of AI systems and functions, and approved by top
management. Each objective must:

- derive from at least one principle in section 5 or a requirement in
  the legal register;
- have a measure, a target, an owner, the resources needed, a due date
  and the method for evaluating results;
- be reviewed at each management review and updated when context
  changes.

| Objective ID | Objective | Principle | Measure | Target | Owner | Due | Evaluation |
|---|---|---|---|---|---|---|---|
| OBJ-AI-001 *(Example)* | Complete an impact assessment for every AI system that affects external individuals | PR-02, PR-10 | Share of in-scope systems with an approved assessment | 100% | [@ai-governance-lead] | YYYY-MM-DD | Quarterly inventory check |
| OBJ-AI-002 *(Example)* | Reduce unsupported claims in support assistant answers | PR-04 | Groundedness failure rate on the evaluation set | Below [x]% | [@head-of-ml] | YYYY-MM-DD | Release evaluation report |
| OBJ-AI-003 *(Example)* | Deliver role-based AI literacy measures to all staff who operate AI systems | PR-01, PR-07 | Share of in-scope staff with completed module | [95]% | [@hr-lead] | YYYY-MM-DD | Learning system report |
| OBJ-AI-004 *(Example)* | Assess all AI suppliers before contract signature | PR-01, PR-05 | Share of new AI contracts with a completed vendor questionnaire | 100% | [@procurement-lead] | YYYY-MM-DD | Procurement audit |

## 7. Roles and responsibilities

<!-- Guidance: Clause 5.3 asks top management to assign responsibility and authority for the AIMS conforming to the standard and for reporting on its performance. Control A.3.2 extends this to AI roles across the life cycle. Name roles, not people, and keep names in the RACI annex. -->

| Role | Responsibilities |
|---|---|
| Top management | Approves this policy, sets direction, provides resources, accepts residual risk above [level], chairs or attends management review |
| AI governance board | Recommends policy and objectives, approves high-risk use cases, reviews incidents and audit results, decides exceptions |
| AIMS manager | Runs the AIMS, maintains the Statement of Applicability, reports performance to top management |
| AI system business owner | Accountable for the purpose, benefits and risks of a system; signs off impact assessments |
| AI system technical owner | Responsible for design, testing, deployment, monitoring and documentation of a system |
| Data owner | Approves data use for AI, rights and quality criteria |
| Legal and compliance | Maintains the AI legal register; advises on AI Act roles, contracts and transparency |
| Data protection officer | Advises on personal data processing and DPIAs |
| Security lead | Owns AI threat modelling, security testing and incident response for AI |
| Procurement | Runs third-party AI assessment and contract clauses |
| All staff | Follow this policy and the AI acceptable use policy; report concerns and incidents |

| Activity | Top mgmt | Board | AIMS mgr | Business owner | Technical owner | Legal |
|---|---|---|---|---|---|---|
| Approve AI policy | A | R | C | I | I | C |
| Approve high-risk use case | I | A | C | R | C | C |
| Impact assessment | I | C | C | A | R | C |
| Statement of Applicability | I | C | A/R | C | C | C |
| Incident notification to authorities | I | A | C | C | R | R |

## 8. Acceptable, restricted and prohibited uses

<!-- Guidance: Three tiers make decisions easy: allowed after normal intake, allowed only with board approval, never allowed. The prohibited list follows Article 5 of the AI Act in original wording; check the consolidated text, the Commission guidelines on prohibited practices and national law, which can be stricter. -->

### 8.1 Acceptable uses

AI may be developed or used for a documented business purpose after the
use case is registered through the AI use case intake process and the
required reviews in section 9 are complete. *Example:* drafting customer
replies for agent review, summarising internal documents, detecting
anomalies in invoices, code assistance under the acceptable use policy.

### 8.2 Prohibited uses

[Organisation name] does not develop, provide, buy or use AI systems for
any of the following practices. The list follows Article 5 of the AI
Act, which has applied since 2 February 2025, and is extended by
internal rules where marked.

| ID | Prohibited practice (paraphrase) | Source |
|---|---|---|
| PRH-01 | Subliminal, purposefully manipulative or deceptive techniques that materially distort a person's behaviour and cause or are likely to cause significant harm | AI Act Art. 5(1)(a) |
| PRH-02 | Exploiting vulnerabilities linked to age, disability or a specific social or economic situation to materially distort behaviour with significant harm | AI Act Art. 5(1)(b) |
| PRH-03 | Social scoring that leads to detrimental or unfavourable treatment in unrelated contexts or that is unjustified or disproportionate | AI Act Art. 5(1)(c) |
| PRH-04 | Assessing or predicting the risk that a person will commit a crime based solely on profiling or personality traits | AI Act Art. 5(1)(d) |
| PRH-05 | Creating or expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV | AI Act Art. 5(1)(e) |
| PRH-06 | Inferring emotions of people in the workplace or in education, except for medical or safety reasons | AI Act Art. 5(1)(f) |
| PRH-07 | Biometric categorisation to deduce race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation | AI Act Art. 5(1)(g) |
| PRH-08 | Real-time remote biometric identification in publicly accessible spaces for law enforcement, outside the narrow exceptions in the Act | AI Act Art. 5(1)(h) |
| PRH-09 | Generating or manipulating realistic intimate or sexually explicit images, video or audio of an identifiable person without consent, or child sexual abuse material | Added by Regulation (EU) 2026/1744, applicable from 2 December 2026; check the consolidated text |
| PRH-10 *(Example internal rule)* | Fully automated decisions to dismiss or discipline staff | Internal rule |
| PRH-11 *(Example internal rule)* | Entering secret or restricted data into AI tools not on the approved tools register | Internal rule; see AI acceptable use policy |

### 8.3 Restricted uses (board approval required)

| ID | Restricted use | Condition |
|---|---|---|
| RST-01 | Any use case in an AI Act Annex III area (for example employment, education, access to essential services, credit, insurance, law enforcement, migration, justice, critical infrastructure) | Board approval, impact assessment and, for deployers in scope, a fundamental rights impact assessment |
| RST-02 | AI that makes or materially shapes decisions about individuals | Documented human review and a contest route |
| RST-03 | Training or fine-tuning on personal or customer data | DPIA, data owner approval, contract check |
| RST-04 | Autonomous agents that can act in external systems (payments, email, production changes) | Tool permission design, human approval for high-impact actions, red team test |
| RST-05 | Public-facing generated content at scale | Content transparency plan and marking where required |

## 9. Risk and impact assessment

<!-- Guidance: Clause 6.1.2 requires an AI risk assessment, clause 6.1.4 an AI system impact assessment, and A.5 controls cover the impact process. Say when each is required, who approves it and how often it is refreshed. -->

Every AI system in scope goes through these steps before deployment and
on any material change:

```mermaid
flowchart TD
  I["Use case intake and tiering"] --> P{"Prohibited (8.2)?"}
  P -->|Yes| X["Stop"]
  P -->|No| T{"Tier"}
  T -->|Low| R1["Light risk review"]
  T -->|Medium or high| R2["AI risk assessment (6.1.2)"]
  R2 --> IA["AI system impact assessment (6.1.4, A.5)"]
  IA --> L{"Legal triggers?"}
  L -->|Personal data| DPIA["DPIA"]
  L -->|Annex III deployer in scope| FRIA["FRIA (AI Act Art. 27)"]
  L -->|None| D["Decision"]
  DPIA --> D
  FRIA --> D
  R1 --> D
  D --> SOA["Controls in Statement of Applicability"]
```

| Requirement | Applies to | Approver | Refresh |
|---|---|---|---|
| Use case intake and risk tier | All AI systems | AIMS manager | On material change |
| AI risk assessment | Medium and high tier | Business owner; board for high tier | [Annually] and on change |
| AI system impact assessment | Systems affecting individuals, groups or society | Business owner and board | [Annually] and on change |
| Generative AI risk profile | Systems using generative models | Technical owner | Each major release |
| DPIA | Processing likely to result in high risk to individuals | DPO opinion | On change |
| Fundamental rights impact assessment | Deployers within AI Act Article 27 | Board | Before first use and on change |

Risk scoring, tolerance and acceptance authority follow the risk
methodology [RISK-METH-001].

## 10. AI system life cycle

<!-- Guidance: State the minimum life cycle rules; the engineering standard holds the detail. A.6 controls cover objectives, processes, requirements, documentation, verification, deployment, operation, technical documentation and event logs. -->

For each AI system the technical owner makes sure that:

- requirements, including performance, safety and fairness acceptance
  criteria, are documented before development starts;
- design decisions, data, models, prompts and evaluation results are
  recorded and version-controlled;
- verification and validation results meet the acceptance criteria
  before release, and a launch review records the decision;
- event logs are kept at least while the system is in use, with the
  retention period set in the logging standard;
- operation is monitored for performance, drift, misuse and incidents,
  with a documented rollback or shutdown procedure;
- technical documentation and user information are prepared for each
  audience that needs them;
- retirement is planned, including data and model disposal.

## 11. Data for AI systems

<!-- Guidance: A.7 controls cover data management, acquisition, quality, provenance and preparation. Pitfall: using production data for training because it is convenient, without rights or lawful basis. -->

- Data used to train, fine-tune, evaluate or ground AI systems has a
  documented source, licence or lawful basis, and an owner.
- Data quality criteria are defined per use and checked before use.
- Provenance is recorded so the organisation can answer what data a
  model was built with and where it came from.
- Personal data is minimised, pseudonymised where possible, and
  processed under the privacy policy and DPIA.
- Customer data is used for AI training only when the contract allows
  it and the customer has been informed as agreed.

## 12. Third parties and customers

<!-- Guidance: A.10 controls cover allocation of responsibilities, suppliers and customers. Under AI Act Article 25, a deployer or other party can become a provider of a high-risk system, for example by substantially modifying it or changing its intended purpose. -->

- Responsibilities between the organisation, suppliers, partners and
  customers are allocated in writing for each AI system.
- AI suppliers, including providers of general-purpose AI models, are
  assessed with the AI vendor risk questionnaire before contract and on
  renewal.
- Contracts include, as relevant: data use limits, security, incident
  and change notification, audit or evidence rights, documentation,
  model change notice, AI Act cooperation duties and exit support.
- Before rebranding, substantially modifying or repurposing a
  third-party AI system, legal reviews whether the change makes the
  organisation a provider under AI Act Article 25.
- Customer requirements and expectations for AI are captured and
  reflected in product decisions and documentation.

## 13. Transparency and information

<!-- Guidance: A.8 controls cover user information, reporting of adverse impacts, incident communication and reporting obligations. AI Act Article 50 sets transparency duties for some systems; check the consolidated text and the Commission guidelines for dates and scope. -->

- People are informed when they interact directly with an AI system,
  unless this is obvious from the context.
- Synthetic audio, image, video or text content is marked or disclosed
  where the law requires it, following the content transparency plan.
- User documentation states the intended purpose, known limitations and
  how to report problems.
- A summary of this policy is published for interested parties
  [location].

## 14. Human oversight

<!-- Guidance: Set the oversight level per system in its specification. For high-risk systems, AI Act Article 14 (providers) and Article 26 (deployers) set specific duties. -->

| Level | Description | Typical use |
|---|---|---|
| Human in the loop | A person approves each output before it takes effect | Decisions about individuals, external communications in regulated areas |
| Human on the loop | A person monitors and can intervene or stop the system | Agents acting within limited permissions, fraud alerts |
| Human in command | People set goals and limits and review aggregate performance | Low-risk automation, internal analytics |

Staff assigned to oversight have the competence, authority and time to
do it, and can override or stop the system without penalty.

## 15. Incidents and concerns

<!-- Guidance: A.3.3 covers reporting of concerns and A.8.4 communication of incidents. Providers of high-risk systems have serious incident reporting duties under AI Act Article 73 and deployers have information duties under Article 26; check the consolidated text for deadlines. -->

- Anyone can raise a concern about an AI system through [channel], with
  protection against retaliation under the speak-up policy.
- AI incidents and near misses (for example harmful outputs, data
  exposure, discriminatory results, unsafe actions by an agent) are
  reported to [ai-incidents@example.org] and handled under the AI
  incident response plan.
- The incident manager assesses legal and contractual notification
  duties for each incident and records the decision.
- Lessons learned feed the risk register and the Statement of
  Applicability.

## 16. Competence, awareness and AI literacy

<!-- Guidance: Clause 7.2 covers competence and 7.3 awareness. AI Act Article 4 asks providers and deployers to take measures to support AI literacy of staff and others operating AI on their behalf; Regulation (EU) 2026/1744 reworded it and it does not require a specific level for each person. -->

- The policy is communicated to all staff at onboarding and after each
  revision, and acknowledgement is recorded.
- Role-based AI literacy measures follow the AI literacy plan and take
  into account people's knowledge, experience and the context of use.
- People with AI governance, development, oversight or audit roles have
  documented competence, refreshed at least [annually].

## 17. Exceptions

<!-- Guidance: Allow exceptions only through a recorded, time-limited process. Prohibited uses in section 8.2 that derive from law can never be excepted. -->

Requests for an exception to this policy are submitted to the AIMS
manager with the business reason, the risk, compensating measures and
the end date. The AI governance board decides. Exceptions are recorded
in the exceptions register, last no longer than [12 months] and are
reviewed before renewal. No exception can be granted for a practice
prohibited by law.

| Exception ID | Section | Reason | Compensating measures | Approved by | Expires |
|---|---|---|---|---|---|
| EXC-AI-001 *(Example)* | 11 (customer data for training) | Pilot with anonymised tickets from one consenting customer | Contract addendum, DPIA, deletion after pilot | [@ai-governance-board] | YYYY-MM-DD |

## 18. Compliance and monitoring

<!-- Guidance: Clauses 9.1 to 9.3 cover monitoring, internal audit and management review. Say how compliance with this policy is checked and what happens on breach. -->

- The AIMS manager reports AIMS performance, objective status, incidents
  and audit results to top management at least [twice a year].
- Internal audit covers this policy within the AIMS audit programme.
- Breaches are handled under the disciplinary or contractual process and
  are recorded as nonconformities with corrective action (clause 10.2).

## 19. Policy review

<!-- Guidance: A.2.4 expects review at planned intervals and when needed. List the triggers so review is not only calendar-driven. -->

The owner reviews this policy at least [annually] and also when: a new AI
law or major amendment applies to the organisation; the organisation
takes on a new AI role (for example becomes a provider); a serious AI
incident occurs; management review or audit finds the policy
ineffective; or the business strategy for AI changes. Each review is
recorded in the revision history, even when no change is made.

## 20. Related documents

<!-- Guidance: A.2.3 asks where other policies interact with AI objectives. Record each related policy and what was aligned. -->

| Document | Relationship |
|---|---|
| AI acceptable use policy (`ai-data/ai-usage-policy`) | Staff rules for using AI tools; implements section 8 for individuals |
| [Statement of Applicability (ISO/IEC 42001)](iso-42001-statement-of-applicability.md) | Controls selected to implement this policy |
| [AI management system policy and impact assessment](iso-42001-ai-management.md) | Short combined policy and impact format for smaller organisations |
| AI use case intake (`ai-data/ai-use-case-intake`) | Entry point for section 8 and 9 decisions |
| AI risk assessment (`ai-data/ai-risk-assessment`) | Method for section 9 |
| AI system impact assessment (`ai-data/ai-impact-assessment-42005`) | Method for section 9 |
| AI literacy plan (`ai-data/ai-literacy-plan`) | Implements section 16 |
| [AI vendor risk questionnaire](ai-vendor-risk-questionnaire.md) | Implements section 12 |
| [Objectives register](objectives-register.md) | Holds AI objectives under section 6 |
| Information security policy, privacy policy, procurement policy | *Example:* Updated to reference AI threats, AI data use and AI supplier checks |

## 21. Glossary and references

<!-- Guidance: Define terms for readers who are not specialists. -->

| Term | Meaning |
|---|---|
| AI system | Machine-based system that infers from input how to generate outputs such as predictions, content, recommendations or decisions |
| AIMS | AI management system under ISO/IEC 42001 |
| Provider | Organisation that develops an AI system or model and places it on the market or puts it into service under its own name |
| Deployer | Organisation using an AI system under its authority in a professional activity |
| General-purpose AI model | Model trained on broad data that can perform a wide range of tasks and be integrated into many systems |
| Impact assessment | Assessment of the potential consequences of an AI system for individuals, groups and society |

References: ISO/IEC 42001:2023, clauses 5.2, 5.3, 6.1, 6.2, 7.2, 7.3, 9,
10 and Annex A (A.2 to A.10), Annex C; Regulation (EU) 2024/1689 as
amended by Regulation (EU) 2026/1744 (consolidated text on EUR-Lex),
Articles 4, 5, 14, 25, 26, 27, 50, 73 and Annex III; NIST AI RMF 1.0;
ISO/IEC 42005:2025.

## Standard and licence note

Structure aligned with ISO/IEC 42001:2023, clauses 5.2, 5.3 and 6.2 and
Annex A control objective A.2. ISO/IEC standards are copyrighted: this
template cites clause and control numbers only, and all policy text is
original; obtain the standard for the normative requirements and check
the current edition. The prohibited practices are summarised in original
wording from Article 5 of Regulation (EU) 2024/1689 as amended by
Regulation (EU) 2026/1744; EU legislative texts are free to reuse. Check
the consolidated text on EUR-Lex for binding wording and application
dates. This is a documentation format, not legal advice. Template
licence: MIT.