EU AI Act Requirements: What to Know in 2026

Key Takeaways

• The Digital Omnibus on AI, in force since 27 July 2026, pushed the Annex III high-risk deadline to 2 December 2027 and the Annex I deadline to 2 August 2028 — but prohibited practices, AI literacy, GPAI obligations, and Article 50 transparency rules are already applicable and enforced.
• High-risk classification depends on intended purpose measured against Article 6 and Annex III, not on industry alone — a bank, hospital, or HR department can run plenty of AI systems that never trigger high-risk obligations.
• Credit scoring is high-risk under Annex III point 5(b) by default, with a narrow exception for systems whose main purpose is genuinely fraud detection.
• Providers and deployers carry distinct obligations; buying an AI product does not transfer a vendor's compliance responsibilities to the buyer.
• The AI Act and GDPR are separate, overlapping frameworks — satisfying one does not satisfy the other, and both need active attention wherever personal data flows through an AI system.
• A Fundamental Rights Impact Assessment applies to a specific, limited set of deployers and use cases — it is not a universal requirement.
• The extended timeline is an opportunity to build durable governance infrastructure, not a reason to deprioritize the work.

What are the EU AI Act requirements for businesses in 2026? Businesses must already comply with the AI Act's bans on prohibited practices and its transparency rules for AI-generated content, which took effect in 2025 and August 2026. High-risk obligations — risk management, technical documentation, human oversight, and conformity assessment — were due in August 2026 but were postponed by the Digital Omnibus on AI to 2 December 2027 for most high-risk use cases, and 2 August 2028 for AI embedded in regulated products. The delay is a scheduling change, not a reduction in scope.

If you read that and thought "wait, wasn't August 2026 the big deadline?" — you're not wrong, and you're also not alone. For most of 2025 and early 2026, every EU AI Act explainer online pointed to 2 August 2026 as the date high-risk obligations would bite. That changed in mid-2026, and a lot of compliance calendars built around the old date are now out of sync with the law. This guide reflects the current legal position as of September 2026, after the Digital Omnibus on AI entered into force.

One caveat before we go further: this article is written for compliance, security, privacy, and technical leaders trying to understand what applies to their organization. It is not legal advice, and following it does not make a company compliant on its own — the AI Act ties specific obligations to how a given AI system is classified and used, which is a fact-specific exercise that usually needs legal input.

What Is the EU AI Act?

The EU AI Act (Regulation (EU) 2024/1689) is the European Union's horizontal regulation governing the development, marketing, and use of AI systems. It exists because the EU concluded that AI systems making or influencing decisions about people — who gets a loan, who gets hired, who gets flagged by law enforcement — needed a legal framework tied to risk, not to the technology itself.

The regulation doesn't treat all AI the same way. It sorts AI systems into four risk tiers: unacceptable risk (banned outright), high risk (subject to the heaviest obligations), limited risk (mainly transparency duties), and minimal risk (largely unregulated). Most of the compliance workload in this article concerns the high-risk tier, because that's where the AI Act's substantive requirements live.

Who it affects is broader than "companies based in the EU." The AI Act applies to providers who place AI systems on the EU market regardless of where the provider is headquartered, and to deployers who use AI systems within the EU. A US-based SaaS company selling an AI hiring tool to a French employer is squarely in scope. So is a company outside the EU whose AI system's output is used by people located in the EU, even if the company has no EU office. This extraterritorial reach is one of the most commonly missed points by non-EU businesses evaluating whether the regulation applies to them.

What Changed for Businesses in 2026?

2026 was the year the AI Act's timeline stopped looking like the original 2024 text and started looking like something businesses actually have to track on two separate calendars.

What's already applicable and enforceable:

Prohibited AI practices (Article 5) have applied since 2 February 2025. These include AI used for social scoring, certain forms of manipulative or exploitative AI, and untargeted scraping of facial images to build recognition databases. A new prohibition targeting AI systems that generate non-consensual intimate imagery ("nudifiers") and CSAM was added by the Digital Omnibus and applies from 2 December 2026.

AI literacy obligations (Article 4) — requiring providers and deployers to ensure staff and other people operating AI systems on their behalf have sufficient understanding of the systems — have also applied since February 2025.

Governance rules and obligations for general-purpose AI (GPAI) models, including the European AI Office's supervisory role over GPAI providers, have applied since 2 August 2025.

Article 50 transparency obligations — disclosing when someone is interacting with an AI system, labeling deepfakes, and disclosing AI-generated text published on matters of public interest — apply from 2 August 2026 and were not delayed by the Digital Omnibus. Only the specific technical requirement to watermark AI-generated content for systems already deployed before 2 August 2026 got a short reprieve, to 2 December 2026; systems placed on the market after August 2026 must meet the watermarking requirement immediately.

What was delayed, and why it matters:

By late 2025, it was clear that the technical standards, conformity assessment infrastructure, and guidance documents the high-risk provisions depend on weren't going to be ready in time for the original August 2026 deadline. The European Commission proposed the Digital Omnibus on AI in November 2025 to address this. After negotiation, the European Parliament and Council reached political agreement on 7 May 2026, the Parliament formally endorsed the text on 16 June 2026, the Council adopted it on 29 June 2026, and the regulation entered into force on 27 July 2026.

The result: obligations for Annex III high-risk AI systems — the standalone, use-case-based category covering things like recruitment tools, credit scoring, and biometric identification — now apply from 2 December 2027 instead of August 2026. Obligations for Annex I high-risk AI systems, meaning AI embedded as a safety component in products already regulated by EU product-safety law (medical devices, machinery, lifts, and similar), now apply from 2 August 2028.

What businesses should actually be doing right now: this is a later deadline, not a lighter one. The requirements themselves — risk management systems, technical documentation, human oversight, data governance, conformity assessment — are unchanged. Organizations that pause preparation because the deadline moved are likely to find themselves back in the same time-pressure situation in late 2027 that many were in during mid-2026.

What to act on now versus what's still transitional: Prohibited practices, AI literacy, GPAI obligations, and Article 50 transparency requirements are current, binding law with active enforcement — treat these as immediate priorities. Annex III and Annex I high-risk obligations are legally certain (the dates are fixed in the amended regulation, not conditional on further guidance) but not yet applicable, which gives most organizations roughly one to two years of genuine runway to build the documentation, governance, and technical controls those provisions require.

What Are the Main EU AI Act Compliance Requirements?

There's no single list of "EU AI Act requirements" that applies uniformly to every AI system a business touches. Obligations attach based on two variables: how the system is classified, and what role the organization plays (provider or deployer). That said, the requirement categories that recur across the regulation are worth understanding before diving into classification:

Risk management — a documented, iterative process for identifying and mitigating risks the AI system poses across its lifecycle, required for high-risk systems.

Data and data governance — training, validation, and testing datasets need to be relevant, representative, and examined for errors and bias where the system is high-risk.

Technical documentation — a record of how the system was designed, developed, and tested, sufficient for authorities to assess compliance.

Record-keeping and logging — automatic logging capability so a system's operation can be traced after the fact.

Transparency — information provided to deployers or end users so they understand a system's capabilities, limitations, and intended purpose.

Human oversight — measures allowing a natural person to understand, monitor, and intervene in a system's outputs.

Accuracy, robustness, and cybersecurity — technical performance and resilience standards appropriate to the system's purpose.

Quality management system — for providers, an organizational structure ensuring ongoing compliance, not just a one-time certification.

Conformity assessment — a formal process (self-assessment or third-party, depending on the system) confirming a high-risk system meets its requirements before it's placed on the market.

Post-market monitoring and incident reporting — ongoing tracking of a deployed system's performance, with obligations to report serious incidents.

Nearly all of these requirements are triggered by high-risk classification. A low-risk internal chatbot doesn't need a conformity assessment. A high-risk credit-scoring model does. That's why classification, not the requirement list itself, is usually where compliance work actually starts.

Which AI Systems Are Considered High-Risk?

High-risk classification under the AI Act runs through two distinct pathways, both anchored in Article 6.

The first pathway (Article 6(1)) covers AI systems that are safety components of products already regulated under EU product-safety legislation — think medical devices, machinery, toys, lifts, and radio equipment — where the product is required to undergo third-party conformity assessment under that sectoral law. This is the Annex I category.

The second pathway (Article 6(2)) covers AI systems that fall within one of the specific use cases listed in Annex III — regardless of what product or industry they're embedded in.

The point that trips up a lot of businesses: neither pathway means "any AI system used in a sensitive-sounding industry is automatically high-risk." Classification depends on the system's intended purpose — what the provider says the system is designed to do — matched against the specific legal criteria in Article 6 and Annex III. A general-purpose writing assistant used by an HR team to draft job descriptions is not the same thing, legally, as an AI system used to screen or rank job applicants. Article 6(3) also provides a narrow exception: even a system that technically falls within an Annex III use case can avoid high-risk classification if it doesn't pose a significant risk to health, safety, or fundamental rights — for example, because it performs a narrow procedural task or improves the result of a previously completed human activity. Providers relying on this exception have to document the justification and, in most cases, register the assessment.

What Is Annex III of the EU AI Act?

Annex III is the list of use cases that trigger high-risk classification for standalone AI systems — the part of the regulation most enterprise buyers actually need to know by heart, because it's where the deadline moved to 2 December 2027. It groups high-risk use cases into eight broad areas:

• Biometrics — remote biometric identification, biometric categorization based on sensitive attributes, and emotion recognition (subject to specific carve-outs).
• Critical infrastructure — AI used as a safety component in managing critical digital infrastructure, road traffic, or the supply of water, gas, heating, or electricity.
• Education and vocational training — AI used to determine access, admission, or assignment to institutions, or to evaluate learning outcomes and detect cheating.
• Employment, worker management, and access to self-employment — AI used for recruitment, targeted job advertising, evaluating candidates, and making decisions on promotion, termination, or task allocation.
• Access to essential private and public services — including creditworthiness evaluation and credit scoring, life and health insurance risk assessment and pricing, and eligibility for public assistance benefits.
• Law enforcement — AI used to assess the risk of a person offending or reoffending, evaluate evidence reliability, or profile individuals during criminal investigations.
• Migration, asylum, and border control management — AI used to assess security or health risks posed by individuals, examine applications, or assist in detecting, recognizing, or identifying individuals.
• Administration of justice and democratic processes — AI used to assist judicial authorities in researching and interpreting facts and law, and AI used to influence elections or voting behavior.

Being listed in one of these eight areas doesn't automatically mean every AI application touching that area is high-risk. A hospital using an AI scheduling tool to manage appointment slots isn't using a high-risk system just because it operates in healthcare; a hospital using AI to triage patients for treatment priority is in different territory. Intended purpose is the determining factor, not industry.

Is Credit Scoring High-Risk Under the EU AI Act?

Yes, in most cases. Annex III, point 5(b) classifies AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score as high-risk, under the broader Annex III category covering access to essential private services.

There is a specific exception: AI systems whose main intended purpose is detecting financial fraud fall outside this high-risk category. For the exception to apply, fraud detection has to be the system's primary use — pattern recognition and anomaly detection aimed at catching fraudulent activity — rather than an assessment of a person's ability or willingness to repay. It's worth being precise here: this exception is narrow and doesn't extend to anti-money laundering or counter-terrorist-financing systems, which remain covered separately. It also doesn't extend to insurance risk-pricing systems under the neighboring Annex III point 5(c), which have no equivalent carve-out.

The practical takeaway for lenders, fintechs, and any business using a third-party credit-decisioning model: don't assume a vendor's "fraud detection" label exempts the system from high-risk obligations unless fraud detection genuinely is the system's primary, documented purpose — not a secondary feature layered onto a creditworthiness model.

Are Healthcare, Finance, HR, and Other Enterprise AI Systems Automatically High-Risk?

No — industry and use case are not the same thing. A bank, hospital, HR department, law firm, or insurer can deploy dozens of AI tools without any of them meeting the AI Act's high-risk criteria, and can also deploy a single tool that clearly does.

This is the distinction between industry risk and use-case/classification risk. Industry risk is a general sense that a sector handles sensitive matters — health, money, legal outcomes, employment. Use-case risk is the specific legal test in Article 6 and Annex III applied to what a particular system is designed to do.

Some concrete contrasts:

• A bank's AI-powered fraud-detection system may fall outside high-risk classification under the credit-scoring exception described above, while its AI-driven loan-approval model very likely falls inside it.
• A hospital's AI system for optimizing staff scheduling is unlikely to be high-risk; an AI system used to determine treatment priority or triage decisions is a different question entirely.
• An HR team's AI writing assistant for drafting internal memos is not the same as an AI system used to screen resumes or rank candidates, which sits squarely inside Annex III point 4.
• A law firm's AI research assistant summarizing case law for internal use is not the AI system Annex III is concerned with; an AI tool used to assist a judicial authority in researching facts and law is.

Enterprises evaluating their own AI footprint get more value from mapping each system's intended purpose against Article 6 and Annex III than from asking "is my industry high-risk?" — a question the regulation doesn't actually ask.

None of this is meant to be copied verbatim from the regulatory text into a policy document. The obligations that matter most in practice are the ones a governance program actually has to operationalize: someone owns the risk assessment, someone maintains the documentation, someone is accountable for the human-oversight mechanism actually working rather than existing on paper.

AI Act Provider vs Deployer: Who Is Responsible?

This distinction determines who owes what under the AI Act, and it's one of the most consequential things an enterprise buyer can get wrong.

Provider — the organization that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. Most obligations in the AI Act — technical documentation, conformity assessment, risk management design, quality management systems — sit with the provider.

Deployer — the organization that uses an AI system under its own authority, in the course of a professional activity. Deployers have a narrower but still meaningful set of obligations: following the provider's instructions for use, ensuring human oversight is actually exercised, monitoring the system's operation, and — for certain high-risk use cases — conducting a fundamental rights impact assessment before deployment.

Here's the part enterprises consistently underestimate: buying an AI product from a vendor does not transfer the vendor's compliance work to your organization, and it does not eliminate your own obligations as a deployer. A company purchasing a third-party AI hiring tool cannot assume "the vendor handles EU AI Act compliance" and stop there. The vendor's compliance covers the provider side of the equation — building the system correctly, documenting it, running conformity assessment. The buyer still has deployer obligations: using the system consistently with the provider's instructions, maintaining human oversight, and keeping records of that oversight. In some circumstances — for instance, if a deployer substantially modifies a high-risk system or puts it to a different intended purpose than the provider specified — the deployer can even be reclassified as a provider, inheriting the fuller set of obligations.

Shared responsibility, in other words, is the norm, not the exception, in most enterprise AI procurement relationships.

What Do AI Deployers Need to Do?

For most enterprise buyers of AI systems, this is the more directly relevant question. Deployer obligations scale with the risk classification of the system, but the recurring themes are:

• Follow the provider's instructions for use — deploying a system outside its documented intended purpose can shift legal responsibility onto the deployer.
• Ensure human oversight is real — assign specific people with the authority, training, and time to review and intervene in the system's outputs.
• Monitor the system's operation — watch for signs it's behaving outside expected parameters and have a process for acting on that.
• Maintain records — logs the system generates, and evidence of the oversight and monitoring the deployer performed.
• Build AI literacy among staff — Article 4's requirement applies to deployers too, not just providers; people operating or relying on a system need enough understanding of it to use it appropriately.
• Escalate incidents — a defined internal process for identifying and reporting serious incidents connected to a high-risk system.
• Understand the data the system touches — deployer-side data governance matters even though most formal data-governance obligations sit with the provider, because deployers are the ones actually feeding the system operational data.
• Assess fundamental rights impact where required — certain deployers (public bodies, and private entities providing certain public services, insurance, and credit-related high-risk systems) must conduct a FRIA before putting a high-risk system into use.
• Document classification decisions — keep a record of why a given system was or wasn't treated as high-risk, especially where the Article 6(3) exception is relied on.
• Manage vendors actively — request and retain the documentation providers are required to supply, rather than treating a vendor's compliance claims as self-verifying.

Which of these apply, and how heavily, depends entirely on whether the specific system in question is high-risk. A minimal-risk internal tool doesn't need a FRIA. A high-risk recruitment platform does.

Does EU AI Act compliance replace GDPR compliance?

No. They are separate legal frameworks that frequently apply to the same AI deployment simultaneously, and satisfying one does not satisfy the other.

The overlap shows up constantly in practice. An AI hiring tool that qualifies as high-risk under Annex III is also, almost certainly, processing personal data — which means GDPR's lawful-basis requirements, data minimization principles, and individual rights (including rights connected to automated decision-making under GDPR Article 22) apply in parallel with the AI Act's technical documentation and human-oversight requirements. A company can build a technically compliant AI Act risk-management file and still be in breach of GDPR if it hasn't established a lawful basis for the personal data feeding that system, or hasn't given data subjects the transparency GDPR requires about automated decisions affecting them. The two regulations were deliberately designed to complement rather than duplicate each other, but that means compliance work has to genuinely cover both — treating a GDPR data protection impact assessment as a substitute for AI Act risk management, or vice versa, misses obligations that only exist in one framework.

Fundamental Rights Impact Assessment Under the EU AI Act

A Fundamental Rights Impact Assessment (FRIA) is a deployer-side assessment, required under Article 27 for specific categories of high-risk AI use, that evaluates how a system's deployment could affect the fundamental rights of the people it impacts — before the system goes into use, not after.

Who needs one: the obligation applies to deployers that are bodies governed by public law, private entities providing public services, and deployers of high-risk AI systems used for creditworthiness evaluation or life/health insurance risk assessment and pricing under Annex III. It is not a universal requirement for every organization deploying a high-risk AI system.

When it applies: before the relevant high-risk system is put into use, and it should be updated if the way the system is used changes materially.

What it should consider: the deployer's own processes for using the system, the categories of people likely to be affected, specific risks of harm to those people, the human oversight measures in place, and steps to take if risks materialize.

FRIA vs DPIA — these are not interchangeable. A Data Protection Impact Assessment under GDPR focuses on risks to personal data — how it's collected, processed, secured, and whether the processing is proportionate. A FRIA focuses on a broader set of fundamental rights — non-discrimination, human dignity, access to essential services — that can be implicated by an AI system's operation even in ways that don't reduce to a data protection question. Where both apply, they can draw on overlapping information, but one doesn't substitute for the other, and the AI Act explicitly allows a FRIA to be conducted alongside a DPIA rather than requiring entirely separate processes from scratch.

What Should Businesses Do to Prepare for EU AI Act Compliance?

A practical, sequenced approach — this is not a substitute for legal review, but it reflects how AI governance teams are actually structuring the work in 2026:

1. Build an AI inventory. You cannot classify or manage what you haven't identified. Most organizations discover shadow AI usage — tools adopted by teams without formal procurement — during this step.
2. Identify your role for each system. Provider, deployer, or both, on a system-by-system basis, since the same organization can be a provider for one AI tool and a deployer for another.
3. Document intended purpose for every system. This is the anchor for classification, and it needs to come from actual documentation, not assumption.
4. Classify each system against Article 6 and Annex III. Determine which systems are high-risk, which fall under Article 50 transparency obligations, and which are minimal-risk.
5. Prioritize genuinely high-risk use cases first. Given the extended Annex III timeline, sequence effort around systems with the most exposure, not everything at once.
6. Map the data each system processes. Understand what personal, sensitive, or confidential data flows into and out of each AI system, and where GDPR obligations overlap.
7. Review vendor documentation for purchased systems. Request the technical documentation, instructions for use, and evidence of conformity assessment that providers are required to supply.
8. Establish real human oversight mechanisms. Assign named owners with actual authority and time to review outputs, not a nominal sign-off step.
9. Implement monitoring and logging. Build the operational capability to track how systems behave in production, not just at deployment.
10. Maintain evidence and revisit classifications. Compliance isn't a one-time file; AI systems change, get retrained, or get repurposed, and classification decisions need to be revisited when they do.

How Should Businesses Evaluate AI Vendors for EU AI Act Risk?

Enterprise buyers evaluating an AI vendor — whether for procurement, renewal, or due diligence — get the most useful answers by asking specific, verifiable questions rather than accepting general compliance claims:

• What is the system's documented intended purpose, and does our use case match it?
• How has the vendor classified this system under the AI Act, and on what basis?
• What technical documentation can the vendor supply, and is it specific to the version we'd be using?
• What data does the system process, and where is it processed and stored?
• What logging capability exists, and can we access those logs?
• What human oversight mechanisms does the system support, and are they meaningful or nominal?
• How does the vendor handle and disclose incidents?
• How are model updates or retraining communicated, and could an update change the system's classification?
• What security controls protect the data the system processes?
• What transparency information is provided to end users interacting with the system?
• What evidence — not just claims — supports the vendor's stated compliance posture?

A vendor that can answer these specifically, with documentation, is a fundamentally different proposition than one that answers with a general assurance that "we're AI Act compliant." The regulation doesn't recognize blanket compliance claims; it recognizes documented, system-specific compliance.

Why Data Privacy Still Matters in EU AI Act Compliance

AI governance and data privacy are frequently treated as separate workstreams inside organizations, which creates gaps neither team is positioned to catch alone.

Most AI systems — high-risk or not — run on data that includes personally identifiable information, sensitive personal data, or confidential business information. The prompts employees type into AI tools, the documents fed into a retrieval system, the transcripts an AI note-taker generates: all of it is data that has to be governed regardless of whether the AI system itself is classified as high-risk. Reducing the amount of unnecessary sensitive data reaching an AI system in the first place — through data minimization, redaction, or anonymization — is a meaningful privacy and security control that reduces exposure if something does go wrong downstream: a breach, a misconfigured logging system, a third-party model provider retaining data longer than expected.

It's worth being precise about what that kind of control does and doesn't do. Anonymizing or redacting sensitive data before it reaches an AI model reduces the blast radius of a given data flow — it is not, by itself, a substitute for AI Act risk management, GDPR lawful-basis analysis, or a documented classification decision. Data minimization is one input into a broader compliance program, not the program itself.

Where Privacy-First AI Fits Into an EU AI Act Strategy

A recurring gap in enterprise AI governance is that a lot of sensitive data reaches AI systems — internal tools, vendor platforms, and public LLMs — before anyone has applied any privacy control to it at all. Shadow AI use compounds this: employees pasting contracts, patient notes, or customer records into whichever AI tool is fastest, without a governance layer in between.

A privacy-first architecture addresses one specific piece of that problem: reducing unnecessary exposure of sensitive information before it reaches downstream AI systems, rather than trying to control what happens after the fact. Questa AI is one example of this approach — its anonymization layer is designed to detect and mask sensitive data such as PII, PHI, and confidential business information in prompts, documents, and transcripts before that content reaches an AI model, restoring it afterward only for authorized users, with an audit trail of what was processed and when.

That kind of control is useful as one technical layer inside a broader AI governance and privacy strategy — it can reduce the amount of sensitive data an organization exposes to third-party AI vendors, and it can support the data governance and record-keeping expectations that show up throughout the AI Act and GDPR. It is not, on its own, a mechanism for achieving EU AI Act compliance or guaranteeing GDPR compliance — classification, risk management, human oversight, and lawful-basis analysis are separate, necessary pieces of the picture that a data protection layer doesn't replace. Organizations evaluating tools in this category are better served treating them as infrastructure that supports AI governance work, not a substitute for it.

EU AI Act Penalties and Enforcement

Enforcement of the AI Act runs on two levels. The European AI Office, established within the European Commission, supervises and enforces obligations for general-purpose AI models and coordinates enforcement across member states. National competent authorities and market surveillance authorities, designated by each EU member state, are responsible for supervising and enforcing the AI Act within their territory — including for high-risk AI systems once those obligations become applicable.

Enforcement is not theoretical at this point: prohibited practices have been enforceable since February 2025, GPAI obligations since August 2025, and Article 50 transparency obligations became enforceable in August 2026 alongside their applicability. National authorities are actively standing up their supervisory functions.

Penalty structure is tiered by severity. The most serious infringements — violations of the prohibited-practices rules — carry the highest maximum penalties, reaching up to €35 million or 7% of a company's total worldwide annual turnover, whichever is higher. Other infringements, including failures related to high-risk system obligations, carry lower maximum penalties, and supplying incorrect or misleading information to authorities carries a separate, lower tier still. The exact figures and how they apply to SMEs are set out in Article 99 of the regulation; the practical point for enterprise leaders is that the AI Act's penalty regime, like GDPR's, is turnover-based rather than fixed, which makes it materially different from most sector-specific fines businesses are used to budgeting for.

Common EU AI Act Compliance Mistakes

• Treating every AI system the same. Applying full high-risk-level rigor to a low-risk internal tool wastes resources; applying minimal-risk assumptions to a high-risk system creates real exposure.
• Assuming the vendor handles everything. Provider compliance and deployer compliance are separate obligations — see the section above.
• Ignoring intended purpose. Classification hinges on documented intended purpose, not on how a system happens to get used in practice.
• Failing to maintain an AI inventory. You can't classify, govern, or report on systems you haven't catalogued.
• Ignoring data governance. AI Act compliance and data privacy compliance are related but distinct workstreams; skipping one to focus on the other leaves gaps in both.
• Relying on policies without technical controls. A written human-oversight policy that no one is actually resourced to execute doesn't satisfy the requirement in practice.
• Confusing GDPR compliance with AI Act compliance. They overlap heavily but are not substitutes for each other.
• Ignoring system changes. Retraining, fine-tuning, or repurposing a system can change its classification; compliance work has to be revisited, not treated as a one-time event.
• Failing to document classification decisions. Especially where the Article 6(3) exception is relied on — undocumented reasoning is difficult to defend if a regulator asks.
• Waiting until the deadline to start. The Annex III deadline moved to December 2027, but the underlying work — documentation, governance infrastructure, oversight processes — takes longer to build properly than most organizations expect.

EU AI Act Compliance Checklist for Businesses

• AI inventory built and kept current across all departments, including vendor-supplied tools
• Role identified (provider, deployer, or both) for each AI system
• Intended purpose documented for each system
• Each system classified against Article 6 and Annex III, with reasoning recorded
• Prohibited-practices review completed for all current and planned AI use
• Article 50 transparency obligations mapped for any AI-generated content or chatbot interactions
• AI literacy program in place for staff operating or relying on AI systems
• Data flows mapped for each AI system, with GDPR overlap identified
• Vendor documentation requested and retained for purchased/licensed AI systems
• Human oversight mechanisms assigned to named individuals with real authority
• Logging and monitoring capability in place for systems in production
• FRIA process defined for deployers of in-scope high-risk systems (public services, credit, insurance)
• Incident escalation process defined and communicated
• Governance documentation stored centrally and reviewed on a set cadence, not ad hoc

Frequently Asked Questions

Conclusion

The EU AI Act isn't going away, and the December 2026 delay isn't a reprieve from the work — it's a reset on the clock. Businesses that treat the postponed deadline as permission to wait will likely find themselves back under the same pressure in late 2027 that many faced in mid-2026. The ones that use this window to actually build their AI inventory, classify systems honestly, and put real human oversight in place will be the ones who aren't scrambling when Annex III obligations become enforceable.

None of this happens through a single policy document or a vendor's compliance claim. It happens through the unglamorous work of knowing what AI systems you run, what they touch, and who's accountable for watching them — which is exactly the kind of groundwork that pays off regardless of how the timeline shifts again.