Questions to ask about AI risk and governance at work

What exactly is the AI-enabled action?

Describe the action as a verb and consequence: retrieve a policy, classify a request, calculate a figure, draft a recommendation, rank options, send a message, or change a record. “Use AI for operations” is too broad to govern. Record the intended users, affected people, data, systems, autonomy, external reliance, and whether the result can be reversed before harm occurs.

Ask what remains a human decision. Name the person or function with authority and what they need to see. “Human review” is not an answer if the reviewer lacks the source material, time, competence, permission, or ability to reject the output.

The NIST AI RMF Core organizes risk work around Govern, Map, Measure, and Manage. It emphasizes context, clear responsibilities, measurement, documented treatment, and continuing review. The framework is voluntary and must be tailored; it does not supply a legal answer for a specific workplace use.

Sources: [1]

What evidence supports the intended use?

Ask which materials define a correct result and whether they are current, complete, and permitted for this use. Distinguish authoritative records from background context and model-generated text. Record transformations between source and output, including filters, calculations, mappings, and human edits.

Then ask what test represents the real failure. A citation check will not detect a wrong business rule. A numerical comparison will not test whether a recommendation ignored a stakeholder constraint. A policy review will not show whether the system exposed confidential data. Match each material failure to a verification method and evidence artifact.

The GAO AI Accountability Framework is organized around governance, data, performance, and monitoring for federal agencies and other entities. Its emphasis on accountability and documentation is useful for structuring questions, although the framework does not establish that a private organization has met its own obligations.

Sources: [2]

Who owns the decision, exception, and stop?

Create distinct fields for business ownership, technical operation, data authority, risk review, legal interpretation, and release approval. One person may fill several roles in a small team, but the responsibilities should remain visible. Ask who can grant an exception, what compensating evidence is required, how long the exception lasts, and who confirms closure.

Define stop conditions in observable terms: missing source authority, unresolved material discrepancy, prohibited data, failed access control, unacceptable error rate in a bounded test, or inability to reconstruct a decision. Include a safe fallback such as manual handling, delayed release, or narrower scope.

Worked artifact: a synthetic customer-credit memo

Imagine a synthetic finance team proposing AI assistance to draft a customer-credit memo. The governance question log records that AI may summarize approved account records and draft the memo, but may not approve a credit, change the ledger, or contact the customer. The controller owns release; data engineering operates the connector; finance policy defines permissible adjustments.

During testing, the model treats an unsigned sales note as authorization for a credit. The evidence question exposes that the note is contextual, not authoritative. The verifier checks the signed agreement and ledger, rejects the proposed adjustment, and records the contradiction. The stop condition prevents the draft from moving to approval until the source hierarchy is corrected.

The log retains the original proposal, authoritative sources, failed test, revised rule, named owner, expiry date, and re-test result. This synthetic example shows how questions become evidence. It does not demonstrate production control effectiveness, legal compliance, or a financial outcome.

When should the decision be reopened?

Ask what changes would invalidate the original reasoning: a new model, altered prompt or retrieval system, different data source, wider user group, new jurisdiction, increased autonomy, changed downstream decision, or repeated exception. Assign a review date and an event-based trigger. Monitoring should compare actual use with the approved action, not merely count logins or prompts.

Finally, ask what remains unknown. Preserve disagreement, missing tests, and unobserved behavior instead of converting them into a confident green status. Governance is stronger when decision-makers can see the limits of the evidence they are using.

These questions support disciplined, evidence-led review. They do not determine compliance, certify safety, or replace accountable specialists. Two Prune can observe how a participant handles evidence, uncertainty, verification, and escalation inside a bounded simulation. It does not operate customer controls or make employment decisions.