The audit testIf a finding cannot be reproduced, assigned and used to change a release decision, it is an observation, not useful audit evidence.
An AI product audit starts with a consequential workflow
Choose a journey where the AI output changes what a person sees, decides or does. Record the input, available context, expected outcome, forbidden outcome and recovery path. A broad tour of features produces many screenshots but little evidence.
Consider a hypothetical invoice assistant. It receives a PDF, extracts supplier and amount, checks a purchase order, then asks a finance manager to approve payment. The audit must follow that sequence because a correct extraction can still lead to the wrong approval when the purchase order is stale.
NIST describes testing, evaluation, verification and validation as evidence that an AI system meets organizational goals while minimizing negative impacts. Start with the decision the organization must defend, then select tests that can change it.
Build evaluation cases from real variation
A useful evaluation set contains ordinary cases, edge cases and known failures. Each case needs an expected result or a scoring rule, not a vague instruction to decide whether the answer feels good.
For the invoice assistant, include a clean PDF, a scan with a missing page, two currencies, a duplicate invoice and a supplier name that resembles another vendor. Define what may vary in the wording and what must never vary in the extracted amount or approval status.
OpenAI's evaluation guidance recommends task-specific tests, logging and continuous evaluation as applications change. Keep the cases versioned with the prompt, model, retrieval configuration and tool definitions so a later result can be reproduced.
If the product is still a demo without representative users or failures, use the AI proof of concept guide first. An audit cannot manufacture production evidence that the team never collected.
Trace the full decision loop before blaming the model
Separate failures by layer: input, context, model response, tool action, interface, human control and recovery. Replacing the model is an expensive answer when the real defect is a stale index or an ambiguous confirmation screen.
Imagine the assistant recommends the wrong refund policy. The model may have ignored a correct document, retrieval may have supplied an old document, or the interface may have hidden the policy date. Replay the same case with captured inputs and tool results before choosing the fix.
| Layer | Concrete test | Decision it supports |
|---|---|---|
| Input and context | Replay missing, stale and conflicting records | Improve validation, retrieval or source ownership |
| Model response | Score factual fields and allowed wording separately | Change instructions, model or evaluation threshold |
| Tools and permissions | Attempt an irreversible action without approval | Reduce scope or add a human gate |
| Interface and recovery | Interrupt the flow and resume with corrected data | Clarify status, undo and escalation |
Permissions and recovery reveal the expensive failures
Test what the product can do after a plausible mistake. Read-only search, drafting an email and issuing a refund do not carry the same consequence. The control should become stronger as the action becomes harder to reverse.
In a recruitment tool, drafting a candidate summary may need review. Sending a rejection or changing a status should require a visible confirmation, a named actor and a record of the source data used. The audit should attempt the prohibited path, not merely confirm that the button exists.
Review the AI UX design guide when users cannot see uncertainty, correct context or understand whether an action already happened. A model score cannot repair a recovery path that the interface never designed.
Production evidence must connect quality to versions
Inspect logs, latency, cost, user corrections, escalations and failures by model and product version. An average success rate hides the exact release, customer segment or document type that caused a regression.
Google recommends tracking model, code and data versions, testing live quality with human labels or real-world proxy metrics, and watching both sudden and slow degradation. For a support assistant, corrected answers and escalations can reveal drift that a static benchmark misses.
Ask whether the team can reconstruct one disputed output without exposing unnecessary personal data. If it cannot identify the prompt, sources, tool results and product version, the audit should prioritize observability before another model comparison.
The deliverable is a release decision, not a score
Require a reproducible case library, a risk register, ranked fixes and acceptance gates. Each finding should name the affected workflow, evidence, consequence, recommended change, owner and retest.
A red score for "hallucination risk" tells the team almost nothing. A better finding says that three of ten policy questions used a superseded document, identifies the retrieval rule, proposes a source-date filter and defines the cases that must pass before release.
The existing AI product requirements document should be updated when the audit exposes a missing constraint or owner. Use the AI product development partner guide if the required repair changes architecture or delivery responsibility.
An audit cannot guarantee future behavior
An AI product audit is a tested snapshot, not a permanent certificate. Models, prompts, data, tools and user behavior change. A passing system can regress after any of them moves.
That limitation does not make the audit pointless. It changes the final requirement: turn the most important cases into repeatable release checks, monitor live signals and keep a rollback path. Google's production guidance similarly emphasizes approvals, staged rollout and documented rollback.
AI product audit buying checklist
Send Seuil one critical workflow, one anonymized failure and the release decision it is blocking. Email bonjour@seuil.digital to scope the smallest audit that can produce a defensible answer.
- One consequential workflow and its recovery path define the scope.
- Representative cases include ordinary inputs, edge cases and known failures.
- Expected outcomes separate fixed facts from acceptable wording variation.
- Inputs, sources, prompts, models, tools and product versions are traceable.
- Permissions and human approvals are tested with prohibited actions.
- Latency, cost, corrections and escalations connect to product quality.
- Every finding has evidence, consequence, owner and a retest.
- The final recommendation says fix, limit, replace or stop.