Delivery note
Getting a pilot through change control
The gap between a working prototype and a deployed system is mostly paperwork you can prepare for. Most teams meet it for the first time at the end.
A prototype that works is a good week. Then the change advisory board asks for a rollback plan, the data protection lead asks where the processing happens, and the platform team asks which runbook covers it at two in the morning. Teams treat this as bureaucracy. It is a list of questions with correct answers, and every one of them is cheaper to answer during the build.
The questions, and when to answer them
| Question | Who asks | Answer it during |
|---|---|---|
| What identity does it act as | security | the prototype |
| Where does the data get processed | privacy | the prototype |
| What is the rollback | change control | the first deploy |
| How do we know it still works | operations | the first deploy |
| What happens when the model provider is down | resilience | the first deploy |
| Who is on call | the receiving team | before the build starts |
| What is the retention on prompts and outputs | privacy and legal | the prototype |
The rows marked prototype are the ones that force architecture changes if you answer them late. Identity is the worst of them, because delegated access has to be accepted by every downstream system and retrofitting it usually means rebuilding the tool layer.
Rollback is not redeploying the old container
An AI system has more moving parts than the image. A rollback plan names the version of each: prompt, tool definitions, index, embedding model, generation model, and policy. Pin them together as one release artifact so that going back is one action rather than six coordinated ones.
- Version prompts and tool definitions in the repository, never in a console.
- Pin the index and the embedding model together, because they are only valid as a pair.
- Keep the previous index alive until the new one has been in production for a full cycle.
- Rehearse the rollback once before the first real deploy, and time it.
Give the receiving team something to hold
The most common reason a working system does not get promoted is that no team will accept it. What they need is not documentation in general. It is a runbook that names the three failure modes you have actually seen, the dashboard that shows each one, and the person to call when the answer is not in the runbook.
Bring us the problem.
Tell us the outcome you are trying to create, what you have already attempted, and where the constraints are.
Contact nuperX