What the EU AI Act means for your build
Law firms explain the regulation. This page explains what to write in the code.
If you are building an AI feature for EU users today, the obligation that most likely affects you is Article 50 transparency: tell people they are talking to an AI, mark AI-generated content in a machine-readable way, and label synthetic media. The heavier high-risk obligations have been deferred, and most ordinary products - support assistants, document search, internal copilots - are not high-risk in the first place.
What to do now: work out whether you are a provider or a deployer, check your system against the high-risk list rather than against your intuition, implement disclosure and content marking, and start keeping the documentation. All of that is engineering you would want anyway.
Last reviewed: 22 September 2026. Dates and article numbers should be checked against the Official Journal before you rely on them - this is an engineering summary, not legal advice.
What is in force, and what moved
| Obligation | Status | Note |
|---|---|---|
| Prohibited practices | In force since February 2025 | Enforceable now. Social scoring, untargeted facial-image scraping, emotion inference at work and in education, and similar. |
| General-purpose AI model obligations | In force since August 2025 | Falls on model providers. If you fine-tune and distribute a model, check whether it falls on you too. |
| Article 50 transparency | Applies from 2 August 2026 | Not deferred. This is the one that affects most ordinary builds. |
| High-risk, Annex III standalone systems | Deferred to 2 December 2027 | Moved by the Digital Omnibus package. |
| High-risk, Annex I embedded systems | Deferred to 2 August 2028 | Same instrument. |
| Additional Article 5 prohibitions | Phasing in from 2 December 2026 | Added by the Omnibus. |
Penalties at the top of the scale reach EUR 35 million or 7% of global annual turnover, which is why the classification question is worth answering properly rather than assuming. How we handle client data while building against this is on the security page.
Is your system actually high-risk?
Work through this in order. Most systems stop at the first or second question.
1. Is it a prohibited practice?
Social scoring by public authorities, untargeted scraping of facial images, emotion inference in workplaces or schools, biometric categorisation by protected characteristics, and real-time remote biometric identification in public spaces for law enforcement. If yes, it cannot be placed on the EU market at all.
2. Is it a safety component of a regulated product?
Annex I covers systems embedded in products already regulated under EU product-safety law - medical devices, machinery, vehicles, lifts, toys. If your AI is a safety component of one of those, you are in the Annex I high-risk track.
3. Is it on the Annex III list?
Biometrics, critical infrastructure management, education and vocational training decisions, employment and worker management including CV screening, access to essential private and public services including credit scoring and insurance pricing, law enforcement, migration and border control, and administration of justice. Note how specific this list is - "our system makes important decisions" is not the test.
4. Does it interact with people or generate content?
Then Article 50 transparency applies even though it is not high-risk. This is where most products land.
What Article 50 requires, in code
Disclose that it is an AI
A person interacting with an AI system must be told so, unless it is obvious to a reasonably well-informed person. In practice: persistent text in the interface rather than a one-time modal, present in the first response of a session, and carried into any channel the assistant reaches - a chat widget, an email reply, an SMS thread. Put it in the system's own response template so it cannot be lost when someone redesigns the page.
Mark generated content machine-readably
Providers of systems generating synthetic audio, image, video or text must mark the output in a machine-readable way. That means provenance metadata on the artefact - C2PA content credentials for media, and a recorded, queryable flag on generated text in your own datastore - not just a visible watermark a screenshot removes.
Label deepfakes and public-interest text
Deep-fake image, audio and video must be disclosed as artificially generated. AI-generated text published to inform the public on matters of public interest must be disclosed too, unless a human reviewed it and someone holds editorial responsibility. If you generate marketing or news copy at scale, the editorial review step is the cheapest route to compliance and improves the output anyway.
Logging and human oversight patterns to build now
These are required for high-risk systems and are simply good practice everywhere else. Building them from the start costs very little; retrofitting them into a live system costs a lot.
- Immutable request logs: input, retrieved context, model and version, output, and the identity of the person or service that triggered it. Retention long enough to investigate a complaint.
- A recorded human decision point for anything consequential - who approved, when, and what they saw at the time.
- An override path that is used, not theoretical. If nobody has ever overridden the system, your oversight is decorative.
- Versioned prompts and model configuration in source control, so you can answer 'what was it doing on 3 March' without guessing.
- Evaluation results stored with the release they gated, not in a spreadsheet someone owns personally.
We build these into every system as a matter of course - see AI integration for how the evaluation and rollback layers fit together, and AI agent development for the capability boundaries and approval steps that Article 14 oversight ends up resting on.
Provider or deployer?
| Provider | Deployer | |
|---|---|---|
| Who you are | You develop the system and place it on the market under your own name or trademark | You use an AI system under your own authority in your operations |
| Typical example | You ship an AI feature inside your own product | You use a vendor's AI tool to screen job applicants |
| Main duties | Conformity, technical documentation, risk management, transparency, post-market monitoring | Use it as instructed, assign competent human oversight, keep logs, inform affected people |
| Watch for | Substantially modifying someone else's system can make you its provider | Putting your own name on a third-party system makes you the provider |
Documentation to start keeping today
- A one-page description of the system: intended purpose, the decisions it supports, and what it must not be used for.
- Data sources and their provenance, including anything scraped or licensed.
- Evaluation methodology, the test set, and the results you accepted before launching.
- Known limitations and failure modes, written honestly enough to be useful in an incident.
- Human oversight arrangements: who, what they can override, and how they are trained.
- A change log of anything that alters behaviour - prompt, model version, retrieval configuration, thresholds.
Frequently asked questions
It applies if your system is placed on the EU market or its output is used in the EU, regardless of where you are established. A US company whose product has EU users is in scope. Location of your servers is not the test; where the system is used is.
Almost certainly not. High-risk is a defined list - biometrics, critical infrastructure, education and employment decisions, essential services, law enforcement, migration, justice - not a judgement about how important the system feels. Most customer support, search and internal productivity systems are not high-risk but are covered by Article 50 transparency obligations.
Three things: tell a person they are interacting with an AI system unless it is obvious, mark AI-generated or manipulated content in a machine-readable way, and disclose deepfakes and AI-generated text published to inform the public. In practice that is a disclosure string in the interface, provenance metadata on generated media, and a label in the publishing pipeline.
You are a provider if you develop a system and put it on the market under your own name. You are a deployer if you use someone else's system in your own operations. Most companies building an AI feature into their own product are providers of that system and deployers of the underlying model. The obligations differ, and it is worth writing down which you are before you need to prove it.
A description of the system's purpose and limits, the data sources it uses, the evaluation results you accepted before launch, the human oversight arrangements, and a log of material changes. None of that is wasted effort even if the obligations never bite - it is the same documentation that makes a system maintainable.
We build the technical parts - disclosure patterns, content marking, logging, human-in-the-loop checkpoints and the documentation that goes with them. We are engineers, not lawyers, and we will not give you a legal opinion on your classification. We will tell you what we built and hand it to your counsel.
Building for EU users?
We build the disclosure, content-marking, logging and oversight patterns into the system rather than bolting them on. Tell us the use case and we will tell you what applies.