The EU AI Act for companies building software with agents

The EU AI Act (Regulation (EU) 2024/1689) reaches a company that only uses coding agents (Claude Code, Codex, Cursor) through one duty: Article 4 AI literacy, which the Digital Omnibus (Regulation (EU) 2026/1744) softened but did not remove. General-purpose AI model duties fall on the vendors. Your product changes the picture once it contains an AI system.

A customer’s procurement questionnaire arrives with a new line: “Describe your compliance with the EU AI Act.” Your engineers now open most pull requests through agents, the board read that the Omnibus “delayed the AI Act”, and a sales lead wants to answer “fully compliant” by Friday. Nobody in the room can say which articles apply to you, which apply to Anthropic or OpenAI, and which apply only if the product ships an AI feature.

This page is for the CTO who has to give that answer, and for the executive who has to sign it. It is an engineering reading of the regulation, not legal advice: confirm your position with counsel before you rely on it.

Sources and how they were checked

The legal texts are Regulation (EU) 2024/1689 (the AI Act) and Regulation (EU) 2026/1744 (the Digital Omnibus on AI, in force 27 July 2026). The Council announced the political agreement on 7 May 2026. On 2026-09-26 EUR-Lex could not be fetched from the environment this page was written in, so the post-Omnibus dates and the Article 4 change below rest on the Council’s announcement and on secondary law-firm and specialist summaries: Gibson Dunn, Morgan Lewis, Cuatrecasas, Usercentrics and aiactblog.nl (2026). Read the consolidated text on EUR-Lex before you quote a date in a contract.

What this page gives a CTO preparing for the AI Act

• A role table for you and your vendors, and a dated timeline of what the Digital Omnibus moved.
• A product decision table: which features change your obligations, and from when.
• An AI-literacy record, an AI-system register, a CI check that blocks an unregistered AI feature, and two inventory prompts.
• Failure modes in agent-heavy teams, and five questions an executive can ask the CTO.

Which AI Act roles does a company using coding agents hold?

The AI Act assigns duties by role, not by technology. Four roles matter to a software company. The definitions are in Article 3 of the regulation.

Role	Definition in short	Who holds it for Claude Code, Codex and Cursor
Deployer	Uses an AI system under its authority in a professional activity	You, for every coding agent your engineers use at work
Provider of an AI system	Develops an AI system and places it on the market or puts it into service under its own name	Anthropic (Claude Code), OpenAI (Codex), Anysphere (Cursor). You, for any AI system you build, including one you build only for internal use
Provider of a general-purpose AI (GPAI) model	Develops a general-purpose model and places it on the market	The model vendors: Anthropic for Claude models, OpenAI for GPT models, and the vendor of any other model you select
Downstream provider	Integrates a GPAI model into its own AI system	You, when you build a product feature or an internal agent on a model API such as the Claude API, the Claude Agent SDK or the Codex SDK

The second row is the one teams miss. Wiring the Claude API into an internal review bot, or building a support chatbot on GPT, makes you the provider of that AI system. Using Claude Code to write an ordinary web application does not: the application is not an AI system.

What reaches you today if you only use coding agents?

For a company whose agents write, test and review code, and whose shipped product contains no AI feature, the list is short.

Provision	Applies to you?	Since	What it asks
Art. 4 AI literacy	Yes, as deployer	2 Feb 2025; amended by the Omnibus from 27 Jul 2026	Measures for the AI literacy of staff who operate or use AI systems. The Omnibus softened Article 4 (secondary: Gibson Dunn, aiactblog.nl, 2026); it still requires measures for staff AI literacy. Read the amended wording on EUR-Lex before quoting it
Art. 5 prohibited practices	Only if you cross one	2 Feb 2025	Relevant here: no AI system that infers the emotions of employees at work, except for medical or safety reasons. Do not build “developer sentiment” tooling from voice, video or keystrokes
Art. 50 transparency, deployer side	Rarely	2 Aug 2026	Covers emotion recognition, biometric categorisation, deepfakes and AI-generated text published to inform the public on matters of public interest. Source code is none of these
Art. 26 high-risk deployer duties	No, for coding agents	Annex III systems from 2 Dec 2027	A coding agent is not an Annex III use. The exception is using an AI system to evaluate engineers, covered in failure modes
Arts. 53 and 55 GPAI obligations	No, they bind the model vendors	2 Aug 2025; Commission enforcement from 2 Aug 2026	Technical documentation, information to downstream providers, copyright policy, training-data summary, and systemic-risk duties for the largest models

Two consequences follow. Agent-written code carries no AI Act labelling duty; labelling agent changes for review routing and audit (change provenance and risk routing) is an engineering choice. And the vendor’s GPAI compliance does not discharge your Article 4 duty: each role carries its own obligations.

Fine-tuning rarely makes you a GPAI provider

The Commission’s guidelines for GPAI providers treat a downstream modifier as a new GPAI provider only when the modification uses more than one third of the original model’s training compute, an indicative threshold. Prompting, skills, CLAUDE.md or AGENTS.md files, retrieval and ordinary fine-tuning are nowhere near it.

What did the Digital Omnibus change, and what did it not?

The Omnibus did not postpone the AI Act as a whole. It moved the high-risk dates, softened AI literacy and left the rest of the timeline in place.

Date	What applies	Changed by the Omnibus?
2 Feb 2025	Prohibited practices (Art. 5) and AI literacy (Art. 4)	Art. 4 softened, not removed
2 Aug 2025	GPAI provider obligations; penalties regime	No
27 Jul 2026	Regulation (EU) 2026/1744 enters into force	Yes: it adds a prohibition on AI systems that generate non-consensual intimate imagery or child sexual abuse material (secondary sources). That prohibition did not exist in February 2025; read its application date in the Omnibus text on EUR-Lex
2 Aug 2026	Commission enforcement powers over GPAI providers, including fines up to 3% of worldwide turnover or €15 million; Art. 50 transparency duties	No
2 Dec 2026	Art. 50(2) machine-readable marking for generative AI systems placed on the market before 2 Aug 2026	Yes: a grace period for systems already on the market
2 Aug 2027	GPAI models placed on the market before 2 Aug 2025 must comply	No
2 Dec 2027	High-risk obligations for Annex III systems (employment, credit, education, essential services and others)	Yes: moved from 2 Aug 2026
2 Aug 2028	High-risk obligations for AI in products covered by Annex I sectoral law (medical devices, machinery and others)	Yes: moved from 2 Aug 2027

For a company that only uses coding agents, the Omnibus changed one thing that matters: it softened Article 4. It is still an obligation to take literacy measures, and it has applied since February 2025.

When does the product you build change the picture?

Your obligations grow with what you ship, not with how much of it the agents wrote. Use this table in product review whenever a feature touches a model.

You ship or run…	Your role	What applies	From
Ordinary software written with agents, no AI feature	Deployer of the coding agents	Art. 4 only. The software itself falls under other EU law: see CRA, NIS2 and DORA-EU	Now
An internal agent on a model API (review bot, triage agent, runbook agent)	Provider and deployer of that system	Art. 4. Art. 50(1) disclosure is not needed where it is obvious to a reasonably well-informed person that they are talking to AI; label the bot anyway	Now
A chatbot or assistant that talks to customers	Provider	Art. 50(1): design it so people are informed they are interacting with an AI system	2 Aug 2026
A feature that generates text, images, audio or video	Provider	Art. 50(2): mark outputs in a machine-readable format, detectable as artificially generated	2 Aug 2026; 2 Dec 2026 for systems already on the market
An AI feature in an Annex III area: recruitment and worker management, creditworthiness, education assessment, access to essential services	Provider of a high-risk system	Risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, conformity assessment, registration	2 Dec 2027
AI inside a product under Annex I sectoral law, such as a medical device	Provider	High-risk obligations through the sectoral conformity route	2 Aug 2028
A model you train, or modify beyond the compute threshold	GPAI provider	Arts. 53 and 55	Already applies
AI features you build for a client who sells them under its own name	Usually the client is the provider; your contract must say so	As above, for whichever party is the provider	Per feature

The last row matters to software houses: whoever places the system on the market under its own name is its provider, so the delivery contract must name the provider per AI system and assign the Art. 50 and documentation work. See AI-native delivery for software houses and agencies.

Where does the vendor chain sit for each coding agent?

Your obligations are the same whichever tool you use; what differs is the upstream provider you ask for documentation. Record the model that ran, because its vendor is the GPAI provider.

Claude Code

Anthropic provides both the AI system (Claude Code) and the GPAI models it runs. The default model is Claude Opus 5.5 on the latest release channel; see the models hub for current defaults. Routing through Amazon Bedrock or Google Cloud’s Agent Platform changes the contracting party and data terms, not the model provider.

To make CI runs auditable, pin the model and keep the JSON result as evidence:

# CI job: pipe the diff in so the job does not depend on tool permissions
# (claude -p starts in Manual mode, v2.1.283); pin the model and keep the JSON result as evidence
mkdir -p evidence
git diff origin/main...HEAD | claude -p --model claude-opus-5-5 --output-format json \
  "Review this diff against docs/ai-register.yaml and list any new AI system" \
  > evidence/claude-review.json

Codex

OpenAI provides both the AI system (Codex) and the GPAI models. GPT-6 Astra is the bundled default in codex-cli 0.157.1; see the models hub.

To make CI runs auditable, pin the model and keep the JSONL event stream:

# CI job: pipe the diff in, pin the model and keep the event stream as evidence
mkdir -p evidence
git diff origin/main...HEAD | codex exec -m gpt-6-astra --json \
  "Review this diff against docs/ai-register.yaml and list any new AI system" \
  > evidence/codex-review.jsonl

Cursor

Anysphere provides the AI system (Cursor). The GPAI provider is the vendor of whichever model the developer selects, so it can change between sessions. Record Cursor once as the AI system and list each model your policy allows, with its vendor, as a separate upstream provider; check the models hub before you name one.

To make headless runs auditable, run Cursor’s CLI in print mode (-p), record which model it ran from its output, and keep that output as evidence; see CI/CD with the Cursor CLI.

If you build on a model API rather than only using an agent, Article 53(1)(b) obliges the GPAI provider to give downstream providers the information they need to understand the model’s capabilities and limitations. Ask for it in procurement and file it with the register entry.

How do you meet the AI-literacy duty with evidence?

Article 4 asks for measures that fit the people, the systems and the risk. A single all-hands slide is a measure, but it is not evidence that anyone operating an agent knows what it can break. A record per role is.

1. List who operates or uses AI systems. Everyone with a Claude Code, Codex or Cursor seat, everyone who approves agent pull requests, and everyone who configures agents, hooks, skills or MCP servers.

2. Define what each role must understand. Developers: prompt injection, secrets, hallucinated dependencies and how to verify output. Reviewers and tech leads: what the gates prove and what they do not. Product managers: which features are AI systems under the Act. Executives: the role table and the timeline on this page.

3. Choose a measure per role. Onboarding sessions, a kata set, review-to-learn sessions, reading assignments with a short check. The upskilling curriculum doubles as this record.

4. Record completion with a date and a link to the material. Store it where HR or compliance can read it without asking engineering.

5. Re-run when the systems change. A new agent, a new autonomy level or a new model family is a trigger. So is a 12-month age on any record.

Adopt this record format as-is. It is YAML so that an agent can generate and check it:

docs/compliance/ai-literacy-record.yaml

- person: "j.kowalski"
  role: developer
  systems: [claude-code, codex]
  autonomy: "tier 1: reversible local changes"
  measures:
    - name: "Agent onboarding: injection, secrets, dependency checks"
      date: 2026-09-12
      material: "https://wiki.example.com/agents/onboarding"
    - name: "Review-to-learn session: verifying agent PRs"
      date: 2026-09-19
      material: "https://wiki.example.com/agents/review-to-learn"
  next_review: 2027-09-12
  owner: "head-of-engineering"

The metric that proves the duty is met: literacy coverage, the share of people with an active agent seat or agent-approval rights who have a record with a measure dated within the last 12 months. Target 100%, report it quarterly and treat a gap as an access problem: no record, no seat.

Register every AI system you provide

The register answers the questionnaire, feeds the literacy record and tells you when a feature crosses into Article 50 or Annex III. Keep one entry per AI system, including internal agents:

docs/ai-register.yaml

- id: support-assistant
  owner: "team-support-platform"
  our_role: provider            # provider | deployer | downstream-provider
  purpose: "Answers customer questions in the help widget"
  users: external               # internal | external
  upstream_models:
    - vendor: Anthropic
      model: claude-opus-5-5
  art50: ["50(1) disclosure in widget header"]
  annex_iii: none               # or the point number, e.g. "4(b)"
  personal_data: true           # triggers the GDPR record as well
  reviewed: 2026-09-26
  reviewer: "cto"

Then stop an unregistered AI feature at the pull request. This CI step fails when a change adds a model SDK but does not touch the register. The three-dot diff needs the merge base, so check out full history (actions/checkout with fetch-depth: 0 on GitHub Actions); the same applies to the git diff origin/main...HEAD examples above:

# CI step (GitHub Actions or any runner), run on pull requests.
# Fails closed: a missing base ref or merge base is an error, not a pass.
set -euo pipefail
BASE_BRANCH="${GITHUB_BASE_REF:-main}"   # set by GitHub Actions on pull requests
git fetch --no-tags origin "$BASE_BRANCH"
BASE="origin/$BASE_BRANCH"
git rev-parse --verify "$BASE" >/dev/null || { echo "base ref missing"; exit 1; }
# Capture the diff first: with no merge base, git diff fails here and set -e stops the job.
# Manifests at any depth, so a monorepo package or a service subdirectory is covered too.
DIFF=$(git diff "$BASE"...HEAD -- ':(glob)**/package.json' ':(glob)**/pyproject.toml' \
  ':(glob)**/requirements*.txt' ':(glob)**/go.mod')
if printf '%s\n' "$DIFF" | grep -iE '^\+.*(anthropic|openai|claude-agent-sdk|codex-sdk|cursor[-/_]?sdk|google[-/]genai|generative-?ai|langchain|llama[-_]?index|@ai-sdk/|"ai"[[:space:]]*:|mistral|cohere|ollama)'; then
  git diff --name-only "$BASE"...HEAD | grep -qx 'docs/ai-register.yaml' || {
    echo "A model SDK was added. Add or update the entry in docs/ai-register.yaml."; exit 1; }
fi

The pattern is deliberately broad. A false positive costs one register review; a missed chatbot costs an Article 50 finding. It reads dependency manifests only: a model reached through raw HTTP calls or a vendored client does not trip it, which is what the inventory prompt below is for.

Copy-paste prompts to map your AI Act exposure

Run these from the repository root in any of the three tools.

Copy-paste prompt: inventory AI systems in this codebase

Inventory every place this repository calls a language model or other AI
system at runtime (not the coding agents used to write it). Search
dependency manifests and imports for model SDKs (Anthropic, OpenAI, Claude
Agent SDK, Codex SDK, Cursor SDK, Google GenAI, LangChain, LlamaIndex) and
for HTTP calls to model APIs.

For each one, report: file and function, what the feature does, who sees
its output (internal staff or external users), whether it talks to people,
whether it generates text, images, audio or video that leaves the system,
and whether it makes or supports decisions about hiring, worker performance,
credit, education or access to essential services.

Output a YAML list in the format of docs/ai-register.yaml. Mark every field
you are unsure about as "UNSURE" with the evidence you found. Do not guess
a legal classification; flag it for review instead.

Copy-paste prompt: draft AI-literacy records from existing material

Read our onboarding and agent documentation (docs/, CONTRIBUTING.md,
CLAUDE.md, AGENTS.md and any .cursor/rules files). Draft
docs/compliance/ai-literacy-record.yaml entries for four roles: developer,
reviewer or tech lead, product manager, and executive.

For each role, list which existing documents already teach: prompt
injection, secrets handling, hallucinated or typosquatted dependencies,
what our CI gates prove and do not prove, and which of our features are AI
systems. List each topic no document covers as a GAP with a one-line
proposal for the smallest measure that would cover it. Do not invent
completion dates; leave date fields empty.

Treat both outputs as drafts. The inventory is a search result that a named engineer confirms, and the classification is a decision that the CTO signs with counsel.

How do you prove the AI Act position holds?

Four controls keep the position true as features merge, without anyone reading every diff:

Control	What it proves	Owner	Cadence
Register CI check (above)	No model SDK enters the codebase unregistered	Platform team	Every pull request
Register review	Each entry’s role, Art. 50 and Annex III fields are still correct	CTO, with counsel for any annex_iii other than none	Quarterly and before each launch of an AI feature
Literacy coverage	Every agent operator has a current record	Head of engineering	Quarterly
Art. 50 acceptance test	The disclosure is rendered and generated media carry a machine-readable marker	Feature team	In the feature’s end-to-end suite

The CTO signs the register review. For any entry with an Annex III point, the sign-off needs counsel as well, and a plan for the 2 December 2027 obligations.

What goes wrong with AI Act compliance in agent-heavy teams?

Reading the Omnibus as “the AI Act is delayed.” Only the high-risk dates moved. Article 4 and Article 5 have applied since February 2025, and Article 50 since August 2026. Recovery: put the timeline table in the board pack and correct the internal message in writing.

Scoring individual engineers with an AI system. A per-person performance score, ranking or task allocation produced by a model from agent telemetry is an Annex III point 4(b) use: monitoring and evaluating the performance and behaviour of workers. From 2 December 2027 that is a high-risk system, and it brings GDPR and works-council questions today. A plain dashboard that counts merged pull requests is not an AI system; a model that judges people is. Recovery: measure teams, not people, with the metrics frameworks, and remove per-person AI scoring before it spreads.

A feature team ships a chatbot through an agent. The agent adds an SDK, writes the widget, and nobody asks whether users are told they are talking to AI. Recovery: the register CI check, plus an Art. 50 acceptance test that fails when the disclosure is missing.

“Fully compliant” in a customer questionnaire, or “our vendor covers it”. A blanket claim invites a follow-up you cannot answer, and the vendors’ GPAI compliance does not transfer your deployer and provider duties. Recovery: answer by role, split into “vendor” and “us”. Attach the vendor’s documentation to the first half; in the second, name your role per system, the articles that apply, your measures and the date of the last register review.

Five questions an executive can ask the CTO

1. For each AI system we use or ship, what is our AI Act role, and where is that written down?
2. What is our literacy coverage today, and what happens to someone’s agent access when their record lapses?
3. Which of our shipped features talk to people or generate media, and how do we test the Article 50 disclosure?
4. Does anything we build or use evaluate, rank or allocate work to individual employees with AI?
5. When did counsel last review the register, and which entries are waiting on the 2 December 2027 high-risk date?

Who supervises the AI Act in Poland?

Each member state designates its own market surveillance authorities. Poland designates its authority in a national implementing act; the government draft named a new Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI). Check in ISAP whether the act has been adopted before you cite it. GPAI providers are supervised by the Commission’s AI Office, not by national authorities.

Where to go next with EU regulation and agents

CRA, NIS2 and DORA-EU The EU rules that govern the software your agents write: vulnerability reporting, SBOMs and operational resilience.

Upskilling a team for agentic engineering The curriculum that produces the AI-literacy record.

Legal and IP questions about agent-written code Ownership, licences and contracts, which the AI Act does not settle.

An AI usage policy engineers will follow Where the literacy duty and the register become day-to-day rules.

Data privacy and enterprise policies GDPR and data terms for agent data flows.

Reporting AI engineering to the board Put the role table and the timeline in the risk section of the board pack.