General Manager
I am more interested in what an AI service does with a withdrawn document than in another successful answer to the same demonstration question.
The document is an ordinary operational problem. Someone replaces a policy, changes a permission or removes a source. The service has to respond correctly after that change, including in an existing conversation.
An enterprise AI pilot is ready for a production decision when the organisation has tested the intended workflow under realistic conditions, recorded the remaining limitations and assigned responsibility for operating it. A good answer in a demonstration establishes much less than that.
For Altaius SI work, I would make that distinction concrete with an acceptance record. Each requirement needs a test, a result, an owner and an agreed response if it fails.
Take an internal assistant that helps an employee find the right purchasing procedure. Before choosing a model, define what a completed task looks like.
The employee should receive the current procedure for their location and role, with an accessible source. If the procedure does not answer the question, the assistant should say so and direct the employee to an appropriate owner. It should not invent an approval or apply a policy from another business unit.
That definition gives the team something to test. A general instruction to make the assistant helpful does not.
Keep the boundary visible. Reading a procedure and approving a purchase are different permissions. If the first release only supports reading, acceptance should verify that the system cannot take the second action.
This is a starting record I would adapt with the service owner. It is an example, not a universal release standard.
| Test | What to change or attempt | Evidence to retain |
|---|---|---|
| Current source | Replace a policy with a materially different version | Retrieved version, answer and elapsed refresh time |
| Restricted source | Ask the same question as users with different permissions | Authorised source sets and results for each user |
| No reliable answer | Ask a valid question the approved sources do not answer | Refusal or escalation and the route offered |
| Conflicting instructions | Provide two approved sources that disagree | How the conflict is identified and resolved or escalated |
| Service failure | Make a required dependency unavailable in a test environment | User message, alert, fallback and recovery record |
| Arabic usage | Test equivalent tasks in the language people will use | Task completion, meaning errors and reviewer comments |
| Operating cost | Run the agreed workload including retries and reviews | Full service cost and completed task count |
| Ownership | Ask the receiving team to investigate a failed request | Whether they can diagnose it with their own access |
Set thresholds before looking at the final results. The acceptable failure rate for a low consequence information lookup may differ from that for a workflow affecting payments. Some failures, such as unauthorised disclosure in the test set, should stop release until investigated.
A clean test set does not prove that every future request will be safe. It establishes what was tested and provides a basis for the next decision.
An English evaluation followed by a quick Arabic translation check would leave too much unexamined for a service intended for Saudi users.
I would include the actual terms people use for the workflow, mixed language requests where appropriate and questions whose meaning changes with the user's role. Ask reviewers to evaluate whether the task was completed correctly, not just whether the answer reads fluently.
For example, a fluent answer that routes a request to the wrong approval authority still fails. Record that failure in the task result, even if the language quality is good.
Microsoft's RAG evaluation guidance treats evaluation as broader than answer quality, including responsible AI and security concerns. I use that distinction here to keep fluent output from masking a failed workflow.
Production systems change. The acceptance process should include at least one controlled change to a source, configuration or model, followed by the relevant regression tests.
Record the versions involved. Otherwise, the team can end up with a passing report for a configuration that is no longer running.
I would also ask for a rollback demonstration in a suitable test environment. If a new configuration produces unacceptable behaviour, the operating team should know which version it can restore, what data will remain and how it will verify recovery.
This is one reason I see architecture and operation as connected work. In Altaius SI, I want the people receiving a system involved while there is still time to change its design.
The release record should allow three outcomes: proceed within a defined boundary, continue the pilot with specific work remaining, or stop this approach.
A conditional approval should say what is excluded. Perhaps the service can answer questions from one reviewed collection but cannot use a more sensitive source yet. That boundary needs to exist in the system, not only in the meeting notes.
The voluntary NIST Generative AI Profile is a useful reference for examining risks throughout an AI system's lifecycle. It does not certify a particular implementation, and citing it does not replace testing.
Before signing off, I would ask the receiving team to explain one failed test and what they will do if it happens after release. Their answer tells me whether the project has produced an operable service.
That is the record I would want beside a release approval: the workflow we tested, what failed, what remains excluded and who will answer when the service needs attention.
