By now you have the components of a practical AI program: a defined job, dependable sources, clear instructions, review criteria, bounded permissions, a cost model, a policy, and a recovery plan. The next decision is where to put them to work together.
Choose one workflow with an owner and a measurable business purpose. Give it a staged ninety-day plan. Progress should depend on evidence and permission, with dates providing review points rather than automatic authorization to expand.
Your deliverable is a plan that ends with a documented decision: expand, continue at the present scope, improve and retest, or stop. All four can be responsible outcomes. Buying more seats or adding more autonomous actions is not the definition of success.
NIST's management playbook describes ongoing monitoring, feedback, incident handling, change management, and continual improvement after deployment. The ninety-day sequence below is this guide's practical planning structure, not a schedule prescribed by NIST. NIST AI RMF Playbook: Manage
Start with one sentence you can evaluate
Write the business purpose without mentioning a product: “Help the coordinator prepare accurate inspection-fee answers for review while preserving unknown appointment availability.” Then identify the finished work, eligible requests, permitted sources, excluded actions, and person accountable for the result.
For fictional Mesa, this points toward a bounded drafting and review workflow. It does not establish that a real Mesa pilot exists. The examples in this guide are teaching fixtures, and the local automation is not ready-made production infrastructure.
List the assumptions that could overturn the proposal. Perhaps the task volume is too low to justify administration. Perhaps the existing helpdesk already solves the problem. Perhaps review takes longer than manual drafting. The plan should collect evidence about these possibilities early enough to change direction.
Name a manual alternative. A workflow needs a credible comparison and a fallback. Improving a source document or standard reply may deliver much of the desired benefit before any integration is necessary.
Put dates on the reviews, not on permission
The companion plan starts on September 14, 2026. Counting that date as day one, day thirty is October 13, day sixty is November 12, and day ninety is December 12. These are proposed planning dates, not scheduled meetings or completed work. Ninety days is not exactly thirteen weeks.
| Period | Main question | Required work product |
|---|---|---|
| Days 1–30 | Can we define and prepare a worthwhile, permitted pilot? | Scope, baseline method, policy, vendor evidence, evaluation and recovery plans |
| Days 31–60 | Does the authorized bounded workflow meet its conditions in use? | Complete work log, quality review, cost record, feedback, and observed recovery evidence |
| Days 61–90 | What should change based on the evidence? | Decision record and a controlled expansion or improvement proposal |
If a necessary owner, access control, or approval is missing on day thirty, the pilot does not start merely because day thirty-one arrives. Record the blocker, continue useful preparation, and revise the schedule. Preserve the actual dates so later reporting does not imply that a delayed or shortened pilot had the originally planned exposure.
Days 1–7: Choose the workflow and its owner
Review a small set of candidate jobs using the prioritization method from the earlier chapters. Consider task frequency, source readiness, consequences of error, measurable value, and the effort needed to operate the workflow. Do not choose solely because the demonstration is impressive.
Assign a business owner and identify the people doing, reviewing, and supporting the work. Ask them where time goes and which exceptions create trouble. Use real consultation for a real plan; the constructed staff examples in this guide are not evidence that your employees have been consulted.
Produce a one-page charter. Include the problem, intended result, task boundaries, data categories, expected volume, decision rights, evaluation period, and stop conditions. Mark estimates as estimates and record the source of each important assumption.
A solo operator can own several responsibilities, but review capacity still matters. Limit the task or obtain appropriate independent help when the consequences exceed what one person can reliably assess.
Days 8–14: Prepare sources and the comparison
Make the source pack usable before optimizing the prompt. Remove superseded material from the permitted retrieval set, assign document owners, preserve unresolved questions, and establish how updates reach the workflow.
Define acceptance criteria with examples of complete, incomplete, and unacceptable work. Include realistic exceptions such as missing information, conflicting records, a request outside scope, and an instruction embedded in source content that should not gain authority.
Prepare a manual baseline method and the complete effort log. Specify the unit of work, observation window, exclusions, correction effort, maintenance allocation, and customer outcome if relevant. Keep baseline observations blank until they are collected.
Select a budget scope: setup, training, recurring software, usage, integration, review, and support. Internal time value and cash outlay should remain separate. Use your actual prices and constraints when available; the guide's teaching assumptions are not a budget for your business.
Days 15–30: Close the conditions for a pilot
Complete the workflow register and vendor evidence review from Chapter 37. Confirm the actual workspace, account settings, data permissions, reviewer authority, escalation route, and retention arrangements. A policy draft becomes operational only through the organization's actual decision process.
Test the proposed workflow against its evaluation cases in an appropriate environment. A model-assisted version needs observations of that model's outputs; the Part 9 fixed-template tests cannot supply them. An integration needs checks of its real identity, record scope, action controls, and failure behavior.
Prepare the continuity runbook and perform the level of recovery testing required by the proposed dependency and risk. A tabletop can identify missing steps, but it cannot substitute for an export and restoration test when recoverability is an essential condition.
At the day-thirty review, record a specific decision. If approved, state the allowed task, users, data, volume, duration, review requirements, spending limit, and stop conditions. If not approved, state what remains unresolved. Neither this chapter nor the companion checklist records a real approval.
Days 31–45: Operate within the approved boundary
Begin only after the required conditions are satisfied. Keep the initial workload small enough for the actual review team to inspect and support. Count all eligible work, including requests left on the manual path and reasons for exclusion.
Record the source and configuration version used for each evaluation period. When a material change occurs, note it so the results can be interpreted. Avoid silently mixing a revised prompt or model with earlier observations under one undifferentiated average.
Review errors and exceptions promptly. A serious permission failure or unsupported external action needs the response specified in the pilot agreement, even if average acceptance looks strong. Staff should have a usable way to pause and escalate without first diagnosing the entire system.
Collect practical feedback: unclear instructions, repeated corrections, inaccessible source material, and work shifted onto another person. Ask whether the assistant makes the finished job easier, not just whether people enjoy trying it.
Days 46–60: Decide whether the evidence is adequate
Update the impact scorecard with the full effort and cost scope. Separate observed results from assumptions, unfinished cases, and outcomes that need a longer observation window. Investigate missing records before interpreting a favorable percentage.
Compare quality and effort for equivalent work where the evidence allows it. Document any differences in task mix, staff experience, or operating conditions. If the baseline is weak, say so and improve it; do not fill the gap with a vendor benchmark.
Examine the economics at the proposed next volume. Additional usage may require more review, another plan, support coverage, or a more capable integration. A favorable result at one volume does not automatically establish a favorable result at another.
The Chapter 38 constructed example shows why this matters: eight minutes of modeled capacity coexist with a negative two-dollar provisional recurring resource result after the specified software allocation. That example supports a lesson about accounting, not a recommendation to expand Mesa's workflow.
At day sixty, identify the evidence that supports continuation and the uncertainty that limits it. A short pilot may justify continued learning while remaining insufficient to establish long-term customer or financial outcomes.
Days 61–75: Propose one controlled change
If the gates are met, choose the next change deliberately. You might increase eligible volume, add trained users, improve source coverage, or test a related task. Each has different implications for permissions, review capacity, and evaluation.
Avoid changing the task, model, source pack, integration, and action authority together unless the redesign requires it and the evaluation accounts for those changes. Smaller changes are often easier to diagnose and reverse.
Treat greater action authority as a distinct proposal. Permission to draft does not become permission to send because the drafts usually look good. Define the exact new action, approval requirements, record scope, uncertain-outcome handling, and recovery method before any such expansion.
Update the policy register, operating instructions, and training examples with the approved change. Check that the backup person can explain the new boundary. If the main owner is unavailable, the workflow should still have someone capable of stopping it and interpreting its records.
Days 76–90: Make the decision and leave a usable record
Prepare a short decision memo with the original purpose, actual scope and dates, sample and exclusions, quality results, complete effort, specified costs, customer or staff outcomes, incidents, and recovery observations. Include the material unknowns.
State the decision and why it follows from that evidence. For expansion, specify what is newly allowed and what must be checked after the change. For improvement, identify the defect and the next test. For stopping, preserve necessary records, remove access appropriately, and return work to the manual process.
Assign the next review date and change triggers. Ownership, vendor terms, source policy, model behavior, and business volume can all change after day ninety. Keep the operating documents connected to the workflow people actually use.
Finally, assemble the capstone pack: charter, source register, task instructions, acceptance rubric, authority record, evaluation evidence, impact scorecard, policy and vendor review, continuity runbook, and decision memo. A folder full of templates is a preparation milestone. A usable business process requires completed evidence and accountable decisions.
You have now reached the end of the forty-chapter core guide. Return to the guide hub to choose the chapters and working tools relevant to your next job. Start with one concrete business problem, keep the boundaries understandable, and let the quality of the finished work determine what you do next.