Accepting AI-Assisted Work: The Control Is Usually Aimed at the Wrong Object

Five unrelated cases landed within a few weeks of each other — four decided or published in August 2026, one an older incident that only makes sense next to them — from five different fields. Each is the same sentence wearing different clothes: the control was aimed at the wrong object. A build that compiles is not evidence the code behaves. A scanner that reads package manifests is not looking at the agent. A reviewer who approves is not a boundary. A prohibition is not a verification.

If you deliver client work — websites, integrations, migrations, portals — and any part of that work is now AI-assisted, this is the practical question in front of you, and it is not "should we use AI." It is: what do you hand a client, an auditor, or your own future self as proof that the thing you shipped was accepted, and not merely produced? That artifact is what almost nobody has.

What is an acceptance artifact?

An acceptance artifact is the record that a change was checked against a standard before it shipped: what was checked, by which rule, with what result, and when. It is not a feeling of confidence and it is not the absence of complaints. Three properties make it worth having. It must be mechanical — it happens because a stage runs, not because someone remembered. It must leave a record that outlives the person who ran it. And it must sit outside the thing it is checking, because a check that lives inside the system under test inherits that system's failures.

Most delivery shops have artifacts for the old risks — a signed-off design, a test run, a deployment log. Very few have one for the new risk, which is not "the AI wrote something bad" but "nobody can say what standard this was accepted against."

Why isn't a green build enough?

Because a green build is an instrument that fires without discriminating: it tells you the code compiles and the tests you happened to write passed, which is a much smaller claim than "this behaves like the thing it replaced." The clearest evidence that serious engineering organisations know this comes from Canonical, which is funding a three-year PhD project with the University of Bristol, with UK Research and Innovation co-funding, on automated translation of large C codebases into Rust. AppArmor and snap-confine — security enforcement code, not a side project — are the case studies.

Read what that funding decision implies. Generating a Rust translation of a C file is something a model will do in seconds, for free, today. Canonical is instead spending research money over three years on the other half: establishing that the translated code is behaviourally equivalent to the original. Generated code can compile cleanly and still do something different, and a rewrite that leans on escape hatches can quietly reimport the exact class of bug the rewrite existed to remove. A Linux distribution vendor declining to ship security-critical code on the strength of a green build is the strongest available answer to "the AI writes it now."

The transferable version for a web delivery team: generation is cheap and acceptance is the scarce thing. Your equivalent of behavioural equivalence is usually much cheaper than formal analysis — a recorded before-and-after on the URLs that matter, a redirect map that is tested rather than eyeballed, a content diff — but it is not free, and it does not happen unless a stage makes it happen.

What did Debian actually decide?

Debian settled it. General Resolution 2026-002, "LLM usage in Debian", closed on 28 August 2026 after a two-week vote on nine ballot options, ranging from a prohibition written into the Social Contract through to explicit permission with a long list of conditions attached. The result is worth reading closely, because the vote was widely described as being about whether AI is allowed, and that is not what the tally says.

The prohibition lost, and not narrowly. As a Social Contract amendment it needed a 3:1 majority; it drew 144 votes to 257 against — a ratio of 0.56 where 3.0 was required — so it was dropped before the pairwise stage. The option that won, "Responsible Use of Generative AI", passed by 281 to 126, and beat the detailed conditions-list option head to head by 203 to 148. Its opening position is the sentence to carry away: Debian "neither endorses nor prohibits" the use of generative AI tools in the development, maintenance or documentation of what the project publishes.

What the adopted statement does instead is put every requirement on the contribution and on the person submitting it. Contributions must meet the same standards of quality, correctness, maintainability and legal compliance regardless of how they were produced. Using a tool "does not diminish the contributor's responsibility for the work they submit." Contributors are expected to understand, review, test and where appropriate modify AI-assisted output before it goes in, and the statement says in as many words that blindly uploading generated material without appropriate human review is inconsistent with the project's established practice. It declines to resolve the copyright question, and it tells contributors not to hand confidential material, embargoed security information, keys or credentials to third-party AI services.

The most instructive detail is the one that ran opposite to what a governance-minded reader would predict: disclosure is encouraged and explicitly not required. A project with as much process as any in open source had a mandatory "this was AI-assisted" label available on the ballot and declined to make it a rule — while leaving the acceptance standard non-negotiable. That is this article's argument delivered by a body that had eight alternatives in front of it and a published tally to show for it: a label on the tool is not what protects the archive. The obligation to understand and test what you submit is.

Is "nobody knows our internals" still a control?

No, and the clearest statement of that came in August 2026 from CISA advisory AA26-231A, co-signed by the NSA, the FBI, the Department of Energy and the Environmental Protection Agency, warning that attackers are actively targeting internet-exposed Siemens S7 programmable logic controllers using AI-assisted tooling built on public industrial libraries. Its own framing is that this is not a theoretical risk.

The precise mechanism matters, and getting it wrong turns a useful fact into a scare story. The advisory's point is not that AI finds exposed systems — internet-wide scanning services have listed them for a decade, and discovery was never the barrier. The point is that AI removes the specialist-knowledge barrier: building something that speaks an industrial protocol convincingly used to require an engineer who had worked with those systems. That is now a much shorter distance for someone who has never seen one.

Apply that to what a web shop actually operates: bespoke admin endpoints, one-off integration middleware, undocumented CMS module APIs, a legacy client portal nobody has looked at in three years. Every one of those has been protected in part by the fact that understanding it took effort. That protection is the thing that just got cheaper to defeat, and it was never an acceptance artifact — it was the absence of one.

Why won't a dependency scan catch an agent problem?

Because a dependency scanner inspects the packages a project declares, and an AI agent's permission model is not a package. In 2025 the researcher Johann Rehberger demonstrated against Amazon's Q Developer that an agent could be driven — through content it was asked to process — into running commands and leaking data the developer never approved; the resolution was a change to how the product asks for confirmation, not a patched library version. Nothing in a manifest would have flagged it, before or after.

This is the same wrong-object error in its purest form. The scanner is a real control, aimed at a real risk, returning a real answer — about the wrong layer. Scanning is not coverage. If your acceptance evidence for AI-assisted delivery is "the dependency scan was clean," you have evidence about your dependencies and no evidence about your agents.

Can you warrant human review as a safeguard?

This is where the two halves of the pincer close, and it is the most uncomfortable finding of the set. On one side, human review measurably underperforms as a filter: an analysis of 409,000 approve/deny decisions across roughly 40,000 agent runs found reviewers caught about two thirds of malicious commands — which means roughly one in three got approved by a human who was, in that moment, doing their job.

On the other side, the absence of human review is now a priced violation. On 21 August 2026 the Dutch data protection authority published a decision fining Uber €824,990,000 over driver account deactivations. Three things belong in the same breath as that number: the conduct period is 2018 to 2022, Uber has filed an appeal, and the amount is about 1.85% of a roughly €44.5 billion 2025 turnover against a 4% statutory ceiling — meaning it is a percentage-of-revenue calculation, and the same finding against a company of any other size produces an entirely different figure. A number that size is not transferable; the mechanism is.

What the regulator found is that software tracked driving behaviour and ratings and deactivated accounts on threshold breaches with no human assessment at the point the consequence attached. It found, as a separate violation, that drivers were not adequately informed that automated decision-making was in operation. And it is worth being careful about the law here rather than sloganeering: this is one authority's application of the GDPR's provision on solely automated decisions, the decision is under appeal, roughly 40% of the €7.1 billion in announced GDPR fines has been annulled or is under active challenge, and the European Commission's Digital Omnibus proposal of November 2025 would restructure that very provision. Report it as a decision, not as the settled law.

Put the two sides together and the practical conclusion is sharp: you cannot warrant attentive human review as a control, and you cannot omit it either. The only thing that survives both is a review step that is mechanical and logged — a stage that must complete, and that leaves a record of what was checked.

What does a regulator mean by meaningful human review?

More than a signature. In a March 2025 consultation on meaningful human intervention in algorithmic decisions, the same Dutch authority argued that a human assessor must hold genuine authority to overrule the automated outcome and must actually exercise it when warranted — a rubber stamp does not qualify. Its deputy chair put the underlying position plainly when the Uber decision was published: a computer should not make decisions on its own that have major consequences for a person, and those decisions should have been looked at by a human being first.

Note what that does to the box-ticking version of oversight. A reviewer with no authority to say no, or with no time to look, is not a control that got weaker — it is a control that was never present, and describing it in a policy document creates the exposure rather than closing it. The second Uber finding is the one to remember here: the disclosure failure was cited separately from the decision-making failure. A disclosure gap gets priced, not merely remediated.

What does an acceptance artifact look like in a delivery shop?

It is much smaller than the case studies suggest. For a team shipping client sites, an acceptance artifact for AI-assisted work usually means four things, none of which require a research budget. Disclosure at the point of contribution — a commit trailer, a ticket field, a line in the change log recording that a change was substantially tool-assisted, in the record rather than in someone's memory. Debian declined to require that of volunteers, and a client engagement is not a volunteer project: you are being paid, and the Uber decision prices inadequate information as a finding of its own. A named accountable human per change, expected to understand it and to be able to justify it — which is the obligation Debian's adopted statement puts on the contributor, almost verbatim. A behavioural check proportional to the risk — for most web work that is a recorded before/after on the pages and endpoints that matter, not a formal proof. And a default of pending: when no rule matches, the change waits, rather than proceeding because nothing objected.

That last one is the whole design principle in four words. Every failure in this article is a system that proceeded because nothing stopped it: the build was green, the scan was clean, the reviewer clicked approve, the threshold was crossed. A control that defaults to "allow" when it has nothing to say is not a control.

What changes in the statement of work?

Two clauses, and they are cheap to add before a project rather than expensive to argue about after one. First, disclosure: say plainly whether AI-assisted tooling is used in delivery, and record it per change rather than as a blanket sentence in a master agreement. A blanket sentence tells a client nothing they can verify, and the Uber decision is a reminder that inadequate information is a finding in its own right, not a footnote to a different one. Second, acceptance criteria that name the artifact: what evidence accompanies handover, in what form, retained for how long. "Tested" is not an artifact. "Redirect map verified against the pre-migration URL inventory, output attached" is.

Neither clause requires you to resolve whether AI-assisted work is good or bad — which is fortunate, because nobody is going to resolve that in a contract. They only require that the work be acceptable on stated terms. That is the same standard you already apply to a subcontractor.

What this article is not claiming

It is not claiming that AI-assisted delivery is unsafe, or that any of the organisations named did something foolish. Canonical is doing the careful thing, Debian had the argument in public and published the tally, and the Uber decision is under appeal in a legal area the European Commission has already proposed to rewrite. It is not a claim about any particular platform's internal controls, ours included — a reassuring sentence about our own review process would be exactly the kind of unverifiable control claim this article is about, so there isn't one.

And it is not a prediction. It is an observation about five unconnected sources arriving at one shape: a green build, a dependency manifest, an attentive reviewer, an obscure internal API and a prohibition are all controls that were pointed at something adjacent to the risk. The remedy in each case is the same, and it is boring: put the check outside the thing being checked, make it fire without depending on anyone's attention, and keep the record it produces.

Where does this leave an agency or integrator?

In a better position than it leaves a large platform, because the artifact is easier to produce at your scale than at theirs. A four-person team can genuinely record who accepted what against which rule; a ten-thousand-person organisation discovers, four years later and in a regulator's summary, that the step it described in its policy was not happening. Small delivery organisations have spent a decade being told their governance is a liability next to enterprise process. On this specific question the position is reversed, and it is worth saying so to clients.

If you are choosing the platform that work will land on, the questions worth asking are the same shape: what does the platform let you record, what does it let you reverse, and what evidence can you hand over at the end. We have written that up as a checklist for evaluating a white-label DXP, along with how an integrator actually runs delivery on WebinOne — portal, roles, environments and handover — and, for the sake of an honest answer, where WebinOne is the wrong choice. If the work ahead is a portfolio move rather than a new build, our migration path is the relevant page, and the platform overview covers what the environment is. Agencies and integrators reselling the platform work under the partner programme; teams doing AI-assisted build work with us do it through our managed delivery service. If you would rather ask a person, talk to us.