The European regulation on artificial intelligence — Regulation (EU) 2024/1689, the "EU AI Act" — entered into force on 1 August 2024. It applies in stages. 2 August 2026 is the date set in the text for the heaviest phase for most European companies: the operational obligations for high-risk AI systems. Not a consultation, not a best-practice guide — enforceable obligations, backed by fines of up to €15 million or 3% of worldwide turnover.
The question every CISO, DPO or Chief Compliance Officer at a bank, insurer, telecom operator, public body or any company running a scoring engine, CV screening, fraud detection or video surveillance is asking: am I compliant? This article answers point by point.
1. The timeline — where things actually stand
The regulation was adopted on 12 July 2024, published in the Official Journal the same day, and entered into force on 1 August 2024. Application follows a three-year compliance schedule:
| Date | What applies |
|---|---|
| 2 February 2025 | Absolute prohibitions (Art. 5): social scoring, subliminal manipulation, emotion recognition at work, untargeted facial-image scraping |
| 2 August 2025 | Obligations for general-purpose AI models (GPAI): technical documentation, training-data summary, copyright compliance, governance |
| 2 August 2026 | Operational obligations for high-risk systems (Art. 6 + Annex III) — the subject of this article |
| 2 August 2027 | High-risk systems embedded in products already covered by sectoral legislation (medical devices, toys, vehicles…) |
2 August 2026 therefore concerns the majority of enterprise AI use cases, not just foundation-model providers.
The postponement proposed by the Commission
In November 2025, the European Commission proposed, in its "digital omnibus" package, to delay the Annex III high-risk obligations until harmonised standards are available — with an end-2027 backstop mentioned — and the Annex I obligations to 2028. At the time of writing this is a proposal: it must be adopted by Parliament and Council to change the timeline above. Two practical consequences: do not build your plan on a postponement that has not been voted, and know that national market-surveillance authorities are being set up now. Check the status of the text with counsel before fixing your milestones.
2. Am I concerned? The map of high-risk systems
A system is high-risk if it falls under one of the eight areas of Annex III. The most common in business:
- Employment and HR — CV screening, candidate ranking, promotion or termination decisions, monitoring of performance and behaviour.
- Access to essential services — creditworthiness scoring, life and health insurance pricing, eligibility for public benefits.
- Biometrics — remote biometric identification, categorisation by sensitive attributes.
- Critical infrastructure — safety components in water, gas, electricity, digital infrastructure.
- Education — admission, assessment, proctoring.
- Law enforcement, migration, justice — risk assessment, evidence evaluation.
Three questions to settle it
Bank: does your scoring engine pre-approve credit without documented human validation? Yes → high-risk. Large company: does your ATS filter CVs before a recruiter sees them? Yes → high-risk. Insurer: does your health pricing use a predictive model on personal data? Yes → high-risk.
An exemption exists (Art. 6(3)) when the system performs a narrow procedural task, improves the result of a human activity, or does not materially influence the decision. It must be documented — a note in a file, before the audit, not after.
3. The seven operational obligations (Art. 8 to 15)
A high-risk system must meet seven core obligations. They are cumulative, not alternative.
3.1 Risk management system (Art. 9)
A continuous, iterative process: identification of foreseeable risks, evaluation, mitigation measures, testing. Not a frozen document — a lifecycle that lives with the system.
3.2 Data governance (Art. 10)
Training, validation and test datasets must be relevant, representative, as error-free and complete as possible. Bias examination is mandatory. Provenance, collection and labelling must be documented.
3.3 Technical documentation (Art. 11)
Drawn up before the system is placed on the market and kept up to date. Annex IV lists the content: general description, development process, monitoring and control, performance metrics, risk management, changes over time.
3.4 Record-keeping / logging (Art. 12)
Automatic logging of events over the system's lifetime, sufficient to trace its operation, identify situations of risk and support post-market monitoring. Logs must be retained, timestamped and attributable.
3.5 Transparency and information to deployers (Art. 13)
Instructions for use that let the deployer understand capabilities, limitations, expected accuracy, known risks, and the human-oversight measures required.
3.6 Human oversight (Art. 14)
Designed so that a natural person can understand the system, remain aware of automation bias, correctly interpret output, decide not to use it, override a decision, and interrupt it. The oversight must be effective, not nominal.
3.7 Accuracy, robustness and cybersecurity (Art. 15)
Appropriate levels of accuracy declared in the instructions, resilience to errors and inconsistencies, and protection against attempts to alter use or performance — including data poisoning, model poisoning and adversarial examples.
4. Provider vs deployer: who does what
The provider develops the system or has it developed and places it on the market. The deployer uses it under its own authority. Most companies are deployers — and deployers have their own obligations (Art. 26): use according to instructions, assign competent human oversight, ensure input data is relevant, keep logs for at least six months, inform workers, and — for public bodies and certain private uses — perform a fundamental-rights impact assessment (Art. 27). Substantially modifying a system, or using it for a purpose the provider did not intend, makes you a provider.
5. Penalties — the cost of non-compliance
| Breach | Maximum fine |
|---|---|
| Prohibited practices (Art. 5) | €35 M or 7% of worldwide turnover |
| Other obligations, including high-risk | €15 M or 3% of worldwide turnover |
| Incorrect or misleading information to authorities | €7.5 M or 1% of worldwide turnover |
For SMEs, the lower of the two amounts applies. For everyone else, the higher.
6. Compliance checklist — five actionable axes
- Map your high-risk AI uses. Full inventory of AI systems in production or in project, cross-referenced with Annex III: system name, purpose, input data, decisions produced, provider, role (provider / deployer), high-risk yes/no.
- Document risks and mitigations. For each high-risk system: identified risks (bias, error, drift), mitigations in place, tests performed, monitoring indicators. A living register, not a deliverable.
- Ensure operational traceability. Logs of prompts / requests, of decisions produced, of human oversight interventions. Retained, timestamped, attributable. Without this, no demonstration of compliance is possible.
- Make human oversight effective. Not "a human validates" on paper. Document who supervises, when, with what competence, and give that person the real power to contradict the system and interrupt it.
- Prepare the technical file. Annex IV sections, versioned, tied to the actual system in production. If a provider supplies the system, obtain its documentation now.
GDPR is not enough
A DPIA covers personal data. The AI Act covers the system: its accuracy, its robustness, its oversight, its logs — even when no personal data is involved. The two regimes stack; neither replaces the other.
7. How CompliForge automates the audit
Most of the work above is inventory, cross-referencing and documentation — exactly what AI agents do well, provided they run inside your perimeter. CompliForge deploys on your infrastructure:
- An AI Act agent that maps your AI uses from your application registry, cross-references them with Annex III, and produces the per-system classification.
- A Documentation agent that generates the Annex IV sections from your existing artefacts (models, data, metrics, mitigations).
- An on-premise traceability layer that captures logs, prompts, decisions and human oversight without sending a single byte to a third-party cloud.
- A compliance dashboard per system: status of the seven obligations, gaps, action plan.
Everything runs on your infrastructure, with sovereign models (Mistral, DeepSeek on-premise) or your own cloud keys. None of your data leaves your perimeter.
EU AI Act compliance audit — 30 minutes
Mapping of your high-risk uses, identification of the obligations that apply to you, prioritised action plan. Free consultation, no commitment.