The Rules for Agent-Written Code in a Regulated Codebase Just Changed

Maciej Lewandowski · 25 July 2026 · Engineering notes

Standing note, 25 July 2026. The position as I read it today; the timeline moved twice last week, so treat the date as load-bearing. I am not a lawyer and this is not legal advice - it is an engineer's reading of public sources, and every claim links to its source. Where I could not reach the primary text, I say so in the sentence.

Two documents landed four days apart. On 20 July 2026 the Commission adopted its guidelines on the Article 50 transparency obligations. On 24 July 2026 an amending regulation - the Digital Omnibus on AI, Regulation (EU) 2026/1744 - was published in the Official Journal. Between them, most of what is written online about "the AI Act and developers, August 2026" describes a timeline that no longer exists - almost all of it predates June, when the amendment stopped being a proposal.

So, narrowly: what applies to code an agent wrote, inside a codebase a regulator can inspect? Not what people are looking at. The AI Act is mostly a distraction. The regulation that already governs your agent-written diff arrived in January 2025, is technology-neutral, and never mentions AI.

What did not happen on 2 August 2026

The high-risk regime did not start. Per the Commission's own regulatory-framework page, obligations for standalone high-risk systems under Annex III moved from 2 August 2026 to 2 December 2027, and AI embedded in Annex I products to 2 August 2028. I cite the timeline page rather than my own reading of the amended Article 113: the consolidated text on EUR-Lex was not machine readable.

What does start is narrow. First, the Article 50 transparency obligations - the guidelines state that Article 50 "will apply as from 2 August 2026" (paragraph 153). Second, Article 101, the Commission's power to fine providers of general-purpose AI models, which Article 113 expressly carved out of the August 2025 package. That second point is my reading of Article 113's construction, not something official.

And a coding agent is not a high-risk AI system. "A tool for writing software" appears nowhere in Annex III or Annex I. Annex III is a closed list of eight areas; in finance it reaches two things: creditworthiness assessment and credit scoring of natural persons (point 5(b), fraud detection expressly excluded), and risk assessment and pricing in life and health insurance (point 5(c)). That is the entire financial footprint. Annex I is product legislation - machinery, toys, lifts, medical devices - with no entry for development tooling. I quote Annex III as originally enacted, not having confirmed whether the amendment touched it.

The chain runs one way. Classification follows intended purpose, not the tool used to type the source: the scoring engine is high risk either way, and the agent that wrote it is not high risk by association.

binds the diff today DORA since 17 Jan 2025 CDR (EU) 2024/1774 AI Act, after the July 2026 Omnibus 2 Aug 2026 Art. 50 + Art. 101 2 Dec 2026 marking transition ends 2 Dec 2027 Annex III (was 2 Aug 2026) 2 Aug 2028 Annex I embedded the regime expected on 2 Aug 2026 moved by 16 months; DORA did not move

You do not have to label AI-written code

The most useful thing in the new guidelines, and unambiguous. On the scope of the Article 50(2) synthetic-content marking obligation, the Commission's guidelines of 20 July 2026, paragraph 68, put outside scope:

"Source code understood as content written in a programming, scripting, markup, query or configuration language that is intended to be interpreted, compiled or executed by a computing system, regardless of whether it is composed of text characters. This may also include natural-language comments and contextual information that form an integral part of the source code."

The same paragraph extends the exclusion to SDKs, SQL, infrastructure-as-code, YAML, JSON configuration, schemas, scripts, machine-readable specifications and APIs. The reasoning sits one paragraph earlier: Article 50(2) exists to let people tell AI-generated content apart, so content not intended to be interpreted or acted upon by a natural person is not what it is for. Note the limit - it covers code, not everything an assistant emits. Documentation written for humans does not inherit it.

If you have seen the claim that AI-generated text must be watermarked from August and concluded that generated code is in scope, that inference is now closed off. Where the claim lives: in developer discussion it is made about prose; the extension to code turns up mainly in vendor content. And the guidelines call themselves non-binding, though market surveillance authorities will work from them.

Two things do bite on 2 August. Article 50(1), disclosure that a person is interacting with an AI system, applies with no transition and binds the provider of the tool, not you. And for generative systems on the market before 2 August 2026, the guidelines describe a transitional period for Article 50(2) marking running to 2 December 2026. Again: a duty of whoever ships the model.

Now the part that actually binds you

Pivot. DORA has applied since 17 January 2025, without transposition. It is technology-neutral, which is precisely why it catches agent-written code without mentioning it: its requirements are built around the change and the system, never the author.

Article 9(4)(e) requires documented policies, procedures and controls for ICT change management ensuring changes are "recorded, tested, assessed, approved, implemented and verified in a controlled manner". The detail lives one level down, in Commission Delegated Regulation (EU) 2024/1774, the RTS on ICT risk management tools, applicable from the same date. A caveat: EUR-Lex would not render either text for me, so the phrases below come from article-by-article reproductions that agree with each other, and I would check them against the Official Journal before relying on them.

  • Article 16(3) requires source code reviews covering static and dynamic testing, security testing for internet-exposed systems, identified vulnerabilities, remediation plans and monitoring of their implementation. Paragraph (7) requires controls protecting source-code integrity, in-house or third-party alike. Paragraph (8) requires analysis and testing of proprietary software and, where feasible, open-source components, before production.
  • Article 17(1)(b) requires "mechanisms to ensure the independence of the functions that approve changes and the functions responsible for requesting and implementing those changes". That is the legal anchor of four eyes, across all changes to software, hardware, firmware, systems and security parameters.

None of it cares who typed the diff. No gap to fill, no exemption to claim.

what teams read about AI Act high-risk regime: December 2027 Art. 50 marks the model output, not your repository source code expressly excluded vs what actually governs the diff DORA + CDR (EU) 2024/1774 change management and testing controlled implementation and verification of changes never asks who typed it

The four-eyes problem, stated properly

This is where it gets interesting, and where I suspect most teams are quietly non-compliant. An agent produced the diff. One engineer approved it. Which function did that engineer perform? They requested the change: they wrote the prompt, assembled the context, decided what "done" looks like. They arguably implemented it: they chose to run the agent, they will fix what comes back wrong, and the output would not exist without them. Then they approved it. Article 17(1)(b) requires independence between precisely those functions.

The strongest textual argument available is that the provision speaks of functions, not natural persons. An agent is not an organisational function; it is an instrument of the function that invoked it. On that reading the human who ran the agent occupies the requesting and implementing side, and independence has to hold between them and whoever approves. The consequence is cheap to state: one engineer prompting an agent and merging its diff alone looks like a breach of 17(1)(b) - not because AI was involved, but because the requesting and approving functions collapsed into one person.

No supervisor has published an authoritative answer. I found no interpretation from the ESAs, the Commission or any national competent authority confirming or rejecting that reading. It is a defensible position, not the answer, and anyone who tells you the question is settled has not looked.

Two regulators have already said it out loud

At EU level there is still nothing normative about AI-generated code.

BaFin, in the Orientierungshilfe on ICT risks in the use of AI of 18 December 2025, has a paragraph headed "Code-Erzeugung mit KI-Assistenten" - code generation with AI assistants - whose operative sentence is: "Grundsätzlich gelten für alle Arten der Codeerstellung, sei es durch Menschen oder Maschinen, die gleichen Regelungen". In principle, the same rules apply to all kinds of code creation, whether by humans or machines. It then names one risk specific to generated code - that it may silently invoke AI-based functionality the user is unaware of, turning a non-AI application into an AI system - and points at static code analysis under Article 16(3) of the RTS as the control. It calls itself non-binding.

CSIRT KNF, the Polish supervisor's CERT, published a concrete control set on 23 July 2026, under the heading "AI-assisted code": approved tooling, a prohibition on passing sensitive data to unauthorised services, mandatory review, SAST, secret scanning, dependency testing and adequate security testing. It accompanies recommendations issued the day before, where the authority states that it expects action and that what firms implement will be verified in supervision and inspections. Soft law with teeth, framed as cybersecurity - defect supply, attack surface - not model risk.

Sit with the ordering: two national supervisors named coding assistants before any EU-level text did, and landed in the same place.

A trap worth flagging

If your internal policy still cites EBA/GL/2019/04 for SDLC or change management, it is citing repealed text. EBA/GL/2025/02, issued 11 February 2025 and applying from 20 May 2025, deleted paragraphs 1 to 91 - the whole of sections 3.1 to 3.7, covering development, testing, environment separation, source-code integrity and change management. The EBA's stated reason: the gaps were not material and were covered by DORA. Cite DORA and the RTS.

This is ICT risk, not model risk

There is a reflex to route anything with "AI" in the name to model validation. Supervisors steer the other way. The revised US model risk guidance of 17 April 2026 (SR 26-2 / OCC 2026-13) states flatly: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." US supervisory guidance, not EU law - a signal, not an obligation. BaFin points the same way, excluding model methodology from its Orientierungshilfe and treating AI as an ICT asset.

The engineering consequence: your evidence lives in the change management and ICT risk process, not a model validation file. That decides who you talk to, and what artefacts you produce.

The supervisor is walking towards this

The ECB's supervisory priorities for 2026-2028 announce, under operational resilience, "a targeted review of ICT change management to identify gaps in basic control frameworks". Non-binding, but they steer inspection planning, and that is the sentence to read twice.

Meanwhile, the adoption numbers. An ECB Supervisory Board speech of 24 February 2026 puts AI use at over 85% of large European banks, with generative AI deployed first in IT operations, "to support incident management, coding or system maintenance". ESMA's February 2026 analysis finds 87% of reported AI use cases purely internal and code generation the third most common use case overall. The AMF's French survey puts code generation at 8% of use cases, mainly in IT teams, and just 5% of firms training technical functions including developers. Neither attaches a risk comment to code generation: they are counting, not yet expecting. Adoption is far ahead of governance, and the gap is not in the law - it is in the evidence.

What this means for the pipeline

The picture I would want to draw for an auditor: every box leaves an artefact behind.

independence: CDR 2024/1774 Art. 17(1)(b) intent + context agent diff review (second human) merge deploy prompt + context tool + version diff approver identity test run release record evidence chain: what an audit asks for no artefact, no change: the auditor reconciles deploys against records, not against intentions

As defensible practice, not compliance certainty, because nobody has certified this:

  • Record AI involvement as an attribute of the change. No framework requires it, but the approved-tool control CSIRT KNF describes is unenforceable unless you know which changes used which tool.
  • Keep the prompt and context linked to the change record, alongside the diff. Cheapest artefact to capture live, most expensive to reconstruct later.
  • A human other than the one who ran the agent approves. The reading of Article 17(1)(b) I would defend, and near-free.
  • SAST and secret scanning on every agent-authored branch as a gate, not a report. A scan whose findings nobody has to clear is not a control.
  • An approved-tool list, and a rule about what code and data may leave the building. Both supervisor documents name this directly.
  • Dependency and licence checks on generated code. Article 16(8) wants third-party and open-source components tested before production; licence exposure from reproduced training data is copyright, not DORA.
  • Evidence that tests were executed, not merely written. And keep the branch protection configuration: auditors want to see the rule cannot be bypassed.

The open questions

None of these has an authoritative answer. Five honest gaps beat a false checklist.

  1. Must "AI-assisted" be an attribute of the change record? Article 17(1)(d) requires purpose, scope, timeline and expected outcomes, not the author or the tool, and no framework I checked carries a code-provenance attribute. No obligation, no prohibition, no guidance.
  2. Is human review still a real control at agent volume? The only body I found engaging with this is the FSB, whose June 2026 consultation report accepts that continuous human oversight of individual agent decisions becomes impractical and shifts emphasis to "human-in-command": governing the boundaries of autonomy rather than approving each decision. Non-binding, consultative, silent on software development. The closest thing to an answer, and not one.
  3. Is sending source code to a model as context a transfer to an ICT service provider? Source code is an ICT asset under DORA, and Article 30 requires contractual terms on processing locations, confidentiality and integrity. Read literally, yes. No supervisory statement confirms or excludes it here.
  4. Is an agent holding repository or CI credentials an identity subject to the access-control provisions? Non-human identities sit inside identity management, but the RTS says nothing about autonomous agents as subjects of access. Whether an agent may hold merge rights at all is Article 17(1)(b) again, from the other end.
  5. What does an auditor want when the tool changes weekly? Every framework assumes stable, versioned, testable developer tooling. A model behind an API changes with no version bump on your side and no change request. Whether that is an ICT change you must process is unresolved: the text covers changes to software, systems and security parameters, and this one happens at the provider.

The checklist

  1. Stop worrying about labelling generated code. The Commission put source code outside the Article 50(2) marking obligation, comments and IaC included.
  2. Stop citing the August 2026 high-risk deadline. Per the Commission's timeline it is December 2027 for Annex III, August 2028 for Annex I.
  3. Stop citing EBA/GL/2019/04 for SDLC. Deleted with effect from 20 May 2025.
  4. Take it to ICT risk, not model validation. That is where the evidence lives and where the review is coming.
  5. Make the approver someone other than the person who ran the agent. Cheap, defensible, and the control the text most plausibly demands.
  6. Gate on SAST, secret scanning and dependency checks for agent-authored branches, findings cleared rather than filed.
  7. Retain the chain: prompt and context, tool and version, diff, approver, executed test results, release record - reconcilable to one change ID.
  8. Reconcile deploys against change records. Production changes with no record is where audits break, and agents raise volume faster than evidence.

Regulation did not arrive to stop engineers using agents. It arrived years earlier, technology-neutral, and already covers this without anyone writing the word "agent" into a statute. What the supervisors have said out loud is that there is no separate regime for machine-written code - and no discount either.

So the engineering question was never "am I allowed to". It is "can I evidence what happened". For most teams running agents today the honest answer is no - not because the code is bad, but because the volume grew and the paperwork did not. That gap closes either deliberately, on your schedule, or in an inspection, on someone else's.