What evidence shows an acceptable AI use policy is operating?

Start with a control claim

Avoid the broad claim, "Our AI policy is effective." Write a testable control claim instead:

> People using approved AI systems for internal knowledge work follow defined data, review, approval, and escalation rules, and material exceptions are detected and resolved.

NIST's AI Risk Management Framework supports this approach by separating governance, context mapping, measurement, and risk management. It calls for transparent policies, clear roles, documented oversight, ongoing monitoring, testing, risk tracking, and incident response. Those outcomes are useful anchors, but the framework is voluntary and does not certify a particular organization's control.

This page provides an educational evidence method. It does not establish legal compliance or control effectiveness for a specific organization.

Build an EVIDENCE chain

Use eight links. A missing link should become a finding, not an invented assurance statement.

### Expectation

Translate policy language into observable rules. For example:

### Version

Record the policy owner, approver, effective date, scope, review date, and superseded version. Link associated standards, tool lists, data classifications, and workflow procedures.

### Implementation

Show how the rule reaches work: access controls, configured warnings, approved templates, manager briefings, workflow gates, and role-specific instruction. A signed acknowledgement shows receipt, not behaviour.

### Demonstration

Collect representative work evidence. Examples include source maps, approval records, redacted prompts where authorized, calculation checks, decision logs, or simulation artifacts. Choose evidence based on the control claim rather than collecting everything a system can log.

### Exceptions

Keep an exception register with request, reason, risk assessment, approving authority, expiry date, conditions, and closure evidence. An undocumented workaround is not an exception process.

### Notification

Retain reports of suspected misuse, model errors, data exposure, or control bypass. Record triage, accountable owner, affected workflow, containment, and communication decisions.

### Correction

Connect findings to action. Evidence can include revoked access, corrected output, updated guidance, changed configuration, additional review, or a narrowed use case. Verify completion instead of recording only an action owner.

### Evaluation

Set a review period, sampling method, result, limitations, and next decision. Reassess when tools, permissions, data, policy, or workflows change.

• use only approved systems for specified data classes;
• retain sources for material factual claims;
• require human approval before external communication;
• prohibit unsupported sensitive inferences; and
• escalate incidents and uncertain high-impact uses.

Worked artifact: a synthetic quarterly control test

An original synthetic organization permits an approved assistant for internal drafting but prohibits confidential client data, requires source checks for external factual claims, and requires communications approval before release.

The reviewer samples 20 completed content tasks across two teams. The sample is chosen from the approved workflow queue, not from volunteers. It is small and does not support an enterprise-wide effectiveness claim.

| Control objective | Evidence reviewed | Result | Required disposition | | --- | --- | --- | --- | | Approved tool use | Access list, system sign-in record, task metadata | 20 of 20 used the approved environment | Pass for sample only | | Data handling | Source labels and authorized redacted prompt records | One task included a client identifier contrary to procedure | Open incident review; do not mark effective | | Claim verification | Source map and final external draft | 16 traceable, 3 repaired before release, 1 unsupported claim released | Correct output, investigate approval path, retain finding | | Human approval | Approval record linked to released item | 18 present, 1 late, 1 missing | Hold assurance claim; test whether workflow gate was bypassed | | Exception process | Exception register and approvals | Two current exceptions with expiry; one workaround absent from register | Route workaround for assessment and close or formalize |

The reviewer reports: "The sampled workflow shows the approved environment is being used, but data-handling and approval exceptions prevent a conclusion that the control operated consistently during the quarter." That wording reflects the evidence. It does not turn 20 records into a universal claim.

Every organization, task, count, and result in this example is synthetic.

Test design

For each policy rule, record:

| Field | Question | | --- | --- | | Control objective | What risk or decision is the rule intended to address? | | Procedure | What should a person or system do? | | Population | Which workflows, people, tools, and period are in scope? | | Sample | Why do the selected items represent the stated population? | | Evidence | What retained artifact can reproduce the conclusion? | | Exception | What deviation occurred and who can authorize it? | | Finding | What does the evidence support, and what remains unknown? | | Action | Who must do what by when, with what closure evidence? |

Use both design and operating tests. A design test asks whether the policy, procedure, authority, and evidence route could address the stated risk. An operating test asks whether those elements actually appeared in representative work during a defined period.

Evidence that is often overclaimed

Policy publication: proves availability, not use.

• Training completion: proves recorded completion, not applied judgment.
• Tool access logs: show access, not whether outputs were verified.
• Zero reported incidents: may mean no incidents, weak detection, or weak reporting.
• A successful simulation: shows performance under those conditions, not every production context.
• A dashboard percentage: is only as reliable as its population, definitions, missingness rules, and source lineage.

How Two Prune fits the boundary

A Two Prune assessment can provide task-bounded evidence of how a participant handled sources, AI output, uncertainty, calculations, approval cues, and escalation in a realistic simulation. It may complement policy monitoring by revealing patterns that training completion cannot show.

It does not certify that a policy is effective, inspect all production use, promise incident prevention, establish legal compliance, rank people, or make employment decisions. Control conclusions require the organization's broader operating evidence and accountable reviewers.

Sources

NIST: AI Risk Management Framework Core

• NIST: AI Risk Management Framework Playbook
• NIST: Generative Artificial Intelligence Profile

Sources: [1] [2] [3]