EU AI Act Compliance Guide: Deadlines, Roles, and Enterprise Requirements

The EU AI Act is no longer a future-policy problem. Some obligations already apply, the transparency regime begins on 2 August 2026, and the main high-risk deadlines now split between 2 December 2027 for most Annex III systems and 2 August 2028 for many product-embedded systems under Annex I.

That timetable matters, but the date is not the hardest part. The difficult work is building evidence: an inventory of AI systems, a defensible risk classification, clear provider/deployer roles, technical documentation, human-oversight procedures, incident playbooks, and logs that can be explained months later.

This guide explains what enterprises need to know, what changed in the current law, and how to turn the regulation into an operational compliance program. It is general information, not legal advice. The final classification of a system depends on its purpose, role, deployment context, sector, and the current legal text.

The current EU AI Act timeline

The original 2024 timetable is not the complete current picture. The current consolidated text and the Digital Omnibus amendments create several separate transition points.

The authoritative starting points are the current consolidated EU AI Act text on EUR-Lex, Regulation (EU) 2026/1744, and the European Commission implementation timeline. Treat third-party timeline graphics as summaries that must be checked against those sources.

Who is in scope?

Article 2 covers more than companies incorporated in an EU Member State. It can apply to providers placing AI systems or GPAI models on the Union market, providers putting systems into service in the Union, Union deployers, importers, distributors, product manufacturers, authorised representatives, and certain third-country providers or deployers where the output is used in the Union.

That does not mean that every foreign company using an AI tool automatically carries every obligation. Scope depends on the system or model, the use case, the role, the territorial connection, applicable exclusions, and whether the relevant provision is aimed at a provider, deployer, importer, distributor, or another operator.

One organization can hold different roles for different systems. A company might be a deployer of an HR assistant, a provider of an internal high-risk application, and a product manufacturer when AI is embedded into equipment sold under its brand.

For the security boundary around agents, the Vertex Frontier guide to agentic AI security is a useful companion: it treats the model as one component in a larger chain of prompts, retrieval, memory, identity, tools, runtimes, and downstream side effects. That is an engineering model, not a replacement for the legal role analysis above.

The EU AI Act risk framework

The Commission commonly explains the Act through four broad risk levels: prohibited or unacceptable risk, high risk, limited-risk transparency duties, and minimal or no risk. This is a useful mental model, but the legal analysis still depends on the exact Articles, Annexes, provider/deployer role, intended purpose, and exceptions.

Prohibited practices

The current Commission framing includes nine prohibited-practice groups after the Omnibus additions.

They include harmful manipulation or deception, harmful exploitation of vulnerabilities, social scoring, certain individual criminal-offence prediction practices based solely on profiling, untargeted scraping to build facial-recognition databases, certain emotion-recognition uses in workplaces and education, certain biometric categorisation, restricted real-time remote biometric identification in publicly accessible spaces for law enforcement, and the additional Omnibus-created group covering specified non-consensual sexual or child-sexual-abuse content generation.

The effective dates are not identical for every group. In particular, the new Omnibus-created additions apply from 2 December 2026. Do not reduce the current law to an old list of eight categories.

High-risk systems

Article 6 identifies two main routes:

• Article 6(1) / Annex I: an AI system that is a safety component of, or is itself, a product covered by listed Union harmonisation legislation where the product requires third-party conformity assessment.
• Article 6(2) / Annex III: systems used in listed areas such as biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and border control, and administration of justice or democratic processes.

Annex III is not a license to classify by label alone. Intended purpose matters. Article 6(3) also provides a significant-risk exception for some narrow procedural, preparatory, or post-human-review tasks, while profiling remains high-risk under that paragraph. Any exception should be documented rather than assumed.

Limited and minimal risk

Article 50 imposes specific transparency obligations for certain AI systems. Depending on the system and use, this can include informing people that they are interacting with AI, marking synthetic audio/image/video/text in a machine-readable way, disclosing certain emotion-recognition or biometric-categorisation uses, disclosing deepfakes, and disclosing certain AI-generated text published on matters of public interest.

The European Commission’s transparency guidance should control the implementation details. “Limited risk” is not a universal legal shortcut that reduces every system to one generic banner.

What high-risk providers must build

The high-risk regime is a lifecycle program, not a one-time policy document.

Logging: the correction that matters most

Article 12 requires a high-risk system to technically allow automatic recording of events over the system’s lifetime. It does not, by itself, say that every log must be “tamper-proof,” and it does not create a universal 24-month retention rule for biometric or law-enforcement systems.

Articles 19 and 26 address logs under the control of providers and deployers and establish an at-least-six-month period, subject to other Union or national law. The exact retention decision still needs data-protection, sectoral, security, and operational analysis.

A tamper-evident store, centralized event schema, or immutable archive may be sensible controls. They are implementation choices. The Act does not prescribe a particular gateway, ledger, registry, or observability product.

Article 15, APIs, MCP, and agent actions

Article 15 does not expressly name APIs, MCP servers, tool-calling layers, or agent action telemetry. It does, however, address resilience throughout the lifecycle, interactions with other systems, unauthorised attempts to alter use, outputs, or performance, and several AI-specific attack classes.

The safer engineering conclusion is narrower:

If an API, tool server, retrieval layer, agent handoff, or downstream action can affect a high-risk system’s use, output, performance, data exposure, or ability to be interrupted, include that boundary in the risk assessment and security testing.

That is a risk-based implementation recommendation, not a claim that every connected service automatically becomes an AI Act high-risk system or that Article 15 expressly mentions MCP.

For a deeper security treatment of delegated authority, identity lineage, last-hop authorization, MCP, and A2A, see Vertex Frontier’s non-human identity blueprint for agentic AI. For prompt injection, tool permissions, sandboxing, and autonomous side effects, see the agentic AI security guide.

General-purpose AI: provider duties and downstream reality

The GPAI rules apply to providers of general-purpose AI models. Article 53 duties include technical documentation, information for downstream providers, a copyright-compliance policy that takes account of the Union text-and-data-mining rules, and a public summary of training content using the applicable Commission template.

Systemic-risk GPAI providers have additional duties under Article 55, including standardized evaluation and adversarial testing, systemic-risk assessment and mitigation, cybersecurity, and serious-incident reporting without undue delay. Do not replace that phrase with an unsupported 15-day deadline.

The GPAI Code of Practice is voluntary. The Commission describes it as a practical compliance route for corresponding obligations until harmonized standards become available; it is not a universal statutory safe harbor for every AI Act duty.

If an enterprise deploys a third-party GPAI model rather than providing the model, the company still needs vendor due diligence. A useful evidence request should cover intended use, model version and change notifications, evaluation material, known limitations, incident channels, data handling, copyright information where relevant, security controls, logging, and allocation of responsibilities. It should not pretend that a supplier questionnaire alone proves compliance.

Deployers: the operational duties are not “lighter” in every practical sense

Article 26 requires deployers to use systems according to instructions, assign competent and trained people for human oversight, monitor operation, handle relevant logs under their control, and suspend use where a risk is suspected. Some public-sector and essential-service contexts add further duties, including fundamental-rights impact assessment requirements.

The right way to think about deployer compliance is not “the provider handles compliance and the customer is covered.” The provider and deployer have different duties, and the deployer often controls the context that determines the real-world risk: the data entered, the people affected, the workflow, the override process, and the decision that follows the model output.

A practical deployer evidence pack

Where the AI system retrieves confidential business information, the security boundary deserves separate treatment. Vertex Frontier’s enterprise RAG security architecture guide covers permission-aware retrieval, source-system ACLs, identity, and auditability.

Running a model locally may change a data-transfer boundary, but it does not create an automatic exemption or make the deployment compliant; the local AI deployment guide explains why privacy is a property of configuration rather than the word “local.”

A defensible enterprise compliance architecture

The Act does not require a single runtime control plane, model registry, data lineage product, or “AI compliance platform.” Those can be useful design patterns when they match the environment and have verified coverage.

A practical architecture usually has five connected layers:

1. Inventory and ownership: systems, models, agents, SaaS features, datasets, tools, identities, vendors, and owners.
2. Lifecycle governance: classification, intended purpose, approvals, evaluation, versioning, change management, and documentation.
3. Runtime controls: authentication, authorization, data minimization, policy enforcement, tool-call validation, rate limits, budgets, and safe interruption.
4. Human oversight: named competent people who can interpret outputs, reject them, override them, pause the workflow, and escalate problems.
5. Evidence and response: logs, monitoring, incident triage, evidence preservation, reporting, rollback, and post-market feedback.

For systems that use RAG, model tools, or autonomous agents, a useful event record may need to connect the initiating human or workflow, model/version, prompt or input reference, retrieved sources, tool call, identity, authorization decision, output, human action, and downstream side effect. Data minimization and access controls still apply; more logging is not automatically better if it creates an uncontrolled copy of sensitive data.

EU AI Act compared with GDPR, NIS2, DORA, ISO 42001, and NIST AI RMF

The NIST AI RMF and NIST Generative AI Profile can complement a governance program. ISO/IEC 42001 can provide management-system structure. Neither source supports the claim that organizations can simply substitute certification or a framework for an AI Act assessment.

A practical eight-step compliance roadmap

1. Build the inventory

Include internally developed models, purchased systems, embedded SaaS AI, spreadsheets and scripts used for material decisions, RAG applications, agents, tools, connectors, and shadow AI. Record owner, purpose, users, data, geography, provider, model/version, integrations, and affected people.

2. Classify the system and use

Document whether the organization is provider, deployer, importer, distributor, or another operator. Map Article 5, Article 6, Annex I, Annex III, Article 50, and relevant exclusions. Record the reasoning and the reviewer.

3. Identify evidence gaps

For each system, ask what exists for risk management, data governance, technical documentation, logging, instructions, human oversight, cybersecurity, monitoring, incidents, and vendor accountability.

4. Set the control boundary

Map not only the model, but also retrieval, memory, identities, prompts, tool servers, APIs, downstream systems, human decisions, and side effects where they affect the intended use or risk.

5. Establish human oversight

Name people with the authority, competence, and time to interpret outputs, reject or reverse them, pause operation, and escalate failures. A human named in a policy but unable to intervene is not meaningful oversight.

6. Create vendor evidence requirements

Request model/version information, intended-use limits, evaluation material, security information, incident contacts, change notifications, logging options, data-processing terms, and responsibility allocation. Track unanswered requests.

7. Test and monitor

Use pre-deployment tests, adversarial tests where appropriate, shadow mode, simulation, controlled rollout, production monitoring, drift or performance review, and incident exercises. Do not claim a universal test threshold without evidence for the use case.

8. Preserve and review evidence

Make the evidence retrievable: classification decision, version history, test results, oversight actions, incidents, provider communications, and changes to purpose or data. Review the inventory when a model, provider, workflow, or decision changes.

Common mistakes to avoid

Treating one date as the entire timetable

The 2 August 2026 date is important, but it does not replace the 2 December 2027 and 2 August 2028 high-risk transition dates.

Treating a human in the loop as an automatic exemption

Human review can matter to the legal and operational analysis, but it does not automatically make a system non-high-risk. Document the function and the actual authority of the reviewer.

Calling an architecture legally mandatory

A model registry, runtime gateway, MCP gateway, immutable log, or product platform may be a useful pattern. The Act does not mandate a particular vendor or topology.

Confusing Article 73 with NIS2 incident clocks

Article 73’s current high-risk reporting windows are different from NIS2’s early-warning and notification sequence. Maintain separate playbooks and ownership.

Treating ISO certification as a legal shortcut

A management-system certificate can support evidence and governance, but it does not erase the need to classify the system and meet applicable obligations.

Tracking only the model

A practical inventory may need to include agents, embedded product features, RAG stores, connectors, tool servers, identities, and downstream actions. The legal classification still depends on the AI Act definitions and intended purpose; inventory breadth is a governance control, not a legal conclusion.

Conclusion

The safest way to approach EU AI Act compliance is to treat it as an evidence and operating-model problem, not a race to publish one more policy. Start with the inventory. Document the role and intended purpose.

Classify the system using the current legal text. Then connect the classification to technical documentation, human oversight, security testing, logging, monitoring, vendor evidence, and incident response.

The regulation does not require every organization to buy the same platform or build the same architecture. It does require organizations to understand what their systems do, who controls them, who may be affected, and what evidence supports the decisions made around them.

For the authoritative legal baseline, use the consolidated EU AI Act on EUR-Lex and the European Commission’s AI Act policy and guidance pages. For a technical program, combine that legal review with your organization’s privacy, security, procurement, engineering, and sector-specific requirements.

Frequently asked questions

About The Author

A Gadallh

Ahmed Gadallah is the Founder and Editor of Vertex Frontier, where he publishes research-driven articles on AI, data science, cloud computing, cybersecurity, software engineering, and emerging technologies, with a focus on technical accuracy, clarity, and practical insights.

View all articles by A Gadallh →