What duties do development teams have under the EU AI Act?

For the common case - a team using commercial AI coding assistants to build ordinary software - the duty set is small: the organization is a deployer and must support AI literacy among staff working with the tools (Article 4, softened to a 'support' duty by the 2026 Digital Omnibus), and transparency duties under Article 50 apply where people interact with AI systems you operate. The heavier provider obligations only attach if your team places AI systems on the market itself - and the high-risk regime only if those systems fall into the regulated categories.

Is using GitHub Copilot, Claude Code or Cursor regulated by the AI Act?

Using them makes your organization a deployer of an AI system, which as of July 2026 triggers little beyond the softened AI-literacy duty - coding assistants are not in a high-risk category. The tool vendors carry the general-purpose-AI obligations for the underlying models. What the Act notably does not do: regulate the quality of the code these tools produce. That stays your engineering responsibility.

What changed with the Digital Omnibus in June 2026?

Three things matter for development teams. High-risk compliance deadlines moved: standalone Annex III systems to December 2, 2027, and AI embedded in regulated products (Annex I) to August 2, 2028. The Article 4 AI-literacy duty was softened from 'ensure a sufficient level' to 'support the development of AI literacy'. Article 50 transparency obligations stayed on schedule for August 2, 2026, with a watermarking grace period until December 2, 2026 for systems already on the market.

When does a development team become a provider instead of a deployer?

Broadly: when it develops an AI system (or has one developed) and places it on the market or puts it into service under its own name. A team that ships an AI-powered feature in its product is heading toward provider territory for that system; a team that only uses AI tools to write conventional code is not. The classification decides which obligations apply, so it deserves a real assessment by your legal counsel rather than a heuristic.

Does the AI Act require us to verify AI-generated code?

Not as such - the Act regulates AI systems, not the code they emit for you. There is no article that mandates code review or verification of assistant output for ordinary software. The reasons to verify are engineering and liability reasons: the new Product Liability Directive treats software as a product, sector rules demand traceable development processes, and unverified AI code carries measured defect rates. The AI Act is the wrong place to look for that duty - it exists anyway.

What should a team realistically do now?

Four things, none dramatic: document which AI tools are in use and in which roles (that answers most audit questions); run a proportionate AI-literacy measure for staff using the tools and record it; check whether anything you ship is itself an AI system, and if so, classify it with counsel against the post-omnibus deadlines; and put your verification and evidence practice in writing - not because the AI Act demands it, but because the adjacent rules and your own risk do.

Compliance

The EU AI Act for Development Teams

Last updated: 2026-07-025 min read

For teams that use AI coding tools to build ordinary software, the EU AI Act demands less than the headlines suggest: the organization is a deployer, owes a (since June 2026 softened) AI-literacy duty under Article 4, and faces transparency duties only where people interact with AI systems it operates. The heavy obligations attach to providers of AI systems – and the high-risk deadlines moved to December 2027 and August 2028. What the Act does not regulate: the quality of the code your tools produce.

Contents

Where AI coding tools sit in the Act's risk model

Legal status: July 2, 2026. This article describes regulation for orientation – it is not legal advice; the assessment for your organization belongs to your counsel.

The AI Act sorts obligations by role and by risk. Role: whoever places an AI system on the market is a provider; whoever uses one professionally is a deployer. A team coding with Copilot, Claude Code or Cursor is a deployer; the tool vendors are providers and carry the general-purpose-AI obligations for the underlying models. Risk: coding assistants are not among the high-risk categories of Annex III – so the deployer duty set for everyday AI-assisted development is genuinely small.

The duties that actually apply to your team

AI literacy (Article 4). Since February 2, 2025, organizations owe their staff AI literacy appropriate to role and context. The June 2026 Digital Omnibus softened the wording from “ensure a sufficient level” to “support the development of AI literacy” – for a dev team, a documented, role-appropriate training measure on capabilities, limits and failure modes of the tools remains the sensible reading. The Commission’s Q&A confirms no specific certification is mandated.
Transparency (Article 50). Applies from August 2, 2026 where people interact with AI systems you operate – chatbots, AI-generated content toward users. Internal coding assistance does not put you in this bucket; an AI feature in your product might.
Provider duties - only if you ship AI. If your team places an AI system on the market itself, the provider obligations attach, with the high-risk regime (where applicable) now due December 2, 2027 (Annex III) or August 2, 2028 (Annex I embedded). That classification is a legal call, not a heuristic.

The dates that matter, post-omnibus

Date	What applies	Who it hits
Feb 2, 2025	AI literacy duty (Art. 4); prohibitions (Art. 5)	All providers and deployers - including dev teams
Aug 2, 2025	General-purpose AI model obligations	Model providers (your tool vendors)
Aug 2, 2026	Transparency obligations (Art. 50)	Operators of user-facing AI systems
Dec 2, 2026	End of watermarking grace period for pre-existing systems	Providers of generative systems
Dec 2, 2027	High-risk obligations, standalone systems (Annex III) - moved from Aug 2026	Providers/deployers of high-risk AI
Aug 2, 2028	High-risk obligations, AI embedded in regulated products (Annex I) - moved from Aug 2027	Product manufacturers with embedded AI

EU AI Act dates relevant to development teams after the June 2026 Digital Omnibus - the most common error in this field is citing pre-omnibus deadlines (status: July 2, 2026).

What the AI Act does not regulate: your code

The Act regulates AI systems – not the ordinary software those systems help you write. No article mandates review or verification of assistant output. That gap is easy to misread in both directions: it does not mean AI-generated code is legally safe to ship unchecked, because the duties live elsewhere – the new Product Liability Directive treats software as a product from December 2026, NIS2 puts development risk under management oversight, and sector rules demand traceable processes. Verification of AI output is engineering diligence the adjacent rules assume – the practical shape of it is described in our governance guide.

Where Reality Graph fits

Reality Graph makes no compliance promises and issues no legal verdicts. What it contributes to an AI Act posture is documentation where today there is mostly memory: written tasks, validation results and evidence reports per AI coding run – material your team can point to when someone asks how AI tools are used and controlled. Whether that satisfies any given duty is your counsel’s call, not ours.

This orientation gives you

The deployer/provider distinction that sorts your duties
Post-omnibus dates instead of stale 2026 deadlines
The honest boundary: the Act does not regulate your code quality
A short, concrete to-do list without alarmism

It does not give you

Legal advice or a classification of your systems
A compliance guarantee for any tool, including Reality Graph
Coverage of every edge case - counsel exists for those
A reason to skip verification - that duty lives outside the Act

If these boundaries fit how your team wants to ship:

Get early access See how it works

FAQ

What duties do development teams have under the EU AI Act?: For the common case - a team using commercial AI coding assistants to build ordinary software - the duty set is small: the organization is a deployer and must support AI literacy among staff working with the tools (Article 4, softened to a 'support' duty by the 2026 Digital Omnibus), and transparency duties under Article 50 apply where people interact with AI systems you operate. The heavier provider obligations only attach if your team places AI systems on the market itself - and the high-risk regime only if those systems fall into the regulated categories.
Is using GitHub Copilot, Claude Code or Cursor regulated by the AI Act?: Using them makes your organization a deployer of an AI system, which as of July 2026 triggers little beyond the softened AI-literacy duty - coding assistants are not in a high-risk category. The tool vendors carry the general-purpose-AI obligations for the underlying models. What the Act notably does not do: regulate the quality of the code these tools produce. That stays your engineering responsibility.
What changed with the Digital Omnibus in June 2026?: Three things matter for development teams. High-risk compliance deadlines moved: standalone Annex III systems to December 2, 2027, and AI embedded in regulated products (Annex I) to August 2, 2028. The Article 4 AI-literacy duty was softened from 'ensure a sufficient level' to 'support the development of AI literacy'. Article 50 transparency obligations stayed on schedule for August 2, 2026, with a watermarking grace period until December 2, 2026 for systems already on the market.
When does a development team become a provider instead of a deployer?: Broadly: when it develops an AI system (or has one developed) and places it on the market or puts it into service under its own name. A team that ships an AI-powered feature in its product is heading toward provider territory for that system; a team that only uses AI tools to write conventional code is not. The classification decides which obligations apply, so it deserves a real assessment by your legal counsel rather than a heuristic.
Does the AI Act require us to verify AI-generated code?: Not as such - the Act regulates AI systems, not the code they emit for you. There is no article that mandates code review or verification of assistant output for ordinary software. The reasons to verify are engineering and liability reasons: the new Product Liability Directive treats software as a product, sector rules demand traceable development processes, and unverified AI code carries measured defect rates. The AI Act is the wrong place to look for that duty - it exists anyway.
What should a team realistically do now?: Four things, none dramatic: document which AI tools are in use and in which roles (that answers most audit questions); run a proportionate AI-literacy measure for staff using the tools and record it; check whether anything you ship is itself an AI system, and if so, classify it with counsel against the post-omnibus deadlines; and put your verification and evidence practice in writing - not because the AI Act demands it, but because the adjacent rules and your own risk do.

Keep reading

ComplianceGDPR-Compliant AI CodingCode is rarely personal data - the context AI tools ingest often is. The eight-point checklist: data flow, Art. 28 DPA, transfers, training opt-outs, minimization. Assessment stays with your DPO.ComplianceAudit Trails for AI-Generated CodeGit records what changed - not what the task was, what was validated, who approved. The five auditor questions, why the demand rises under NIS2 and the new product liability, and how to build the trail.All articlesThe whole collection – 43 cited, dated guides on verifying AI-generated code.