Customer and tender requirements: answering "how much of your code is AI-generated, and how is it quality-assured?" with evidence

Last reviewed 2026-08-21 · 8 min read

Enterprise procurement and public tenders increasingly ask what share of your code is AI-generated and how it is quality-assured. A defensible answer is a standing vendor profile with verified numbers — AI share, review coverage, test evidence — backed by a record a buyer can inspect. A recorded chain supplies that profile; the buyer's scoring stays theirs.

What it is

The fastest-growing question in software procurement is not on any statute book. Enterprise vendor assessments, security questionnaires and public tenders now ask some version of: what share of your code is AI-generated, and how is it quality-assured? It appears in supplier onboarding forms, in the “secure development” section of information- security questionnaires, in due-diligence checklists and in the award criteria of tenders for software and IT services. A shrug — or a confident number with nothing behind it — loses the deal, or the points.

The question has three roots. First, buyers’ own regulatory duties: NIS2 makes supply-chain security and security in the development of systems part of an essential entity’s risk-management measures, DORA makes ICT third-party risk a managed discipline in finance, and the Cyber Resilience Act makes secure-development documentation a manufacturer’s own obligation — all of which push “how do your suppliers develop software?” down the chain. Second, buyers’ liability exposure: under the recast Product Liability Directive, a product that embeds a vendor’s software carries the vendor’s development record into the buyer’s own disclosure risk. Third, plain commercial risk: AI-generated code that no human reviewed is a defect and a licence question waiting to happen, and procurement knows it.

What buyers are really asking for is a vendor profile: verified numbers about how your software is developed — AI share, review coverage, test evidence, release discipline — that hold up when someone asks to see the data underneath.

Who it applies to and when

Anyone who sells software or software-intensive services to organisations that take their own supply-chain duties seriously: SaaS vendors, agencies and consultancies, system integrators, product companies with embedded software, and anyone bidding for public contracts. Public procurement in the EU runs under Directive 2014/24/EU and its national transpositions, which let contracting authorities set technical specifications, selection criteria and award criteria — including quality-assurance and security requirements for the software they buy. Private buyers set their own.

There is no start date. The question is already in questionnaires, and its frequency tracks the regulatory calendar around it: NIS2 enforcement since late 2024, DORA since January 2025, the CRA’s reporting duties from 11 September 2026 and full application from 11 December 2027, the PLD from 9 December 2026. Every one of those dates makes a buyer’s procurement team a little more insistent on a real answer.

This topic is not part of our regulatory mapping — it is a commercial and contractual demand that draws on several acts rather than one. The support section below uses the mapping’s vocabulary and marks the boundary.

What it asks of your development process

A defensible answer to the vendor question has four properties, and each one is a property of your development record, not of your sales deck:

Measured, not estimated. “About 30 %” is a guess. “Over the last 90 days, 41 % of changes to the product were authored by coding agents — by our recorder’s count, method stated” is a measurement. The measurement requires that agent authorship is captured at the source: the commit author in git is the human whose session the agent ran in, so git alone cannot produce the number.
Reviewed, and provably so. The second half of the question — “how is it quality-assured?” — is answered by review coverage: of the agent-authored changes, how many carried a human approval before release, and what tests ran. A policy that says “all AI code is reviewed” is an assertion; a per-change record is evidence.
Inspectable. Buyers increasingly reserve the right to audit or at least to see the data. A record a buyer can read — and ideally verify independently — turns a questionnaire answer into something closer to a disclosure.
Standing, not assembled per request. Procurement cycles are short and repeated; the vendor profile has to exist before the question arrives, for any period a buyer picks, or the assembly cost eats the margin of every deal.

Beyond the numbers, buyers ask about the process around them: how are coding agents governed, which tools and models are in use, what happens when an agent’s change fails review, how are dependencies and licences handled, how quickly are vulnerabilities remediated. Each is easier to answer from a record that already attributes changes, links reviews and tests, and seals releases with an SBOM than from a process document written for the occasion.

The failure mode is attribution. Teams whose records cannot distinguish agent-written from human-written changes end up answering either “we don’t know” or an estimate — and a procurement team that has read the same answer from five vendors recognises both.

What OLOBOLO evidence supports

OLOBOLO records authorship per change — human or agent, with tool and model — together with review decisions, test evidence and sealed releases, and turns them into release evidence reports with the AI share, review coverage and test-evidence figures a vendor profile is built from. The export is a canonical file any buyer can verify with the open-source verifier. The table uses our mapping vocabulary; this is not a regulatory mapping — vendor requirements are contractual and competitive, and how a buyer scores an answer is the buyer’s decision.

Buyer question	What you need to show	Chain evidence	Support
What share of your code is AI-generated?	A measured agent-authorship share over a stated period, method disclosed	`change.authored` with actor type (human/agent), tool and model; aggregated in the release evidence report	Supports
How is AI-generated code quality-assured?	Human review and test evidence linked to agent-authored changes	`change.reviewed` (reviewer, decision) and `test.evidenced` linked per change; review-coverage figure per release	Supports
Can we inspect or audit the evidence?	A record the buyer can read and verify independently	Canonical chain export + open-source verifier; RFC 3161 anchors	Supports
Which releases contained what, built how?	Release-level accountability	`release.sealed` segments with SBOM and license snapshot; evidence report per release	Supports
Security programme, penetration testing, contractual terms, SLAs, data-processing agreements	Organisational and contractual assurances	—	Out of scope

The first line carries a caveat worth repeating to buyers: the share is a count of recorded changes by actor type — honest about its method, and only as complete as the repositories you record. The last line is most of a vendor assessment; the chain answers the development-process block of it, not the whole form.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your buyer decides what their requirements demand.

How to start

Build the profile before the next questionnaire. Install the recorder on the repositories behind what you sell; after a release or two the report already carries the AI share, review coverage and test figures.
Capture agent identity at the source. Let your coding agents carry tool, model and session in commit trailers so each lands as change.authored with actor_type: agent — the number no one can produce from git afterwards.
Pair agent changes with human review. The approval before merge becomes change.reviewed; that pairing is the “quality-assured” half of the answer.
Offer the export, not just the numbers. When a buyer asks to see the data, hand them the canonical export and the verifier. A vendor who invites inspection answers a different question than one who asks to 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

Is there a law that requires vendors to disclose their AI-generated code share?

Not as such. The question arrives through buyers' own duties — supply-chain security under NIS2, ICT-risk management under DORA, product documentation under the CRA — and through procurement's general right to set technical and quality criteria. It is contractual and competitive pressure, not a standalone statute.

What is a good answer to 'what share of your code is AI-generated'?

A measured one: the share of changes authored by agents over a period, how many of those carried a human review, and what test evidence accompanied them — with the method stated and the record available for inspection. A round number with no method is a promise, not an answer.

Can we answer from git alone?

Usually not: the commit author is the human whose session the agent ran in, so git cannot tell agent-written from human-written code, and it says nothing about review linkage. You need authorship recorded at the source, with the agent's identity, plus the review and test events.

Does OLOBOLO fill in vendor questionnaires for us?

No. It gives you the numbers and the export behind them — a standing vendor profile. The questionnaire, the contractual answers and the risk appetite are yours and your buyer's.

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.