An AI policy that says staff should use AI responsibly is not a governance control. It does not identify which systems are in use, who approved them, what decisions they influence, or what evidence can be produced when a regulator, customer, auditor or board asks. A workable AI policy checklist turns broad intent into defined obligations, operating procedures and accountable ownership.
For compliance-led organisations, the policy is the starting point rather than the finished product. It must connect to an AI inventory, risk assessments, supplier due diligence, technical documentation, training records and incident management. Without those operational links, it is a document with no evidential value.
What an AI policy must achieve
A proportionate AI policy establishes the rules for acquiring, developing, deploying and monitoring AI systems across the organisation. It should apply equally to a customer-facing model, an HR screening tool, a generative AI assistant used by employees and a predictive tool embedded in third-party software.
The detail will depend on your role. A provider developing an AI system has different duties from a deployer using a vendor product, and both differ from an importer or distributor. The EU AI Act allocates obligations according to these roles. Your policy should therefore prevent a common failure: treating every AI use case as though it presents the same legal and operational risk.
It should also be aligned with the organisation’s AI management system if ISO/IEC 42001 certification is a goal. ISO 42001 expects defined policies, objectives, roles, risk treatment, performance evaluation and continual improvement. A standalone policy that does not drive those activities will not satisfy an auditor for long.
AI policy checklist: the controls that matter
1. Define AI and set the policy scope
Start with a definition broad enough to capture the systems the organisation actually uses. Do not limit the policy to internally built machine learning models. Include generative AI tools, AI-enabled SaaS products, automated decision-support systems, models integrated through APIs and material features added to existing suppliers’ products.
State where the policy applies: business units, subsidiaries, contractors, temporary staff and outsourced service providers. Set clear exclusions only where they are defensible. A basic office tool may require a lighter approval route, but it should not disappear from the inventory merely because it is low risk.
2. Make the AI inventory mandatory
No policy can govern unknown systems. Require every proposed or existing AI system to be registered before procurement, development, significant modification or live use. The inventory record should capture the system purpose, owner, provider, deployment location, affected people, data categories, model type, intended users and business criticality.
This is the control that replaces scattered spreadsheets and informal approvals. It also creates the population against which you can assess EU AI Act classification, privacy implications, cyber risk and contractual exposure. A policy should specify who maintains the register, how often entries are reviewed and what happens when an owner cannot verify the information.
3. Assign accountable owners and approval authority
Every AI system needs a named business owner, not a shared mailbox or a generic technology function. That owner should be responsible for accurate inventory information, completing assessments, implementing required controls and escalating material change or incidents.
The policy should distinguish operational ownership from approval authority. Compliance, legal, information security, data protection and risk teams may each provide challenge or approval depending on the use case. For high-risk decisions, establish a formal governance forum with authority to pause deployment. Escalation routes matter because a policy that has no power to stop an unsafe use case is only advisory.
4. Require legal classification before deployment
The EU AI Act is risk-based, but classification is not a one-off tick-box exercise. The policy should require documented assessment of whether a system is prohibited under Article 5, high-risk under Article 6 and Annex III, subject to transparency obligations under Article 50, or outside these categories while still requiring internal controls.
The assessment should record the rationale, evidence reviewed and the legal role held by the organisation. A recruitment system, for example, may trigger high-risk analysis even when purchased from a supplier. A generative AI tool used to draft internal notes may be lower risk, but its data handling and output assurance requirements can still be significant.
Set mandatory review triggers. Changes to intended purpose, model provider, training data, target users, decision impact, geographic deployment or integration with personal data can alter the classification and control set.
5. Set rules for data, confidentiality and intellectual property
An effective policy gives staff usable instructions, not vague warnings about sensitive data. Specify what information must never be entered into public or unapproved AI tools, such as special category personal data, customer confidential information, security credentials, legally privileged material or commercially sensitive strategy.
Where personal data is processed, require involvement from the Data Protection Officer or privacy team and assess whether a data protection impact assessment is necessary. Address data retention, international transfers, processor terms, model training opt-outs and deletion routes. Procurement approval should not be treated as proof that a supplier’s data practices remain acceptable after a material product change.
The policy should also deal with ownership and reuse of AI-generated content. Staff need to know when outputs may be published, when human review is compulsory and when licences, copyright or third-party rights require legal review.
6. Establish human oversight and decision boundaries
Where AI influences decisions about people, finances, eligibility, employment, safety or access to essential services, the policy should make the decision boundary explicit. Define what the system can recommend, what a trained human must decide, and when the use of AI is prohibited altogether.
Human oversight is not satisfied by placing a person nominally in the process. The reviewer needs sufficient authority, training, time and information to challenge an output. They must be able to override or stop the system without commercial pressure. For high-risk AI, these arrangements support the requirements in Article 14 and should be evidenced through procedures, training and system design.
7. Set testing, monitoring and change-control requirements
Before release, require testing proportionate to the system’s impact. This may include accuracy testing, bias and fairness evaluation, prompt-injection testing, security testing, performance testing across relevant user groups and validation of safeguards. The policy should define minimum acceptance criteria and identify who signs them off.
After deployment, monitoring is essential. Specify what will be monitored, such as drift, error rates, override rates, user complaints, harmful outputs, security events and supplier changes. Define review frequency and thresholds for escalation. A model that performed acceptably in a pilot can create a very different risk profile after being connected to production data or used at scale.
8. Control third-party AI suppliers
Most organisations are deployers of supplier systems rather than model developers. The policy should require due diligence before onboarding and at defined intervals thereafter. This should cover the supplier’s system documentation, data use, security controls, hosting location, sub-processors, incident notification, audit rights, support for compliance evidence and contractual allocation of responsibilities.
For higher-risk systems, ask whether the provider can supply the technical documentation, instructions for use, logging information and performance evidence needed for your own obligations. If it cannot, the procurement case may be commercially attractive but operationally indefensible.
9. Make training, incidents and records non-negotiable
Article 4 of the EU AI Act requires organisations providing or deploying AI systems to take measures to ensure a sufficient level of AI literacy among staff and others operating systems on their behalf. Your policy should translate that requirement into role-based training. A general user needs different instruction from a system owner, developer, HR manager or senior approver.
Require staff to report suspected harmful outputs, data leakage, unlawful discrimination, security concerns, loss of human control and supplier failures. The incident process should state who investigates, who informs affected stakeholders, when use must be suspended and how corrective actions are recorded.
Finally, set a retention schedule for approvals, assessments, test results, training evidence, monitoring records and incident decisions. Audit readiness is not achieved by recreating a rationale six months later. It depends on contemporaneous evidence that can be traced to the relevant system and control.
Test the policy against real decisions
Before approval, run the policy through realistic scenarios. Can a marketing employee tell whether they may use a public generative AI tool with draft customer material? Can a procurement lead identify when an AI supplier needs enhanced due diligence? Can the HR team recognise that an automated candidate-ranking tool requires a formal classification and oversight review?
If the answer relies on a lengthy legal interpretation, the policy needs clearer operational procedures. The policy should be concise enough to guide action, while linked governance workflows carry the detailed assessment questions, control mappings and evidence requirements. This is where a system of record is more defensible than policy documents and spreadsheets distributed across several teams.
Review the policy at least annually, and sooner after material legal developments, significant incidents, changes to the AI portfolio or new organisational risk appetite. The EU AI Act is being phased in, with prohibited-practice and AI literacy provisions already applicable, while further obligations apply on different dates. A static policy will age quickly.
The useful test is simple: when the next AI system arrives, your team should know who registers it, who assesses it, who approves it, what controls apply and where the evidence sits. If those answers are not immediate, the policy is not yet doing its job.