Enterprise AI trust is built through operating evidence, not tool novelty

What the paper develops

Consider an AI assistant that drafts summaries of customer contracts for a sales-operations team. A risk reviewer approved that use after the team tested it. Now the procurement team asks to use the same assistant on supplier contracts. The first approval covers customer contracts, and its tests and notes sit in one team's files. The procurement lead can depend on the first team's experience for a use nobody tested, or reopen the whole debate, which makes every new use as slow as the first. This is an illustration, not an account of a real company.

This paper's position is that the proof has to be written so it can travel and be checked again. The record is an evidence pack. In it, the system is the AI assistant or tool itself, and a use is one task for one group of people. The pack says what the system did, on what basis, where it has and has not been tested, and who answers for depending on it, and it is kept current as the system and its uses change. The paper starts after the first approval, which "The Demo-to-Production Gap" covers. In this paper's design, that approval and its tests become the first use's part of the pack, and the second use answers the four questions again plus whichever of that paper's seven production questions, such as ownership or stop authority, the new use changes.

A strong pilot often ends up on low-stakes work at the edge of the business. That is the paper's observation, and no source here counts how often it happens. A tempting response is to ask for a better model. The paper reads the stall differently: the people accountable for important work cannot show that they can depend on the system for that work. A new model is a change like any other, so the tests run on the old one no longer cover it.

This is a reading, not a measured cause. McKinsey's survey found security and risk concerns to be the top barrier to scaling agentic AI, and Deloitte's found that few companies have a mature governance model for autonomous agents. McKinsey asks what holds leaders back and Deloitte asks how mature their governance is. Neither measures why a particular pilot stalled. The reading would be wrong if a pilot with a current pack, a named owner, and tested limits were still kept out of important work, or if a pilot moved into important work on a better model alone, with no new tests.

A use means one task, for one group of people, with one kind of input. For each use, the owner who answers for it has to show four things: what the system did, the basis for its result, where it has and has not been tested, and who answers for depending on it. Because the answers belong to a use, a second use starts with four new questions, and the first team's answers only partly carry over.

The pack has two parts, kept by two people. The system part is true for every use: the version and supplier, what has changed, test results, incident history, and known weak spots. The system steward, the person or team that runs the system for everyone, keeps it and keeps a register of uses. The use part covers one use: the purpose, the cases tested and not tested, how human review works, and the owner. It ends with one line saying what the pack covers and what it does not. A reviewer who did not build the pack reads it against the four questions and tries to find an answer that is missing or untested.

When the second team asks, its owner checks that the system part is current, writes a use part, and tests a sample of its own cases. If all four answers are there, the use goes ahead. If one is missing, the use stays a trial on low-risk work. If one is weak, the use is limited to the cases the tests cover. Nothing here measures how much time the review saves; the paper expects it to look at the differences instead of the whole system.

A pack filed once is a snapshot. The paper sets five triggers for testing again: the system changes, the inputs change, the use widens, something goes wrong, or a fixed interval passes with none of those. A better model is a trigger like the rest. The owner decides what to retest, and the reviewer samples the changes the owner called small. A trigger with no retest behind it counts as a missing answer for whatever it touches. The triggers are the paper's design, drawn on NIST guidance that treats AI risk work as continuous and asks for re-evaluation when a model is adapted to a new domain.

The pack becomes paperwork if no decision ever uses it, so each page must answer one of the four questions. It is not a certification: no single standard governs AI evidence packs, and a complete pack can still sit beside a system used past its tested limits. A small team with one use can write one page and split it when a second use appears. The paper's cost figures are planning estimates, a day or so for the system part and a few days for a use part. No study tests whether packs shorten a second review or reduce incidents, and NIST says assurance cases for software were still under study.

Pick the system that already has one approved use and is most likely to get a second. Have its steward assemble the system part and start the register of uses, have the first owner write the use part and end it with the covers line, and name a reviewer from outside the team. When the next team asks, hand over the pack and ask that team's owner to answer the four questions for the new use. If the system has no approval for its first use yet, begin with "The Demo-to-Production Gap."