The AI Act arrived in August. Most teams noticed nothing.

EU AI Act enforcement began on 2 August 2026. Transparency obligations took effect, active enforcement powers arrived, and in most engineering organisations the day passed without incident.

That absence is being read two ways, and both readings are wrong. One camp concluded the thing was overhyped. The other concluded they must already be compliant, since nothing broke. What actually happened is that the obligations land on classification, logging and traceability, none of which change what a developer does on a Tuesday, and all of which are answered by artifacts most teams cannot produce on request.

Why nothing happened on the day

Regulation of this shape does not work like a deploy. There is no switch that fails a build.

The obligations attach to whether your system falls into a regulated category, whether you can produce documentation when asked, and whether your logs would satisfy someone examining them. None of that surfaces during ordinary development. It surfaces when somebody asks, and the asking is the enforcement.

So the correct question is not “did anything break.” It is “if a regulator asked next month, what could we hand over, and how long would assembling it take.” For most teams the honest answers are: less than we would like, and weeks.

The three things that actually bind

Classification. High risk is a category with criteria, not an adjective. Most software that writes code is not itself a high-risk AI system under the Act, and the sloppy version of this conversation treats every use of AI as though it were. Getting your classification right, in writing, with reasoning, is the first piece of work, and it is a legal exercise rather than an engineering one.

Article 12 logging. Automatic logging of events relevant to identifying risk and ensuring traceability. Logs must be tamper-evident, retained for at least six months, and twenty-four for biometric and law-enforcement uses.

Transparency. Certain systems must disclose that they are AI, and machine-generated or altered content must carry machine-readable marks.

The second is where engineering has real work, and it is worth being precise about the word that does the damage.

Tamper-evident is stronger than teams register

Most pipelines produce logs. Far fewer produce logs that would survive somebody asking whether they could have been altered.

The usual arrangement is that the system performing an action writes the record of having performed it, into storage the same system can write to, in a format with no integrity chaining. That is a component attesting to its own behaviour. For debugging it is entirely fine. As a control it is the exact circularity that controls exist to prevent.

Logs most pipelines produce

• Written by the acting component
• Into storage that component can modify
• No chaining, so deletion is silent
• Retention set by cost, not by rule
• Prove intent, not occurrence

What tamper-evident implies

• Recorded at a boundary, not by the actor
• Append-only, not writable after the fact
• Chained, so removal is detectable
• Retention set deliberately, 6 or 24 months
• Evidence an event happened

The gap nobody has closed

Here is the item on this subject I find most striking, and it is barely discussed.

There is an established approach to provenance for generated images. Watermarking, content credentials, machine-readable marks on generated media: imperfect, contested, but real and standardised enough to point at.

There is no documented equivalent for generated code.

A function written by an agent, committed, reviewed and merged, carries no intrinsic mark distinguishing it from one a person wrote. The only record that it was generated at all is whatever your pipeline chose to keep, in whatever format you invented, for as long as you chose to keep it. There is no standard, no interchange format, and nothing an auditor can compare against.

For an industry where something like 41 percent of production code is now agent-generated, that is a substantial hole. And unlike most regulatory gaps, this one is not waiting on legislators. It is waiting on the industry to agree a format, which nobody is currently incentivised to do alone.

What to do this quarter

Get the classification written down, by someone qualified, with reasoning. It is cheap and it determines everything downstream.

Then find out what your pipeline can actually produce for a change from six months ago: what changed, on whose authority, against which stated criteria, verified how, approved by whom. Do it as an exercise, timed, on a real change. The elapsed time is your answer, and it is usually the first moment the problem becomes concrete for people who control budget.

Where this breaks down

I am not a lawyer and this is not advice. Classification in particular turns on specifics of your product and deployment that no article can assess. Get proper counsel; the cost of getting this wrong is not an engineering cost.

Most code-writing tools are not high-risk systems, and I may be overweighting all of this. For a large share of teams the Act’s direct obligations are genuinely light, and the honest answer for them is to document why and move on rather than build a compliance programme they do not need.

Tamper-evident logging has a real cost. Boundary-recorded, append-only, chained storage is more expensive and more operationally awkward than writing to a log file. For a team with no regulatory exposure that spend buys very little, and I would not pretend otherwise.

And a complete record can flatter a bad process. Comprehensive provenance makes weak controls legible; it does not make them strong. An organisation that can prove exactly how its unreviewed changes reached production has documented the problem, not solved it.

The takeaway

Nothing happening on 2 August is not evidence of compliance. The obligations attach to classification, traceability and disclosure, none of which announce themselves during development, and all of which are tested by someone asking.

Article 12 is the piece with engineering work in it, and “tamper-evident” is a stronger requirement than most pipelines meet, because the usual arrangement has the acting system writing its own record. Meanwhile the provenance gap for generated code remains open, with no standard and no obvious party motivated to close it.

If you take one thing into next week: pick a change from six months ago and time how long it takes to assemble what changed, why, on whose authority and what verified it. That number is the honest state of your readiness.