What it is

Regulation (EU) 2024/1689 — the AI Act — is the EU’s horizontal rulebook for artificial intelligence. It is risk-based: a short list of prohibited practices, a large body of obligations for “high-risk” AI systems (technical documentation, risk management, data governance, human oversight, conformity assessment, CE marking), a set of transparency duties for certain AI systems and AI-generated content (Article 50), and lighter rules for general-purpose models. Most of its weight falls on providers of AI systems; deployers carry their own, narrower duties.

For a software team the Act is relevant in two quite different ways, and keeping them apart is the single most useful thing this guide can do. First, your product may itself be, or contain, an AI system — in which case the Act’s provider or deployer duties may attach to it, up to the full high-risk regime. Second, your process may use AI — coding assistants and agents that write, review or test code. The Act was not written about the second case. What it asks there is mostly indirect: where your product is in scope, the documentation of how it was developed — including the role of AI tools and the human oversight over their output — becomes part of what you must be able to show.

The “Digital Omnibus on AI” (Regulation (EU) 2026/1744, in force since 27 July 2026) amended the timeline: it postponed the high-risk obligations but left the transparency article where it was. If your mental model is “the AI Act got delayed”, it is one article too coarse.

Who it applies to and when

The Act applies to providers placing AI systems on the EU market or putting them into service, to deployers established in the EU, and in defined cases to providers and deployers outside the EU whose system output is used in the EU. Whether a given piece of software is an “AI system” in the Act’s sense, and whether it is high-risk, is a classification your counsel and product owners make — this guide does not.

The dates after the Omnibus:

  • Article 50 transparency obligations have applied since 2 August 2026. The Omnibus did not move them.
  • High-risk obligations for standalone Annex III systems apply from 2 December 2027.
  • High-risk obligations for AI embedded in products covered by other EU harmonisation legislation apply from 2 August 2028.

Article 50, in broad strokes, requires that people are told when they interact with an AI system rather than a human; that providers of systems generating synthetic audio, image, video or text mark the output as artificially generated in a machine-readable way; and that deployers disclose deepfakes and AI-generated text published to inform the public on matters of public interest.

Read against a normal development workflow, those duties attach awkwardly to code at best. The marking duty sits with the provider of the AI system — the maker of the coding assistant — not with the team using it; and it targets content categories in contexts where a person might be deceived about origin. Source code in a private repository is not “published to inform the public”, and your compiled product is not, in any ordinary reading, the AI system’s output presented to an end user. The Commission’s own guidance names source code among the outputs that fall outside Article 50(2)’s marking obligation. Honesty requires the edge cases too: if your product embeds a model that generates content for users, you may carry provider or deployer duties in your own right, and whether an unusual configuration falls in or out is a question for counsel, not a web page.

What it asks of your development process

Where your product is in scope — and increasingly where a buyer or an auditor simply assumes it might be — three parts of the Act shape what your development process must leave behind.

Transparency (Article 50). Even where your code is outside the marking duty, the underlying expectation — knowing where and how AI was involved in producing an output — is the one every other actor asks about. Being able to say, per change, “this was written by an agent, using this tool and model, and approved by this person” is the documentation form of that expectation.

Human oversight (Article 14, high-risk). The Act requires that high-risk systems be designed so humans can effectively oversee them. For the development of such a system with AI assistance, the practical question is whether humans reviewed and approved AI-produced work — and whether you can show it. A review policy on paper is an assertion; a review record linked to each agent-authored change is evidence.

Technical documentation (Annex IV, high-risk). The technical file for a high-risk system covers design, data governance, performance, monitoring and much more. Development-process records — how the system was built, reviewed, tested and released — are one element of it, not the file itself.

What distinguishes evidence from prose here is the same short list as elsewhere in EU software regulation: it is contemporaneous (recorded when the work happened), attributable (each event names its actor, human or machine), append-only and tamper-evident (a third party can check its integrity) and tied to releases. Codebases with meaningful AI authorship most often fail on attribution: the process description says “all changes are reviewed”, and the record cannot say by whom, or of what.

And the trap to avoid: “not covered by Article 50” is not “not asked”. The questions about AI-written code arrive from other directions — a due-diligence team, a court applying the Product Liability Directive’s disclosure mechanics, a market-surveillance authority reading Cyber Resilience Act documentation — and none of them is satisfied by “Article 50 doesn’t apply to us”. They want provenance, recorded when it happened, and that cannot be created retroactively.

What OLOBOLO evidence supports

OLOBOLO records each change with its author — human or agent, and for agents the tool, model and session reference — together with the review that approved it, the tests that ran and the release it shipped in, in an append-only chain anchored in time. The table mirrors our regulatory mapping v1 for the AI Act, line for line.

Requirement What you need to show Chain evidence Support
Art. 50 — transparency for AI-generated content and AI interaction Document where and how AI was involved in producing output, so disclosure duties can be met and evidenced change.authored actor records (agent tool, model, session reference) per change Supports
Art. 14 — human oversight (high-risk systems) Evidence that humans reviewed and approved AI-produced work in the development process change.reviewed entries with reviewer identity and decision, linked to agent-authored changes Partially supports
Annex IV — technical documentation for high-risk AI systems Development-process records as one element of the broader technical file Chain export, release evidence reports, in-toto attestation Partially supports
Conformity assessment and CE marking (Art. 43 et seq.) Formal conformity procedures — Out of scope

The notes matter as much as the states. The chain evidences AI involvement in development; whether a given deliverable falls under Article 50 is the deployer’s legal assessment. The oversight evidence covers AI-assisted development — runtime oversight of a deployed AI system is a separate matter. And the chain feeds the development-process sections of an Annex IV file; the file requires far more. OLOBOLO attests to what was recorded — it performs no assessment.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your counsel decides what compliance requires.

How to start

  1. Record agent authorship from the first commit. Let your coding agents carry identity in commit trailers (tool, model, session); the recorder turns each into a change.authored entry with actor_type: agent — the provenance every later question starts from.
  2. Pair every agent change with a human review. The approval your reviewer gives before merge becomes change.reviewed, linked to the agent’s change. That pairing — agent wrote, human approved — is the oversight trail in evidence form.
  3. Seal releases and keep the reports. If your product is, or may be, in scope, the release evidence report is the piece you hand to the people assembling the technical file.
  4. Let counsel classify. Whether your system is an AI system, whether it is high-risk, and what Article 50 means for your specific deliverable are their calls. Our job is to make sure that, whatever they conclude, the record already exists.