AI-assisted risk and control deliverables

Define the decision before the artifact

Start by naming the decision the artifact supports: approve a bounded trial, continue an existing use, change a safeguard, accept a temporary exception, or stop the workflow. Record the system or work process in scope, affected people and information, permitted use, decision owner, reviewers, and the date after which the evidence is stale.

NIST describes its AI Risk Management Framework and Playbook as voluntary resources for incorporating trustworthiness considerations across the Govern, Map, Measure, and Manage functions. The Playbook offers suggested actions rather than a universal checklist (NIST AI RMF Playbook). That distinction matters: a risk artifact should show how a team applied relevant practices to its context, not merely state that a framework was used.

Sources: [1]

Assemble a control evidence packet

Create one packet per material risk. Include a risk statement with cause, event, and consequence; a control objective; the operating step; the owner; the evidence source; the test procedure; the sample or observation window; the result; known limitations; and the disposition. Link dependencies such as identity controls, source-data permissions, human review, or vendor behavior.

Separate design evidence from operating evidence. A policy or workflow diagram may show that a control was designed. It does not show that the control operated for the cases under review. Preserve the original record, the AI transformation applied to it, and the reviewer action so a later reader can reconstruct what happened.

Make test results reproducible

Write tests as instructions another reviewer can repeat. State the population, sample selection, expected condition, comparison rule, tolerance, evidence location, and treatment of missing records. For generated content, include representative prompts or inputs, model or service version when available, output capture, reviewer rubric, and failure classification.

The U.S. Government Accountability Office organizes its AI accountability framework around governance, data, performance, and monitoring, with practices and questions for entities, auditors, and assessors (GAO AI Accountability Framework). The framework is not proof that a particular control works. It supports keeping governance, input quality, observed performance, and ongoing monitoring visible as separate evidence concerns.

Sources: [2]

Worked artifact: a synthetic control packet

Consider a synthetic policy-answering assistant used by an internal operations team. The risk statement says that an outdated procedure could be presented as current and cause an incorrect operational step. The control objective is that every answer containing a procedure must cite an approved, current policy record and receive human confirmation before action.

The packet links the approved policy repository, a dated 40-question test set, the expected policy for each question, captured answers, citation checks, reviewer decisions, and an exception log. Thirty-seven answers cite the current record and are confirmed. Two cite superseded versions, and one gives no usable citation. The owner disables those three question paths, records the affected policy identifiers, and opens a retrieval-index repair. The packet does not convert 37 of 40 into a universal accuracy claim; it records a bounded observation for a specified test set and configuration.

Track exceptions as expiring decisions

An exception record should state the unmet control, reason, affected scope, compensating measure, accountable approver, start date, expiry date, and closure evidence. Do not let an exception become permanent through silence. Trigger re-review when the data source, model, prompt layer, integration, user population, policy, or impact changes, or when monitoring reveals a new failure pattern.

Maintain a disposition vocabulary such as pass, repair, restrict, accept temporarily, and stop. Each disposition needs a named decision owner and supporting evidence. AI may summarize records or propose classifications, but it should not approve its own control effectiveness or exception.

Verify the packet and keep claims bounded

Before release, confirm that every claim points to an evidence item, every test can be repeated, dates and versions are visible, exceptions have owners and expiry dates, and the final disposition follows the recorded results. Check that reader-facing summaries preserve failures and limitations instead of averaging them away.

A control evidence packet can improve traceability and make review easier. It does not establish legal compliance, certify safety, prove that a control will remain effective, or replace jurisdiction-specific and domain-specific review. Two Prune can observe task-bounded behavior in a synthetic assessment and report evidence for human interpretation. It does not operate a customer’s controls, audit production systems, or make employment decisions.