EU AI Act After the Digital Omnibus: What Applies Now
EU AI Act compliance 2026 requirements are already enforceable in several areas, but the often-repeated claim that “the AI Act was delayed until 2027” is wrong. The Digital Omnibus changed the timetable for high-risk AI systems. It did not postpone the Act as a whole.
As of September 2026, Article 50 transparency obligations apply. The European Commission’s AI Office and national authorities have enforcement powers. Rules for providers of general-purpose AI models, known as GPAI models, have applied since August 2025 and became enforceable by the Commission in August 2026. Specified prohibited practices and AI literacy duties are already in force.
The dates that moved concern the dedicated high-risk regime. The rules for Annex III use cases now apply from December 2, 2027. The rules for high-risk AI embedded in products covered by Annex I apply from August 2, 2028.
For CISOs, compliance leads, CTOs, general counsel, and boards, the immediate task is to separate obligations that apply now from controls that are still being prepared for 2027 or 2028. This guide explains that timeline and the evidence a security program can produce. It is general information, not legal advice. Counsel should confirm how the Regulation applies to a specific product, role, market, and use case.
EU AI Act Compliance 2026: What Applies Now
| Date | What changed | Practical effect |
|---|---|---|
| February 2, 2025 | Specified prohibited AI practices and AI literacy obligations began applying | Organizations needed controls for prohibited uses and proportionate AI literacy measures |
| August 2, 2025 | Obligations for providers of GPAI models began applying | GPAI providers entered the documentation, copyright, information, and, where applicable, systemic-risk regime |
| August 2, 2026 | Most of the Act became applicable; Article 50 duties began; Commission and national enforcement powers became active | Chatbot notices, synthetic-content marking, deepfake disclosure, and relevant public-interest text disclosures became live requirements; GPAI obligations became enforceable |
| December 2, 2026 | Transitional date for certain pre-existing systems under Article 50(2), and application date for new prohibitions added by the Omnibus | Providers should confirm whether the narrow transition applies to systems already on the market |
| December 2, 2027 | High-risk rules apply to Annex III use cases | Providers and deployers in areas such as employment, education, essential services, biometrics, critical infrastructure, migration, asylum, and border control enter the dedicated high-risk regime |
| August 2, 2028 | High-risk rules apply to AI systems embedded in Annex I regulated products | Product manufacturers and other operators receive the longer product-safety transition |
The European Commission’s current AI Act overview confirms the split timeline. Regulation (EU) 2026/1744, the AI Omnibus, entered into force on July 27, 2026. The Commission’s enforcement guidance confirms which rules can be enforced now and which wait for their later application dates.
What Article 50 requires now
Article 50 does not apply to every AI feature in the same way. The obligation depends on what the system does and whether the organization is acting as a provider or deployer.
AI systems that interact directly with people
Providers must design systems intended to interact directly with natural persons so that people are informed they are interacting with AI, unless that fact is obvious to a reasonably well-informed, observant, and circumspect person in the circumstances.
For a customer-support chatbot, onboarding assistant, or public-facing copilot, the evidence should show that the notice appears in the actual user journey. A policy document is not enough if the production interface omits the notice, shows it too late, hides it behind an inaccessible control, or loses it in one language or channel.
Systems that generate synthetic content
Providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video, or text must ensure outputs are marked in a machine-readable format and can be detected as artificially generated or manipulated. The technical solution must be effective, interoperable, robust, and reliable as far as technically feasible, taking account of the type of content, implementation cost, and state of the art.
The rule contains exceptions, including for standard assistive editing that does not substantially alter the input or its meaning. Teams should document why an exception applies instead of relying on an undocumented product assumption.
Emotion recognition and biometric categorisation
Deployers of emotion-recognition or biometric-categorisation systems must inform exposed persons that the system is operating. Data protection duties continue to apply. The disclosure obligation does not replace a GDPR assessment, lawful-basis analysis, or any sector-specific restriction.
Deepfakes and public-interest text
Deployers must disclose when image, audio, or video content constituting a deepfake has been artificially generated or manipulated. Deployers must also disclose AI-generated or manipulated text published to inform the public on matters of public interest, subject to the Regulation’s exceptions, including qualifying human review or editorial control where a natural or legal person holds editorial responsibility.
The information required by Article 50 must be clear, distinguishable, accessible, and provided no later than the first interaction or exposure. The Commission’s Article 50 guidelines have applied since August 2, 2026 and should be the operating reference for implementation.
GPAI obligations and enforcement are separate dates
The GPAI timeline is easy to misstate. Obligations for GPAI model providers began applying on August 2, 2025. The Commission’s enforcement powers for those obligations became active on August 2, 2026.
The distinction matters because many SaaS companies use a third-party foundation model but are not themselves the provider of that underlying GPAI model. Their own role may be provider of an AI system, deployer, downstream provider, importer, or distributor, depending on how the product is developed, branded, placed on the market, and used.
A contract that calls a company a “customer” of a model API does not settle its regulatory role. Product, engineering, compliance, and counsel should document the AI value chain: who supplies the model, who modifies it, who builds the downstream system, who determines its purpose, who places it on the EU market, and who operates it.
For organizations that do provide GPAI models, current enforcement powers include requests for information, model evaluations, requests for access, corrective measures, market restrictions, and fines. The AI Act Service Desk enforcement FAQ provides the Commission’s current summary.
What the high-risk delay changed
The Omnibus replaced the earlier high-risk dates with a clearer two-stage schedule. Annex III systems move to December 2, 2027. High-risk systems embedded in Annex I regulated products move to August 2, 2028.
This gives affected organizations more implementation time for the dedicated high-risk requirements, including risk management, data governance, technical documentation, record keeping, transparency to deployers, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, registration, and post-market monitoring where applicable.
It does not pause Article 50. It does not suspend GPAI obligations or enforcement. It does not remove existing AI literacy duties or prohibitions. It also does not override GDPR, product safety, consumer protection, employment, financial-services, medical-device, or other laws that may already govern the same system.
The delay should therefore change the sequence of work, not stop it. A company with an Annex III use case may have time before the full high-risk regime applies, while still needing a live Article 50 notice, vendor documentation, privacy controls, incident processes, and evidence for customers or auditors today.
Determine which obligations attach to each system
A reliable assessment starts with the system and the organization’s role, not a generic “AI product” label.
For each production or planned system, record:
- Intended purpose and reasonably foreseeable use.
- Countries where the system or its output is offered or used.
- Whether it interacts with people, generates content, performs biometric categorisation or emotion recognition, or produces deepfakes or public-interest text.
- Whether the use case may fall within Article 5 prohibitions, Annex III, or Annex I product legislation.
- The organization’s role for that system and each underlying model.
- Model providers, versions, fine-tuning, retrieval sources, tools, APIs, and downstream actions.
- Data categories, affected people, user roles, approval gates, and system owners.
- Applicable exceptions and the legal analysis supporting them.
This inventory should link to an accountable owner, a classification decision, evidence, and a review date. A list of model names without business context will not support legal scoping or technical testing.
What security testing can prove
Penetration testing does not certify EU AI Act compliance. It can produce evidence that selected technical controls operate as described and that realistic abuse paths were tested. Legal applicability, governance duties, fundamental-rights analysis, conformity assessment, and regulatory filings require separate work.
The most useful assessment maps each obligation or control claim to an observable test.
| Control claim | Security test | Evidence to retain |
|---|---|---|
| Users are told they are interacting with AI | Test every supported interface, role, language, and entry path for disclosure timing, clarity, and persistence | Screenshots, route coverage, test cases, accessibility results, release version |
| Synthetic outputs carry machine-readable marks | Generate representative outputs, inspect the marking, transform or export the content, and test detectability after supported workflows | Sample outputs, marker inspection, transformation results, detector results, limitations |
| The agent acts only with authorised permissions | Test user-to-agent identity propagation, tool permissions, cross-tenant boundaries, approval gates, and denied actions | Identity map, allowed and denied action matrix, proof of enforcement, logs |
| Untrusted content cannot silently redirect an agent | Test indirect prompt injection through files, tickets, retrieved content, webpages, and tool results | Payloads, execution traces, policy decisions, impact evidence, remediation |
| Logs support investigation and accountability | Trigger representative actions and verify actor, model, tool, source, policy decision, timestamp, and outcome are recorded | Log samples, field dictionary, retention rule, integrity and access tests |
| Material changes trigger review | Change a model, prompt, retrieval source, tool permission, or orchestration step and verify the change workflow | Change ticket, approval, regression scope, test results, deployment record |
| Findings are corrected | Reproduce each issue after remediation and check adjacent paths for regression | Retest report, closure status, residual-risk decision, approval record |
Testing scope should reflect the deployed system. A chatbot without tools has a different risk surface from an agent that can read customer records, send messages, update a case, or initiate a financial workflow. Our AI penetration testing service covers the application, model integration, retrieval layer, APIs, identities, tools, and downstream actions rather than treating the model as an isolated component.
For financial workflows, the assessment should also test segregation of duties, provenance, service-account authority, and approval gates. The financial-services AI agent security guide explains that workflow-specific scope.
Build one evidence structure without claiming equivalence
SOC 2 and ISO 27001 can provide useful control operations and evidence repositories, but neither makes an organization compliant with the EU AI Act. The reverse is also true. The frameworks have different purposes, responsible parties, and assessment models.
Existing control programs can still reduce duplicated work. An AI inventory can feed enterprise risk assessment. Access-control evidence can cover model APIs, vector stores, agent tools, and administrative consoles. Change-management records can include model, prompt, retrieval, and permission changes. Monitoring evidence can include model and tool activity. Vendor-risk files can include GPAI providers and other AI subprocessors.
The SOC 2 and AI risk guide explains how AI enters an existing SOC 2 scope. The NIST AI RMF mapping guide shows how testing evidence can support Govern, Map, Measure, and Manage activities without turning a voluntary framework into a certification claim.
Maintain a crosswalk with separate columns for the legal obligation, internal control, technical test, evidence location, owner, status, and next review. Do not write “covered by SOC 2” where the accurate statement is “the same control evidence is reused.”
Evidence checklist for boards, auditors, and regulators
A defensible evidence set should include:
- An AI system register with roles, purpose, market, data, models, integrations, and classification decisions.
- A dated legal-applicability assessment and documented exceptions.
- Article 50 disclosure designs, machine-readable marking specifications, accessibility checks, and production validation.
- GPAI-provider and downstream documentation, including model versions and contractual responsibilities.
- Threat models covering direct and indirect prompt injection, data exposure, tool abuse, cross-tenant access, and unsafe downstream actions.
- Rules of engagement and an independent AI security assessment report where testing is in scope.
- Finding-level evidence, severity, business impact, remediation ownership, and retest results.
- Logs that connect user, system, model, source, tool, policy decision, and outcome.
- Change records for models, prompts, retrieval sources, permissions, tools, and orchestration.
- Incident and complaint routes, escalation criteria, and tested response procedures.
- Board or risk-committee reporting that separates current obligations from 2027 and 2028 readiness work.
Procurement teams may ask for a shorter version of the same material. The AI red teaming vendor-questionnaire guide explains how to distinguish testing scope, evidence, and framework mapping in customer responses.
Penalties and enforcement exposure
Article 99 places Article 50 transparency failures in the tier that can attract administrative fines of up to EUR 15 million or, for an undertaking, up to 3 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. For SMEs, including start-ups, the ceiling is the lower of the percentage or fixed amount. The final amount depends on the circumstances, national implementation, responsibility, cooperation, mitigation, and procedural safeguards.
Separate penalty rules apply to prohibited practices, incorrect information supplied to authorities, and GPAI providers. Enforcement can also involve information requests, corrective measures, warnings, non-monetary measures, model access, evaluations, or market restrictions. The Commission’s AI Act enforcement page and the official Article 99 text should be checked when reporting exposure.
Boards should not receive one undifferentiated maximum-fine number. Reporting should identify the system, operator role, provision, current application date, responsible authority, evidence status, remediation owner, and legal uncertainty.
A practical 60-day evidence plan
Days 1 to 15: establish applicability
Complete the AI inventory, value-chain map, operator-role analysis, Article 50 screening, prohibited-practice review, and preliminary Annex III or Annex I classification. Record decisions and exceptions with counsel.
Days 16 to 30: close live transparency gaps
Implement or correct chatbot notices, deepfake labels, public-interest text disclosures, and synthetic-content marking. Test accessibility, language coverage, export paths, transformations, and pre-existing-system transition questions. Assign owners for evidence retention.
Days 31 to 45: validate security controls
Threat-model the deployed workflow and test the controls that protect data, identities, retrieval sources, agent tools, approvals, and logs. Prioritise exploitable findings. Capture evidence in a form engineering can reproduce and compliance can reference.
Days 46 to 60: remediate and report
Retest corrected findings. Build a board view that distinguishes live duties from 2027 and 2028 readiness. Update SOC 2, ISO 27001, vendor-risk, change-management, and incident records where the same systems are in scope. Set review triggers for material model, prompt, retrieval, permission, tool, and orchestration changes.
Questions leadership should ask now
- Which AI systems face EU users or produce outputs used in the EU?
- For each system, are we provider, deployer, downstream provider, importer, distributor, or more than one?
- Which Article 50 duty applies, and where is production evidence that it works?
- Do we provide a GPAI model, or do we build on one supplied by another provider?
- Which systems may enter Annex III in December 2027 or Annex I in August 2028?
- Which control claims have been tested under adversarial conditions?
- Can we connect findings, fixes, retests, logs, and approvals to one system owner?
- What change would require a focused retest or a new legal classification?
Frequently asked questions
Was the EU AI Act delayed until 2027?
No. Article 50 transparency rules and enforcement powers became active on August 2, 2026. GPAI obligations began applying in August 2025 and became enforceable in August 2026. The Omnibus moved the dedicated high-risk rules to December 2, 2027 for Annex III systems and August 2, 2028 for Annex I product systems.
Does Article 50 apply to every chatbot?
Providers of systems intended to interact directly with people generally must inform them they are interacting with AI unless that fact is obvious in context. Exceptions and the exact presentation should be assessed against the Regulation and Commission guidelines.
Does a SOC 2 report prove EU AI Act compliance?
No. SOC 2 evidence may support related controls such as access, change management, monitoring, and vendor risk. It does not decide EU AI Act applicability or satisfy legal duties by itself.
Is AI penetration testing required by Article 50?
Article 50 specifies transparency outcomes, not a named penetration-testing requirement. Security testing can validate whether disclosures, marking, identity, authorization, logging, and connected controls work in the deployed system. It is supporting evidence, not a legal certification.
Should a company wait until 2027 to test a likely high-risk system?
Waiting can leave current Article 50, GPAI, privacy, security, customer, and sector obligations untested. Early testing also gives engineering time to correct architecture and evidence gaps before the dedicated high-risk regime applies.
Scope the evidence before the next reporting cycle
The practical question in 2026 is not whether the entire AI Act has arrived. It is which provisions apply to each system now, which duties begin later, and whether the organization can prove its controls operate in production.
Pentest Testing Corp helps teams connect regulatory scoping to technical evidence through compliance and risk management services and AI penetration testing. A scoped engagement can test the deployed AI workflow, document validated findings, and provide remediation and retest evidence without presenting security testing as legal certification.
Scope AI security testing ahead of EU disclosure obligations: request a fixed-price compliance and security-testing scope.
