AI Act compliance by design: 8 steps for building in the EU

AI Act compliance by design means building the EU AI Act's requirements into an AI product while you develop it, rather than auditing them in afterwards. In practice it comes down to eight steps: define the intended purpose, classify the risk, fix your role, govern your data, design transparency, build in logging and human oversight, document as you go, and monitor after launch. For most products the effort is modest; for high-risk systems it is substantial, and the Annex III deadline is 2 December 2027.

Key takeaways

• Compliance by design under the EU AI Act starts with a written intended purpose, because the use case, not the technology, decides your obligations.
• Classify early: prohibited, high-risk, transparency-only or minimal risk, and record your role as provider or deployer for each system.
• Build transparency, logging and human oversight into the architecture; they are expensive to retrofit and the transparency duties already apply.
• For high-risk products, EN 18286 is the first harmonised standard for the quality management system, and SMEs and small mid-caps get simplified documentation options.
• The Annex III deadline of 2 December 2027 leaves roughly one product cycle: start documentation now, alongside the code.

Why design for the AI Act instead of checking at the end?

Because several requirements are architectural. Logging, human oversight controls and machine-readable marking of generated content are hard to add once a product is live, and the evidence a high-risk provider needs (data provenance, test results, design decisions) is easiest to capture at the moment it is created. The obligations themselves are set out in the AI Act as amended by the Digital Omnibus on AI.

What are the eight steps of AI Act compliance by design?

Step 1: Write down the intended purpose

Describe in a paragraph what the system does, for whom, in what setting and with what limits. The AI Act attaches obligations to the use, so this sentence drives everything else. Be specific: "ranks inbound job applications for recruiters" and "drafts replies for support agents to edit" land in very different places.

Step 2: Classify the risk

Check four tiers in order: prohibited practices under Article 5; high-risk under Article 6 (Annex I products or Annex III uses such as employment, credit and education); transparency duties under Article 50 (chatbots, generative output, deepfakes); and minimal risk. The Commission's overview gives examples of each tier. Our high-risk AI classification checklist walks through the tests, including the Article 6(3) exemption and its documentation duty.

Step 3: Fix your role and your supply chain

Decide whether you are provider, deployer or both for each system, and record which general-purpose AI models you build on. Model providers must give downstream providers the information needed to integrate their models under Article 53. Put responsibilities in contracts: who discloses, who marks output, who reports incidents. Remember that repurposing a general model for a high-risk use makes you the provider under Article 25.

Step 4: Govern your data

For high-risk systems, training, validation and test data must meet quality and governance requirements. Record sources, licences, cleaning steps and known gaps from day one. The Omnibus added Article 4a, which allows processing of special categories of personal data to detect and correct bias, under strict conditions. GDPR applies alongside throughout.

Step 5: Design transparency into the interface

If users interact with the system, they must be told it is AI at the latest at the first interaction, unless obvious; if it generates content, outputs must be marked in a machine-readable, detectable way. These duties under Article 50 have applied since 2 August 2026. The Commission's Article 50 guidelines suggest first-turn greetings and visible labels for chatbots and spoken notices for voice agents. For high-risk systems, also plan the instructions for use you will give deployers.

Step 6: Build in logging and human oversight

High-risk systems need logging and must be designed so people can oversee them effectively; both are among the core requirements the Commission lists for the tier. Deployers must keep the logs under their control for at least six months and assign oversight to trained staff, so your product should make both easy: exportable logs, clear confidence indicators, the ability to override or stop. Even outside the high-risk tier, these controls reduce the damage from wrong outputs.

Step 7: Document as you build

High-risk providers need technical documentation and a quality management system. Three things make this lighter than it sounds:

• A standard to build to. On 14 October 2026 the Commission cited EN 18286:2026, a quality management system standard for AI Act purposes, in the Official Journal through Implementing Decision (EU) 2026/2274. Following a cited harmonised standard gives a presumption of conformity with the requirements it covers.
• Simplified quality management for SMEs. Under amended Article 63, SMEs and start-ups without partner or linked enterprises may implement certain quality management elements in a simplified way, with Commission guidelines to follow. The obligations in Articles 9 to 15, 72 and 73 still apply.
• Simplified technical documentation. The Commission confirms that simplified documentation has been extended to small mid-caps as well as SMEs.

Keep documentation in the repository next to the code: architecture decisions, data sheets, evaluation reports and change logs.

Step 8: Test, monitor and be ready to report

Evaluate accuracy, robustness and bias before launch against thresholds you set in advance, and keep the results. After launch, high-risk providers need post-market monitoring and serious incident reporting. The Omnibus asks the Commission to provide post-market monitoring guidance and a voluntary template by 2 September 2027. Our guide to evaluating an LLM feature before launch covers the testing side in practical terms.

How do the steps differ by risk class?

Step	Minimal risk	Transparency (chatbot, generative AI)	High-risk
1. Intended purpose	Recommended	Recommended	Required, drives documentation
2. Classification	Record it	Record it	Record it; exemptions must be documented and registered
3. Roles and contracts	Good practice	Allocate disclosure and marking	Required along the value chain
4. Data governance	GDPR only	GDPR only	AI Act data requirements plus GDPR
5. Transparency	None specific	Article 50 duties	Article 50 if applicable plus instructions for use
6. Logging and oversight	Good practice	Good practice	Required
7. Documentation and QMS	AI literacy record	AI literacy record	Technical documentation, QMS, conformity assessment
8. Monitoring	Good practice	Good practice	Post-market monitoring, incident reporting

Where can a startup test with regulators?

In an AI regulatory sandbox. Each Member State must have at least one operational by 2 August 2027, access is free for SMEs, and the exit report must be taken into account positively in conformity assessment. See our guide to AI regulatory sandboxes in Europe.

Compliance-by-design checklist

• [ ] Intended purpose written and agreed
• [ ] Prohibited-practice check recorded
• [ ] Risk class and Article 6(3) reasoning documented
• [ ] Role recorded for each system and model dependency
• [ ] Vendor and customer contracts allocate AI Act duties
• [ ] Data sources, licences and gaps logged
• [ ] AI disclosure shown at first interaction
• [ ] Generated output machine-readably marked
• [ ] Event logging and override controls built
• [ ] Documentation stored with the code
• [ ] Pre-launch evaluation thresholds and results kept
• [ ] Post-market monitoring and incident process defined
• [ ] Team AI literacy measures recorded

Frequently asked questions

Does compliance by design apply if my AI product is not high-risk?

Yes, but the list is shorter. Every AI product needs a clear intended purpose, a check against prohibited practices, AI literacy for the team and, for chatbots and generative features, the Article 50 transparency measures that have applied since 2 August 2026. The heavy documentation and conformity work applies only to high-risk systems.

Do I have to follow EN 18286?

No. Harmonised standards are voluntary. Following a standard whose reference is published in the Official Journal gives a presumption of conformity with the requirements it covers, which simplifies proving compliance. You can meet the requirements another way, but you then have to show how.

Are there simplified rules for startups?

Yes. SMEs, including start-ups, without partner or linked enterprises can implement certain quality management elements in a simplified way, and the Omnibus extended simplified technical documentation to SMEs and small mid-caps. These options reduce paperwork but do not remove the underlying requirements.

Can I use sensitive personal data to test my model for bias?

The Digital Omnibus added Article 4a, which allows processing of special categories of personal data for detecting and correcting bias, under strict conditions. GDPR still applies in full, so plan this with your data protection adviser and document the safeguards.

When should I start if my product will be high-risk?

Now. Annex III obligations apply from 2 December 2027, and documentation, testing and a quality management system take months to build. Starting during development is far cheaper than reconstructing evidence after launch.

If you are planning an AI product for the EU market and want compliance built into the roadmap from the start, book a free 30-minute call.

Cover photo by cottonbro studio on Pexels.