The EU AI Act has very little to say about the coding assistant your engineers use, and a great deal to say about what they build with it.
Teams that start their AI Act work with the assistant start in the wrong place. The Act assigns obligations by role and by risk. Using a coding assistant makes your company a deployer of what is, in almost every case, a minimal-risk system, and the obligations on the model behind it fall on the model's provider. If your product contains AI, you are its provider, and if that AI is high risk, the heaviest obligations in the Act are yours.
Does the EU AI Act apply to AI coding assistants
Lightly. Writing software is not one of the high-risk uses the Act lists, and your direct duties as a deployer of a coding assistant are limited. The Act's rules for general-purpose AI models apply to whoever provides the model, not to you as a user.
What applies to what you ship
Two sets of obligations matter for most software teams. Transparency: AI that interacts with people, such as a chatbot, has to make clear the user is dealing with AI, and generative systems have to mark their output as AI-generated in a machine-readable way. High risk: if your product is or contains a high-risk AI system, such as credit scoring or hiring, or AI in a product already covered by EU product safety law, such as a medical device, you face requirements for risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, and a quality management system.
The dates, after the amendments adopted in 2026:
- 2 August 2025. Obligations for providers of general-purpose AI models.
- 2 August 2026. Transparency duties. For systems already on the market before that date, the marking duty applies from 2 December 2026.
- 2 December 2027. High-risk requirements for the stand-alone uses the Act lists, such as credit scoring and hiring.
- 2 August 2028. High-risk requirements for AI in products covered by EU product safety law, such as medical devices and machinery.
Where the coding agent comes back in
A provider of a high-risk AI system needs a quality management system that covers the design, design control, and design verification of the system, and its development, quality control, and quality assurance. If agents write part of that system, they are part of the process the quality management system has to describe and control. The assistant the Act mostly ignores reappears inside your obligations, not as a regulated system but as a step in a regulated process.
An illustrative case, not a customer: a lender sells a credit-scoring model to consumers in the EU, a listed high-risk use. Its quality management system, written two years ago, says every change to the scoring service is written by an engineer and reviewed by a second engineer. Today coding agents write a large share of the feature pipeline and service code, and the engineer who prompts the agent often reviews the result. No sentence in the procedure was false when it was written. It just no longer describes the process that runs. When an auditor or regulator asks how a change to the model's pipeline was designed, built, and verified, the documented answer and the real one differ, and the lender cannot show which is which.
Medical device makers face the same gap from two directions, the AI Act and their FDA quality system. See IEC 62304 and FDA expectations when AI agents write device software.
ISO/IEC 42001 and the NIST AI RMF
Many teams organize this work around ISO/IEC 42001, the certifiable AI management system standard published in 2023, or the voluntary NIST AI Risk Management Framework and its four functions: govern, map, measure, and manage. Neither replaces the Act. Both ask what the Act's quality management system asks: where AI is used in your processes, what it did, and whether your controls over it work.
What to have ready
- An inventory by role. Which AI systems you provide, which you deploy, and which are high risk. The coding assistant belongs on the list, in the deployer row.
- A quality management system that names agents. Which development steps agents may do on high-risk systems, which they may not, and where a person has to approve their work.
- A development record for every high-risk change. Who or what wrote it, how it was verified, and who approved it, so you can show the documented process is the one that ran.
- A transparency check on what is already live. Chat features that disclose they are AI, and generated content that carries a machine-readable mark, since those duties already apply.
Keeping the quality system honest
A quality management system is only as good as its match to the process. Bloomfilter rebuilds the process that actually runs from your tickets, version control, CI, and agent sessions, including which steps agents did and where reviews were skipped, so the gap between the documented process and the real one is something you can see and close. It does not classify your AI systems. Read the regulated software use case.