Answer box
The EU AI Act entered force August 2024 with extraterritorial reach — if your AI affects EU users, you're in scope regardless of headquarters. It sorts AI into four risk tiers (unacceptable, high, limited, minimal), with the heaviest obligations on high-risk systems and general-purpose AI (GPAI) providers. The December 2024 Digital Omnibus pushed most Article 6(2) high-risk obligations from August 2026 to December 2027. What did not shift: prohibited practices (February 2025), GPAI obligations (August 2025), AI literacy under Article 4 (February 2025), and the penalty regime. For EU AI Act compliance in 2026, do four things now — finish an AI system inventory, assign each system a risk tier and regulatory role, stand up an AI literacy program with evidence, and build technical documentation and a risk-management system for anything plausibly high-risk. The Omnibus runway isn't idle time; it's the window to get organized before audits start.
The four risk tiers, with what each requires
Obligations scale with potential harm. Most enterprise systems sit in high-risk or limited-risk, and the most common failure is misreading which tier you're in.
Unacceptable risk (prohibited)
Banned use cases: social scoring by public authorities, manipulative subliminal techniques, untargeted facial-image scraping, real-time biometric ID in public spaces (narrow law-enforcement exceptions), emotion recognition in workplaces and schools, and predictive policing based on profiling alone. No compliance posture exists — you stop deploying or remove from EU markets. Enforceable since February 2025.
High-risk
Ninety percent of your CISO attention belongs here. Annex III high-risk covers AI in employment decisions, credit scoring, essential services, biometric ID, critical infrastructure, education access, law enforcement, migration, and administration of justice. Medical devices and other Annex I regulated products are also captured. High-risk carries the full stack: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, post-market monitoring, conformity assessment, and EU database registration.
Limited-risk
Chatbots, emotion recognition outside prohibited contexts, biometric categorization, and generative AI producing synthetic content carry transparency obligations only. Users must know they're interacting with an AI, and AI-generated content (including deepfakes) must be labeled in a machine-readable way. Lighter, but real, and applies to most consumer-facing GenAI.
Minimal-risk
Spam filters, AI in games, inventory optimization. No formal duties, but document why a system landed here. The justification is the deliverable — in an audit, "we decided it was minimal-risk" is not a defense; "we applied the Annex III intended-purpose test and recorded the result" is.
| Risk tier | Examples | Key obligations | Deadline |
|---|---|---|---|
| Unacceptable | Social scoring, workplace emotion recognition, untargeted scraping for face DBs | Banned outright | In force February 2025 |
| High-risk | HR screening, credit scoring, biometric ID, critical infrastructure AI, medical devices | Full Article 6–27 stack: risk management, data governance, technical docs, human oversight, conformity assessment, registration, post-market monitoring | December 2027 (most), August 2026 (some Annex I products) |
| Limited-risk | Chatbots, deepfake/synthetic media, biometric categorization | Transparency: disclose AI interaction, label AI-generated content | August 2026 |
| Minimal-risk | Spam filters, AI in games, inventory optimization | No formal duties; voluntary codes of conduct encouraged | N/A |
What changed with the Digital Omnibus delay
The December 2024 Digital Omnibus pushed most Article 6(2) high-risk obligations from August 2026 to December 2027. That headline created the impression the Act was "delayed" — wrong in ways that matter for how you allocate engineering and legal hours.
What got delayed: operational obligations for Annex III high-risk systems — risk management (Article 9), data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), human oversight (Article 14), accuracy and robustness (Article 15), conformity assessment, and database registration. Most enterprise AI sits here, so you have until December 2027.
What did not shift: Article 5 prohibited practices (February 2025), the Article 4 literacy duty (February 2025), GPAI provider obligations on transparency, copyright, and foundation-model documentation (August 2025), and the penalty regime. The Annex I category — AI embedded in regulated products like medical devices — runs on existing sectoral timelines, several of which hit in 2026.
The operational read: don't use the delay as cover to defer your governance program. Literacy and the prohibited-practice scan are live, and a banned system in production carries fines up to €35 million or 7% of global turnover. Treat December 2027 as a hard deadline and use the next eighteen months properly. Our full delay explainer walks through each Article under the new timeline.
The 10-point CISO checklist
- Inventory every AI system you deploy or develop. Including shadow AI — marketing's third-party copywriting tool, analytics' auto-classifier, the chatbot support spun up over a weekend. If it ingests data and produces output that influences a decision or user experience, it's in scope. Most enterprises discover 3–5x more AI in production than they expected.
- Classify each system by Annex III risk tier. Use the "intended purpose" test, not the technology. A logistic regression for credit scoring is high-risk; the same model for inventory forecasting is minimal-risk. Record the reasoning, signoff, and date — that audit trail is the deliverable.
- Identify your regulatory role per system: provider, deployer, importer, or distributor. Providers place an AI system on the market under their own name; deployers use it in professional activity. Providers do the conformity assessment, deployers do the human oversight. Most enterprises are deployers, but fine-tuning a foundation model and putting it in production can turn you into a provider without anyone noticing.
- Establish an AI literacy program (Article 4 — already enforceable). Staff and contractors operating AI need "sufficient" literacy. No curriculum is mandated, but you need evidence: role-based training matched to system risk, completion records, refresh cadence. A board member approving a high-risk deployment needs different literacy from a data scientist tuning the model — design for both.
- For high-risk: build the technical documentation (Article 11). Annex IV lists what goes in — system description, intended purpose, components, data sources, training methodology, validation procedures, known limitations, risk measures, post-market monitoring plan. Treat it as a living document owned by the system owner. In an audit, this is the first thing requested.
- For high-risk: implement a risk management system (Article 9). Iterative — identify foreseeable risks, evaluate against intended purpose and reasonably foreseeable misuse, mitigate, test. The Article is process-prescriptive: a model card is not enough; you need documented risk reviews on a defined cadence with clear ownership.
- For high-risk: data governance protocols (Article 10). Training, validation, and test data must be relevant, representative, error-free to the extent possible, and complete. Document data sourcing, processing, and bias examination. The hard part is usually proving representativeness for your specific intended-use population.
- For high-risk: post-market monitoring (Article 72). A documented plan for collecting performance data, detecting drift, and escalating issues. Connects to incident response — production performance degrading below your declared accuracy threshold can be a reportable event.
- For GPAI: provider transparency and copyright disclosure. If you develop or fine-tune a general-purpose model and make it available to others, you owe a public training-data summary, a copyright compliance policy, and technical documentation for downstream deployers. Above the "systemic risk" compute threshold, add model evaluation, adversarial testing, cybersecurity, and incident reporting. Most enterprises are downstream of GPAI rather than providers — but check.
- Establish an Article 73 incident-reporting workflow. Serious incidents on high-risk systems must be reported within tight windows — 15 days for most events, 2 days for incidents involving life or critical infrastructure. You need a trigger taxonomy, an escalation path that doesn't bottleneck on legal, and templates ready. One of the most operationally underestimated requirements in the Act.
To benchmark your current posture against this list, the AI governance maturity assessment takes about fifteen minutes.
The five most common self-classification mistakes
1. Under-classifying creditworthiness assessment as limited-risk
Annex III is explicit: AI used to evaluate creditworthiness or establish credit scores (narrow carve-outs for financial fraud detection) is high-risk. Organizations classify these as limited-risk because "the human always makes the final call" — but the designation is about the AI's role in a consequential decision, not whether a human rubber-stamps the output.
2. Missing the "intended purpose" test on dual-use models
Classification follows intended use, not architecture. The same off-the-shelf NLP model can be minimal-risk for email categorization and high-risk for screening job applicants. Teams that classify "the model" once and reuse the classification across use cases get this wrong.
3. Forgetting that off-the-shelf AI in HR is in scope
Buying a vendor tool does not move you out of the deployer obligation set. CV screening, performance evaluation, task allocation, and termination-decision support are all Annex III. If HR uses a vendor's AI module for any of these, you are the deployer, you owe human oversight and record-keeping, and you need to verify the provider's conformity assessment exists.
4. Assuming "we only use it internally" exempts you
The Act applies to systems placed on the market or put into service. Internal deployments are in service. Internal HR analytics, internal credit risk models, internal employee monitoring — all in scope.
5. Treating fine-tuning as a no-op for regulatory role
Take a foundation model, fine-tune it on your data, deploy it under your name for a high-risk purpose — you have likely become a provider, and provider obligations are heavier. Teams miss this because the fine-tuning team and the governance team don't talk. Set up a checkpoint: any model modification triggers a role re-assessment.
Documentation requirements at a glance
The Act is documentation-heavy by design — the point is to make AI auditable. Use this as a starting RACI.
| Requirement | Article | Likely owner | Effort |
|---|---|---|---|
| Risk management system (lifecycle process) | Article 9 | AI governance lead + system owner | High |
| Technical documentation (Annex IV) | Article 11 | Engineering lead per system | High |
| Data governance documentation | Article 10 | Data engineering + DPO | Medium |
| Automated logging and event records | Article 12 | Engineering / platform | Medium |
| Conformity assessment | Article 43 | Compliance / external notified body where required | High |
| EU database registration | Article 49 | Compliance | Low |
| Post-market monitoring plan | Article 72 | System owner + SRE | Medium |
| Serious incident logs and reports | Article 73 | Security operations + legal | Medium |
| AI literacy training records | Article 4 | People ops + security awareness | Low |
| Human oversight procedures | Article 14 | Business owner of deployed system | Medium |
The trap is treating each row as a separate workstream. Most of this documentation overlaps with what you already produce for SOC 2, ISO 27001, or NIST AI RMF — the unified AI compliance crosswalk maps the overlaps explicitly.
How AccuroAI maps to EU AI Act
Governance work feels overwhelming because most teams build a separate evidence pipeline for every framework — one for NIST AI RMF, one for ISO/IEC 42001, one for the EU AI Act, one for sector regulators. AccuroAI inverts that. You collect evidence once at the system level — risk assessments, data lineage, model cards, oversight logs, incident records — and the platform maps it to article-level requirements across every framework you're subject to.
Concretely: a single risk register entry satisfies Article 9 (EU AI Act), the GOVERN function of NIST AI RMF, and clause 6.1 of ISO/IEC 42001 at the same time. Technical documentation collected once for Article 11 maps to ISO/IEC 42001 Annex A controls and your NIST AI RMF MAP profile. Article 4 literacy records feed your ISO/IEC 42001 competence evidence. Article 72 post-market monitoring runs on the same telemetry pipeline that powers your SOC 2 continuous-monitoring evidence. For regulated sectors the platform extends to sector mappings — our healthcare AI security playbook shows the HIPAA overlay.
The bet is straightforward: AI governance will look more like SOX or PCI-DSS over the next five years — continuous, evidence-driven, auditable. Spreadsheets work in 2026; by 2028 they don't scale.
FAQ
Do non-EU organizations need to comply?
Yes, if your AI's output is used in the EU or EU residents are affected by its decisions. The Act has GDPR-style extraterritorial reach. A US SaaS with AI features accessible to EU users is in scope. A model provider whose API is consumed by an EU deployer is in scope. Geography of headquarters is irrelevant; geography of effect is what matters.
What's the difference between a provider and a deployer?
A provider develops an AI system and places it on the market or puts it into service under its own name. A deployer uses an AI system under its own authority in professional activity. Providers carry conformity assessment, technical documentation, and registration; deployers carry human oversight, intended-purpose monitoring, and record-keeping. You can be both on different systems. Substantially modifying a high-risk system or putting it out under your name can convert you from deployer to provider.
Do shadow AI tools count?
Yes. If a team uses an AI tool — sanctioned or not — your organization is the deployer. Deployer obligations attach to the organization, not the individual who clicked "sign up." Discovering the shadow inventory is step one because regulators won't accept "we didn't know" as a defense.
Can vendors transfer their liability to me through contracts?
No. The Act assigns obligations by role, and roles cannot be contractually reassigned to move statutory liability. A vendor can indemnify you for breaches, and you should negotiate strong indemnities and audit rights — but the regulator will still come to whoever owes the obligation. Contracts allocate economic risk, not statutory accountability.
What do the penalty caps look like?
Three tiers. Prohibited practices: up to €35 million or 7% of global annual turnover, whichever is higher. Most other violations: up to €15 million or 3%. Misleading information to authorities: up to €7.5 million or 1%. SMEs and startups get the lower of the two amounts — meaningful relief for smaller players.
Can SMEs use lighter obligations?
Partially. The substantive obligations remain, but SMEs get priority access to regulatory sandboxes, simplified technical documentation formats, fee reductions for conformity assessment, and the SME-friendly penalty calculation. Member States are also encouraged to provide SME-specific guidance.
To pressure-test your timing against the August 2026 milestones, the August 2026 countdown breaks down which workstreams land before that date and which can wait for 2027.