Key findings

• Choose one high-volume, reversible workflow with a named business owner.

• Measure the current process before buying or building anything.

• Keep consequential decisions and irreversible actions behind human approval.

• Define quality, cost, latency, privacy, and failure thresholds before the pilot.

• Scale only when production evidence beats the baseline without unacceptable risk.

Set the 90-day outcome before selecting technology

A useful 90-day target is not adopt AI or launch an agent. It is a business result attached to a bounded workflow, such as reducing the time required to classify inbound support requests while maintaining routing accuracy and escalation quality. Name one executive sponsor, one process owner, one technical owner, and the people who perform the work today. Record what the system may recommend, what it may change, and what it must never do autonomously.

Write a one-page charter with the problem, users, inputs, outputs, affected systems, expected volume, excluded cases, budget ceiling, and go-live decision date. Include a kill switch and an owner for incidents. NIST's AI Risk Management Framework is useful here because its Govern, Map, Measure, and Manage functions connect organizational accountability to use-case context, testing, and ongoing treatment of risk. Treat those functions as concurrent disciplines, not a sequence that ends at launch.

Days 1-15: discover the workflow and establish a baseline

Observe the real process rather than relying only on a procedure document. Sample completed cases, exceptions, rework, handoffs, waiting time, and the data employees copy between systems. Calculate a baseline using measures the team can reproduce: median handling time, error or rework rate, backlog age, percentage escalated, and cost per completed case. Separate time spent making a judgment from time spent moving information.

Score candidate workflows on value, feasibility, and risk. Favor repetitive work with digital inputs, stable rules, enough historical examples, and an easy way to undo mistakes. Avoid starting with hiring decisions, credit decisions, safety-critical advice, unrestricted financial transactions, or processes involving large amounts of special-category data. Confirm that an ordinary rule, form, integration, or search improvement would not solve the problem more reliably.

• Deliverables: process map, baseline dataset, candidate scorecard, data inventory, and risk tier.

• Gate: the sponsor approves one workflow and a measurable definition of success.

Days 16-30: design the minimum viable automation

Design the smallest end-to-end workflow that can prove value. Define every trigger, transformation, model call, tool call, human review point, system write, retry, and fallback. Use structured inputs and outputs wherever possible. Constrain the model to a narrow task, such as extracting fields into a schema or drafting a response from approved knowledge, rather than asking it to run an entire function.

Set acceptance criteria before implementation. Include task quality by important case type, maximum serious-error rate, latency, per-case variable cost, uptime, and review workload. Document permitted data, retention, provider use of prompts, regional processing, and access rights. Build a small evaluation set from representative historical cases, difficult edge cases, and adversarial inputs. Remove or protect personal data as required before using cases in development.

• Deliverables: workflow specification, permission matrix, test set, evaluation rubric, fallback path, and pilot plan.

• Gate: business, technical, security, and privacy owners approve the design.

Days 31-60: build and run a shadow pilot

Implement the workflow in a test environment with separate credentials and the minimum permissions needed. Start in shadow mode: the automation processes real or replayed cases but does not change production records or contact customers. Compare its result with the outcome produced by the normal process. Review failures by category instead of averaging them away. A system that performs well overall can still fail badly on a small, important slice.

Hold a weekly error review with the process owner and frontline users. Fix deterministic problems in code or workflow rules; do not use prompt changes as the answer to every failure. Version prompts, models, retrieval sources, tools, and evaluation sets. Track end-to-end cost and human review time, including the time spent correcting plausible but wrong outputs. The pilot should demonstrate operational value, not merely model fluency.

Days 61-75: harden security, privacy, and operations

Before any production action, test prompt injection, malicious documents, malformed inputs, unauthorized data requests, excessive tool use, retries, provider outages, and downstream API errors. OWASP identifies prompt injection, sensitive information disclosure, improper output handling, excessive agency, and unbounded consumption as core generative-AI risks. Enforce authorization in application code; never allow a model's text to grant itself access.

Add trace IDs, structured events, tool-call logs, latency and token metrics, quality samples, budget limits, and alerts. Redact secrets and unnecessary personal data from telemetry. Document manual operation, rollback, credential revocation, incident triage, and vendor escalation. Train reviewers on the limits of the system and require them to record reasons for overrides on high-risk cases so the business can distinguish model errors from unclear policy.

Days 76-90: release gradually and decide with evidence

Move from shadow mode to a limited production cohort. Keep the scope narrow by team, customer segment, case type, or percentage of traffic. Require human approval for external messages, deletions, payments, access changes, and other irreversible or consequential actions. Compare pilot cases with the baseline and, where feasible, a contemporaneous control group. Watch queue length and exception handling as closely as model accuracy.

At day 90, choose one of four outcomes: scale, continue a bounded pilot, redesign, or stop. Scale only if the workflow meets the pre-agreed quality and risk thresholds, delivers net value after review and platform costs, and has an accountable operating owner. A stopped pilot can still be a good result if it prevents a weak automation from becoming an expensive production dependency.

Use a compact scorecard for the scale decision

The final scorecard should show business value, user impact, system quality, risk, and operational readiness on one page. Include the baseline, pilot result, confidence or sample limitations, serious incidents, unresolved risks, total cost, and expected benefit. Avoid reducing the decision to one blended score; a critical privacy or safety failure should remain visible even when average productivity improves.

The reusable asset from the quarter is the operating method: a charter, risk assessment, evaluation set, permission design, observability pattern, and release gate. Apply that method to the next workflow only after the first has a stable owner and monitoring cadence. This prevents a small team from accumulating multiple fragile pilots that no one is equipped to maintain.

Sources and methodology

This article synthesizes the primary sources below as of the publication date. Forecasts and recommendations are directional scenarios, not guarantees; they should be tested against your workflow, data, risk tolerance, and current vendor documentation.

National Institute of Standards and Technology: AI Risk Management Framework (accessed 2026-07-30)

National Institute of Standards and Technology: NIST AI RMF Playbook (accessed 2026-07-30)

UK Department for Science, Innovation and Technology: Planning and preparing for artificial intelligence implementation (accessed 2026-07-30)

UK Government: Guidance on the Impact Evaluation of AI Interventions (accessed 2026-07-30)

OWASP Foundation: OWASP Top 10 for LLM Applications 2025 (accessed 2026-07-30)