The EU AI Act 2026 milestone is the 2 August 2026 general application date in Regulation (EU) 2024/1689. That date has passed, so the live questions are which duties bind you today and which high-risk timetables the Digital Omnibus moved. The through-line: a living AI usage inventory plus interaction-level evidence is the deployer’s audit backbone, not a one-time assessment.

Last updated: September 2026.

What the EU AI Act 2026 Milestone Covers

The EU AI Act 2026 milestone means 2 August 2026, the general application date set in the final provisions of Regulation (EU) 2024/1689, two years after the Regulation entered into force on 1 August 2024 (Regulation (EU) 2024/1689, 2024). The Act lands in stages, not all at once. Article 113 sets the sequence.

The earlier stages were narrow. Prohibited AI practices and the AI literacy duty applied from 2 February 2025. Obligations for providers of general-purpose AI (GPAI) models, the governance structure, and most penalty provisions applied from 2 August 2025. Those dates bound model builders, GPAI providers, and the small set of organizations running banned use cases.

The 2026 date reaches ordinary enterprise buyers, because it brings in duties that attach to using AI rather than building it. Three variables decide what you owe: your role for each system, the system’s risk class, and the effective date of the provision in question. That third variable is unusually live, because the Digital Omnibus package proposed changes to some of the Act’s application dates. The next section separates the timetable in the Regulation as adopted from the status you need to confirm before setting an internal deadline.

Existing assurance work rarely closes the gap. A security certification or a privacy audit report may not document system classification, named human oversight, runtime monitoring, or the logs a high-risk AI system generates. Operation produces those artifacts, not review. So the inventory and the evidence trail have to run continuously rather than annually.

Obligations by Date: 2024 Through the End of the Transition

Read the Act as a calendar before you read it as a rulebook. The table below maps each application date in the Regulation as adopted to what begins to apply and who it binds. The 2026 milestone splits into three distinct duty sets, because one organization can be caught by one of them and not the others.

Date	What begins to apply	Who it binds
1 August 2024	Regulation enters into force and the transition clock starts	Everyone in scope
2 February 2025	Prohibited AI practices and AI literacy duties	Providers and deployers
2 August 2025	GPAI model obligations, notified bodies, national competent authorities, most penalty provisions	GPAI providers and member states
2 August 2026 (high risk)	Requirements for standalone Annex III high-risk systems, and the Article 26 obligations that attach to using them	Providers and deployers of Annex III systems, subject to the Digital Omnibus outcome below
2 August 2026 (transparency)	Article 50 duties covering AI that interacts directly with people, machine-readable marking of specified synthetic outputs, and disclosure of covered deepfakes and certain AI-generated text	Providers and deployers, with different duties for each and defined exceptions
2 August 2026 (registration)	Article 49 registration in the EU database before a system is placed on the market or put into service	Providers of Annex III systems, and deployers that are public authorities or bodies
2 August 2027	High-risk systems that are safety components of products already regulated under the Annex I harmonisation legislation; GPAI models placed on the market before 2 August 2025	Product manufacturers and earlier GPAI providers
After 2 August 2027	Article 111 transitional arrangements for systems already on the market, and for AI components of large-scale European information technology systems, on their own longer schedule	Operators of pre-existing and legacy systems

One open question governs the high-risk half of that table. The Digital Omnibus package proposed changes to the Act’s application dates, including a deferral of the compliance deadline for standalone Annex III high-risk systems, with 2 December 2027 reported as the replacement date for that category. Before you set an internal deadline, establish three things from the official legislative record: whether the Annex III date moved, what date now applies, and which connected provider and deployer duties moved with it. The work does not wait on that answer. Inventory, role determination, classification, oversight design, and log capture all carry lead times measured in quarters.

Past 2027, transitional provisions govern rather than a fresh general application date. Article 111 sets separate arrangements for high-risk systems already placed on the market and for AI components of the large-scale European information technology systems listed in the Act’s annexes.

Provider or Deployer: Getting the Role Right First

Every obligation attaches to a role, so role determination comes before the checklist. A provider develops an AI system, or has one developed, and places it on the EU market under its own name or trademark. A deployer uses an AI system under its own authority in a professional capacity. Most enterprises deploy many systems and provide a few.

The roles are not fixed. Under Article 25, a deployer takes on the provider’s obligations if it puts its own name or trademark on a high-risk system already on the market, makes a substantial modification to such a system, or changes the intended purpose of a system so that the system becomes high risk. The third trigger is the live one for internal AI teams. Wrapping a general-purpose model in an applicant-screening workflow is a purpose decision, so the organization that makes it should test its own role rather than assume the model vendor carries the obligation.

The same logic reaches agents built in house. An agent that reads a ticketing system, queries a customer record store, and writes a decision back is an assembled system. The organization that assembles and operates it determines its own role for that composition instead of inheriting a role from any single component.

Scope is territorial as well as functional. The Act reaches providers placing systems on the EU market wherever they are established, deployers established in the EU, and providers and deployers outside the EU whose system output is used inside it.

High-Risk Classification: Annex I, Annex III, and the Article 6 Filters

High risk has two doors. The first covers AI used as a safety component of a product, or as a product, already covered by the EU harmonisation legislation listed in Annex I, such as machinery, medical devices, and lifts. The second covers the standalone use cases in Annex III: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services including creditworthiness scoring and life and health insurance pricing, law enforcement, migration and border control, and the administration of justice.

Annex III membership is not automatic classification. A system in one of those areas can fall outside the high-risk tier where it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing human assessment, or performs preparatory work, provided it does not profile natural persons, under the Article 6 filters. Claiming that derogation carries its own cost: you document the assessment before the system is placed on the market or put into service, and you still enter the system in the EU database.

Both doors assume something many organizations have not finished: a list of the AI actually in use. As of April 2026, more than half of organizations lacked a basic AI system inventory (Responsible AI Labs, 2026). Classify against an incomplete list and you get a defensible-looking register over an undefended estate. The AI features inside a hiring platform, the coding assistant a team installed last quarter, and the agent someone wired into a customer data store are exactly the entries a manual survey misses. Sector mapping helps here. The same exercise runs through for healthcare and pharmaceutical organizations and for financial services.

That inventory gap is one symptom of a wider readiness problem, and the problem is not confined to enterprise buyers. As of April 2026, 78% of organizations had not taken meaningful steps toward EU AI Act compliance, and at least 12 EU member states had missed their own deadline to appoint the national competent authorities the Act requires (Responsible AI Labs, 2026). The second figure matters as much as the first. Article 26 duties assume a functioning market surveillance authority to notify when a high-risk system presents a risk, and an incident-reporting channel that works. Where a member state has not yet stood up its authority, a deployer’s obligation to escalate does not disappear, but the practical path for doing so may still be forming. Build internal readiness ahead of external certainty rather than waiting for the regulatory infrastructure to catch up.

The preparedness gap is rarely technical. Organizations that have already inventoried their AI estate and settled their provider or deployer role for each system move through classification and oversight design in weeks. Organizations that have not, most of the market by the figures above, are still doing that groundwork after the general application date rather than before it. That reordering turns the deployer checklist below from a maintenance routine into a remediation project, and it explains why the checklist is sequenced the way it is.

The Deployer Checklist, and What Changes Now the Date Has Passed

Deployer duties sit in Article 26, and they are operational rather than documentary. The starting position is thin across the market: 90% of organizations say employees use AI tools, but only 38% have a formal, comprehensive AI policy and 25% have none (ISACA, 2026). Work the list in this order.

1. Inventory every AI system in use, including the ones nobody registered. Cover approved applications, AI features inside existing software, copilots, coding assistants, local AI on endpoints, and agents built by internal teams.
2. Determine your role for each entry. Provider, deployer, importer, or distributor, with a named owner and the reasoning recorded.
3. Classify against Annex I and Annex III. Where you rely on the narrow-task derogation, document the assessment before the system goes into service.
4. Use each high-risk system according to the provider’s instructions. A change to the intended purpose can move you into the provider column.
5. Assign human oversight to named people who are competent, trained, and resourced. Oversight means authority to intervene, not a line in a policy.
6. Control input data where you supply it. Deployers are responsible for input data being relevant and sufficiently representative for the intended purpose, to the extent they exercise control over it.
7. Monitor operation and escalate. Suspend use and inform the provider, the distributor, and the market surveillance authority when the system presents a risk, and report serious incidents.
8. Retain the system’s automatically generated logs. Six months is the floor for logs under your control, unless other law requires longer.
9. Tell the people affected. Inform workers and their representatives before putting a high-risk system into service in the workplace, and inform individuals when a high-risk system is used in decisions about them.
10. Run the fundamental rights impact assessment where Article 27 applies, and register where required. Bodies governed by public law, entities providing public services, and deployers of certain credit and insurance systems carry this extra step.

Now that the August date has passed, split the list in two. Items one through six and item ten are remediation: point-in-time work that is either done or overdue, and that an authority can ask to see on request. Items seven, eight, and nine are continuous. They generate a record every day the system runs, and no amount of retrospective effort recreates a month of missing monitoring. Programmes fail on the second group, because a review cadence cannot produce evidence about the intervals between reviews.

Sequencing beats scope. Deploying Aurascape at The Police Credit Union ran AI governance in two phases: a visibility phase covering AI app inventory, automated discovery, risk assessments, and entitlement and data exposure visibility, then a protection phase that coached users away from risky use, required enterprise accounts for approved apps, and mapped data protections to credit union classifiers, with controls mapped to NCUA examination expectations around AI and the NIST AI Risk Management Framework (Aurascape, 2026). Visibility first, because everything after it is guesswork otherwise.

Conformity, Registration, Transparency, and Penalties

If your role assessment landed on provider for any high-risk system, a defined market-entry sequence applies before that system reaches users.

1. Confirm the classification and the specific requirements that attach to it.
2. Put the required systems in place: risk management, data governance, technical documentation, record keeping, instructions for use, human oversight design, and accuracy, resilience, and cybersecurity measures.
3. Run the conformity assessment under Article 43, through internal control or with a notified body, depending on the system and the standards applied.
4. Draw up the EU declaration of conformity and affix the CE marking to the system or its documentation.
5. Register in the EU database under Article 49 before placing the system on the market or putting it into service.
6. Run post-market monitoring and report serious incidents to the relevant authorities.

Deployers do not repeat that sequence for a system someone else placed on the market. The registration duty reaches deployers that are public authorities or bodies, and Article 26 duties run for everyone using a high-risk system.

Transparency duties under Article 50 reach far past the high-risk tier, and they divide by role. Providers of covered systems make direct interaction with an AI system evident to the person involved, and apply machine-readable markings to specified synthetic audio, image, video, and text outputs. Deployers carry separate disclosure duties, including for covered deepfakes and for certain AI-generated or manipulated text published to inform the public, with defined conditions and exceptions in each case. A support chatbot and a marketing image generator can land in different rows of that split, so map each system to a duty and a role rather than to a general rule.

Penalties are tiered by what was breached. Prohibited practices carry fines up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher. Most other infringements, including the deployer obligations above, carry up to EUR 15 million or 3%. Supplying incorrect, incomplete, or misleading information to notified bodies or national authorities carries up to EUR 7.5 million or 1%. Lower ceilings apply to small and medium-sized enterprises.

The Act stacks on top of existing regimes rather than replacing them. The General Data Protection Regulation (GDPR) still governs the personal data flowing into and out of an AI system, and financial entities in the EU carry the Digital Operational Resilience Act (DORA), whose information and communication technology risk management, incident reporting, and third-party oversight requirements overlap with the monitoring and reporting duties here (EUR-Lex, 2022). One evidence base can serve reviews under all three while each regime keeps its own distinct requirements, the pattern described in our guide to AI compliance frameworks for enterprise AI.

Making the Inventory and the Evidence Trail Continuous

Read Article 26 again and notice the tense. Oversight while the system is in use. Monitoring of operation. Logs of what happened. Reporting when something goes wrong. These are runtime duties, and most organizations still treat AI assurance as a gate: roughly one-third have no process at all to validate AI security before deployment (World Economic Forum, 2026). A gate cannot produce evidence about the period between gates.

Discovery is where the compliance artifact starts. Aurascape has detected that 50+ new AI apps release every day, and maintains a continuously updated catalog of 30,000+ AI apps and agents, with discovery running across network, endpoint, and application programming interface (API) planes and each discovered app classified by risk and capability (Aurascape, 2026). That is the raw material the classification exercise assumes you already have, refreshed at the speed the estate actually changes.

Evidence then comes from the interaction itself. Aurascape decodes the AI exchange inline, applies 600+ real-time data classifiers, and enforces policy at the moment of use through allow, coach, notify, redact, redirect, and block (Aurascape, 2026). Aurascape creates interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy, so a compliance owner can answer who used which AI system, under which account, with what data, and what the policy decision was.

For deployers running agents on top of high-risk or GPAI-backed systems, the reportable event is usually an action rather than a sentence. Aurascape discovers and secures local AI agents and their interactions, and adds a Zero-Bypass MCP Gateway that marks every tool call it approves and blocks unmarked calls, governing the agent-to-tool execution path inline rather than observing it (Aurascape, 2026). Model Context Protocol (MCP) is one common tool-execution pattern, not the whole agent access-control problem, and the governance claim holds where the architecture applies: approved workflows, approved tool execution, and fail-closed blocking of unmarked calls.

Deployer duty in practice	Periodic documentation review	Destination-level access control	Aurascape
Know which AI systems and accounts are in use	Records the systems known to reviewers on the review date	Applies policy to the AI destinations already on its list	Continuous discovery across network, endpoint, and API planes against a catalog of 30,000+ AI apps and agents
See what data moves into an AI system	Relies on policy text and user attestation	Applies pattern matching at the destination boundary	600+ real-time data classifiers applied inside the prompt, the file, and the response
Human oversight at the moment of use	Training records and sign-off	Allows or blocks access to the application	Inline actions inside the interaction: allow, coach, notify, redact, redirect, block
Records of system operation for audit	Collected by hand from each system owner	Connection and destination logs	Interaction records for audit and effectiveness, governed by role-based access control
Oversight of actions an agent takes on your behalf	Reviewed as documentation after the fact	Applies at the point of access to the destination	Zero-Bypass MCP Gateway marks every approved tool call and blocks unmarked calls

The compliance payoff is narrow and useful. The inventory the classification exercise depends on stays current as the estate changes, and the monitoring, logging, and incident duties produce a record while the system runs rather than a reconstruction afterwards. Regulated-sector teams can see the same mechanics applied to supervisory expectations in our guide for banks and investment firms.

Frequently Asked Questions

What is the EU AI Act 2026 milestone?

It is 2 August 2026, the general application date of Regulation (EU) 2024/1689, when the duties attached to using AI, not just building it, came into effect alongside transparency and registration requirements.

Did the high-risk deadline move under the Digital Omnibus?

The Digital Omnibus package proposed deferring the compliance deadline for standalone Annex III high-risk systems, with 2 December 2027 reported as the replacement date. Confirm the current status, the affected system categories, and the effective date against the official legislative record before treating any later date as binding.

Does the EU AI Act apply to companies outside the EU?

Yes. It reaches providers placing AI systems on the EU market regardless of where they are established, deployers established in the EU, and providers and deployers in third countries where the output produced by the system is used in the EU.

Am I a provider or a deployer?

A provider builds an AI system and places it on the market under its own name; a deployer uses one under its own authority in a professional capacity. The practical test is control over purpose and presentation, because changing either for a high-risk system can move you into the provider column under Article 25.

Which AI systems count as high risk?

Two routes: AI acting as a safety component of a product already regulated under the Annex I harmonisation legislation, and standalone systems in the Annex III areas such as employment, creditworthiness, and education. A system in an Annex III area can still fall outside the tier under the Article 6 filters, but only with a documented assessment.

How prepared are organizations for the EU AI Act 2026 deadline?

Not very, on the available figures. As of April 2026, most organizations had not taken meaningful steps toward compliance and more than half lacked a basic AI system inventory, while several EU member states had not yet appointed the competent authorities the Act requires. The gap sits on both the enterprise side and the regulatory infrastructure side.

What are the penalties for non-compliance?

Three tiers, set by what was breached: 7% of worldwide annual turnover or EUR 35 million for prohibited practices, 3% or EUR 15 million for most other infringements including deployer duties, and 1% or EUR 7.5 million for misleading information to authorities. The higher figure in each pair applies, with lower ceilings for small and medium-sized enterprises.

What logs does a deployer have to keep?

At least six months of the logs a high-risk system automatically generates, where those logs are under the deployer’s control and no other law sets a longer period. The binding constraint is that you have to capture them while the system runs.

How does the EU AI Act relate to GDPR and DORA?

It sits alongside them. GDPR governs the personal data an AI system processes, DORA governs technology risk and incident reporting for EU financial entities, and each keeps its own requirements even where one evidence base can serve reviews under all three.

What should a security team do now that the date has passed?

Close the remediation items first: inventory, role assignment, documented classification, and named oversight. Then turn to the continuous duties, monitoring, logging, and incident escalation, because those produce evidence only for the period in which they actually run.

---

Aurascape turns the EU AI Act’s deployer duties into something a security team can operate: continuous discovery of the AI apps, accounts, and agents in use, real-time data classification inside every interaction, inline policy at the moment of use, and an interaction-level record of what happened and what was decided. Compliance owners get current records of AI use, data movement, policy decisions, and agent actions instead of a survey that ages the day it is filed. See how your current AI usage inventory and evidence trail support ongoing EU AI Act duties.

See how Aurascape builds a continuous AI Act evidence trail →