A compliance analyst asks AI to summarize an evidence pack. The summary reads well, so it moves into a management report. A qualification disappears along the way: the documents cover only one business unit. The report now sounds like an organization-wide conclusion.
The problem began before the wording. Nobody defined what the output was allowed to support.
For GRC professionals, useful AI adoption starts with a bounded task and a decision owner. The practical question is: What may this system prepare, and what evidence is needed before anyone relies on it?
Start with the work product
Choose an output you already understand: an evidence index, a policy comparison, a draft issue summary, or a list of questions for a control owner. Specify who will use it and what they will do next.
“Help with compliance” leaves too much open. “Compare these two approved policy versions and identify changed responsibilities, with section references” gives the reviewer something testable.
NIST describes its AI Risk Management Framework as voluntary guidance for incorporating trustworthiness into AI design, development, use, and evaluation. It does not make an individual workflow compliant simply because the team references it. NIST AI RMF
The operating pattern below is an editorial recommendation for practitioners. Adapt it to your organization’s approved tools, obligations, and decision processes.
Write a small task agreement
Before the first run, capture six things:
- Purpose: the specific work product and intended audience.
- Inputs: approved source documents, versions, scope, and relevant dates.
- Data boundary: what information the selected environment may process.
- Authority: what the assistant may draft, retrieve, or change.
- Acceptance: what a reviewer must check before using the result.
- Record: where the accepted output and its supporting references belong.
This can fit in a short task brief. Its value comes from resolving ambiguity, not its length.
For a draft policy comparison, authority might stop at producing a table. Editing the policy, changing the control register, or notifying an owner would require separate authorization in the workflow.
Keep the authoritative record identifiable
An AI conversation is a working surface. Decide which repository holds the approved policy, obligation, workpaper, or incident record.
Give the assistant the relevant version rather than asking it to remember an earlier upload. Require source references that a reviewer can actually open. A citation to the wrong document version can look reassuring while supporting the wrong conclusion.
Preserve the source scope in the output. A summary based on one region, system, or time period should carry that boundary into the accepted record.
Design review around consequences
A draft heading and a proposed control conclusion deserve different scrutiny.
For a low-impact formatting task, a quick check may be enough. For a statement used in audit reporting, the reviewer should verify supporting evidence, limitations, and the reasoning that connects them. If the reviewer cannot access the underlying material, the workflow is not ready for that use.
“Human reviewed” is too vague to be an acceptance rule. Specify what the person checks and what causes rejection: unsupported conclusions, missing sources, changed scope, or unresolved contradictions.
Try it on a realistic task
Consider this illustrative example: a compliance team needs a summary of changes between two approved internal policies.
AI prepares a table of changed responsibilities. A reviewer checks each entry against both versions, adds a responsibility the model missed, and rejects a suggested implementation deadline that appears in neither document. The accepted table goes into the controlled change record with its source versions and reviewer decision.
The team has used AI to prepare a comparison. It has not demonstrated that the revised policy is legally sufficient, implemented, or effective.
A reusable instruction for that task is:
Compare only the two supplied policy versions. Identify changes to responsibilities, scope, timing, and required evidence. For each change, provide the old and new section references and a concise explanation. Separate explicit changes from possible implications. Mark missing or conflicting information. Do not invent deadlines or determine legal sufficiency. Return a draft for review.
These instructions help define the task. They do not replace access controls or prevent every error.
Count the review cost
The strongest objection is practical: if a reviewer must rebuild the output to trust it, the AI workflow may create more work.
Compare total effort: preparing inputs, generating the draft, checking it, correcting it, and recording the result. Track material errors and omissions alongside time. A fast draft with expensive corrections is not automatically a productivity gain.
For repeatable rules, a spreadsheet formula or deterministic check may be the better choice. For ambiguous synthesis, a carefully bounded AI draft may be worth testing.
Make the next use easier
Keep a reusable context package containing the approved task brief, source selection rules, output format, and examples of rejected answers. Include an owner and a review date so yesterday’s instructions do not quietly become permanent.
Share what failed as well as what worked. “The summary dropped a scope limitation” is more useful learning than “the prompt was good.”
Start with one recurring GRC task this week. Write its task agreement, test it on approved material, and compare the full review effort with your existing method. Expand only when the result is useful and inspectable.