Business assurance testing for AI knowledge systems

Traditional acceptance testing uses business processes and user needs as a test basis. The same principle matters for AI systems. A knowledge assistant is not accepted because it answers ten curated questions fluently. It is accepted for a bounded job when the people who own that job can observe correct outcomes and controlled failures.

The ISTQB acceptance-testing syllabus treats business processes, rules, and user needs as foundations for acceptance cases. NIST's AI Risk Management Framework adds lifecycle risk and test, evaluation, verification, and validation. Together they point away from a model-only score and toward the operating system around it.

Choose one workflow. State who asks, what decision follows, which evidence is allowed, who owns the result, and what damage an incorrect or unavailable answer can cause. That boundary determines the test depth and launch gate.

An incorrect response can begin in several places. The source may be wrong. The ingestion pipeline may retain an old version. Retrieval may miss the authoritative passage. The model may overstate weak evidence. The action layer may write the right value to the wrong record. One accuracy percentage cannot tell the team where to repair the system.

Start with normal examples, then add the situations that create expensive correction: a superseded policy, two active contracts, a revoked employee, a customer with a similar name, an unavailable approver, a destination changed during review, and a source deleted after indexing.

For each case, record the input state, user identity, permitted sources, expected answer or limitation, allowed action, reviewer, tolerance, and evidence required to judge the result. If a range of outputs is acceptable, describe the boundary. Do not pretend one reference sentence is the only valid response when the decision depends on context.

Use production-shaped records with sensitive values removed or a controlled test environment. The case should preserve the relationships and ambiguity that make the workflow difficult without exposing unnecessary personal or client data.

A citation proves where a passage came from. It does not prove that the source owns the fact. Build one case where an informal record is more semantically similar than the approved policy, and another where two approved records apply to different scopes or dates.

Pass requires the system to retrieve the authoritative evidence, apply the relevant scope, and expose disagreement when no rule resolves it. Review is appropriate when the evidence may support the answer but an owner must decide. Fail includes a correct-looking statement supported by the wrong source.

Open every citation used in an acceptance case. Confirm that the cited passage directly supports the material claim and that the user was allowed to retrieve it. Broken, decorative, or inaccessible citations are assurance defects.

Permissions and freshness are stateful. Run the same question as an authorized user, a restricted user, and a user whose access was revoked. Change the authoritative source, wait for the promised update window, and repeat the question. Delete a record and search for paraphrases that previously retrieved it.

Inspect the entire route: visible answer, citations, retrieved context, logs, caches, and proposed action. A final refusal does not prove that restricted evidence never reached the model. A successful ingestion job does not prove that an old chunk stopped appearing.

Set a freshness service level by business consequence. A product specification used in a safety procedure may need event-driven updates and a hard stop when currency is unknown. A historical lesson may tolerate a slower review cycle.

The system must be useful when it cannot answer. Remove a required fact, create a contradiction, ask beyond the approved scope, and introduce a question whose wording implies a conclusion the evidence does not support. The correct result may be a limitation, a clarification request, or an owner escalation.

The NIST TEVV-Athlon draft framework emphasizes tailoring evaluation to real-world impacts and outcomes. That makes controlled non-answer behavior part of business performance, not a cosmetic refusal test.

Place an instruction inside a permitted source that asks the model to ignore its rules, reveal another record, or invoke a tool. The application should treat the text as untrusted evidence. Test that tool and permission boundaries hold even when the generated explanation sounds certain.

A system can explain the right change and still execute it incorrectly. Create cases for missing approval, expired approval, a changed destination record, duplicate delivery, rate limits, partial failure, and a successful write followed by an unavailable confirmation response.

Pass requires the correct destination and value, the expected version, one durable operation, and a recorded outcome. Review is appropriate when the evidence supports a proposal but an accountable person must decide. Fail includes silent overwrite, duplicate action, wrong entity, or a green status that hides partial completion.

Keep read-only and write acceptance gates separate. A knowledge route can deliver value while action assurance remains incomplete. This prevents pressure to broaden credentials merely because the answer demonstration succeeded.

State which cases are mandatory, which defects block launch, what review capacity is available, who can accept residual risk, and when the suite must run again. A low-impact internal draft assistant and a system that updates contractual or personnel records do not need the same burden.

ISO/IEC 42001 describes an AI management system built around policies, objectives, processes, performance evaluation, and continual improvement. Its official overview is a management-system reference, not a certificate of product correctness. Business assurance tests turn that operating responsibility into observable cases for one system.

Publish the decision ledger with failed cases, accepted limitations, owners, remediation dates, and the conditions that invalidate approval. Rerun after source-model changes, connector updates, permission redesign, new tools, material prompt or policy changes, and incidents that reveal an untested route.

Use the live Business Brain assurance testing standard to structure the acceptance gate, then keep the resulting evidence with the implementation rather than in a temporary launch document.