What the EU AI Act Actually Asks You to Record About AI-Written Code

Your team shipped a feature two weeks ago that an AI agent wrote most of. Nobody wrote down which parts, which model produced them, or who reviewed them, and now someone is asking for that record: a customer's security questionnaire, a SOC 2 auditor, or a compliance lead who read a headline about the EU AI Act. This post is not legal advice. It answers one narrower question: what should a developer actually write down about an AI-written change, where should that record live, and how much of this the law actually requires today.

What actually changed on 2 August 2026

Most of what circulated online before 2 August 2026 said the same thing: high-risk obligations under the AI Act become enforceable that day. That was true when it was written, and it stopped being true on 27 July 2026, when the Digital Omnibus on AI entered into force and moved the compliance deadline for stand-alone high-risk systems under Annex III from 2 August 2026 to 2 December 2027, a sixteen-month extension the Council finalized in June. High-risk systems embedded in regulated products under Annex I got the same treatment, moving from August 2027 to August 2028.

One date did not move. Article 50's transparency rules, covering chatbots, deepfakes, and AI-generated content aimed at the public, still took effect on 2 August 2026 on schedule. Article 6, which decides which systems count as high-risk, moved along with the obligations it triggers: its Annex III branch now applies 2 December 2027 and its Annex I branch 2 August 2028, the same dates as the deadlines above. General-purpose AI model obligations have applied since 2 August 2025 and were never part of this extension.

A post from before July that said "the deadline is 2 August 2026" was accurate then and is stale now. The deadline that touches most software is 2 December 2027.

Who this actually applies to, and who it does not

Article 12's logging duties and Article 11's documentation duties attach to the AI system being placed on the market, not to the tools a team used to build it. Annex III lists eight categories: biometric identification, critical infrastructure, education and vocational training, employment and worker management, essential services such as credit and benefits eligibility, law enforcement, migration and border control, and the administration of justice and democratic processes. If you are not building something that decides who gets hired, who gets a loan, who gets flagged at a border, or who gets convicted, none of Article 12's operational logging requirements apply to you, on 2 December 2027 or any other date.

Using Claude Code, Codex, or Gemini CLI to write code does not, by itself, make your software a high-risk AI system. Article 6 treats a coding assistant used for convenience or automation as outside the safety-component definition that would apply if it were, say, controlling a medical device. The Act regulates the product you ship, not your development process, unless that product is itself one of the eight listed categories, or a safety component of one. For most SaaS teams and internal tools, that is the end of the legal analysis.

For teams building anything in those eight categories, the deadline moved sixteen months out, real breathing room, not permission to skip the paperwork forever: Annex IV's technical documentation still has to describe "the methods and steps performed for the development of the AI system, including, where relevant, recourse to pre-trained systems or tools provided by third parties," and "how those were used, integrated or modified by the provider," broad enough to cover an AI coding agent once the clock runs out.

The gap: 43% can't tell AI code from human code in their own repos

Even the minority building an Annex III system have a more immediate problem: most companies cannot currently produce the record the Act, or their customers, would ask for. GitLab's AI Accountability Report, a Harris Poll survey of 1,528 developers and technology buyers across six countries published 23 June 2026, found that difficulty distinguishing AI-generated code from human-written code was the single biggest barrier to control, cited by 43% of respondents, ahead of fragmented toolchains (40%) and systems that don't track code origin at all (39%). The same report found 78% say developers are committing code faster since adopting AI tools, and 91% run two or more AI coding tools at once. Velocity went up before visibility did, and that gap is why this conversation has anything left to say.

Why git blame is the wrong instrument for this

Git blame answers one question: who made the last commit that touched this line, and when. It says nothing about whether that commit was typed by a person or produced by an agent, what model generated it, or whether anyone reviewed it before it merged. The closest convention git offers is the Co-authored-by trailer, which an agent can append to a commit message and which GitHub recognizes and displays, provided the co-author's email is linked to a GitHub account. That convention has three gaps: it is optional, so nothing enforces that anyone adds it; it carries no model name, task reference, or review status, only a name and an email; and, being plain text inside a commit message, it is exactly as durable as that commit, so a squash merge collapsing ten commits into one keeps whatever text someone chose to keep, not everything sitting in the trailers underneath.

None of that makes git blame useless. It is still the right tool for "who touched this line last." It is the wrong instrument for "was this line written by a person or an agent, under what model, reviewed by whom," a different question that Article 12's logging purposes, identifying risk situations, post-market monitoring, and operation monitoring, implicitly assume a system already answers somewhere.

The minimum record for one AI-written change: six fields

Strip the legal language and Annex IV's requirement to document "the methods and steps performed for the development of the AI system" reduces to something a developer can produce per change, not per project. Six fields cover it:

None of these need new infrastructure. A source, a model name, and a timestamp are things an agent already knows about itself; a task reference and a reviewer are fields a pull request or tracker already has. The discipline is making sure all six land in the same place, not scattered across a commit message, a chat thread, and someone's memory.

Line-level attribution: git-ai, AgentBlame, and git notes

Two open-source tools now automate the line-level version of this record by writing to git notes, a native git feature that attaches supplementary data to a commit without altering the commit itself. git-ai captures attribution the moment an agent calls git-ai checkpoint, then stores it in git notes on commit, viewable with git log --show-notes="ai" or a dedicated git ai blame command. It moves those attributions forward through rebase, squash, reset, stash, and cherry-pick, the durability the Co-authored-by trailer lacks, and stores prompt text outside the repository, scanned and redacted.

git log --show-notes="ai"
git ai blame src/billing.ts

AgentBlame takes a narrower approach: it hooks into Cursor, Claude Code, and OpenCode at the moment each edits a file, then stores content hashes, the provider, the model, and a confidence score per line before writing the result to git notes on commit. Its output surfaces as gutter markers in a diff and an AI-percentage badge on a pull request, and its documentation, published January 2026, describes it as squash-safe.

Both tools solve the durability problem git's own conventions don't. Neither tells you whether the change was reviewed, which is where a reviewer field earns its place in the six above.

Task-level attribution, and why it is easier to keep honest

Line-level attribution answers "who wrote this line." Task-level attribution answers a coarser but often more useful question: who did this piece of work, and who signed off on it. It can't tell you that line 47 of a 300-line file was the one human edit inside an otherwise AI-generated change, but it's harder to let slip, since it doesn't depend on every commit carrying the right trailer or every editor firing the right hook. It depends on the tracker the team is already looking at.

Trail, a hosted issue tracker an AI coding agent writes to directly over MCP, records exactly this at the card level: every change to a card carries whether a human or an agent made it, with the full history, a feature it has shipped since 5 August 2026. That doesn't replace a line-level tool for per-line proof inside one file, and it doesn't fit a team whose hard requirement is that every record stay inside the repo rather than a hosted database, a tradeoff worth weighing against a local-first tracker's own limits. What it does mean is that the task reference, source, and reviewer fields above exist as a byproduct of work already being tracked, not a separate logging step.

What an auditor will actually ask to see

Whether the auditor works for a notified body checking Annex IV compliance or a SOC 2 firm checking change management, the questions converge: who made this change, was it reviewed by someone qualified to review it, was that review documented before the change shipped, and can you produce that trail for a sample the auditor picks, not one you picked. GitLab's report is blunt about the mechanics: with 91% of teams running two or more AI coding tools at once and 40% citing fragmented toolchains as a barrier, the honest answer is often scattered across systems that don't talk to each other. An auditor doesn't care which tool holds the record. They care that a record exists, that it wasn't edited after the fact, and that it names a specific human who looked at the change before it merged.

The SOC 2 code review control nobody is testing yet

Long before the AI Act's postponed deadline, SOC 2 audits were already running a control aimed at this exact gap. Trust Services Criteria CC8.1, the change management criterion, is what an auditor checks when asking whether material changes were properly tested and approved before shipping, typically evidenced by a pull request with an independent reviewer and a branch protection rule blocking a direct push to production. The control assumes the person who typed the code and the person who reviewed it were both making a human judgment call, an assumption most current audit evidence quietly rests on.

AI-generated code doesn't break CC8.1's letter. A pull request still gets opened, a reviewer still clicks approve. It breaks the assumption underneath: that a careless human, not a fluent one, was the failure mode worth catching. Veracode's GenAI Code Security Report tested output from over 100 large language models across Java, Python, C#, and JavaScript and found 45% of samples introduced an OWASP Top 10 vulnerability, with Java failing 72% of the time, and scaling up the model doesn't reduce that rate. A reviewer approving a pull request without knowing which lines were AI-generated applies exactly the scrutiny CC8.1 has always required and no more, against code with a different failure profile than the control was calibrated for. Nobody's SOC 2 report currently asks whether the reviewer knew a change was AI-generated; given how directly that follows from what CC8.1 already tests, it reads like the next line item, not a hypothetical one.

Starting the record today without re-litigating last year

None of this requires reconstructing history. A record starting today and covering every change forward is worth more than a perfect record you never start because last quarter's commits don't have one. Pick one place for the six fields to live, git notes via git-ai or AgentBlame, a tracker card, or both, and apply it going forward. Providers of in-scope systems must keep their own automatically generated logs for at least six months under Article 19; that floor is worth borrowing for a development record too. Retroactively tagging old commits with a model name nobody wrote down at the time produces guesses dressed up as records, worse than an honest gap with a clear start date.

The one thing worth doing retroactively is deciding whether anything you've shipped falls inside Annex III's eight categories, since that determines whether December 2027 is a real deadline for you. That question doesn't get easier by ignoring it. The same instinct that makes a team write down why an exception was made, not just who made it, so the same mistake doesn't repeat next session, is what makes a compliance record worth keeping: the reasoning is often the part an auditor actually wants, not just a name and a timestamp.

A short checklist you can run this week

Where you land depends on what you're building, not on how nervous the news cycle about the AI Act has made you. If nothing you ship falls into Annex III's eight categories, the Act imposes nothing on your code today, and won't in December 2027 either; keep reading only because your customers' SOC 2 requirements are arriving faster than the law is. If you are building something in scope, the 43% who cannot currently separate AI from human code is the number that should worry you more than the regulation, since the deadline moved but the underlying gap did not. And if you sell into an enterprise that requires a SOC 2 report, CC8.1 already expects the review your team gives AI-written code, whether or not anyone has said "AI Act" out loud yet.

Run this checklist this week:

1. Pick where the six fields live: git notes, a tracker, or both, and write down that decision.
2. Turn on Co-authored-by trailers or a line-level tool like git-ai or AgentBlame going forward, without touching history that already shipped.
3. Confirm whether anything you're building falls into Annex III's eight categories, and if it does, put 2 December 2027 on a calendar, not a hope.
4. Ask whoever runs your SOC 2 audit whether CC8.1's evidence sample distinguishes AI-generated changes from human ones, and note the answer.
5. Revisit the record in three months; a six-field habit nobody checks drifts back into a commit message nobody reads.

If the harder problem is that your team runs several client codebases at once and none share what the last one learned, that's a different gap than this post covers, closer to context bleeding across repos than record-keeping. And if you're still choosing which tracker should hold any of this, the fuller comparison of trackers built for AI coding agents covers authorship, memory, and who else gets to see the board, not just this one compliance question.