The EU AI Act for developers

The EU AI Act (Regulation (EU) 2024/1689) is the EU’s law on AI. It doesn’t regulate models in general. It regulates what an AI system is used for, and the duties grow with the harm that use could do. If you build a product with an AI feature and it has users in the EU, some of it probably applies to you, even if your company is based elsewhere.

Most of the Act is about process and paperwork. A small part shows up in code, and that part is what this guide covers.

Provider or deployer

The Act gives different duties to two roles.

• A provider builds an AI system, or has one built, and puts it on the EU market under its own name.
• A deployer uses an AI system in its work.

A startup that wraps a model API in a hiring tool and sells it is a provider of that tool. A company that buys the tool and uses it to screen candidates is a deployer. Calling a vendor’s model doesn’t move your duties to the vendor: if the feature is yours, the system is yours.

The four tiers

The Act sorts uses into four groups.

1. Banned uses (Art. 5). For example social scoring, manipulation that causes harm, and reading people’s emotions at work or school.
2. High-risk uses (Art. 6 and Annex III). AI that helps decide about people in areas such as credit, hiring, education, essential services, insurance and biometrics.
3. Uses with openness duties (Art. 50). Chatbots must say they are AI, and AI-made images, audio and video must be marked.
4. Everything else. Mostly the AI literacy duty in Art. 4: the people who build and use the system should understand it well enough for their job.

The same model can sit in different tiers in different features. A summariser for internal notes is low-risk. The same summariser ranking loan applicants is high-risk. The tier follows the use.

The dates that matter

The Act applies in stages. The 2026 Digital Omnibus on AI (Regulation (EU) 2026/1744) moved the high-risk dates later.

Date	What starts to apply
2 February 2025	Banned uses and the AI literacy duty
2 August 2025	Rules for providers of general-purpose AI models
2 August 2026	General date of application, including most openness duties
2 December 2026	New bans on non-consensual intimate images; deadline for older generative systems to mark output
2 December 2027	High-risk rules for Annex III uses, such as credit and hiring
2 August 2028	High-risk rules for AI that is a safety part of products under Annex I

If your feature is high-risk, December 2027 sounds far away. Logging, human oversight and documentation take months to build into a product, so teams that start in 2027 will be late.

What shows up in code

Five duties leave traces you can find in a repository.

Record-keeping (Art. 12)

High-risk systems must log what they do so that events can be traced later. In practice that means every model call that affects a decision is recorded with a time, the model and version, a reference to the input and the output.

// Hard to trace later
const res = await openai.chat.completions.create({ model, messages });

// Traceable
const res = await openai.chat.completions.create({ model, messages });
await auditLog.write({ at: new Date(), model, inputRef: request.id, output: res.choices[0].message.content });

Lintsure’s AI call with no record kept rule flags files that call a model and never log anything.

Human oversight (Art. 14)

A person must be able to understand the output, ignore it, override it or stop the system. Code that turns a model score straight into a final decision, with no review step and no override, is the pattern to look for.

const decision = model.predict(features) > 0.7 ? "approved" : "rejected";

The automated decision rule flags lines like this one. Whether your process has a human check somewhere else is something only you can confirm, which is why Lintsure marks it Partial.

Telling people they talk to AI (Art. 50(1))

If your AI talks with people, they must know it is an AI unless that is obvious. A system prompt that tells the model to pose as a human breaks this directly. See AI told to hide that it is an AI.

Marking AI-made content (Art. 50(2) and 50(4))

Generated images, audio and video should carry a machine-readable mark, for example C2PA metadata or a watermark, and realistic fakes of real people or events need a visible label. Lintsure flags image, audio and video generation calls so you can check that the output gets marked.

Banned uses (Art. 5)

Emotion recognition at work or in schools is banned, with narrow exceptions. Libraries that read emotions from faces or voices are easy to spot in code. See emotion recognition or biometric categorisation.

What code can’t show

Most of the high-risk duties live outside the repository:

• the risk management process (Art. 9)
• data governance for training and test data (Art. 10)
• technical documentation following Annex IV (Art. 11)
• instructions for deployers (Art. 13)
• the quality management system (Art. 17)
• for deployers, named people who oversee the system and keep its logs (Art. 26)

A code scan can’t produce any of these. It can tell you whether the code supports them: whether there are logs to keep and an override for the overseer to use.

A short checklist for your repo

1. List every place your code calls a model, and write down what each one is used for.
2. For each use, decide the tier. If one could be high-risk, have a person with legal knowledge confirm it.
3. Make sure every high-risk call is logged with time, model, input reference and output.
4. Make sure no high-risk output becomes a final decision without a way for a person to review and override it.
5. Check that chat features say they are AI and that generated media is marked.
6. Remove anything close to a banned use.

Steps 3 to 6 are what npx lintsure scan looks for. Steps 1 and 2 need a person who knows what each feature is for.