From AI demo to a service your team can run.

Ask for release evidence, not another demo

A demo often follows a prepared path with clean data. Production has missing fields, stale documents, changing permissions, unavailable services and users who phrase the same request differently. The useful question is what happens in those cases.

Keep a small release evidence pack beside the working software. It should contain the agreed scope, test results, unresolved defects, permissions, recovery procedure and operating owner. A product owner should be able to read it without having to interpret a model trace.

Start with your acceptance cases. Include straightforward requests, ambiguous requests, requests that must be refused and jobs that cannot finish because a dependency is down. Record the expected treatment of each case before running the test. An honest “needs review” can be a successful outcome when the alternative is an unsupported answer.

Twelve questions to settle before launch

1. What job does this release finish?Name the input, result and acceptance rule. List important work that stays outside this release.
2. Who owns the result?Assign a business owner who can judge quality and an operator who can investigate failures.
3. What did the test actually cover?Keep the cases, expected outcomes, measured results and open defects together.
4. What may the workflow read or change?Record accounts, data sources, tools and authorization boundaries in a permissions map.
5. Which actions need approval?Identify consequential actions and enforce the approval in application code or the downstream system.
6. How does it stop?Set time, call and retry limits. Give operators a way to pause new work and revoke access.
7. What is recorded?Capture enough to investigate the job, while controlling access, sensitive content and retention.
8. How will we notice poor results?Monitor accepted outcomes and review backlog as well as uptime, latency and errors.
9. What happens after a failed action?Test duplicate requests, partial completion and recovery without repeating external effects.
10. Can we restore and roll back?Exercise the relevant backup, configuration restore and previous release procedures.
11. Who answers an incident?Agree service hours, severity, escalation, communications and authority to disable the workflow.
12. Who pays and who can leave?Confirm usage limits, operating budget, account ownership, export and handover obligations.

Make permissions narrower than the prompt

“Do not delete anything” in a prompt is not the same as an account that lacks deletion rights. Give the workflow only the tools and data it needs. Put authorization checks where actions execute, including checks that the current user may access the selected record.

OWASP describes excessive agency as a risk from too much functionality, permission or autonomy. Its guidance supports minimizing available tools and independently controlling high-impact actions. These controls should still hold when a model misunderstands an instruction or reads hostile content in a document.

For example, a service assistant might search approved guidance and draft a response. Sending that response, changing a customer record or issuing a refund are separate capabilities. You can release drafting first while keeping those actions behind an explicit approval step.

Write down one ordinary failure

Make this a test with a recorded result. Ask what the user sees, whether the work remains queued, who can retry it and how the final state is reconciled. A “retry” button is not a recovery plan until those questions have answers.

Also test a document the user cannot access, an expired credential and a model-provider interruption. The right behavior depends on the task: pause, give a limited answer from verified information or hand the case to a person. Avoid a fallback that quietly bypasses the original permission or quality requirement.

Give each operating responsibility an owner

On a small screen, scroll the table sideways.

One person may hold several roles in a small team, but none should disappear into “the AI handles it”. Agree the time allocated to the work. Check that operating effort appears in the monthly cost model.

Choose a release boundary you can support

A controlled launch might serve one team, one document collection and one task. Keep the old route available while reviewing real cases. Decide which signals would pause the rollout, such as unauthorized access, repeated incorrect results or an unmanageable review queue.

The NIST AI Risk Management Framework is voluntary guidance for addressing trustworthiness throughout an AI system’s lifecycle. Referencing it does not make a system certified or compliant. Use relevant guidance to ask better questions and document your actual decisions.

At handover, request the source and deployment instructions promised in the contract, account ownership details, configuration, current limitations, support contacts and the next review date. A team should be able to operate or replace the service without reconstructing its behavior from a chat history.