How to Implement AI in Your Business: A 90-Day Operator’s Plan

The fastest way to waste money on AI is to begin with a tool. The better starting point is a recurring business problem that already has an owner, a measurable cost, and enough volume to justify changing the workflow.

I use a 90-day structure because it is long enough to produce operating evidence and short enough to force decisions. The objective is not to prove that AI works in general. It is to determine whether a specific new way of working should be scaled, revised, or stopped.

Before day one: choose the right workflow

List recurring workflows that create visible friction: slow response, repeated data entry, inconsistent quality, avoidable rework, long queues, missed follow-up, or knowledge trapped in a few employees.

Score each candidate from 1 to 5 on:

• Business impact: revenue, cost, capacity, quality, risk, or customer experience
• Frequency: how often the workflow occurs
• Data readiness: whether representative inputs and outcomes are accessible
• Reversibility: how easily a human can detect and correct an error
• Adoption fit: whether the affected team sees the problem and wants it solved

Start with a high-impact, frequent workflow where errors are visible and reversible. Avoid using the first pilot to make consequential employment, credit, medical, safety, or legal decisions.

Write a one-page charter containing the problem, owner, users, baseline, target, data boundaries, maximum budget, deadline, and stop conditions.

Days 1–15: observe and measure the current process

Do not automate a process nobody has watched closely.

Sit with the people who perform the work. Record the real steps, including workarounds, approvals, duplicate entry, exceptions, and the moments when judgment matters. The documented procedure and the actual workflow are often different.

Measure a representative baseline:

• Volume per week
• End-to-end cycle time
• Active labor time
• Error, rework, and escalation rates
• Customer or employee wait time
• Current direct and indirect cost
• Quality or conversion outcome

Separate routine cases from exceptions. AI often performs well on the middle of a distribution while the business risk lives in the edge cases.

By day 15, the owner should be able to state: "We currently process X items, spend Y hours, achieve Z quality, and experience these three important failure modes."

Days 16–30: design the future workflow

Decide what the AI will and will not do.

Use four roles:

1. Draft: AI creates a first version; a person decides
2. Recommend: AI ranks or suggests; a person chooses
3. Execute with approval: AI prepares an action; a person authorizes it
4. Execute within limits: AI acts only inside explicit boundaries with monitoring and reversal

Most first projects should begin in the first two roles. Autonomy is not a maturity badge; it is a risk decision.

Map the future workflow from input to outcome. Mark data sources, permissions, human decisions, quality checks, exception paths, logs, and fallback steps. Assign one business owner and one technical owner.

Define success before configuring a product:

• One primary business metric
• Two or three operating metrics
• Quality thresholds that cannot be traded away for speed
• Adoption criteria
• Cost ceiling
• Stop conditions

Days 31–45: select and configure the solution

Decide whether to use a feature already available in your core systems, a focused vendor, a general-purpose AI platform, or a custom integration.

Buy when the workflow is common and speed matters. Build when proprietary data or a distinctive process creates real competitive value. Use a hybrid approach when a general model can be combined with your permissions, data, workflow, and controls.

Evaluate vendors against the actual charter, not a generic feature list. The 27-question AI vendor scorecard covers business evidence, data rights, security, total cost, governance, adoption, and exit risk.

Keep the initial configuration narrow. Use representative but limited data, least-privilege access, named testers, and a rollback plan. Record the model, prompts, retrieval sources, settings, integrations, and approvals needed to reproduce the test.

Days 46–70: run a controlled proof of value

Run the old and new workflows in parallel where practical. Sample outputs systematically rather than relying on memorable successes.

Track:

• Business result versus baseline
• Time saved at each step
• Error types and severity
• Human corrections and overrides
• Performance on exceptions
• Employee adoption and workarounds
• Customer impact
• Full operating cost

Create an error taxonomy. "The AI was wrong" is not diagnostic enough. Distinguish missing context, incorrect facts, inappropriate tone, flawed classification, stale source information, permission failure, unsafe action, and workflow mismatch.

Meet weekly with the people doing the work. Ask what they stopped using, what they double-check, where the system creates new work, and which suggestion they ignore. Adoption problems are operating evidence, not resistance to be managed away.

Days 71–80: red-team the workflow

Test how the system behaves when inputs are incomplete, contradictory, adversarial, unusual, or sensitive. Verify access boundaries and attempt prohibited actions. Test the manual fallback.

For generative AI, evaluate unsupported claims, source fidelity, data leakage, prompt injection, inappropriate content, and overconfident language. The NIST Generative AI Profile provides a useful risk reference.

Involve security, privacy, legal, compliance, HR, or safety specialists in proportion to the consequences of the use case.

Days 81–90: make a real decision

End with one of four decisions:

• Scale: evidence met the thresholds and controls are ready
• Revise: value is plausible, but a defined gap requires another time-boxed test
• Pause: dependencies or risk make the timing wrong
• Stop: evidence does not justify further investment

The decision memo should compare results with the original baseline, show total operating cost, summarize error patterns and user feedback, state unresolved risks, and name the next accountable owner.

Do not call a pilot successful because people liked the demonstration. Do not call it unsuccessful because it failed to reach production. A stopped project that prevents a bad multi-year commitment created value.

What scaling actually requires

Scaling means more than buying more seats. It requires production-grade identity and permissions, data pipelines, monitoring, support, training, change control, vendor management, incident response, financial ownership, and periodic revalidation.

Scale in stages. Expand to the next team or volume band only after the prior stage remains within quality, cost, and risk thresholds.

Document the operating system:

• Who owns the business result
• Who owns technical reliability
• Who reviews quality and exceptions
• Who approves material changes
• Who can pause the system
• Which metrics are reviewed and how often

The operator's rule

AI implementation should make a workflow observably better. If the team cannot identify the baseline, the changed behavior, the responsible owner, and the evidence, it does not yet have an implementation—it has an experiment.

Start smaller than the excitement suggests. Measure more than the demo reveals. Make it easy to stop. Then scale only what earns the right.