Internal AI governance for engineering: board-level visibility into where agents write code, which tools, and whether review policy holds

Last reviewed 2026-08-21 · 8 min read

Internal AI governance for engineering needs facts, not surveys: where agents write code, with which tools and models, what share of changes they author, and whether the review policy holds in practice. A recorded development chain supplies those facts per change and per release; the policy, the thresholds and the board's risk appetite stay yours.

What it is

AI coding agents moved from autocomplete to authorship faster than most organisations’ governance did. Boards and risk committees now ask engineering leaders questions that sound simple — where do agents write our code? which tools and models? how much? does anyone check it? — and discover that the honest answer is a survey of developers, a list of licences, and a policy document that says all changes are reviewed.

Internal AI governance for engineering is the practice of answering those questions with facts. Not a ban, not a free-for-all: a stated policy (which tools are allowed, what must be reviewed by a human, what must be tested, what is off-limits), measurement of whether the policy holds, and visibility for the people accountable — engineering leadership, risk, the board.

The measurement is the hard part, because the standard tooling cannot provide it. The commit author in git is the human whose session the agent ran in; review tools rarely keep a linkable record of who approved what, and none of them distinguishes an agent’s change from a person’s. A governance report built on that data is a governance report built on estimates. A recorded development chain replaces the estimate: every change carries its author — human or agent, with tool and model — the review that approved it, the tests that ran and the release it shipped in, in a record nobody can quietly edit.

Who it applies to and when

Any organisation where agents write production code: CTOs and VPs of engineering who own the policy, risk and compliance functions who report on it, boards who are accountable for it, and internal audit who test it. Regulated organisations feel it first — NIS2 puts management accountability for cybersecurity risk management on the board of essential and important entities, and security in development is one of the measures; financial entities under DORA, and anyone certifying an ISMS under ISO/IEC 27001, have auditors asking the same questions.

There is no start date: the governance gap opens the day the first agent writes code that ships. The external calendar only sharpens it — the AI Act’s transparency rules apply since 2 August 2026 and its human- oversight duties for high-risk systems from 2 December 2027; the Cyber Resilience Act’s documentation duties fully apply from 11 December 2027; the Product Liability Directive from 9 December 2026 makes the development record part of a software maker’s liability exposure. A board that cannot see where agents write code today will be asked about it under one of those headings soon.

This topic is not part of our regulatory mapping — it is an internal governance use of development evidence. The support section uses the mapping’s vocabulary and says plainly what the record does and does not do.

What it asks of your development process

A workable governance loop for AI-assisted development has four parts, and three of them are properties of the record your process leaves:

A policy that can be measured. “Agent-authored changes to production require a human review and passing tests before release; the allowed tools are X; the following areas are human-only” — stated in terms the record can check.
Attribution at the source. Every change names its actor: human, or agent with tool, model and session. Without this, every other number is an estimate. Git does not give it to you; it has to be recorded when the change is made.
Linkage. For each agent-authored change: the human review that approved it (who, when, decision) and the tests that ran. That is what turns “we have a review policy” into “the policy held for 97 % of agent changes last quarter — here are the 3 %”.
Reporting that cannot be dressed up. Per period and per product: agent share of changes, review coverage of agent changes, test-evidence coverage, exceptions — from a record that is append-only and independently verifiable, so the number the board sees is the number the engineers see.

The fourth part is enforcement, and it lives where it always has: branch protections, required reviews, CI gates. The record does not replace them; it shows whether they held. A useful discipline is to treat every gap between policy and record as a governance finding in its own right — an agent change that shipped without a review is a fact to surface, not to explain away.

What good looks like, concretely: a quarterly AI-governance page that an engineering leader can put in front of the board without caveats, because every figure on it traces to recorded events that internal audit could sample tomorrow.

Two practical failure modes are worth naming. The first is shadow agents: developers using tools outside the approved list, invisible to any survey. A record that attributes changes at the source surfaces them as agent-authored changes from an unexpected tool — a governance finding, not a scandal, and the only way to know the approved list matches reality. The second is review theatre: approvals that exist in the tool but were never a real check on an agent’s output. The record cannot judge the quality of a review, but it can show its timing and its coverage, and a review that approves a 2,000-line agent change forty seconds after it was opened is a pattern a governance report should surface rather than average away.

What OLOBOLO evidence supports

OLOBOLO records every change with its actor — human or agent, with tool and model — the review decision, the test evidence and the sealed release, and aggregates them into release evidence reports (AI share, review coverage, test evidence) that a dashboard and an export expose. The table uses our mapping vocabulary; this is not a regulatory mapping — governance policy, thresholds and risk appetite are yours.

Governance question	What you need to show	Chain evidence	Support
Where do agents write code, with which tools and models, how much?	Per-change actor type and agent metadata; share per period and product	`change.authored` with actor type, tool, model; AI-share figure per release	Supports
Does the review policy hold for agent-authored changes?	Human approval linked to each agent change; coverage and exceptions	`change.reviewed` linked per change; review-coverage figure; exceptions visible in the chain feed	Supports
Are agent changes tested before release?	Test evidence linked per change and per release	`test.evidenced`; test-evidence figure per sealed release	Supports
Can internal audit and the board trust the numbers?	An append-only, verifiable record behind every figure	Hash chain + RFC 3161 anchors; canonical export + open-source verifier	Supports
Policy design, tool approval, enforcement (branch protection, CI gates), risk appetite	Governance decisions and controls	—	Out of scope

The honest caveat: the record covers the repositories you record and the events you send. A governance report is complete only when the recorder’s coverage is — which is itself a governance fact worth reporting.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your policy and your board decide what governance requires.

How to start

State the policy in measurable terms. Which agents are allowed, what must be human-reviewed, what must be tested — phrased so a record can confirm or contradict it.
Record authorship at the source. Agents carry tool, model and session in commit trailers; the recorder turns each into change.authored with actor_type: agent. Cover every repository that ships.
Link reviews and tests. Approvals land as change.reviewed, CI runs as test.evidenced; seal releases so the figures exist per release.
Report from the record, exceptions included. Put the release evidence reports and the export in front of risk and the board; let internal audit sample. A governance page that can be verified is worth more than one that can be believed.

Evidence can't be reconstructed after the fact — it has to be recorded while you build. Start recording now, free, and every change from this moment is on the record.

Start recording

Frequently asked questions

Our developers already tell us which AI tools they use — why isn't that enough?

Because it is a survey, not a measurement. Tool adoption tells you nothing about which changes an agent wrote, whether a human reviewed them before release, or whether the policy you wrote is the policy that runs. Governance needs the record, per change.

Does OLOBOLO block or approve agent changes?

No. It records what happened — authorship, review, tests, releases — and reports on it. Your review policy, your branch protections and your CI gates enforce; the record shows whether they held.

What should a board actually see?

A few honest numbers per period and per product: agent-authored share of changes, the share of those that carried a human review before release, test-evidence coverage, and the exceptions — all from a record that can be verified, not assembled.

Is this required by the AI Act?

Not as a standalone duty for most teams. But where your product is in scope, evidence of human oversight over AI-assisted development is part of what you must be able to show — and buyers, auditors and insurers ask the same questions regardless.

Sources

Last reviewed 2026-08-21. Dates are cross-checked against our regulatory mapping and radar.

A necessary honesty: OLOBOLO is evidence, not a legal opinion. This guide describes what our chain supports as documentation — Supports / Partially supports / Out of scope — and your counsel decides what compliance requires. No tool can promise the latter.