EU AI Act for App Developers: Scope and Duties 2026

EU AI Act for App Developers: Scope and Duties 2026

Your U.S. app can fall under the EU AI Act - even if your company has no EU office. I’d start by checking each AI feature’s purpose, your legal role, and whether the system or its outputs are used in the EU.

As of November 3, 2026, prohibited-practice bans, AI-literacy rules, and Article 50 transparency duties already apply, subject to relevant exceptions and transition rules. Not every AI feature has the same duties.

Here’s the release check I use:

• Scope and role: Identify who supplies, deploys, imports, or distributes each system.
• Risk and notices: Check prohibited uses, high-risk categories, AI disclosures, and any general-purpose model duties.
• Dates: Verify deadlines and legacy-system rules against enacted law - not just guidance.
• Controls and records: Assign human owners, test features, keep required records, and review changes before release.

<u>Agents and vendors can help with the work; they do not take over your legal responsibility.</u>

The EU AI Act Explained for IT Engineers | What Every Developer Must Know (2026 Guide)

sbb-itb-622dc24

Classify Each AI Use Case

Once you’ve set the scope, classify each feature separately. A single app can contain several AI use cases, each with different duties.

Prohibited Practices and High-Risk Systems

Check Article 5 first, then Article 6. Review each feature for manipulation or deception, exploitation of vulnerabilities linked to age, disability, or socioeconomic circumstances, prohibited social scoring, crime-risk assessments based solely on profiling, and untargeted scraping of facial images.

Biometric categorization that infers sensitive characteristics can be prohibited. Emotion recognition in workplaces and educational institutions is prohibited unless intended for medical or safety reasons. Real-time remote biometric identification for law enforcement in publicly accessible spaces has narrow exceptions. Apply the statutory conditions exactly: a human approval step does not make a prohibited practice acceptable.

High-risk status has two routes. Article 6(1) covers AI systems that are products or safety components governed by Annex I harmonization legislation, where the product requires third-party conformity assessment. Annex III covers specified uses in employment, education, essential services, biometrics, and other listed settings.

Article 6(3) allows limited exceptions for Annex III systems that do not pose a significant risk of harm, including certain narrow procedural or administrative tasks. Document why the system does not materially affect decisions and how it meets the statutory conditions. Profiling natural persons rules out this exception. Providers relying on it must document their assessment before placing the system on the market or putting it into service, and retain registration evidence.

Transparency Duties and General-Purpose AI Models

Check transparency duties next - even if the feature is neither prohibited nor high-risk.

Article 50 duties depend on both the activity and the role. Providers must disclose when users are interacting with AI unless that is obvious. They must also support machine-readable marking and detection where required. These measures must be effective, reliable, robust, and interoperable.

Deployers must disclose deepfakes, applicable emotion-recognition or biometric-categorization use, and AI-generated text published to inform the public on matters of public interest. Public-interest text has an exception for human review and editorial responsibility. Artistic or satirical deepfakes receive tailored disclosure treatment - not a blanket exemption. Check the statutory exceptions separately for each duty.

Treat disclosure as a release check, not a substitute for classification or risk controls. A feature outside the prohibited, high-risk, and transparency provisions may have no additional category-specific duties.

GPAI duties cover model documentation, copyright policy, and applicable systemic-risk controls. Downstream app duties concern the complete application. Using a third-party API or an agent workflow does not determine classification; intended purpose, deployment setting, and decision authority do.

A Use-Case Classification Worksheet

Classify each use case separately. Before release, record the classification in one version-controlled worksheet per feature. Include:

• Feature and scope: Name, version, owner, release date, intended purpose, prohibited uses, affected people, users, deployment setting, and EU market placement or output use.
• System and roles: Model type and supplier, inputs, outputs, automated actions, profiling, human review and override, and legal roles.
• Decision and evidence: Applicable provisions, classification reasoning, supporting evidence, uncertainties, and next review date.

Record overlapping duties rather than forcing everything into one risk label. If claiming Article 6(3), retain the exception analysis and registration evidence. Reassess when a feature starts ranking, profiling, recommending, approving, denying, or materially influencing outcomes - or when staff routinely defer to its output.

Map Duties and Deadlines as of October 2026

Requirements in Effect and Future Deadlines

Use the classification above to assign each feature a start date, an owner, and an evidence file. Map its release to the controlling date and the records that show compliance.

Follow the enacted schedule in Regulation (EU) 2024/1689, Article 113. Track enacted amendments separately from guidance.

Duties by Role and Evidence to Keep

Assign each duty to one accountable role and one set of records, and name the responsible legal entity. The evidence formats below are recommendations - not separately required tools.

Existing Apps and Transition Rules

Check legacy apps separately. Transition rules can change when their duties begin.

Existing apps are not automatically exempt. Existing high-risk systems covered by Article 111 may qualify for transition treatment, but a significant design change can end that treatment or trigger new obligations. Special rules apply to public-authority systems and certain large-scale EU IT systems. Use the classification worksheet’s version record to track first placement and later changes. For GPAI models, also record capability changes and whether a new model or substantial modification is involved.

Non-EU high-risk system providers need an EU-established authorized representative before making the system available. GPAI providers face a separate representative requirement when the Act requires one. Keep the written mandate and the terms for accessing required documentation. App-store approval and vendor paperwork do not prove compliance or transfer legal responsibility.

Build Compliance Into Development

Turn each classified AI use case into a release record that stays current.

Create an AI Inventory and Duty Register

Inventory every model, API, agent, recommendation engine, voice or vision feature, and automated decision. Separate internal development tools from AI delivered to users. For each component, record the provider or supplier and the model or version.

For each use case, record its ID, linked classification, duty, deadline, owner, control, test, approval gate, and evidence repository.

Set Review Gates and Keep Records

Add release gates at discovery, architecture, implementation, QA, release, and post-launch monitoring. Each stage has a specific job:

• Discovery: Confirm intended use, users, EU exposure, legal roles, and risk category.
• Architecture: Approve data flows, model providers, fallback behavior, access controls, human intervention, and logging.
• Implementation: Review prompt restrictions, output handling, privacy controls, security, accessibility, and user disclosures.
• QA: Test representative and edge-case inputs, prompt injection, hallucinations, bias, unsafe outputs, abuse cases, and escalation paths.
• Release: Verify required documentation, notices, instructions, training, and rollback procedures.
• Post-launch monitoring: Track incidents, drift, complaints, model changes, and changes in users, markets, data, or automated actions.

Keep evidence of implementation: versioned test sets, model and prompt configurations, approvals, incident reports, monitoring results, and rollback decisions. Set access controls and retention periods that reflect GDPR and applicable national law. Don’t keep evidence longer than required.

For high-risk systems, deployers must keep controlled system logs for at least six months, unless another applicable law requires a different approach.

Require an impact review before changing models, data, markets, users, or automated actions. Block release until classification, controls, testing, notices, and evidence are current. Assign each compliance control to one accountable human owner.

Assign Agent Tasks and Human Oversight

Agents support execution; the regulated organization keeps legal responsibility. Accountable people must approve classification, assess unresolved risks, authorize releases, and handle incidents.

For high-risk systems, human oversight requires people with suitable skills, training, authority, and support - not just a nominal approval button. Agent-assisted development also does not replace privacy, consumer-protection, employment, accessibility, cybersecurity, or product-safety reviews.

Conclusion: A Compliance Checklist for Each Release

Scope → role → risk → date → controls → evidence. After classification, use this checklist to turn scope decisions into release controls. Duties depend on intended purpose, actual use, users, EU market placement, and legal role - not labels such as “AI-powered,” “copilot,” “automation,” or “agent.”

Now: Check Duties Already in Effect

As of October 2026, the August 2, 2026 deadline has passed. Audit each use case against the duties now in effect. Prohibited-practice bans and AI-literacy measures have applied since February 2, 2025.

Article 50 transparency duties apply from August 2, 2026. Check required user disclosures, machine-readable marking, and content or use notices. These transparency duties remain separate from later high-risk obligations.

Next: Prepare for Remaining High-Risk Deadlines

Before setting a ship date, confirm high-risk status, whether the Annex III or Annex I route applies, and the relevant transition rule. The scheduled deadlines are December 2, 2027, for relevant Annex III systems and August 2, 2028, for relevant Annex I product systems.

Assign owners and plan readiness around when the law applies - not your internal roadmap.

Every Release: Recheck Scope and Evidence

For each new release or material change, check for changes to purpose, model, data, users, market, autonomy, output type, integration, or impact. Rerun affected tests and update the related compliance evidence and approvals. If you find that a duty doesn't apply, record the reason and date.

Check EUR-Lex before relying on a deadline. Distinguish enacted amendments from proposals and guidance.

FAQs

Does incidental EU use bring my U.S. app under the Act?

Yes, incidental use by people in the EU can bring your U.S. app under the EU AI Act. The Act generally covers AI systems placed on the EU market or put into service there, no matter where the developer is based.

That said, EU access or use alone doesn’t automatically trigger coverage. Whether the Act applies depends on how your app is offered and used. If it falls within scope, you’ll need to determine its risk classification and meet the related compliance duties.

When does customizing an AI model make me a provider?

Under the EU AI Act, you’re a provider if you place an AI system on the market or put it into service under your own name or trademark.

Customizing an AI model also makes you a provider if major modifications change its risk category or materially alter its intended purpose. If you use the customized model for a different objective than originally intended, you take on the provider’s regulatory duties.

How can I verify which compliance deadlines apply to my app?

Start by checking whether your AI system falls into the high-risk category under the EU AI Act. Work with your legal and compliance teams to review official European Commission updates. Then align your development roadmap with the deadlines that apply to your system.

Check platform-specific policies monthly, keep technical documentation up to date, and conduct Data Protection Impact Assessments (DPIAs). Confirm which requirements are already in effect and which have deadlines ahead.