ISO/IEC 23894 AI Controls Mapping
An AI controls mapping is a chain of decisions, not a list of products. This example starts with one support summarizer and maps four different risk scenarios to a control, accountable owner, test, evidence and residual-risk decision. It distinguishes an organization's selected controls from the customizable ISO/IEC 23894 risk-management guidance and marks where a request gateway has no coverage.
A useful ISO/IEC 23894 controls map starts with a risk scenario and ends with a tested decision. The row in between names a control, its owner, a test and evidence an independent reviewer can retrieve. ISO/IEC 23894:2023 provides customizable AI risk-management guidance. The four rows below are illustrative organizational choices for a support-case summarizer; they are not an ISO control catalogue or a claim of certification.
TL;DR
- Map one risk scenario to a chosen treatment, accountable owner, test, retained result and residual-risk decision.
- Keep model-quality and user-impact controls separate from controls on HTTP requests to a model provider.
- Review the map when a route, model version, data class or use case changes.
Fix the system boundary before filling rows
Example system SUP-17 summarizes customer support cases for agents. It reads case notes in an internal application, calls a hosted language model through an approved HTTP route, then shows a draft summary for human review. Its case notes can contain names and account details. The business owner is the support director; engineering owns the integration. The operational checklist asks for this inventory, but the mapping below begins once the owner has approved the scope.
Each example row uses seven fields: risk ID, scenario, selected control, owner, test, evidence and residual decision. A neat spreadsheet with blank test cells would conceal the only question the assessor needs answered: did the selected control operate against the scenario it was chosen to treat?
Example risk-to-control rows
- R-01, case data sent to an unapproved model. Selected control: allow only approved model endpoints for SUP-17 and block a request carrying a restricted case-data class to any other route. Owner: the AI platform engineer. Test: replay a permitted case and a blocked restricted-data case after each route-policy change. Evidence: policy version, test fixture ID, decision record and dated result. Residual decision: the support director accepts the remaining risk only after the blocked case passes and the downstream provider contract is reviewed.
- R-02, summary invents a customer commitment. Selected control: keep a human approval step before a draft becomes a sent reply, and evaluate a sample of summaries against the source case. Owner: the support operations lead. Test: sample twenty drafts after each model-version change, record unsupported promises and inspect escalations. Evidence: evaluation set, reviewer notes and corrective-action ticket. Residual decision: the owner records the observed error rate and approves or limits rollout. An HTTP request log can identify the model call; it cannot score the truth of the generated answer.
- R-03, an agent sends cases outside its assigned queue. Selected control: bind the request to the application-supplied case scope and a verified service identity before the model call; enforce a narrower route for that workload. Owner: the application security lead. Test: attempt a cross-queue request with a test identity and confirm a denial. Evidence: identity configuration, policy version, rejected-request ID and reviewer sign-off. Residual decision: the security lead records what happens when the application supplies an incorrect scope, since a gateway cannot independently validate a case assignment it never receives.
- R-04, treatment goes stale after a provider switch. Selected control: make the provider change request reopen SUP-17's risk assessment and require a fresh allow/deny test before release. Owner: the support release manager. Test: inspect a staged provider-change ticket and verify the reassessment link and new sample results. Evidence: change record, updated risk row and approval timestamp. Residual decision: the support director signs the refreshed treatment before production traffic moves.
Mark coverage and evidence honestly
The NIST AI RMF Playbook offers voluntary suggested actions under Govern, Map, Measure and Manage. Teams using both sources can record which activity informs each row, while keeping their actual control test as the source of proof. Neither framework turns R-01's route block into evidence for R-02's answer-quality risk. A risk register row should link back to the same SUP-17 ID and decision owner.
For a reviewer, put a redacted sample request ID beside R-01 and R-03, and a dated evaluation-set reference beside R-02. The audit evidence walkthrough shows how to retrieve those records without copying full customer case text into the packet. If a row lacks an owner or a test, leave it open. I would reject a claim of complete coverage based on a policy screenshot alone.
DeepInspect
For routed HTTP AI calls, DeepInspect can evaluate the identity and context supplied by the integration against model and data policy and retain a per-decision record. That can help test the request-layer treatments in R-01 and R-03. The support team still owns case assignment, output evaluation, provider review and the decision to accept residual risk.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does ISO/IEC 23894 prescribe these four controls?
No. The ISO record describes adaptable risk-management guidance. These controls are an example selected for SUP-17's scenarios; an organization should approve its own treatments against its assessed risks.
- What changes when the model provider changes?
Reopen the affected risk rows, confirm the new route and data handling, rerun the relevant tests and date the approval before moving production traffic.