Does an AI Act program need an AI governance policy, and what must it settle?
A customer, contract or regulator asks for AI Act evidence, and the team has no written rules for how AI is approved, owned or used. The AI Act does not prescribe a single mandatory policy template, but a written AI governance policy is the document that assigns ownership and makes the rest of the evidence traceable. Providers also have a specific obligation: Article 17 requires a quality management system documented as written policies, procedures and instructions, so the governance policy is the natural anchor for that system. The organization owns this policy and its approval by senior management. An implementation partner can draft it and put it into operation, but only an independent auditor or certification body issues any report or certificate about it.
The content depends on the organization's role under the Act. A provider that places high-risk systems on the market needs the policy to connect design control, testing, post-market monitoring and incident reporting to named owners. A deployer needs it to cover who may use each AI system, who oversees it, and how staff are trained. Many organizations are both, and some build on general-purpose models they did not train. The number of AI uses matters too. A company with three vendor tools can keep the policy short, while one with dozens of internal models and embedded features needs approval routes, roles and records that scale. Confirm your role for each system before drafting, because the obligations attach to the role, not to the company name.
Start by deciding four things: who is accountable for AI decisions at executive level, who classifies new AI uses and who can approve them, what the rules are for staff using generative AI tools, and where documentation is kept and for how long. Then check the policy against ISO/IEC 42001, whose clause 5.2 requires an AI policy and whose control A.2.2 is the one organizations usually cite in their statement of applicability. Confirm with your certification body or auditor which reference they will test against before you finalize wording. Treat the policy as a living document that is reviewed when your AI inventory changes, not as a one-time filing.
Which policy sections map to which AI Act duties
Each section of an AI governance policy answers a specific AI Act question and should leave a record an assessor can inspect. The cards below pair each component with the duty it supports and the evidence it produces, so the policy can be checked against the Act rather than read as a general statement of intent.
Accountability and roles
The policy names who owns each AI system, who approves its use, and who answers for it when something goes wrong. For providers, this part supports the accountability framework that Article 17 requires within the quality management system. Check that every AI system in the inventory has a named owner, that the owner's authority is written down, and that deputies cover absences. Evidence: a signed role register, a RACI matrix and committee terms of reference.
Intake and risk classification
The policy requires every proposed AI use to be recorded and classified before work starts. Classification decides whether prohibited practices, high-risk obligations, transparency duties or no specific duty apply, and it determines whether the provider or deployer role is in play. Check that the intake form captures intended purpose, the people affected and the data used. Evidence: intake tickets, classification memos and dated decisions for systems classified as not high-risk.
Approval gates
The policy sets the points where an AI system cannot move forward until a named role signs off, such as design, pilot, production release and material change. Gates make the risk management and testing duties operational, because they force evidence to exist at each stage. Check that gates apply to changes in model, data, purpose or vendor, not only to the first launch. Evidence: gate checklists, sign-off records and change logs linked to the inventory.
AI literacy
Article 4 requires providers and deployers to take measures that support AI literacy among staff and others who operate AI for them. The policy should say which roles need which training, how competence is kept current, and who tracks completion. The Commission's Q&A states that no certificate is required and no training format is mandatory, so the record of measures matters more than a particular course. Evidence: a role-based training plan, attendance records and training content kept with version dates.
Generative AI acceptable use
The policy states which generative AI tools staff may use, for what tasks, with which data classes, and which uses need prior approval. Acceptable use links to intake and classification, because a new use case of a general-purpose model can create new duties for the organization. Check that prohibited data entries, output review rules and disclosure of AI-generated content are specified. Evidence: an approved tool list, data handling rules, and access logs for sanctioned platforms.
Documentation and disclosure
The policy sets a standard documentation format, retention periods and a decision on which governance material is published, such as impact assessments or audit summaries. Standard templates let the same evidence serve providers, deployers and ISO/IEC 42001 audits. Check that documents are version-controlled and that the policy says which records each role must keep. Evidence: a documentation register, retention schedule and a published disclosure decision signed by the accountable owner.
How the policy aligns with ISO 42001 and the provider QMS
If your organization is working toward ISO/IEC 42001, the policy is a management system requirement before it is an AI Act document. Clause 5.2 of the standard asks top management to establish an AI policy, and in your statement of applicability the reference control for that policy is A.2.2, which asks you to document a policy for the development or use of AI systems. Annex B gives implementation guidance under B.2.2. Control A.2.3 asks you to identify where your other policies, such as information security, privacy and procurement, can be affected by or apply to your AI objectives, so the AI policy does not sit alone.
- Clause 5.2 policy: Approved by leadership, communicated, and available to interested parties in a form your auditor can sample.
- A.2.2 in the statement of applicability: Lists the policy as implemented, with a pointer to the document and its owner.
- A.2.3 interaction map: A short table linking the AI policy to security, privacy, data governance and third-party risk policies.
- Optional NIST documentation practice: The NIST AI RMF Playbook suggestions under GOVERN 1.4 can shape what your documentation policy covers, such as business justification, training data and deployment monitoring.
- Review cycle: A dated revision history showing the policy was reviewed after material changes to AI use.
Confirm the wording of clause 5.2 and Annex A against the published standard and use the NIST to ISO/IEC 42001 crosswalk as a starting point, not as proof of equivalence.
If you are a provider of a high-risk AI system, the policy must sit inside a quality management system that Article 17 requires. Article 17(1) asks for a QMS documented as written policies, procedures and instructions covering at least 13 aspects, including compliance strategy, design and development control, testing and validation, data management, risk management, post-market monitoring, incident reporting, record-keeping and an accountability framework. Article 17(2), as amended in 2026, allows the system to be proportionate to your size, including for SMEs, start-ups and small mid-cap enterprises, while keeping the rigor the compliance requires.
- Policy as the top layer: Your AI governance policy states the commitments that the procedures under Article 17 then implement.
- Coverage of the 13 aspects: A cross-reference table mapping each aspect to the procedure that covers it.
- Harmonised standard: EN 18286:2026 on quality management was cited in the Official Journal on 14 October 2026 and is the first harmonised standard in this area. Check which parts of it you intend to apply.
- Accountability framework: Named owners for each procedure, not only a policy signed at the top.
- Record retention: Procedures that say where QMS records are kept and for how long.
Confirm the EN 18286:2026 status and scope with the CEN-CENELEC material and the Commission's decision before relying on it.
Some organizations pursue ISO/IEC 42001 certification and also have high-risk systems that need an Article 17 QMS. The practical risk is two parallel policy sets that disagree. The safer approach is one AI governance policy with a control layer that serves both frameworks, so that a change to the policy updates the statement of applicability and the QMS procedures together. Leadership approval, document control and internal audit should run once, not twice.
- One policy, two cross-references: The policy cites clause 5.2 and A.2.2 for the standard and Article 17 for the AI Act, without restating either.
- Shared document control: A single register for policies, procedures and records with version numbers and owners.
- Gap list per framework: Items that the standard requires but the QMS does not cover, and the reverse, kept separately so each audit can be answered.
- Shared internal audit: One audit programme that samples both sets of evidence.
- Interaction with other policies: The A.2.3 map also shows where the AI policy meets your information security and privacy programmes.
Check the mapping line by line against the standard text and the Article 17 wording with your assessor, because a crosswalk is a reference, not an assurance that one set of records satisfies the other.
How to draft, approve and maintain the policy
The sequence turns scattered AI practices into one approved, accountable policy that staff can follow and an assessor can trace. Each step ends with a named output, so the policy can be shown to exist, to have been agreed by the people it binds, and to be kept current.
Scope the policy against the AI inventory
Start from the AI system inventory and list every place where the organization develops, provides, deploys, buys or lets staff use AI, including generative AI tools used on unmanaged accounts. Note which uses are provider activities, which are deployer activities and which may fall under the general-purpose model rules, because the policy has to assign duties to each role. The output is a written scope statement that names the business units, systems, vendors and roles the policy covers, and records what is out of scope and why. Confirm the scope with the person who owns the inventory before drafting begins.
Draft the policy around the settled decisions
Write the policy from the scope, covering accountability and roles, the intake and approval path for new AI uses, the risk classification method, the AI literacy measures, the acceptable use rules for generative AI, the documentation standard and the link to the provider's quality management system where one applies. Each section should state who decides, what they decide and what record they keep. The output is a first full draft with a version number, an owner and a short list of open decisions for the reviewers. Where the organization already runs ISO/IEC 42001 or an information security policy, map the draft to the existing clause or control references rather than repeating them.
Review with legal and privacy counsel
Send the draft to legal and privacy counsel to check the statements about AI Act roles, prohibited practices, transparency duties, data protection obligations for AI training and inference data, employee monitoring and contract terms with AI vendors. Counsel should confirm that the policy's role definitions match how the organization is actually classified under the Act and that no statement is a legal commitment the organization cannot meet. The output is a marked-up draft with each comment resolved, accepted or parked with a stated reason, and a sign-off record from counsel. Ask counsel to confirm which dates and fines they rely on from the Act as amended in 2026.
Review with security, risk and business owners
Walk the security team, the risk function, the data owners and the managers of the business units that use AI through the draft. Security checks the controls for logging, access, vendor review and incident handling, risk checks that the risk acceptance and escalation paths match the enterprise risk process, and business owners confirm that the intake and approval steps fit real workflows without blocking routine use. Record each objection and how it was settled. The output is a reviewed draft with a log of changes and the named reviewer for each section, which shows that the policy was tested against the operations it governs.
Obtain approval from the accountable executive
Present the reviewed draft to the executive who is accountable for AI risk, usually a member of the leadership team with authority over the business units in scope. The executive confirms the scope, the named roles and the resources the policy assumes, such as staff time for intake reviews and budget for training. Approval should be recorded in the governance body's minutes or an equivalent signed record that shows the date, the version approved and any conditions. The output is an approved policy version with the approver's name, role and approval date, filed where auditors and regulators can find it.
Roll out the policy and record training
Publish the approved policy in the location staff already use, and brief the people named in the roles section, including developers, product owners, procurement, HR and managers who approve AI use. Deliver AI literacy training that fits each group's role, since the Commission's Q&A confirms there is no mandatory training format, and keep attendance or completion records with the date, the course content and the version of the policy taught. The output is a rollout record and a training register that links each person to the policy version and the training they received, so the organization can show that the measures it chose were applied.
Schedule review and track changes
Set a review schedule in the policy itself and trigger an earlier review when the legal position changes, a new high-risk category is adopted, a new AI capability enters use, an incident shows a gap, or a harmonised standard relevant to the organization is cited. Each review repeats the scope, role and approval steps for any material change, while minor edits go through the owner with a logged version change. The output is a version history, a change log and a dated next-review record, which together show the policy is maintained rather than filed once.
What the policy work costs and who is paid for it
This table compares the cost components of writing and running an AI governance policy, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a quote checklist: ask each party for its share in writing before work starts, because the policy is only as durable as the staff time behind it.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Internal staff time | Your own staff (governance, legal, product, engineering, HR) | Both: drafting is one-time, reviews and approvals recur | Number of AI uses in scope, how many functions own a use, and how often the inventory changes |
| Legal review | Internal counsel or outside law firm | Mostly one-time, with recurring review after amendments | Whether the policy must reflect sector rules, employment law, and the AI Act amendments in Regulation (EU) 2026/1744 |
| Implementation partner drafting and operationalizing the policy | Implementation partner, under a written scope | One-time for drafting and rollout, optional retainer for upkeep | Agreed scope (roles, approval workflow, training, tooling), number of business units, and existing policy maturity |
| Tooling for the inventory and records | Software vendor or your own infrastructure team, if self-hosted | Recurring for licenses, hosting, and maintenance; one-time for setup | Number of AI systems tracked, integration with ticketing or identity systems, and retention requirements |
| Training and AI literacy materials | Internal L&D team or external trainer | Initial rollout is one-time, refreshers recur | Headcount in scope, role-based content, and whether training records must be kept as evidence |
| Independent auditor or certification body (if certification is sought) | Independent auditor or certification body | One-time for initial certification, recurring for surveillance audits | Scope of the management system, chosen standard, and the number of sites or business units covered |
| Ongoing governance operation | Internal governance committee or designated owner | Recurring | Frequency of new AI approvals, incidents, and regulatory changes that require policy updates |
Why AI governance policies stall or fail an assessment
A governance policy usually fails at the seams: between the people who own it, the gates that approve AI uses, the data rules that guide staff, and the records that prove it works. The cards below cover the pitfalls assessors look for first and how to close each one before the evidence is requested.
No named policy owner
A policy signed by the leadership team but owned by nobody cannot be kept current, and assessors ask who approves exceptions and who reviews the policy after each change. Name one accountable owner with the authority to pause an AI use, plus a deputy. Record the owner, the approvers for each role (provider, deployer, model user) and the review cycle in the policy itself. Check that each named person can show a recent decision they made under the policy.
Approval gates that bypass the inventory
Teams often approve a new AI tool through procurement or a product review that never writes the system into the AI inventory. The result is a policy that describes controls for systems the organization cannot list. Make the inventory entry a precondition for any approval, and require the approver to confirm the record exists. Sample recent purchases and SaaS features with AI functions and trace each one back to an inventory row and an approval.
Generative AI rules that ignore data classes
A blanket rule such as "do not paste confidential data into chatbots" is hard to apply and hard to audit. Staff need to know which data classes may enter which tools, including public, internal, personal and regulated data, and which tools are approved for each class. Tie the rule to the organization's existing data classification scheme and list approved tools by class. Test the rule by asking a few staff what they would do with a customer file.
Policy not linked to QMS records
For providers of high-risk systems, Article 17 requires a quality management system documented as written policies, procedures and instructions. A governance policy that sits apart from the QMS leaves assessors unable to trace a policy statement to a procedure, a training record or a design review. Map each policy section to the QMS procedure that operationalizes it and to the record it produces. Confirm the mapping with the people who run each procedure.
Literacy promised but not evidenced
Article 4 requires measures to support AI literacy for staff and others operating AI on the organization's behalf. The Commission's Q&A confirms that no certificate is required and no training format is mandatory, so the policy needs to say what the organization does and how it knows the measures are in place. Define the audience by role, the topics covered and the refresh trigger, then keep attendance and content records. Ask the owner which records would satisfy a regulator's question about literacy today.
Standard alignment that is claimed, not checked
Organizations sometimes write that the policy follows ISO/IEC 42001 without listing where A.2.2 and clause 5.2 are met, or without noting the related policies that A.2.3 asks them to identify. An auditor will test the statement of applicability against the policy text. Build a short crosswalk showing which policy section answers which requirement, and list the other policies (security, privacy, procurement) that the AI policy touches. Keep the crosswalk under change control with the policy.
Questions buyers ask about AI governance policy for the AI Act
Is an AI governance policy mandatory under the EU AI Act?
The AI Act does not use the words "AI governance policy" as a standalone duty, but several obligations cannot be met without one. Providers of high-risk systems must run a quality management system documented as written policies, procedures and instructions, and that system has to cover an accountability framework and compliance strategy. Deployers and all operators must also show AI literacy measures under Article 4. A written policy is the usual way to meet these duties in one place. Confirm the exact article-level obligations for your role against the consolidated text of Regulation (EU) 2024/1689 as amended in 2026, since dates and articles changed in that amendment.
Does the AI Act require ISO 42001 certification?
No. The AI Act does not require ISO/IEC 42001 certification, and no certificate is needed to show AI literacy compliance according to the Commission's own Q&A. ISO 42001 is a voluntary management system standard, and its policy requirement (clause 5.2) and reference control A.2.2 map well to what the policy must settle. Certification only matters if a customer, contract or internal decision asks for it. For high-risk providers, the harmonised standard EN 18286:2026 on quality management was cited in the Official Journal on 14 October 2026, and conformity can be shown through internal control for most Annex III systems. Ask your counsel which route applies to you.
How long does it take to draft an AI governance policy?
The timeline depends mainly on how many AI systems you run, how many roles touch them, and how much existing policy you can reuse. A small organization with a few deployed tools and an existing information security policy may need a short drafting cycle, while a provider with high-risk systems and a QMS to align will need more review time. The main drivers are the size of the AI inventory, the number of approval bodies (legal, HR, security, product), and whether the policy must be harmonized with ISO 42001 or your quality management system. Ask any consultant for a written scope with milestones before work starts, and separate one-time drafting from the recurring review cycle.
Can our team write the AI governance policy without outside help?
Yes, many organizations draft the policy in-house, and the AI Act does not require an external author. The work that is hard to do alone is the cross-functional part: agreeing who owns each AI system, who approves new uses, and how the policy connects to existing security, privacy and quality policies. Outside help is most useful for gap analysis against the Act and ISO 42001, for reviewing the draft with legal counsel, and for turning the policy into procedures and records that an auditor can test. An implementation partner can prepare the documents and evidence, but the organization owns the policy and an independent auditor or certification body is the one that issues any report or certificate.
Do generative AI tools need their own acceptable use rule?
A separate rule is not strictly required, but most organizations find that generative AI needs explicit treatment because staff can paste personal, confidential or client data into tools without a second thought. The policy should set which tools are approved, what data classes may be entered, when output must be reviewed by a person, and how generated content is labeled where Article 50 transparency duties apply. NIST AI 600-1, the Generative AI Profile of the NIST AI RMF, offers actions you can adapt for these choices. Keep the rule short enough to be read and enforced, and link it to the AI inventory so that each approved tool has a recorded role and purpose.
Who should approve the AI governance policy?
The policy should be approved by senior management with authority over the organization's AI activity, such as the executive who owns risk or the board committee that oversees it. It should name a single accountable owner for the policy and for AI Act compliance, usually someone in compliance, legal, or the office that runs risk management, with technical leads responsible for the systems they run. Ask how approval is recorded, how changes are reviewed, and how often the policy is re-approved. An auditor will look for evidence that the approver had the mandate and that the policy was reviewed after material changes such as new high-risk uses or the 2026 amendments.
What will an auditor ask to see for the policy?
An assessor will usually ask for the approved policy with version history, the named roles and their responsibilities, and proof that the policy is in use. Expect requests for the AI system inventory and its classification decisions, the approval records for new AI uses, AI literacy training or awareness records, and the documentation standards that cover technical files, logs and impact assessments. For ISO 42001 readiness, the auditor will also test the statement of applicability and whether the policy was communicated to staff. The evidence should show that the policy operates, not just that it exists. Confirm the requirements that apply to your audit or notified body with that body before preparing the pack.
When to bring in an implementation partner and what to keep in-house
The split is simple to state and easy to blur in practice: the organization decides its risk appetite, owns its AI governance policy and signs it, while an implementation partner drafts the policy text, builds the approval workflow it describes and prepares the evidence that shows the workflow runs. An independent auditor or certification body assesses the result and is the only party that issues a certificate or report. A partner that offers to sign off compliance, or an auditor that drafts your policy, has crossed a line that should worry you. Keep the decisions that define your accountability, including who may approve a high-risk use, how much residual risk leadership accepts and which generative AI tools staff may use, inside the organization, with named owners and dated sign-off.
Ask for a written scope before any work starts. The scope should list the deliverables by name (for example, the policy document, the approval workflow configuration, the register of approved AI uses, the role matrix and the training records), the systems the work touches, the roles from your side who must review and approve each item, and the acceptance test for each deliverable. Ask the partner to state which parts of the AI governance evidence it will only prepare and which, if any, it will attest to, and confirm that neither party will describe the result as certified or compliant unless an independent assessor has said so. Where a standard is in view, such as ISO/IEC 42001 for the management system or the quality management system the AI Act expects of high-risk providers, confirm the scope against the clauses and controls you plan to cite, not against a general description of the framework.
Before you engage a partner, check three things with your own legal, risk and procurement teams: which AI Act roles your organization holds for each system (provider, deployer or both), whether any system may fall into a category that requires a notified body under Article 43, and which dates in the official Regulation text apply to your obligations after the 2026 amendments. Those answers determine how much of the policy work is governance drafting and how much is technical evidence, which in turn determines the size and cost of the engagement. Ask any partner for a quote built from that written scope, and confirm which costs are one-time (drafting, workflow setup, training) and which recur (policy review, inventory upkeep, audit support).
How DeployOpen works on this
DeployOpen helps organizations draft and put into practice an AI governance policy that supports AI Act compliance, working inside the client's own infrastructure. The organization owns its policy and decisions, and an independent auditor or certification body issues any report or certificate.
How we scope
- Agree the AI systems, business units and roles the policy must cover in writing before work starts.
- Confirm which approval gates, documentation standards and AI literacy activities the client already runs today.
- Define deliverables, responsibilities and timelines in a fixed-scope agreement, with the quote following from that written scope.
How we build
- Draft the policy around accountability, classification and approval of new AI uses, and acceptable use of generative AI.
- Map the policy to the client's existing quality management system and ISO/IEC 42001 clause 5.2 and control A.2.2 references.
- Test the approval workflow and documentation templates against a sample of real AI use cases in the client's environment.
How we hand over
- Deliver the approved policy, role descriptions, decision records and documentation templates in editable form.
- Walk the owners and approvers through the workflow so they can run it without outside help.
- Provide a written evidence list showing which records the organization must keep and where they are stored.
How we support
- Offer ongoing support as a retainer for policy reviews as AI Act dates and harmonised standards develop.
- Update the policy, templates and approval workflow when new AI systems or uses enter the inventory.
- Confirm with your auditor or certification body which evidence they expect before any formal assessment.
