Accepting a System Built With AI-Written Code: What to Put in the TOR and What Evidence to Ask For

At the project closing meeting, the development team says most of the system's code was drafted by an AI tool and then read by an engineer. The acceptance committee asks which parts the AI wrote. The answer is that nobody kept track, because the suggestions were edited, merged and committed alongside human-written code long ago. The next question is yours: what will you rely on when you sign to accept this system?

Accept the system and its evidence, not the author

As the owner, you cannot see which lines came from an AI. Even a team that tries to record it will miss some, because the tools suggest small fragments and a person edits them the moment they arrive. We would not put a line-by-line disclosure requirement in a TOR. It cannot be verified, and it tends to produce a form that someone fills in so the box is ticked.

What works is changing the question from "who wrote it" to "does this system behave correctly and safely, and what evidence can we re-check?" That is the question you would ask about code written entirely by people. What AI changes is the volume of code produced in a short time and the chance that no one has read a given part from start to finish, which gives review evidence more weight than before.

The figures we opened at the source, and the ones we could not verify

Before citing any number we opened each publisher's own page and read it. Here is what they say.

• Software Improvement Group (SIG), in its press release for State of Software 2026 dated 9 June 2026, says that in SIG's testing AI-generated code carries roughly double the security risk violations of human-written code. The same release says SIG's benchmark spans more than 30,000 systems, and that AI-generated code accounts for 1.9% of enterprise production code. We read the press release only, not the full report, so we cannot say what sample the "double" figure rests on.

• Veracode, in its press release for the GenAI Code Security Report dated 30 July 2025, says it tested more than 100 large language models on 80 coding tasks, and that the code introduced security vulnerabilities in 45 percent of cases. The population is a set of test tasks Veracode curated, not production systems.

• Veracode's follow-up, the blog post 2026 GenAI Code Security Report dated 28 July 2026, says roughly 44% of AI code generation tasks introduced a risky vulnerability in tests, and that the average security pass rate across models was 56%, against 55% in the first report. That page does not state how many models were tested or explain the scoring, so we treat it as a directional signal only.

• CloudBees published its State of Code Abundance survey on 19 May 2026 in the press release Enterprise technology leaders report production failures from AI-generated code. Among 213 enterprise technology leaders (margin of error plus or minus 8% at 95% confidence), 81% reported production failures tied to AI-generated code and 12% said they had a dedicated governance function. Both figures are self-reported answers.

A caution on CloudBees. The release we opened is about production failures and governance. We found no standalone figure on security vulnerabilities on that page, so we are not citing CloudBees for the claim that AI-written code has more security flaws. We could not verify that, and we would rather say so than fill the gap.

The two SIG figures need to be read together.

In SIG's benchmark, AI-generated code is still a small share. Your project may use AI far more heavily than that. All three publishers also sell or run something related to software quality or delivery, so these numbers show direction, not the flaw rate of the system you are about to accept. What we can stand behind is this: several independent signals say AI-written code deserves closer checking than teams usually give it. None of them tells you whether your system is secure.

What to put in the TOR and the contract

If you are still drafting, our article on writing a TOR for a system you can maintain (currently in Thai only) covers the general handover conditions. The three clauses below are the additions for a project where the team uses AI.

Disclosure of AI tool use

Require the developer to state in writing which AI tools they use, for which kinds of work (code, tests or documentation), and to notify you when the tools change during the project. Disclosure at project level is checkable, while line level is not. Also state that your source code, personal data and secrets must not be sent to any tool you have not agreed to. That clause ties directly to leaked secrets in repos and pipelines.

A review requirement

State that every change entering the main branch must be reviewed by someone other than its submitter, with a record of who reviewed what. The developer may use AI to write or to assist review, but a named person must own each approval. This turns an unanswerable question (which part did the AI write?) into a checkable one (which part had no human reader?).

Who carries vulnerability fixes after handover

Write that vulnerabilities found during the warranty period are fixed by the developer within a time set by severity, regardless of whether a person or an AI drafted the code. The warranty length and the number of days are yours and your legal team's to set, and we have no neutral figure to lend. After the warranty ends, the obligation moves into the maintenance agreement, which should also set a fix time. The contract checks are in our checklist before signing an annual maintenance contract.

Evidence to ask for at handover

This list covers the main items we think can be verified at acceptance. We do not claim it is complete, and you should adapt it to your system.

• Dependency list. Name, version and licence of every library the system uses, plus the lockfile from the repository. AI tools often suggest libraries the team did not choose deliberately, so this list is the one place you can see what the system relies on. How to use it when a new vulnerability is announced is covered in our article on npm supply-chain incidents and SBOMs.

• Test results. Reports from unit and integration test runs, with a statement of what the tests cover and what they do not. Watch for tests an AI wrote to pass code an AI wrote: they can pass while the behaviour is wrong. Have your business side write at least one set of test cases from the TOR itself and run it in your own environment.

• Raw security scan output. The actual output files from the static analysis (SAST) tool and the dependency scanner, not a summary slide. The files should name the scanned commit, the date and the configuration, and list open findings with an owner and a fix date.

• Review records. The pull requests merged into the main branch, who reviewed each, and any merged without a reviewer. This can be exported from the repository system without anyone rewriting it.

• Secret scan results. A scan of the whole git history, not only the current files, and proof that any secret that ever leaked has been rotated.

• A build from your own repository. Have your internal team or a third party build the system from the delivered source in your own account. If that cannot be done without the developer, the handover is not finished. This is the same continuity concern as in assessing the risk a software vendor disappears.

A clean scan does not prove the system is secure. Scanners have blind spots. What a scan tells you is that the problem types the tool knows were checked at that commit. The rest needs a penetration test.

How this connects to penetration testing and handover

A penetration test fits this situation because it exercises the running system and does not care who wrote the code. If the tester is independent of the developer, you get a view that does not pass through the delivery team's explanation. The scope and conditions are in our guide to commissioning a penetration test that produces fixable findings. For AI-assisted projects we would add two points.

First, test the build that will actually be delivered, not an earlier one, because code that an AI helps modify late in a project changes quickly. Second, make the retest after fixes part of the acceptance conditions, with the developer obliged to fix within the warranty window.

The sequence we suggest: the developer submits the evidence above, your team re-runs a sample of it, an independent tester runs the penetration test, the developer fixes and the tester retests, and only then do you sign. If the delivered system itself calls MCP servers or embeds AI tools as part of the product, that is a separate design question; see our article on MCP server security architecture.

When you do not need the full set

The cost has to be said plainly: asking for the whole package lengthens the closing period, and the development team has to prepare more documents. If your system is an internal tool with a few dozen users, no personal data, no internet exposure, and can be switched off without hurting core work, then commissioning a penetration test and keeping historical review records may be more than the risk warrants. In that case we would ask for three things: the dependency list, the raw scan output, and a rebuild from your own repository. The depth of acceptance should follow the damage that could occur, not the number of fields on a form.

What to keep

If you keep one thing from this article, keep this: you can accept a system with AI behind its code without knowing which line came from where. Write into the TOR that the tools used must be disclosed, that every change needs a named reviewer, and that the developer fixes vulnerabilities during the warranty. Then ask for evidence you can re-run yourself before you sign.

If you would like to talk through a project, you can reach us on 088-983-9386 or at [email protected]. Our office is in Bang Kapi, Bangkok. For organisations still drafting their scope of work, we are glad to arrange a conversation to understand the brief first, without needing complete documents. And if the conversation shows the project is not yet at the point of needing a new system, we will say so plainly, because starting a project at the wrong moment costs more than waiting one more quarter.