EU AI Act compliance, for companies that deploy AI

Everything below unpacks these six statements. If you only remember six things, make them these.

The Act does not regulate artificial intelligence as a substance. It regulates uses, sorted by how much damage a failure could do to a person’s rights, safety or livelihood. A short list of practices is prohibited outright, social scoring and manipulative techniques among them. A defined set of uses is high-risk and carries the heavy machinery of the regulation. A middle band carries transparency duties, telling people they are dealing with a machine. Everything else is minimal risk and carries almost nothing.

General-purpose models, the large models systems like ours call as a service, sit on a separate axis with their own obligations for the companies that train and provide them. That axis is mostly the provider’s problem, not yours, but it matters when you buy, because the documentation your integrator receives from the model provider feeds the file you may one day show an authority.

Here is the honest orientation most guides bury. An internal assistant that answers questions about documentation, a chatbot that books appointments or an agent that reads invoices lands, in most configurations, in the limited or minimal band. The heavy regime is triggered by domain, not by sophistication. The moment AI touches hiring, credit, education, essential services, biometrics or the other domains in the Act’s Annex III, the same underlying technology becomes high-risk with everything that follows. Which band your concrete use falls into is the first question for your lawyers, and the next sections give you the vocabulary for that conversation.

The large models that systems like ours call as a service live under their own chapter, in force since August 2025 for the companies that provide them. Providers of general-purpose models owe technical documentation, information to the companies building on top, a copyright policy and a summary of the content used for training, and the handful of models classed as systemic risk owe more on top of that.

Little of it is your duty as a deployer, and all of it is your business as a buyer. The documentation a model provider publishes flows downhill into your compliance file, because the description of your system leans on the description of the model underneath. When we assemble the file for a client, the model provider’s terms and documentation go in it, which is one more reason the choice of provider is approved by you rather than defaulted by us.

The practical ask is short. Whoever sells you anything built on a large model should be able to name the model, point at its provider’s AI Act documentation and show what of your data reaches it. If any of those three draws a blank, the gap is yours to carry.

The Act entered into force in August 2024 and has been switching on in stages. Every date below is in the past, which is worth letting sink in, because a surprising number of companies still file the whole subject under "future".

The penalty structure is tiered like the GDPR’s. Prohibited practices reach 35 million euros or 7 percent of worldwide turnover, whichever is higher. Most other breaches, deployer duties included, reach 15 million or 3 percent. Supplying misleading information to authorities has its own lower tier. Which bracket a concrete failure lands in is a legal question, and the honest answer to "how likely is an inspection" is that nobody selling you certainty deserves your trust.

What can be said with evidence is who is watching. Each member state names its market surveillance authority, and ours is a useful preview of what these authorities look like, because it moved first. AESIA, the Spanish agency created by Royal Decree 729/2023, was the first dedicated national AI supervisor in Europe, has held full sanctioning powers since August 2025 and published sixteen compliance guides within months of the regulation biting. Its declared line through 2026 has been warnings before sanctions, and it has already opened preliminary investigations into systems deployed by Spanish organisations. The window in which nobody was looking is closing, on schedule and without drama.

The practical consequence for a buyer is timing. Building demonstrability into a system while it is being built costs little, and we know because it is how we work anyway. Retrofitting it under an authority’s deadline is the expensive version of the same project.

Committees lose real time here, so settle it early. The Act defines an AI system through seven elements, and the one that carries the weight is inference: a machine-based system, operating with some autonomy, that infers from its input how to generate outputs like predictions, recommendations or decisions. The European Commission published guidelines on this exact definition in February 2025, precisely because every company asked the same question.

The practical reading is narrower than the panic. A calculator, a fixed spreadsheet formula or a rules engine that applies the same written logic every time does not infer, and generally falls outside. A system that learns patterns, ranks candidates, scores risk or generates text does infer, and is in. The borderline cases exist, they belong to counsel, and the reasoning is worth writing down either way.

For anything built on a language model the question answers itself, models infer, that is their entire job. So we never spend a client’s money arguing that an agent is not AI. We spend it building the agent so that the duties that follow are already met.

Two roles carry almost all of the weight. A provider develops an AI system, or has one developed, and places it on the market under its own name. A deployer uses an AI system professionally, under its own authority, for its own purposes. The provider owes the design-side duties, conformity, documentation and registration where it applies. The deployer owes the use-side duties, and they are the subject of this guide.

A bank that buys a credit-scoring system from a vendor is a deployer, with duties about oversight, monitoring and logs. The vendor is the provider, with duties about how the system was built and documented. The same split repeats down the market: the clinic using an appointment assistant, the manufacturer using a diagnostic aid and the accounting firm running document extraction are deployers of those systems, whoever built them.

When we build a custom agent for a client, the question of who counts as provider of that specific system is exactly the kind of boundary a contract should fix in writing rather than leave to assumption. We flag it in the first conversation, our lawyers and yours settle the wording, and the engineering side of the answer, who documents what, who keeps which records, is designed in rather than argued about later.

The roles are not permanent labels. The Act moves a deployer into the provider seat when it puts its own name or trademark on a high-risk system, when it substantially modifies one, or when it changes a system’s intended purpose into high-risk territory. The third one is the quiet trap, because intended purpose sounds like marketing language and is actually the concept the whole regulation rests on.

Concretely. A company that licenses a general document assistant and turns it into a tool that screens job applications has changed the purpose into an Annex III domain, and with it, possibly, its own role. A company that rebadges a vendor’s system as its own product has walked into provider duties by branding. None of this outlaws customisation, it prices it, and the price is documentation and duties that someone must consciously accept.

Whether any specific modification is "substantial" is a legal judgment. Our contribution is narrower and earlier. Systems built with a written intended purpose, a record of what changed and logs of what the system actually does give your lawyers the raw material to make that judgment cheaply. Systems assembled informally give them nothing to work with, and a careful lawyer with nothing to work from will always give you the expensive answer.

High-risk by domain means the Act lists where the stakes are high enough for the heavy regime. Annex III names eight areas. If your use of AI touches one of them, assume high-risk until your lawyers conclude otherwise.

Article 6(3) opens a narrow exit. A system that lands in an Annex III domain may still avoid high-risk status when it only performs a narrow procedural task, improves the result of a human activity that is already complete, or detects patterns without replacing human judgment. A tool that formats interview notes touches employment and plainly is not deciding anyone’s career.

Two conditions guard the exit. The exemption must be documented, a written assessment of why the system qualifies, produced before you rely on it rather than after someone asks. And profiling slams the door shut. A system in an Annex III domain that profiles people, in the GDPR sense of evaluating aspects of their life like performance, reliability or economic situation, is always high-risk, whatever else it does.

Our advice as builders is unglamorous. Decide which side of this line a system is meant to live on before it is built, write that intention down and design the data flows so the system cannot quietly drift across. Drift is the real risk here, a helpful tool that gains one feature per quarter until it is doing the thing nobody classified.

If a system you deploy is high-risk, Article 26 is your list. In plain terms, duty by duty, this is what it asks.

Article 27 adds one more duty for a defined group. Deployers that are public bodies, private companies providing public services, and deployers using high-risk systems for credit scoring or for risk and pricing in life and health insurance must run a fundamental rights impact assessment before first use. It is what it sounds like, a structured look at which rights the system could touch, who is exposed, and what happens when it goes wrong.

The Act allows leaning on work already done. A deployer may rely on an assessment the provider carried out, or on an existing impact assessment that covers the ground, which in practice means the exercise overlaps heavily with the DPIA your data protection officer already knows how to run. Same discipline, wider lens.

Our role in it stays the same as everywhere else on this page. The assessment is yours to run and sign. The description of the system it needs, what it does, what enters it, who oversees it and what gets recorded, is the file our systems produce as a side effect of being built.

Article 4 is the obligation companies keep missing because it looks soft. Since February 2025, providers and deployers must ensure a sufficient level of AI literacy in the people who operate and use AI systems on their behalf, proportional to their role and the context. It applies to every AI system, high-risk or not, which makes it the one duty in the Act that almost certainly applies to you today.

Sufficient is not defined as a certificate, and the point is not sending everyone to a course. The person approving model outputs should understand what a model can and cannot be trusted with. The person operating an assistant should know what it must never be fed. The person overseeing a high-risk system needs enough depth to justify overriding it. Training that maps to roles, written down, with dates, is both the legal expectation and the cheapest risk reduction on this entire page.

It is also, quietly, a procurement question. Ask any vendor what material they hand your team for this, because a supplier whose answer is a shrug is planning for your people to misuse their system.

The transparency duties in Article 50 apply since August 2026 and they are refreshingly concrete. People interacting with an AI system must be informed they are doing so, unless it is obvious from context. Synthetic audio, image and video content must be marked as artificially generated. Deployers of emotion recognition or biometric categorisation must inform the people exposed to them.

For the systems most companies actually run, this reduces to honest interface design. The assistant introduces itself as an assistant, the generated report says it was generated and the escalation path to a human is real. We covered how our own conversational systems present themselves and hand urgent cases to staff on the sovereignty page, and the same design serves this article without modification. By now the pattern is clear. These duties are cheap to meet when they are designed in and embarrassing to meet after the fact.

Read the duty list again with an engineer’s eye and it breaks down into three properties of the system. Things the system must produce about itself, logs and records. Things a human must be able to do to it, inspect, intervene and override. And things it must never silently change, its purpose and its inputs. None of the three can be added convincingly after the fact, all three are cheap when they are design decisions.

This is where our practice happens to line up with the regulation, not because we built for the Act but because production forced the same conclusions earlier. Our systems write down each decision as it happens, in a record that can be added to but never edited, and the system itself never reads that record back, so it documents behavior without influencing it. Oversight is not a name in a file. The people behind our assistants get real queues with real trails, and every action a system takes on someone’s behalf runs under that person’s own permissions, so the question "who could have done this" always has an answer your identity system already knew.

Monitoring, the duty that sounds vaguest, is the one we can show most concretely. Before any change ships, a battery of real annotated cases must pass, and one of our systems carries 118 of them. After shipping, a weekly probe runs a real conversation against the live system end to end. Two separate checks, kept apart on purpose, and together they are precisely the "monitor the operation of the system" evidence Article 26 asks a deployer to have.

When a system we built enters your compliance review, these artefacts exist because the build produced them, not because someone reconstructed them for the meeting.

None of this requires a consultant to start. A competent internal owner with a spreadsheet gets a company from "no idea" to "mapped, with open questions for counsel" in days, and the open questions come out sharp instead of vague.

The AI Act and the GDPR ask different questions about the same system. One regulates the use by risk, the other the personal data inside, and a system that answers both well tends to be one system, built once, with records, oversight and restraint designed in rather than promised. That architecture is what our sovereignty page describes mechanism by mechanism, and it is the standard everything we build inherits, whether or not a given system ever goes near Annex III.

If you are deciding whether to build something under these rules, the same honesty applies to budgets, and we publish ours. And if what you need first is the map of duties turned into a working system, that is the actual job description of an AI agent development company operating in Europe in 2026.