Find the interruption that already has a cost
Start where work waits for a person to search several systems, interpret an old rule, or repeat an answer that lives in one colleague's memory. Write the question in the language employees use and record how often it appears, who handles it, how long the route takes, and what happens when the answer is late or wrong.
Frequency creates enough cases to learn. Consequence gives the work a reason to matter. A daily question with no meaningful effect may not justify implementation, while a rare high-stakes decision may remain better as careful manual work.
The baseline should follow the problem: active work, elapsed wait, rework, escalations, missed commitments, or correction effort. Counting generated answers will not show whether the workflow improved.
Compare candidates by readiness, not excitement
The strongest first candidate usually has a smaller evidence boundary than the team expects. Two approved systems with clear owners are easier to govern than every document and message the company has produced. A narrow source set also makes missing, stale, and contradictory cases visible.
Name the decision owner and the next action. An answer that proposes one CRM field update or prepares one approval request is testable. An instruction to manage the account is not.
| Factor | Stronger first candidate | Warning |
|---|---|---|
| Frequency | Enough cases to compare with a baseline | One unusual case drives the whole design |
| Consequence | A reliable answer changes time, risk, cost, or service | The result is interesting but not used |
| Evidence | A bounded set of named sources and owners | The workflow needs every shared drive and inbox |
| Ownership | One role can judge the result | Several teams disagree about the correct route |
| Action | Specific, reversible, and easy to verify | Broad authority or several write systems are required |
Write the failure behavior before the build
List what should happen when evidence is missing, stale, contradictory, or restricted. Add a revoked user, an unavailable approver, a hostile instruction inside a retrieved record, and a destination that rejects the write. Write the expected state for each case.
The NIST AI Risk Management Framework organizes work around govern, map, measure, and manage. For a first workflow, that means the test should reflect the actual use, consequence, and operating owner rather than copying a generic checklist.
Keep the manual route during the pilot. It supplies a comparison and a fallback while the team learns where the evidence and exceptions are less stable than expected.
- Known current answer with direct evidence
- Missing fact that should stop the answer
- Two approved sources that disagree
- Restricted source requested by the wrong role
- Unavailable approver or rejected action
- Destination failure after approval
Scale only when the operating burden is understood
Compare the new route with the baseline. Include review time, exception handling, correction effort, source maintenance, and the cost of keeping the connector healthy. A faster answer that moves review to a more expensive owner may not be an improvement.
Expand when the useful outcome repeats, exceptions remain manageable, owners can operate the controls, and the next workflow reuses a real part of the foundation. Stop or simplify when source ambiguity, review load, or maintenance erases the benefit.
Use the readiness assessment to compare a candidate's question, source, permission, owner, action, and assurance foundations before implementation.
Sources and verification
Primary product, architecture, risk, and security sources checked on 29 August 2026. Product behavior can change, so verify current plan and admin documentation before implementation.
- AI Risk Management FrameworkNIST
- AI for small businessU.S. Small Business Administration
- LLM Prompt Injection PreventionOWASP