Learn
The short answer
The EU AI Act does not ask for an "AI policy". For a high-risk system it asks a provider to build and keep a document set: a risk management system, data governance, technical documentation, automatic logging, instructions for use, human oversight measures, a quality management system and a post-market monitoring plan. Deployers carry a lighter and different set. Writing one policy document and filing it satisfies none of this. What it costs to get this wrong is set out in EU AI Act penalties and fines, and the one obligation that already applies to everyone is covered in AI literacy requirements.
The obligations sit in Regulation (EU) 2024/1689, mostly Articles 9 to 17 for providers and Article 26 for deployers.
On this page
- What the Act actually requires
- Provider or deployer: your role sets your list
- The provider document set, article by article
- What deployers have to hold
- The policies teams write that the Act does not name
- Where AI Act documentation overlaps with ISO 42001 and ISO 27001
- How to build the set without starting from a blank page
- Frequently asked questions
What the Act actually requires
The framing that causes the most wasted effort is treating the AI Act like a data protection exercise where one well-written policy discharges the duty. The high-risk regime is closer to product conformity law: you build a system, you document how it was built and how it is controlled, and you keep that documentation current and available.
Search interest reflects the confusion. People look for "EU AI Act policies" and "EU AI Act policy requirements" when what the Act names is a risk management system, technical documentation and a quality management system. The vocabulary gap is the first thing to fix.
Provider or deployer: your role sets your list
Nothing else matters until this is settled. A provider develops an AI system or has one developed and places it on the market under its own name or trademark. A deployer uses an AI system under its own authority in a professional capacity.
The trap: a deployer that puts its own name on a high-risk system, or substantially modifies one, can become a provider and inherit the provider obligations. Organisations that fine-tune or rebrand bought-in models should check this carefully rather than assume they are deployers.
The provider document set, article by article
| Article | What you must have | What it looks like in practice |
|---|---|---|
| Article 9 | A risk management system, running across the lifecycle | A documented, iterative process with identified risks, mitigations and residual risk, reviewed and updated |
| Article 10 | Data and data governance | Criteria and practices for training, validation and testing data, including relevance, representativeness and examination for bias |
| Article 11 and Annex IV | Technical documentation, drawn up before the system is placed on the market | The single largest artefact: system description, design, development process, monitoring, performance and risk management |
| Article 12 | Automatic recording of events over the lifetime of the system | Logging designed into the system, with retention appropriate to its purpose |
| Article 13 | Transparency and instructions for use | Documentation that lets a deployer interpret the output and use the system properly |
| Article 14 | Human oversight measures | Designed into the system so a person can understand, intervene and stop it |
| Article 15 | Accuracy, robustness and cybersecurity | Declared performance metrics and the measures protecting the system |
| Article 17 | A quality management system | Written policies, procedures and instructions covering the whole compliance approach |
| Article 72 | A post-market monitoring plan | How you collect and review performance data once the system is in use |
| Article 73 | Serious incident reporting | A route and a process to report to the market surveillance authority within the Act's deadlines |
Article 17 is the one most often missed, and it is the one that reads most like a policy. A quality management system under the AI Act is a documented set of policies, procedures and instructions covering regulatory compliance, design control, testing, data management, post-market monitoring, incident reporting and record keeping. If someone asks you for your "AI Act policy", this is usually the thing they mean.
What deployers have to hold
Article 26 places a narrower set on deployers of high-risk systems: use the system in accordance with the instructions for use, assign human oversight to people with the competence and authority to exercise it, ensure input data is relevant and sufficiently representative where you control it, monitor operation, keep the automatically generated logs where they are under your control, and inform the provider and authorities where a serious incident or a risk arises.
Some deployers also carry a fundamental rights impact assessment obligation. Employers deploying a high-risk system at work must inform affected workers before putting it into use.
So a deployer's realistic document set is: a record of the systems in use and their classification, the instructions for use held on file, a named oversight owner per system, log retention, an incident route, and the impact assessment where required.
The policies teams write that the Act does not name
Several documents are worth writing even though no article names them, because they make the named artefacts possible.
- An AI system inventory. You cannot classify what you have not listed, and classification drives every other obligation.
- An acceptable use policy for AI at work. This governs the shadow AI problem that creates unclassified systems.
- A procurement standard for AI systems. The point at which to demand instructions for use and technical documentation is before you sign, not after.
- An AI literacy plan. Article 4 obliges providers and deployers to take measures to ensure a sufficient level of AI literacy among staff dealing with the systems.
Where AI Act documentation overlaps with ISO 42001 and ISO 27001
Most of the quality management system and much of the risk management process overlaps with an existing management system. If you hold ISO 27001, the governance scaffolding, document control, internal audit and management review already exist and can be extended rather than duplicated. ISO 42001 overlaps more directly still, and we compared the two in ISO 42001 and the EU AI Act.
The part that does not come free is Annex IV technical documentation. It is specific to the system, it describes design and development choices, and no management system standard produces it for you.
How to build the set without starting from a blank page
- Inventory and classify. List every AI system, decide prohibited, high-risk, limited-risk or minimal, and write down the reasoning. Our guide to who has to comply and from when covers the tiers and the dates.
- Fix your role per system. Provider, deployer or both. Record it.
- Reuse the management system you have. Document control, internal audit and management review carry across from ISO 27001.
- Write the Article 17 quality management system next. It is the spine the other artefacts hang from.
- Build Annex IV documentation per high-risk system. This is per system rather than per company, and it is the long pole.
- Stand up logging, oversight and the incident route before go-live. These are design decisions, and retrofitting them is expensive.
Do this in Venvera
Venvera holds the EU AI Act as a maintained control set: classify each system by risk tier, generate the policy and quality management documents against the articles they satisfy, track Annex IV documentation per system, and keep the evidence current. Policies generated here are mapped to the controls they cover, so the same evidence answers ISO 27001 or ISO 42001 where the requirements overlap. See the EU AI Act workspace, or start with the free EU AI Act compliance checklist. Pricing is published and flat, from EUR 399 per month.
Frequently asked questions
What policies does the EU AI Act require?
The Act does not name a single "AI policy". For high-risk systems a provider must have a risk management system (Article 9), data governance (Article 10), technical documentation (Article 11 and Annex IV), logging (Article 12), instructions for use (Article 13), human oversight measures (Article 14), and a quality management system of documented policies and procedures (Article 17). Article 17 is the closest thing to what people mean by a policy.
Is there an EU AI Act policy template?
Templates help with the quality management system and the surrounding policies, but Annex IV technical documentation is specific to each system and cannot be templated meaningfully. Treat any single-document "AI Act policy template" with suspicion.
What documentation do deployers need?
Under Article 26, deployers use the system per the instructions for use, assign competent human oversight, monitor operation, retain the automatically generated logs under their control, and report serious incidents. Some deployers additionally carry a fundamental rights impact assessment, and employers must inform affected workers before putting a high-risk system into use.
Does ISO 42001 satisfy the EU AI Act?
It covers a large part of the management system expectations and it is a voluntary certification rather than a legal obligation, so it does not discharge the Act on its own. Annex IV technical documentation in particular has no ISO 42001 equivalent.
How long does the documentation take to build?
The quality management system is weeks if you already run ISO 27001 and are extending it. Annex IV technical documentation is per high-risk system and is the item that sets the schedule, because it describes design and development decisions that have to be gathered from the people who made them.
