What happens after an AI proof of concept says yes?

In the proof of concept, every document came with an answer: the work your team had already finished. Your reviewer judged each draft against it, and nothing in the business depended on the result. The live month takes the answer key away. New documents arrive, drafts are made from them, and a person decides on each one before it goes anywhere. The question stops being "did it match?" and becomes "is this right, and can I approve it now?"

Two more things change: an approved draft is now a real order, invoice or reply, so a miss costs something, and the work keeps the desk's own calendar, month-end and odd documents included.

With us the sequence is the one on the proof-of-concept page. After a yes, the fixed price comes before you sign, inside the range you were given before the test. Then the same job runs live in your systems for about 30 days, and a person on your team approves each item before it posts anywhere.

More people touch a live month than touched the test, so write the roles down. NIST's AI Risk Management Framework gives this its own line, GOVERN 2.1: roles, responsibilities and lines of communication documented and clear to everyone involved. For one document job the list is short:

• The owner. The manager who answers for the job's results and decides whether the month carries on, pauses or stops. For high-impact uses of AI, OMB's memo M-25-21 has US agencies record risk acceptance with a signature from the person accepting the risk. A desk job deserves the same clarity about whose decision it is.
• The approvers. Your reviewer, and anyone else who will approve drafts, with a named stand-in for days off. An approver without the time is a queue.
• The system owner. Whoever looks after the ERP or other system the work lands in: the account, its rights and the logs.
• The vendor's contact. One named person on the side that builds the drafts, us included, so every problem has one place to go.

The test ended in one scoring sheet. The live month runs on a log with a line for every document: when it arrived, whether a draft was made, what the approver did and why. Keep the approver's decision to three outcomes, approved as drafted, approved with changes or rejected, and for each change note the field and a few words of reason.

The reasons carry the value. Under MEASURE 3.3, NIST's framework asks for ways for users to report problems and for that feedback to feed how the system is judged. On a desk, the approver's notes are that feedback: a month of changes clustered on one field points to one fix, and the same number spread across every field points somewhere else. Add four more columns:

• Documents that never became drafts, and why: unreadable, outside the job, or sent straight to a person.
• Time from arrival to approval, so a growing queue shows before a customer or vendor notices it.
• Errors found after posting, by a customer, a vendor, the month-end review or anyone else. These weigh most, because they got past a person.
• What the approver had to look up before deciding, which shows what a draft should carry next time.

The documents on a live desk don't sit still. M-25-21 asks agencies to design ongoing monitoring of high-impact AI to detect unforeseen circumstances, changes to the AI system after deployment, and changes to the context of use or the data. On a desk those turn up as a customer who redesigns its PO, an update on the drafting side, or a season that brings a kind of request the desk rarely sees.

Keep changes on the drafting side to a minimum during the month, and record each one with its date, so a shift in the log can be traced to it. Treat a problem as an event, not a mood: write down what happened, who was told and what was done. NIST's framework, under MANAGE 4.3, expects incidents and errors to be communicated and the processes for tracking, responding to and recovering from them to be followed and documented.

Agree the stop rules before the first live draft, while nobody is defending a month already under way. The NIST AI RMF Playbook suggests identifying incident thresholds for bypass or deactivation and planning for backup systems. Three levels usually cover document work:

• Pause one kind of document. A format that keeps coming back with the same mistake returns to the desk by hand while the cause is fixed. Everything else carries on.
• Pause the month. An approved draft found wrong after it posted, a draft citing a record the system doesn't hold, or a queue the approvers can't clear. All the work returns to the desk until the owner knows why.
• Stop. Anything written outside the agreed access, data reaching a place it shouldn't, or a failure nobody can explain. The account is switched off and the month ends.

Going back to working by hand should take minutes. The UK government's AI Playbook (2025) counts fallback processes among the support an organization needs, so critical work carries on if a change has to be reverted or an AI system shut down. In practice the desk keeps its old routine written down and the people who know it on hand, and documents keep arriving where they always did.

Undo means two different things. Items that posted are ordinary records, corrected the way your team corrects any mistake, with a credit memo, a void or a correcting entry. Changes on the drafting side, new instructions or a new model version, should be kept as versions that can be put back. The 2024 joint guidance on deploying AI systems securely, from the NSA's AI Security Center, CISA and partner agencies, describes that as rollback: returning quickly to the last known good state when an update causes problems.

After any pause, find the cause before restarting. The Playbook also suggests preserving the materials, running a root cause analysis and setting criteria for redeploying. M-25-21 asks the same of agencies in its own terms: a plan to discontinue a high-impact AI use that isn't performing at an appropriate level, until it is put right.

In the test, your reviewer scored a batch of drafts against known answers at one sitting. In the live month they approve: drafts arrive through the day, each waiting on a decision, with nothing to compare against but their own judgment. Their hours move from doing the work to checking it, and the early days are when they learn where the drafts can be trusted. Protect that time in their week.

Two habits go wrong in opposite directions, and NIST's 2024 profile for generative AI names both. Experts can be needlessly averse, redoing work that was right. And as a system grows more reliable, people can over-rely on it and rate its output above other sources, which the profile calls automation bias. An approver who changes nothing for a week, or rewrites every draft, deserves a second look either way. A cheap guard is a second person rechecking a few approved items each week. M-25-21 also asks for periodic training and assessment of the people who operate AI, so they can interpret and act on its output; for an approver that means knowing what each mark on a draft means and when to call the owner.

Widen the scope only when the log says the job is ready, and only one step at a time, so a new problem points to one change. Good signs: the approver's changes trace to causes that were fixed, no error found after posting is unexplained, the queue keeps pace on heavy days, and the owner, the approver and IT agree. Within the job, add the customers, vendors or formats held back at the start, or a second desk doing the same work; run old documents of the new kind through first, as the proof of concept did. The next job is different work, so test it the same way on its own finished documents before it runs live; with us it is priced on its own, one job at a time. Either way more work goes through drafts, and a person still approves each one. Once a job is live, monthly support follows, and NIST's framework keeps monitoring in production on the list (MEASURE 2.4), so keep the log running for the life of the job.