EU AI Act compliance for automation you already run

The Act asks what you are before it asks what your system does

Two words carry most of the weight here, and neither of them is "high-risk". A provider builds an AI system, or has one built, and puts it on the market under its own name. A deployer uses one under its own authority in the course of business. Almost every obligation is addressed to one or the other, so the first question is not what your system does. It is which of the two you are for each system you run.

Most companies that automate anything are both at once. Deployer of the assistant baked into your CRM, because someone else built and shipped it. Provider of the support bot your team assembled on a model API and put a logo on. Same company, same afternoon, two different sets of duties.

That boundary also moves without anyone deciding to move it. Under Article 25, a deployer becomes the provider of a high-risk system if it puts its own name or trademark on a system already on the market, modifies it substantially, or changes the intended purpose so that a system that was not high-risk, including a general-purpose one, becomes high-risk. The original provider then has to cooperate and hand over what you need, but the compliance file is yours.

This is worth an hour with a spreadsheet before it is worth an hour with a lawyer. List every AI system in production, name the vendor, name whose brand sits on the output, and mark whether you changed what the system is for. The same inventory habit that decides how much checking a process actually needs also tells you which of the two roles you are in.

The EU AI Act compliance calendar, as of July 2026

This is the one section that dates, and it dates fast. Every line below was checked against the Act's own text and against law-firm analysis on 24 July 2026, so open the linked sources and read the current position before you act on any of it. This is engineering guidance from people who build these systems, current as of that date, and it is not legal advice.

The legal status first, because coverage gets it wrong in both directions. The Digital Omnibus on AI, the package that pushes the high-risk deadlines back, is adopted but not yet in force. The European Parliament approved it on 16 June 2026, the Council gave final adoption on 29 June and the act was signed on 8 July, and it is waiting on publication in the Official Journal, entering into force on the third day after that. Until then, as the note on the Council adoption puts it, the AI Act's text in force and its original application calendar continue to apply.

So the deferral is agreed and signed, and it is still not law. Gibson Dunn make the same point: the new dates bind only once the Omnibus reaches the Official Journal, which is expected before 2 August. Plan on the deferral holding, keep whatever high-risk groundwork you have already done, and remember that no obligation got lighter. Only the date it attaches to moved.

Article 50, the transparency chapter, did not move at all. That is the part a company running ordinary automation is most exposed to, and the part almost nobody prepared for, because a year of attention went to high-risk classification instead.

On fines, since that is usually the next question. Article 99 caps penalties for the banned practices at 35 million euro or 7% of worldwide annual turnover, whichever is higher, and for the rest, transparency included, at 15 million euro or 3%. For SMEs the fine is capped at whichever of the amount or the percentage is lower. Those are ceilings rather than tariffs, and in several member states the authority that would impose them is still being stood up.

The deferral also bought time rather than exemption. Recruitment, credit scoring, education and worker monitoring stay on the Annex III list; they just report at the end of 2027 instead of next week. If you started that work, finish it slowly rather than shelving it, because this deadline moved with a full legislative procedure behind it and is unlikely to move twice.

What this looks like in a system already in production

Strip the article numbers off and the near-term obligations land on an ordinary automation stack as a handful of edits, none of which is a project. Do the cheap ones first. They are also the ones a customer notices first.

One is a line of text. If a person can end up talking to your system, they have to know it is a system, and they have to know at or before the first exchange rather than three clicks into a policy page. That quietly kills a pattern a lot of teams shipped: a bot with a human first name, a stock-photo avatar, and nothing anywhere saying that Marta is a language model. The exemption for cases that would be obvious to a reasonably well-informed person is a poor place to stand if you spent design effort making the bot feel human.

The marker on generated content costs more, because it belongs where the content is produced rather than where it is published. Our content pipeline for OnlyFarms is the shape of the problem: gaming terms go in as a CSV, two sequential model calls produce the HTML body and the SEO metadata, links are validated over HTTP, and the whole payload is POSTed to an admin API without a person reading a line of it. There is one honest place for provenance in a pipeline like that, and it is the payload itself, next to the seo object and the validated content. If generation and publishing live in different services, decide now which one owns the marker, because "both" reliably produces some content marked twice and some marked never.

Then there is something Article 50 does not ask for at all: knowing where each claim came from. On a 500,000-record knowledge base we validate every numerical claim against its source chunk before the answer ships, and a claim with no retrievable source gets flagged as unverified instead of smoothed into confident prose. Nothing obliges a general business assistant to do that today. It is still cheap insurance, because the traceability duties that arrive with high-risk classification are largely a formalisation of it, and adding provenance to a system that never had it is a rewrite rather than a patch.

Last is the line between reading and writing. An agent that reads your CRM and an agent that writes to it are different objects in every sense that matters here, which is why the permission boundary is worth designing rather than inheriting from whatever API key was lying around. Read access mostly raises a data-protection question. Write access raises an accountability one, and that is where the next section starts.

Human oversight is an engineering decision before it is a legal one

The human-oversight requirement sits in the high-risk chapter, so it is one of the things that just slid to the end of 2027. That is a bad reason to postpone it and a worse reason to build it. Teams that add an approval gate because a regulation told them to end up with a gate that satisfies an auditor and annoys everyone who uses it. Teams that costed a wrong action end up with a gate in the right place.

The race engineer we built for live iRacing sessions draws that line hard, for reasons that had nothing to do with Brussels. The agent reads telemetry from 64 cars through 19 MCP tools and answers the driver in under two seconds, entirely on its own. Then it reaches pit commands and stops. Reading is autonomous, acting is not: the agent can recommend and prepare a stop, and the driver confirms before anything reaches the car, because a wrong pit call is unrecoverable in a way a wrong lap-time estimate is not.

The AI assistant for the rector's office at Miras University applies the same split in a much slower domain. It drafts task assignments across departments, chases what is overdue, and answers analytical questions about students and staff, but a person confirms the assignments and decisions, and every action is logged so there is a trail of who approved what. A second rule in that system is worth stealing: it may not answer a statistical question from memory. Numbers come out of the university's records at the moment of the question or they do not get stated.

Both predate anyone requiring them, which is the point. Gate on the effect of the action rather than on the model's confidence, and write the approval down. When the high-risk obligations land, what the file asks for is a record of who oversaw what, and a log you have kept for two years beats a policy written in a hurry the month before.

Being outside the EU does not put you outside the scope

US, UK and other non-EU teams tend to discover this late, usually through a customer's procurement questionnaire rather than a regulator. Article 2 sets the reach in three pieces: providers who put an AI system on the Union market, wherever they are established; deployers established in the Union; and providers or deployers in a third country where the output produced by the system is used in the Union.

That last one is what surprises people. It has nothing to do with where your servers sit or whether you have an EU entity. If your system produces output and that output gets used in the Union, the Act has an opinion about it. A US analytics product whose summaries land on a screen in Berlin is inside the perimeter by that route alone.

The exclusions are narrower than they look. Purely personal, non-professional use is out, and so are systems built and put into service solely for scientific research. Free and open-source licensing helps, but not with the obligations that bind soonest, because the carve-out drops away for high-risk systems, for the prohibited practices and for the transparency duties. Shipping your model under Apache 2.0 does not exempt the chatbot on your own website.

In practice the near-term exposure for a non-EU company is almost entirely transparency, and transparency is cheap. The mistake we keep seeing is treating it as a geo-gating problem: detect EU visitors, show them a different disclosure, leave everyone else alone. That is more code and more ways to be wrong than simply disclosing to everybody. One universal "you are chatting with an AI assistant" line and one universal marker on generated output cost a single implementation and cannot be defeated by a VPN or a misconfigured CDN header.

A checklist you can run this week

None of this needs a consultant and most of it needs an afternoon. Run it in this order, because each step narrows the next.

Write the inventory. One row per AI system in production, including the ones that arrived as a feature inside software you already bought. Per row: the vendor, whether your brand sits on the output, and whether you changed what the system is for. That last column decides whether you are a deployer or, under Article 25, quietly the provider.

Walk your own product as a stranger. Open every surface where a person can end up in a conversation: the website widget, the in-app helper, the WhatsApp number, the email autoresponder that got clever last year. Anywhere someone could reasonably think they are talking to a colleague, add the line. One string, one deploy.

Trace one piece of generated content end to end. Follow it from the model call to the published page and note every service it passes through. Pick the earliest point that can attach a marker without something downstream stripping it, and make that service the owner. If no such point exists, you have found the actual work item.

List every write action your agents can take. Emails sent, records updated, invoices issued, tickets closed, refunds approved. Beside each, write what the worst wrong version costs and how long it takes to undo. Anything expensive and hard to reverse gets a confirmation step, everything else runs free. Same triage as the pit-command gate, applied to a business instead of a race car.

Check that you can answer "who approved this" for last Tuesday. Not in principle, on the actual data. If the answer means reconstructing it from three systems, fix the log first. It is a smaller job than it sounds.

Read the Article 5 list against your roadmap, not just your codebase. The trap in ordinary companies is workplace tooling: emotion or sentiment inference on employees is prohibited outright rather than risk-managed, and it tends to arrive as a bullet point in a vendor demo.

Put a date in the calendar to re-check. The Omnibus has to appear in the Official Journal before the new dates bind, so verify the status yourself rather than trusting a snapshot taken in July. If a second pair of eyes on the read/write split or the gate placement would help, that is what our free audit is for, but the list above is yours to run without us.

FAQ