How Best to Proceed with the EU AI Act
- Proceed in this order: live obligations, inventory, classification, gap assessment, build, monitor.
- Deal with Article 50 first. It is in force now and it is small, concrete work.
- Classification is the decision everything else depends on, and it is the one to slow down for.
- Sequence the technical files by the date each system's obligations bind, not by convenience.
- Plan the monitoring function at the same time as the build, because the Act has no completion point.
Stage 1: Deal with what is already in force
Proceed in this order: fix what is already in force, find every AI system, classify each one, assess the gap, build what is missing, then monitor for the life of each system. The most common mistake is starting with the high-risk requirements because they are the most discussed, while leaving a live transparency obligation unaddressed.
Each stage below carries one or two decisions that are hard to reverse. Those are the ones worth slowing down for.
Three sets of obligations bind now, and they are small enough to handle quickly.
Prohibited practices and the AI literacy duty have applied since February 2025. General purpose AI model obligations have applied since August 2025.
The Article 50 transparency obligations took effect on 2 August 2026. If a system interacts with people, tell them. If it generates or manipulates synthetic audio, image, video or text, mark the output in machine-readable form. Disclose deep fakes. Inform people subject to emotion recognition or biometric categorisation.
Two further dates land soon. On 2 December 2026, Article 50(2) reaches systems that were already on the market on 2 August 2026, and the new prohibitions on AI generating non-consensual intimate imagery and child sexual abuse material take effect.
Decision at this stage: which customer-facing systems need a disclosure, and where it appears.
Stage 2: Inventory
Every AI system your organisation provides or uses, including AI features inside purchased software.
For each: what it does, who owns it, what data it uses, whether it affects decisions about people, which markets its output reaches, and whether it is offered under your name.
Ask departments what tools they use that generate content, rank, score or recommend. That question surfaces more than asking whether they use AI.
Decision at this stage: none, but the completeness of this list determines whether every later stage is accurate.
Stage 3: Classification
Two determinations per system.
Your role: provider or deployer, or both. Check specifically whether you have become a provider by rebranding a third-party system, modifying it substantially, or using it for a purpose the original provider did not intend.
The tier: prohibited, high risk under Annex III or Annex I, subject to Article 50, or minimal.
Record the reasoning, not just the conclusion. Where a system is genuinely borderline, record that too, along with the position taken and why. A classification you cannot explain is one you will pay to redo.
Decision at this stage: the classification itself, and who inside your organisation signs it off. That accountability should sit with you rather than with an adviser.
Stage 4: Gap assessment
Compare each system against the duties its classification attaches, and state what is met, what is not, and what closes each gap.
Sequence the output by the date each system's obligations bind rather than by which is easiest. Article 50 systems first, then Annex III high-risk systems working back from 2 December 2027, then Annex I embedded systems working back from 2 August 2028.
Our readiness and gap assessment delivers this requirement by requirement for a fixed fee.
Decision at this stage: the remediation plan, the sequence, and who does each item.
Stage 5: Build
For high-risk systems: the risk management process, data governance evidence, the Annex IV technical file, automatic logging, instructions for deployers, human oversight design, accuracy and robustness measures, the quality management system, conformity assessment and EU database registration.
Two items usually take longest and should start first. Data governance under Article 10, because the answers about training data often sit with a supplier or with people who have left. And human oversight, because doing it properly means changing a process rather than writing a paragraph.
Where models were bought rather than built, raise the Article 10 questions with your supplier at the start of this stage, not at file-writing time.
Decision at this stage: which processes genuinely change, as opposed to which documents get written.
Stage 6: Monitor
Post-market monitoring runs for the life of each high-risk system: collecting performance data, feeding it back into risk management, and updating the technical file so it describes the system as it is.
Serious incidents must be reported to the relevant authority within defined windows, which means knowing in advance what counts, who reports, and to whom.
Add a classification gate to procurement and to your launch checklist so new systems arrive assessed rather than being discovered later. That single process change prevents most of the work that would otherwise recur.
This is our continuous governance and assurance service, and it is the stage that makes the AI Act a standing function rather than a project.
The order, in one table
| Stage | Output | Decision that is hard to reverse |
|---|---|---|
| 1. Live obligations | Article 50 disclosures in place | Which systems need one |
| 2. Inventory | Complete list of AI systems with owners | None, but completeness determines everything after |
| 3. Classification | Register with recorded reasoning | The classification, and who signs it off |
| 4. Gap assessment | Requirement-by-requirement position, sequenced by date | The remediation plan |
| 5. Build | Technical files, controls, oversight, logging | Which processes change |
| 6. Monitor | A running governance function | Who owns it permanently |
The dates that now apply
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibited practices; AI literacy duty |
| 2 August 2025 | General purpose AI model obligations; governance; penalties framework |
| 2 August 2026 | Article 50 transparency obligations, except Article 50(2) for systems already on the market |
| 2 December 2026 | Article 50(2) for those legacy systems; new prohibitions on nudifier and CSAM-generating AI |
| 2 August 2027 | National AI regulatory sandboxes in operation |
| 2 December 2027 | High-risk obligations, stand-alone Annex III systems |
| 2 August 2028 | High-risk obligations, AI embedded in Annex I regulated products |
These reflect the Digital Omnibus on AI, endorsed by the European Parliament on 16 June 2026, approved by the Council on 29 June 2026, and in force since July 2026.
What to do next
Check your customer-facing systems for Article 50 disclosures this week, since that obligation is already live. Then start the inventory.
Our free AI impact assessment gives an immediate first view, and the EU AI Act service page sets out how we run each stage.
References
FAQ
What is the first step in an EU AI Act programme?
Check what is already in force. The Article 50 transparency obligations took effect on 2 August 2026 and are small, concrete work.
Should we wait for the 2027 deadlines?
No. Obligations are live now, new prohibitions arrive in December 2026, and classification takes weeks to months for anything beyond a few systems.
Who should sign off the classification?
Your organisation. An adviser provides the analysis, the reasoning and the recommendation, and records any genuine uncertainty, but the decision sits with you.
How long does a programme take?
Inventory and classification typically two to six weeks. A build for an organisation with high-risk systems commonly three to six months, driven by how many technical files are needed.
When does the work end?
It does not. Post-market monitoring and incident reporting continue for the life of each system, which is why the monitoring owner matters as much as the build.
About Hael
Hael is an advisory firm specialising in AI governance and security compliance. We do the work, hold the deadline and stand behind the evidence, across the EU AI Act, ISO/IEC 42001, SOC 2 and ISO 27001, and maintain the position afterwards. Every engagement has a named practitioner and an agreed scope, timetable and fee. On engagements involving regulated financial services firms we work alongside Buckingham Capital Consulting, the partner firm that has advised payment and e-money firms on FCA authorisation and compliance since 2013.
This guide is general information and is not legal advice on your particular circumstances.