Is code written with AI regulated by the AI Act? What the definitions say

A question we are asked more often than any other about the AI Act, usually with some anxiety attached: our developers used an AI assistant to write part of this application — does that make it an AI system under the Regulation?

This page does not answer that for you, because the answer depends on facts about your product that we cannot see. What it does is put the two provisions the question turns on in front of you, quoted, so that the conversation with your adviser starts from the text rather than from a headline.

We are not your adviser and this is not advice.

Where these words come from

From the consolidated text of Regulation (EU) 2024/1689, CELEX 02024R1689-20260727 ("02024R1689 — EN — 27.07.2026 — 001.001"), read on 6 September 2026 from the Publications Office CELLAR, the datastore behind EUR-Lex. The consolidation incorporates Regulation (EU) 2026/1744, OJ L 2026/1744 of 24.7.2026. As the text says of itself: "This text is meant purely as a documentation tool and has no legal effect."

The definition everything hangs on

Article 3(1):

'AI system' means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments;

Read that slowly, because the grammar matters more than any summary of it. The definition describes a system that infers from input it receives how to generate outputs. It is a description of something that operates. It says nothing about how the system's own source code came to be written.

That is the whole of the observation we are prepared to make, and we make it about the sentence rather than about your product: the definition is addressed to what a system does, and an assistant that helped a developer type is not, on the face of this wording, thereby part of the system it helped to type. Whether that holds for your particular build is a question about your build.

The scope provisions worth reading alongside it

Article 2 carries the Regulation's scope. Two of its paragraphs come up constantly in this conversation:

10. This Regulation does not apply to obligations of deployers who are natural persons using AI systems in the course of a purely personal non-professional activity.

12. This Regulation does not apply to AI systems released under free and open-source licences, unless they are placed on the market or put into service as high-risk AI systems or as an AI system that falls under Article 5 or 50.

Paragraph 12 rewards a second reading, because it is often quoted with the second half left off. The open-source position is stated and then qualified, and one of the qualifications is Article 50 — the transparency Article. An open-source release is not, by the terms of this paragraph alone, outside everything.

The distinction people are reaching for

When somebody asks whether AI-written code is regulated, they are usually trying to separate two situations that feel similar and read very differently against the definition above:

1. A tool that ran on a developer's machine before release. It produced source code. It is not in the shipped artefact, it does not run when a user uses the product, and it receives no input from your users.
2. A capability that runs when the product runs. It receives input at use time and generates output — a suggestion, a draft, a classification, a summary.

The definition in Article 3(1) is written in the present tense about a system that infers from input it receives. That is the language your adviser will be applying. We are not going to tell you which situation you are in, because in our experience the answer is frequently both, in different parts of the same product, and the interesting cases are the ones nobody thought to classify.

There is also a third situation, and it is the one that catches people: a build step that generates content or configuration at deploy time rather than at development time. It is neither purely a developer tool nor obviously a runtime feature. If your pipeline has one, it is worth naming it explicitly rather than letting it sit unclassified between the two.

Questions for your adviser

• Does any model run at the moment a user uses the product, or did every model run finish before the release was cut?
• If the answer is only during development — is that still true of every build and deploy step, including anything that generates content, copy or configuration on the way out?
• Does our product ship a model, call one over an API, or neither?
• Where a model is called, whose prompt is it, and does the output reach a person outside our organisation or only our own staff?
• If we release any component under a free and open-source licence, have we read Article 2(12) including the qualification, and does any part of what we release touch Article 5 or Article 50?
• What is the first change to our roadmap that would move us from situation 1 to situation 2 — and whose job is it to notice on the day it happens?

That last question is the one worth writing down. The classification is rarely wrong when it is made. It goes wrong when nobody revisits it.

What we sell, and what we do not

We do not sell an AI-Act tool, and this page is not a funnel to one. What we make in this area addresses other regimes: Confida for whistleblowing under Directive (EU) 2019/1937, and Cyresora for incident-reporting clocks under NIS2 and the CRA. The full list is the compliance suite.

Consolidated text read 6 September 2026 from the Publications Office CELLAR (CELEX 02024R1689-20260727). No legal effect; the authentic version is the Official Journal text.