EU AI Act after the Digital Omnibus: What AI Startups Must Do Now

The amended timetable can be useful breathing space for an AI startup, but it is not permission to put compliance aside. A founder needs to know which product, use case, organisation and obligation a date actually describes. This guide explains the position as at 30 September 2026 for teams selling into or operating in the EU, including UK businesses with EU-facing products. It is practical information, not legal advice.

What changed after the Digital Omnibus?

Regulation (EU) 2026/1744 amended the application schedule of the EU AI Act. In particular, Sections 1, 2 and 3 of Chapter III apply to high-risk systems classified under Article 6(2) and Annex III from 2 December 2027. For high-risk systems classified under Article 6(1) and Annex I, those sections apply from 2 August 2028. These are different classification routes; do not pick whichever date is most convenient for the business.

That change does not mean every requirement has been postponed. The original Regulation, Regulation (EU) 2024/1689, still needs to be read together with the amending text, including provisions on scope, roles, phased application and transitional treatment. A date on a slide deck is not a substitute for checking the exact article and the facts of your system. The postponed dates are still in the future as at this guide's review date.

Which EU AI Act requirements already apply?

The prohibitions on specified unacceptable AI practices and the AI literacy requirement have applied since 2 February 2025. For a startup, that calls for a review of actual product and internal use, not just a statement in an AI policy. Identify whether a feature could fall within a prohibited practice, document the reasoning and train people involved in operating or using AI at a level appropriate to their work and context.

Relevant obligations for providers of general-purpose AI (GPAI) models have applied since 2 August 2025, subject to applicable transitional provisions, including those affecting models already placed on the market before that date. A company using a third-party model is not automatically its provider; a company developing and supplying its own model should assess the GPAI provisions against what it actually does. Keep model provenance and supplier arrangements visible in the product inventory.

Article 50 transparency obligations apply from 2 August 2026, subject to the relevant role, system and transitional rules. As at 30 September 2026, this is a current application date, not a future milestone. Depending on the use case, obligations can concern informing people that they interact with AI, marking certain AI-generated outputs, or disclosures around deepfakes and specified public-interest text. Do not assume a universal disclosure solves every case: check the specific paragraph, exceptions and any transition for your system.

How do we decide whether a system is high-risk?

Begin with intended purpose and the setting in which the system is used. The Annex III route covers listed use cases, such as particular employment, education or access-to-essential-services contexts, subject to the Act's classification conditions and exclusions. A generic feature label like “HR assistant” tells you less than the actual decisions the tool supports and who relies on its output. Record the intended purpose, user group, decision workflow, affected people and the evidence behind your classification.

The Annex I route concerns AI that is a product, or a safety component of a product, covered by specified EU product legislation where the relevant third-party conformity assessment condition is met. This is not a catch-all for any startup with a physical device. Document the applicable product legislation and the assessment pathway rather than inferring a route from marketing language. If a use case or exception is unclear, obtain specialist legal advice before a launch or contract commitment.

Classification should be revisited when the product changes. Moving from a writing aid to a tool that ranks job applicants, for example, changes the questions to ask about purpose and effect. A supplier's description of its own model does not settle the risk category of your finished system. Record decisions in a register so sales, product and legal teams work from the same version of the facts.

Are we a provider, deployer or both?

A provider develops an AI system or GPAI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority, except for personal non-professional use. Importers and distributors can also have duties in an EU supply chain. A UK startup may have more than one role across different products and internal uses, and the Act can reach businesses outside the EU where its territorial conditions are met.

Consider a SaaS company that embeds a third-party model in a customer-facing feature. Its supplier may be the model provider; the company still needs to assess whether it is the provider of the finished AI system under its own brand. If it also uses a separate recruitment tool internally, it may be a deployer for that use. Substantial modifications, a change in intended purpose and contractual or supply-chain arrangements can alter the analysis. Use the EU AI Act provider-versus-deployer role guide to record these distinctions system by system.

What should our 90-day readiness checklist include?

Make this an owned programme rather than a single policy-writing task. The next 90 days are a planning horizon, not a legal grace period or a promise that every system can be made ready within it. Put a named owner, decision date and evidence location against each action. Prioritise duties already applicable and product decisions that will become expensive to reverse.

Days 1–30: establish the facts

• Inventory customer-facing AI features, internal tools and any models you develop or supply. Include intended purpose, users, EU market or output routes, third-party dependencies and data flows.
• Map provider, deployer and other relevant roles for each system. Record the reasoning, not only a tick-box conclusion; resolve uncertain cases with the right legal and technical owners.
• Screen for prohibited practices, AI literacy needs, GPAI model responsibilities and currently applicable transparency duties. Identify notices or output-marking changes that need immediate action.

Days 31–60: classify and collect evidence

• Assess risk classification against intended purpose and the applicable legal route. Separate ordinary AI features from potentially high-risk systems and document any exclusion or exception relied upon.
• Ask suppliers what they provide and what evidence is available. Check agreements, model descriptions and change notifications; do not adopt a vendor's role assessment without examining your own product.
• For potentially high-risk systems, gap-assess technical documentation, risk management, data governance, logging, human oversight and post-market processes against the provisions relevant to your role. The EU AI Act technical documentation checklist can structure the evidence review.

Days 61–90: assign delivery and review triggers

• Turn gaps into actions with accountable owners, evidence repositories, approval steps and review dates. Prioritise applicable duties before preparing for later high-risk milestones.
• Test how notices, human review, incident escalation and product-change approvals work in practice. A control that exists only in a draft document is not reliable evidence.
• Schedule reassessment when intended purpose, models, markets or legislation change. Keep a versioned record of the source text you relied on and questions sent for legal advice.

How can governance work without slowing product delivery?

Attach the assessment to existing product decisions: an intake before a new AI feature, a review when its intended purpose changes, and an approval point before a new EU market launch. A small team can maintain one register linking systems to owners, suppliers, roles, obligations, controls and evidence. This avoids separate, contradictory spreadsheets for legal, product and sales. Where an information security or AI management system already exists, connect its change management and risk processes rather than writing a parallel stack of policies.

Good evidence is proportionate and traceable: a documented classification decision, a working user notice where required, supplier information you can retrieve, and records showing who reviewed a change. For broader process design, see the ISO 42001 and EU AI Act governance guide. If roles, dates or controls remain unclear, EU AI Act readiness support can help turn the register into a prioritised plan.

Source and legal note: Last reviewed: 30 September 2026. Verify the current consolidated text and amendments in the Official Journal of the EU through EUR-Lex before relying on a date or classification. Check role-specific and system-specific transitional provisions, national implementation and subsequent changes, and take legal advice on your circumstances.

Common questions

Did the Digital Omnibus postpone every EU AI Act duty?

No. The amended high-risk application dates do not erase obligations already applicable to relevant actors and systems. Assess each provision, role and transition separately.

Does the EU AI Act apply to a UK startup?

It may. A UK business should assess whether it places an AI system or general-purpose AI model on the EU market, puts a system into service in the EU, or supplies a system whose output is used in the EU. The applicable duties depend on the facts and the relevant role.

Is a third-party AI API enough to decide our role?

No. Buying API access does not decide whether your company is a deployer, a provider of a customer-facing AI system, or another actor. Examine intended purpose, branding, market route, contractual responsibilities and any substantial modification for each use.

Should we wait for the high-risk dates to start preparing?

No. Start with an inventory, role and risk assessment, then assign owners to applicable current duties. Use the additional time to assemble evidence and review product decisions rather than assuming that every obligation is deferred.