EU AI Act Compliance in 90 Days: A Practitioner's Playbook

If your organisation deploys or develops an AI system that lands in Annex III of Regulation (EU) 2024/1689 — the EU AI Act — you have until 2 August 2026 to bring it into compliance with Article 6's high-risk obligations. That's 63 days from publication of this post.

The penalty for getting it wrong is not theoretical. Under Article 99(4), non-compliance with high-risk system obligations carries fines up to €15 million or 3% of total worldwide annual turnover, whichever is higher. Prohibited-practice violations under Article 99(3) reach €35 million or 7%. Member-state authorities — under Article 71 — can request your technical documentation at any time.

Most teams I've worked with underestimate the scope. The EU AI Act is not a "have policies" problem. It's a "have a quality management system" problem (Article 17), with a risk management lifecycle (Article 9), a data governance regime (Article 10), and a 9-section technical documentation file (Annex IV) that you have to maintain throughout the system's operational life. Bolt-on compliance doesn't survive scrutiny.

The good news: 90 days is enough to get a single high-risk system to conformity-assessment-ready, if you sequence the work correctly. This post is the week-by-week playbook I'd run if I had to do it myself.

Days 1–15: AI system inventory + Annex III classification

You can't comply with Article 6 until you know which of your AI systems trigger it. The first two weeks are spent building an honest inventory and classifying each entry against Annex III.

The inventory. Capture every AI system — production, internal tooling, third-party SaaS with embedded AI — touching EU data or EU users. For each, record: the intended purpose (Article 3(12)), the system's role (provider, deployer, importer, distributor per Article 3(3)–(7)), the data inputs, the human users, the affected persons, and the deployment region. Spreadsheet is fine; what matters is completeness.

Annex III classification. Annex III lists eight high-risk areas:

1. Biometric identification and categorisation of natural persons (real-time and post-event, plus emotion recognition and biometric categorisation by sensitive attributes).
2. Critical infrastructure — safety components in management/operation of digital infrastructure, road traffic, water/gas/heating/electricity supply.
3. Education and vocational training — access decisions, evaluation of learning outcomes, steering, monitoring during tests.
4. Employment, workers management, and access to self-employment — recruitment screening, performance evaluation, task allocation, monitoring.
5. Access to and enjoyment of essential private services and essential public services and benefits — eligibility for public assistance, creditworthiness, emergency services dispatch, life and health insurance risk/pricing.
6. Law enforcement — risk assessment of natural persons, polygraph and similar, evidence reliability evaluation, profiling.
7. Migration, asylum and border control management — risk assessment, examination of applications, identification of natural persons.
8. Administration of justice and democratic processes — interpretation of facts and law by judicial authorities, influencing the outcome of elections.

The Article 6(3) procedural exemption. This is where many teams over-scope. A system listed in Annex III is not high-risk if it falls into one of four exemptions in Article 6(3): (a) intended to perform a narrow procedural task, (b) intended to improve the result of a previously completed human activity, (c) intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review, or (d) intended to perform a preparatory task to an assessment relevant for the purposes of the use cases listed in Annex III. The provider must document the assessment in technical documentation per Annex IV and register the exemption in the EU database per Article 49(2). Half the systems my clients initially classify as Annex III turn out to qualify for 6(3) exemption — but only when the exemption assessment is documented contemporaneously.

Output at day 15. A scoped inventory with classification + rationale for each entry. Systems you're confident are not Annex III get archived. Systems with Article 6(3) exemptions get documented per Annex IV. Everything else moves to day 16.

Days 16–30: Article 9 risk management system

Article 9 mandates a documented risk management system that runs throughout the AI system's entire lifecycle. This is the spine of EU AI Act compliance. Get this right and the next four sections follow naturally; get it wrong and you'll be rewriting the technical documentation later.

Article 9(2) specifies that the risk management system must consist of "a continuous iterative process planned and run throughout the entire lifecycle." Concretely, it must:

• Identify and analyse the known and reasonably foreseeable risks the system poses to health, safety, or fundamental rights when used in accordance with its intended purpose.
• Estimate and evaluate risks that may emerge from reasonably foreseeable misuse.
• Evaluate other risks possibly arising from post-market monitoring data (Article 72).
• Adopt appropriate and targeted risk management measures to address identified risks.
• Test the system to verify the risk management measures are effective.
• Specifically target risks where mitigation or elimination cannot be achieved through design or development.

Most organisations skip the foreseeable-misuse analysis because it's uncomfortable. That's the gap auditors catch. If your system can be misused to discriminate, manipulate, or surveil — and any meaningful AI system can — Article 9(2)(b) requires you to estimate that risk explicitly and document mitigation.

Output at day 30. A documented risk register per AI system. Each entry has: risk description, severity, likelihood, mitigation measure, owner, review cadence. Risk register lives in your governance system, not in a Word document a single person owns.

Days 31–45: Article 10 data governance

Article 10 governs training, validation, and testing datasets. The standards are stricter than most teams expect.

Article 10(2) requires "appropriate data governance and management practices" covering, among other items: data provenance, data collection processes, relevant data preparation operations (such as annotation, labelling, cleaning, updating), the formulation of assumptions, and an assessment of the availability, quantity, and suitability of datasets.

Article 10(3) sets the bar that breaks most retrospective compliance efforts: training, validation, and testing datasets shall be relevant, sufficiently representative, free of errors, and complete in view of the intended purpose. The recital makes clear "free of errors" is a relative standard — you don't need a perfect dataset, you need one whose error profile is documented and bounded.

Article 10(5) provides a narrow but important exception: providers may process special categories of personal data to ensure bias detection and correction — strictly for that purpose, with technical limitations on reuse, and only when bias detection cannot reasonably be achieved through synthetic or anonymised data.

The practical sequence. Build a data lineage record per dataset (provenance, transformations, version). Then run bias testing across protected categories. Then document the residual bias and the mitigation. Most of the work is in the lineage record — bias testing without lineage doesn't pass scrutiny because you can't say where the bias came in.

Output at day 45. Per training, validation, and testing dataset: a lineage document, a bias assessment, a mitigation note, and a statement of conformity with Article 10(2)(c)–(h) criteria.

Days 46–60: Article 11 + Annex IV technical documentation

Article 11 requires that technical documentation is drawn up before the system is placed on the market or put into service, and kept up to date. The content of that documentation lives in Annex IV, which has nine sections — this is the physical artefact you will hand to a notified body (if required) or to a member-state authority.

The Annex IV sections, summarised:

1. General description of the AI system — intended purpose, provider details, version, hardware required, deployment forms, instructions for use.
2. Detailed description of elements — methods and steps for development, design specifications, system architecture, data requirements and selection, human oversight measures, validation and testing procedures.
3. Monitoring, functioning, control — capabilities, limitations, expected accuracy levels, foreseeable unintended outcomes and sources of risks.
4. Risk management description — the Article 9 system you built in days 16–30.
5. Lifecycle changes — description of any change to the system made by the provider during its lifecycle.
6. List of harmonised standards applied (in full or in part) — once the harmonised standards are published, conformance to them confers a presumption of conformity under Article 40.
7. Copy of the EU declaration of conformity (Article 47).
8. Detailed description of the post-market monitoring system (Article 72).
9. List of test reports and validation procedures.

In practice, most teams treat Annex IV as a sharepoint folder. That works until the document set develops contradictions — risk register doesn't match technical specs, post-market monitoring lacks the metrics the validation reports defined, the EU declaration claims standards the documentation doesn't apply. Treat the technical documentation as a single living document with a strong table of contents, version control, and a named owner.

Output at day 60. A complete Annex IV file. Every section populated with content that cross-references the other sections accurately.

Days 61–75: Articles 12, 13, 14 — logging, transparency, human oversight

Three articles, all of which need design-level decisions rather than bolt-on policies.

Article 12 — logging. The system must automatically record events ("logs") over its lifetime. The logs must ensure traceability of the system's functioning appropriate to its intended purpose. For Annex III(1) biometric identification systems, the recording requirements are explicit in Article 12(3): period of use, reference database checked, input data leading to a match, identification of the natural persons involved in verification.

The gap most observability stacks have: application-level logs aren't enough. Article 12 wants a log of inference events — input identity, output, confidence, timestamp, model version — at a granularity that supports post-hoc reconstruction of a decision.

Article 13 — transparency to deployers. The system must be designed so that deployers can interpret the system's output and use it appropriately. Article 13(3) lists the information that must accompany the system: identity and contact of the provider, characteristics and capabilities, performance, level of accuracy, robustness and cybersecurity, foreseeable circumstances of use, human oversight measures, expected lifetime, maintenance and care measures.

This is the document you hand to the team integrating the AI system, the document that — together with Annex IV — your customer auditors will read.

Article 14 — human oversight. Article 14(4) lists five categories of human oversight measure that the system must enable: (a) understanding the relevant capacities and limitations, (b) remaining aware of automation bias, (c) correctly interpreting the system's output, (d) deciding not to use the output or override or reverse it, and (e) intervening or interrupting through a "stop" function. Human oversight is not a policy. It's a UI commitment plus an organisational role plus a documented escalation path.

Output at day 75. Article 12 logging implemented at inference granularity. Article 13 instructions-for-use document complete. Article 14 oversight measures designed into the deployment surface and trained on by named human operators.

Days 76–90: Article 43 conformity assessment + Article 49 registration

The final stretch. You choose a conformity assessment route, you complete the assessment, you draft the EU declaration of conformity, and you register the system in the EU database.

Article 43 — conformity assessment routes. For most Annex III systems, you follow internal control per Annex VI — the provider conducts the assessment and issues the declaration. For Annex III(1) biometric identification systems where harmonised standards have not been published, you must use a notified body assessment per Annex VII. Most teams will be on the Annex VI internal-control route.

Annex VI internal control has four steps: confirm the technical documentation is complete, verify the quality management system per Article 17 is established and operating, verify the risk management Article 9 is implemented, verify the system is consistent with the documentation.

Article 47 — EU declaration of conformity. A formal document signed by the provider stating the system conforms to the regulation's requirements. Annex V lists the content. Article 47(2) requires the declaration to be drawn up in (at least) one of the official EU languages required by the member state where the system is placed on the market.

Article 48 — CE marking. Affix the CE mark visibly to the system, accompanying documentation, or — for systems where physical marking isn't possible — to the packaging or interface.

Article 49 — registration in the EU database. Providers register their high-risk systems in the database before placing them on the market or putting them into service. Annex VIII lists the information required: the provider's details, EU representative (if applicable), trade name, intended purpose, system status, member states the system is placed on the market in, instructions for use.

Output at day 90. The system has a complete technical documentation file. The quality management system per Article 17 is documented. The conformity assessment per Annex VI is complete. The EU declaration of conformity is signed. The system is registered in the EU AI database. You can demonstrate compliance to a member-state authority on request under Article 71.

What to do if you're behind

Some honest paths if you're starting after the 90-day window has begun.

Revisit Article 6(3) exemptions. Half my clients' first-pass Annex III classifications turn out to be exempt under one of the four procedural exemptions when reviewed by a second pair of eyes. Documenting the exemption is itself a deliverable, but it's a smaller deliverable than full Article 9 + Annex IV compliance.

Phase the work, communicate transparently. Get the inventory + risk register + Article 17 quality management system established first. Conformity assessment and Annex IV completion can run in a follow-on 60-day sprint. If you have enterprise customers asking about your roadmap, most will accept "milestone-based roadmap with documented progress" over "complete on day one but undocumented."

Cut scope on systems that genuinely aren't business-critical. A system you deployed for an internal experiment that nobody actually uses can be decommissioned faster than it can be made compliant. The Article 6 obligation attaches when the system is placed on the market or put into service — withdrawing it before 2 August 2026 removes the obligation.

Pair with existing GRC, don't replace it. If you've already built compliance infrastructure for SOC 2, ISO 27001, or HIPAA, much of the Article 17 quality management work overlaps. Don't build a parallel system. The EU AI Act explicitly contemplates QMS overlap in Article 17(3) — "Providers of high-risk AI systems that are subject to obligations regarding quality management systems or an equivalent function under relevant sectoral Union law may include the aspects listed in paragraph 1 as part of the quality management systems pursuant to that law." Financial institutions get a stronger version in Article 17(4), where most QMS obligations are deemed fulfilled by existing financial-services-law internal-governance rules (except for risk management, post-market monitoring, and incident reporting under Article 17(1)(g)–(i)).

Where Ayliea fits

We built Ayliea's EU AI Act readiness surface to do the parts of this playbook that are mechanical — Annex III classification, conformity assessment generation against Annex IV's nine sections, and ongoing monitoring of GPAI sub-processors. The AISS open standard at CC-BY-4.0 — our open AI-security control set — gives you the methodology to score against, separate from any vendor. Both pair with whatever existing GRC platform you've already standardised on; we don't ask you to replace Vanta, Drata, or Sprinto.

Ayliea sells AI governance software, so treat this section as our pitch. The first ten sections above stand on their own — the EU AI Act doesn't care which tools you use to comply with it.

If you're at day 0 of the 90-day window today, start with the inventory and the Annex III classifications. The rest of the playbook has structure precisely because the early decisions narrow scope for the later weeks. The one thing not to do is wait — the default 24-month transition window in the first paragraph of Article 113 was designed assuming organisations would use it. (Article 113(c)'s 36-month extension applies only to high-risk AI systems that are safety components of products covered by Annex II — for standalone Annex III systems, the date is 2 August 2026.)

Article 6 enforces 2 August 2026. Sixty-three days from now.