eu_ai_act_readiness v1.0.0

name: "eu_ai_act_readiness" description: "Get a product or organisation ready for the EU AI Act (Regulation (EU) 2024/1689, as amended by the 2026 Digital Omnibus): classify each AI system into the risk tiers with a worksheet, work out the duties per tier for providers and deployers, build the technical documentation, transparency, human oversight and logging evidence, and run a dated action plan worked back from the application dates that are actually in force. Triggers on EU AI Act readiness or compliance, AI Act risk classification, Annex III or high-risk AI questions, Article 50 transparency duties, GPAI model obligations, a FRIA, or an AI conformity assessment plan."

EU AI Act Readiness

Purpose

Run a working readiness pass under the EU AI Act and leave behind artefacts a team can operate: a signed classification worksheet for every system, duty checklists split by provider and deployer, an Annex IV documentation gap list, a fundamental rights impact assessment decision, and a dated plan worked back from the application date that applies to each system. This is general information and an operating method, not legal advice. Counsel reviews prohibited practice calls, derogation claims and final conformity decisions.

Workflow

1. Inventory first, and fix the roles. One row per AI system or use: name and version, who provides it, who deploys it, the intended purpose in one paragraph, where the output is used, and whether people are profiled or scored. Roles decide duties, and one organisation is usually both provider and deployer for different systems. Watch for Article 25: putting your name or trademark on a high-risk system, substantially modifying one, or changing a system's intended purpose so it becomes high-risk makes you its provider, with the full provider duty set. The trap case is a general-purpose model wrapped in a product that ranks job applicants.
2. Screen every system against Article 5 before classifying anything. Use the practice list in references/classification-worksheet.md. Any match stops the run for that system: the practice is banned, prohibitions have applied since 2 February 2025, and the ceiling is 35 million euros or 7 percent of worldwide annual turnover. Two practices join the list on 2 December 2026, generating non-consensual intimate material and generating child sexual abuse material. Record the screen result for systems that pass, too.
3. Classify with the worksheet, in order. Run scripts/classify.py for each system and file the output with the inputs it was given. The order matters: Article 5 first, then the Annex I product route in Article 6(1), then the Annex III use case route in Article 6(2), with the Article 6(3) derogation tested last. The derogation never applies where the system profiles natural persons, and a provider claiming it must document the assessment before placing the system on the market (Article 6(4)). Classification follows the documented intended purpose, never the sector the organisation works in. Annex III has eight areas, from biometrics to administration of justice, and the specific listed use case must match, as set out in references/classification-worksheet.md.
4. Run Article 50 separately, because it stacks on every tier. A minimal risk chatbot still owes transparency duties. Check the four triggers with the classifier flags: direct interaction with people (provider designs in the disclosure, 50(1)), synthetic audio, image, video or text output (provider marks it in machine-readable form, 50(2)), emotion recognition or biometric categorisation (deployer informs the people exposed, 50(3)), and deepfakes or AI text published to inform the public on matters of public interest (deployer discloses, 50(4)). Disclosure is clear and distinguishable, at the latest at first interaction or exposure. Detail and exceptions are in references/duties-by-role.md.
5. Check Chapter V if anyone provides a general-purpose AI model. Article 53 duties (technical documentation, information for downstream providers, copyright policy, published summary of training content) applied from 2 August 2025, and models placed on the market before that date must comply by 2 August 2027. A model whose cumulative training compute exceeds 10^25 floating point operations is presumed to have systemic risk and adds Article 55: evaluation including adversarial testing, systemic risk assessment and mitigation, serious incident tracking and reporting, and cybersecurity. Building a system on someone else's model does not make you the model provider. Modifying a model heavily can, and Commission guidance uses training compute above a third of the original model's as the significance marker.
6. Build the duty lists by role. For high-risk providers: the seven system requirements in Articles 9 to 15 (risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy, robustness and cybersecurity), plus quality management (Article 17), 10 year documentation retention (Article 18), at least 6 months of logs under the provider's control (Article 19), corrective action (Article 20), post-market monitoring (Article 72) and serious incident reporting (Article 73). For high-risk deployers: Article 26, use per instructions, named oversight people with real authority to overrule, relevant input data where the deployer controls it, monitoring with suspension and reporting on risk, logs under the deployer's control kept at least 6 months, workers and their representatives informed before workplace use, and people informed when they are subject to a decision based on the system's output. Full checklists are in references/duties-by-role.md.
7. Decide the FRIA question on its own trigger, not on vibes. A fundamental rights impact assessment under Article 27 is required before first use by deployers that are bodies governed by public law or private entities providing public services (except Annex III point 2 critical infrastructure systems), and by any deployer of an Annex III point 5(b) credit scoring system or point 5(c) life and health insurance pricing system. A private employer deploying a recruitment tool does not trigger Article 27 on that fact alone. Where a GDPR data protection impact assessment exists, build on it, and still answer every Article 27 element, including complaint mechanisms.
8. Gap the documentation and the evidence, version by version. Check the Annex IV pack against references/annex-iv-and-evidence.md: general description, development detail including training data provenance, monitoring and control information, performance metrics, the Article 9 risk file, lifecycle changes, standards applied, the declaration of conformity, and the post-market monitoring plan. Then test the live controls, not the paperwork: automatic logging demonstrated on the real system, retention actually configured, the stop procedure actually run, disclosures actually shown at first interaction, machine-readable marking actually detected on real output.
9. Close the market steps for providers. Record the conformity route per system: Annex III points 2 to 8 use internal control under Annex VI with no notified body; Annex III point 1 biometrics uses Annex VII with a notified body unless harmonised standards or common specifications covering the requirements were applied in full; Annex I embedded systems follow the sector legislation procedure. Then the EU declaration of conformity (Article 47), CE marking (Article 48) and EU database registration before placing on the market (Article 49), with the point 2 registration exception checked rather than assumed.
10. Turn the gaps into a dated plan. Run scripts/plan_dates.py per route and work back from the date that applies: prohibited practices 2 February 2025, GPAI 2 August 2025, Article 50 transparency 2 August 2026 with the marking transition for pre-existing systems ending 2 December 2026, legacy GPAI models 2 August 2027, Annex III high-risk Thursday 2 December 2027, Annex I embedded high-risk Wednesday 2 August 2028. Every gap gets one owner and one date. A route whose deadline has passed is triaged in milestone order with the exposure stated plainly, and evidence is never backdated.
11. Score, assign, and set the re-run triggers. Rate each area ready, partial or missing, on artefacts seen: worksheets, risk file, dataset datasheets, Annex IV pack, logging demonstration, oversight roster, conformity evidence, notices sent, FRIA where triggered, transparency tests. Re-run the whole pass when a new system launches, an intended purpose changes, a system is substantially modified, a vendor swaps the underlying model, or new harmonised standards or Commission guidance land. A change of purpose is a reclassification event, not an edit to a spreadsheet.

Output Contract

• A readiness report with: the system inventory with roles, the classification worksheet output per system with its inputs and assessment date, the Article 5 screen results, any Article 6(3) derogation claims with their documented reasoning, the Article 50 duties triggered per system, and the GPAI position where a model is provided.
• Duty gap lists split by role: provider gaps against Articles 9 to 27, 43, 47 to 49, 72 and 73; deployer gaps against Article 26, with the Article 27 FRIA decision and its reasoning stated either way.
• The Annex IV documentation gap list per high-risk system, tied to system versions, plus the results of the live control tests (logging, retention, stop procedure, disclosures, marking detection).
• A dated plan per route from scripts/plan_dates.py, with one owner and one date per gap, and overdue routes flagged with the days overdue and the triage order.
• A plain statement of what was not checked, for example a specific product line, offline uses, or a vendor's internal model documentation, and every item flagged for counsel.
• No invented law. Every date, amount, threshold and article reference in the report traces to Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, a Commission page, or the AI Act Service Desk, with the source named. Pre-Omnibus summaries are stale and must not be copied.

Operating Rules

• Use the post-Omnibus dates or do not publish the plan. The Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026, moved stand-alone Annex III high-risk obligations from August 2026 to 2 December 2027 and Annex I embedded obligations from August 2027 to 2 August 2028. Any source still quoting the old dates for high-risk work is out of date, including most 2024 and 2025 guidance. The bans, the GPAI duties and Article 50 did not move.
• Article 4 applies at every tier and in every role: providers and deployers take measures to support the development of AI literacy of staff and others who operate or use the systems on their behalf. As amended in 2026, no specific level has to be guaranteed for any individual, but the measures must exist, fit the people's roles and the context of use, and be documented well enough to show an authority what was done.
• Penalty ceilings, Article 99: up to 35 million euros or 7 percent of worldwide annual turnover, whichever is higher, for prohibited practices; up to 15 million euros or 3 percent for breaches of the other operator obligations, including Articles 16, 26 and 50; up to 7.5 million euros or 1 percent for supplying incorrect, incomplete or misleading information to notified bodies or national authorities. For SMEs and start-ups, the cap is the lower of the fixed amount and the percentage. The Omnibus extends several SME proportionality measures to small mid-caps; check the current text before relying on that for a specific company.
• Retention numbers are floors with owners: provider documentation 10 years (Article 18), provider logs at least 6 months (Article 19), deployer logs at least 6 months (Article 26(6)), each subject to other EU or national law that applies. Vendor contracts that delete faster than the floor create the breach.
• Serious incident reporting has short, varied deadlines under Article 73, counted from awareness, with 2 days for widespread infringement or serious disruption of critical infrastructure, 10 days where a person has died, and 15 days in other cases. Recheck the consolidated text before filing, rehearse the route once before it is needed, and never hold a first report back to finish an internal investigation.
• The AI Act runs alongside the GDPR, it does not replace it. Lawful basis, data subject rights, GDPR Article 22 safeguards for automated decisions and GDPR Article 35 impact assessments still apply to the same systems, and a FRIA is not a DPIA even where one document covers both.
• Harmonised standards for the high-risk requirements were still in development when the Omnibus passed, which is part of why the dates moved. Where a requirement has no finished standard yet, document the solution adopted and the reasoning, as Annex IV point 7 expects, instead of leaving the section blank.
• Worked example, verified with the bundled scripts on an assessment date of Wednesday 28 October 2026: a 40 person company deploying a vendor CV screening tool is a deployer of a high-risk system, Annex III area 4 (employment), and because the tool profiles candidates the Article 6(3) derogation is not available. The Article 26 duties apply from Thursday 2 December 2027, which is 400 days out: classification signed off by Wednesday 2 December 2026, oversight roles named and vendor conformity evidence requested by Sunday 7 March 2027, log retention set to at least 6 months and the monitoring procedure drafted by Saturday 5 June 2027, worker and candidate notices drafted by Friday 3 September 2027, and notices sent with oversight staff trained by Tuesday 2 November 2027. No FRIA is triggered for this private employer on these facts. Its separate support chatbot, checked the same day, is not high-risk, but its Article 50 disclosure and marking duties have applied since 2 August 2026, so that route is already overdue and gets triaged first.