AI Writes 61% of Your Codebase. Your Git History Says a Human Did.

AI code attribution is the record of which AI tool produced which code, who requested it, and whether a human reviewed it before deployment. Git history does not capture any of that. The record has to be written at the moment of the interaction, because detectors applied to committed code can estimate origin but cannot recover the prompt, the model version, or the review status.

A vulnerability is confirmed in a payment module. The commit is eight months old. The engineer who pushed it left the company in March. Legal asks a simple question: was this code written by a person, generated by an AI assistant, or produced by an agent running in CI? And if it was AI, was it reviewed before it shipped?

Git blame gives you a name, a timestamp, and a diff. It does not give you any of the three answers. That gap is now sitting inside most engineering organisations, and it has stopped being a philosophical question about authorship. It shows up in incident scope, in vendor security questionnaires, and in regulatory files.

CloudBees' 2026 State of Code Abundance report, published in May 2026 and based on independent research with more than 200 enterprise technology leaders, found that AI generates or assists in writing 61% of the average enterprise codebase, while most organisations still lack the visibility, governance, and attribution needed to manage code produced at that volume. The same research found 81% of those leaders reporting an increase in production issues tied to AI-generated code.

The interesting part is not the percentage. It is the mismatch. Every control that engineering teams rely on for accountability was designed around an assumption that a human typed the code and another human reviewed it. Code ownership files, blame history, approval records, and post-incident interviews all inherit that assumption. When AI is involved in most of the code that ships, those controls keep producing answers. The answers are just no longer complete.

During an incident, missing logs force you to assume the worst. Mandiant's M-Trends 2026 report, built on more than 500,000 hours of incident response work in 2025, put global median dwell time at 14 days, up from 11 the year before. If you cannot prove the scope of an intrusion because of logging gaps, you end up assuming and disclosing a worst-case data theft, and you carry the trust cost that comes with it. Substitute "AI activity" for "intrusion" and the logic is identical: scope you cannot narrow is scope you have to disclose.

During procurement and audits, estimates are not evidence. Vendor security questionnaires now routinely ask how AI is used in software development, what data is exposed to models, and what human oversight exists. SOC 2 and ISO 27001 auditors ask the same in different words, and ISO/IEC 42001 makes documented operational records of AI use an explicit expectation. A policy without a corresponding log now reads as an uncontrolled process rather than a governed one.

Under the AI Act, logging is the obligation that did not move. The EU AI Act became generally applicable on 2 August 2026. Six days earlier, the Digital Omnibus on AI (Regulation (EU) 2026/1744) entered into force and deferred the high-risk obligations for stand-alone Annex III systems to 2 December 2027. The deadline moved, as we covered in our breakdown of what the AI Act changes actually require. The substance did not: Article 12 still requires high-risk systems to technically allow automatic recording of events over their lifetime, and Articles 19 and 26(6) still require providers and deployers to keep those logs for at least six months, longer where other law says so.

The obvious shortcut is to scan the repository with a classifier that guesses which code looks AI-generated. Statistical detectors evaluate committed code and infer origin from style. They produce a probability, not a record. They cannot tell you which model version produced a function, what the prompt asked for, whether a human modified the output afterwards, or whether anyone reviewed it before merge. And they degrade exactly where accuracy matters most: on short functions, on heavily edited output, and on code that a developer rewrote by hand after the suggestion.

The event you need to record is the interaction, not the artefact. Once the interaction has happened and nobody captured it, that record does not exist anywhere. Reconstruction after the fact is estimation with a confidence score attached.

Teams that get this right capture five things at the moment of use, not afterwards:

You do not need a governance programme to begin. You need one week of honest inventory: map the surface (list every AI tool with access to code or production systems), pick the systems that carry real risk (customer data, payments, authentication, infrastructure changes go first), define the retention window before you build (ask legal and compliance what they will need to produce and for how long), and decide who owns the policy side — attribution records are one half of AI governance, and the other half is the classification and oversight work that sits in an AI governance programme.

The organisations that will handle 2027 comfortably are not the ones with the strictest AI policy. They are the ones that can answer "which model produced this, who asked for it, and who approved it" with a query instead of a meeting.