Start with the workflow, not the tool
A sensitive workflow is one where an error, disclosure or unfair outcome could meaningfully affect someone. Examples include handling private customer messages, drafting responses to complaints, reviewing job applications or preparing material that others may rely on. Before choosing an AI tool, write down the task you want it to perform. Be specific: “summarize messages for a staff member to review” is a different use from “decide which messages need no reply.”
Map the steps from input to final action. Note who supplies the information, what the AI receives, what it produces, who checks the result and what happens next. This makes an important distinction visible: an AI system might help prepare a draft without being allowed to make or communicate a decision. If you cannot describe where human responsibility sits in the workflow, pause before introducing AI.
Identify what could be exposed or harmed
List the types of information the workflow handles. Look beyond names and contact details: a message may reveal a person’s circumstances, an organization’s plans or information someone shared with an expectation of confidentiality. Ask whether the task requires that information at all. Removing identifiers, using an invented example or working from a short extract may allow you to test a use case without submitting sensitive material.
Then consider the people affected by the output. Could a mistaken summary omit an urgent request? Could an unsupported statement damage trust? Could inconsistent treatment disadvantage some people? Consider both routine mistakes and plausible misuse, such as a user pasting information they should not share. You do not need to predict every outcome. The aim is to find the failures that would matter most and the points where they could enter the workflow.
Check the tool and test realistic failures
Before entering sensitive information into a tool, check the settings and terms available to your team. Find out who can access submitted data and outputs, whether information is retained, what controls exist for deletion and whether the tool may use inputs for other purposes. If those answers are unclear or unsuitable for the material involved, do not assume the tool is safe because it is convenient. Choose a different method or keep the task outside the tool.
Test the proposed workflow with examples that resemble real work but do not expose private information. Include straightforward cases and difficult ones: incomplete instructions, ambiguous wording, conflicting details and content that asks the AI to ignore its assigned task. Check for omissions, invented details, inappropriate confidence and changes in meaning. A successful demonstration shows that a tool can help on those examples; it does not prove that it will handle every future case reliably.
Choose safeguards that match the consequences
For each significant failure, decide what would prevent it or catch it before harm occurs. Possible safeguards include limiting what information is submitted, restricting who can use the workflow, requiring a reviewer to compare outputs with the original material and preventing the AI from sending messages or changing records on its own. Make the review meaningful: a person who sees only the AI’s summary may not be able to spot what it left out.
Set a clear boundary for use. For example, the AI may draft a response, but a staff member must verify factual claims and approve it before sending. Decide what happens when the tool expresses uncertainty, produces inconsistent answers or encounters a case outside the agreed scope. A manual route should remain available when review is not possible or the potential consequences exceed what your safeguards can reasonably address.
Record a decision and revisit it
Keep a short record of the task, data involved, people affected, main failure modes, test cases, safeguards and person responsible for approving use. Then make an explicit decision: proceed with a limited trial, change the design or do not use AI for this task. You do not need a precise risk score to recognize that an unreviewed output affecting a person deserves more caution than an internal draft with no sensitive inputs.
If you proceed, start within a narrow scope and give users a way to report errors or unexpected behavior. Review examples of completed work, including cases that needed correction, and check whether people are following the agreed process. Reassess when the tool, inputs, users or consequences change. Risk assessment is not a promise that nothing will go wrong; it is a way to make the decision deliberate, keep responsibility visible and respond when the workflow falls short.
