Operations
The first 100 days after an AI rollout
The first 100 days after launch decide whether an AI system becomes part of how the company works or quietly fades into a tab nobody opens. Treat launch as the start of operations: stabilize first, measure honestly, then expand.
Why the first weeks decide so much
Most rollout plans end at launch day. The system is deployed, the training session is held, and the project team moves on. Then real work begins: users find edge cases, volumes shift, a data source changes format, and the model behaves differently on inputs nobody tested. The operators who do well treat the first 100 days as a defined phase with an owner, a cadence and a short list of questions.
Days 1 to 30: stabilize
The goal is not improvement. It is predictability.
- Name one owner. One person has authority over the workflow and a direct line to engineering.
- Watch the queue daily. Read a sample of outputs yourself, including the ones that were accepted without edits.
- Log every override. When a person corrects or rejects the system, record why. This is your most valuable data.
- Set a rollback rule. Decide in advance what error level sends work back to the manual process, and who may call it.
- Expect shadow work. People often keep doing the task the old way in parallel. Ask why; the answer points to a gap.
Days 31 to 60: measure
Now you have enough volume to see patterns. Establish a baseline that does not depend on anyone's impression: how long a unit of work took before, how long it takes now, how often a person had to step in, and what it costs including compute and review time. We discuss the pitfalls in measuring AI ROI without vanity metrics.
A frequent surprise is that adoption dips after the first burst of curiosity. That is normal. The question is whether the dip recovers once the system proves reliable on the dull cases.
Days 61 to 80: fix the workflow, not just the model
Most improvement now comes from the process around the system. Look at the top three reasons for overrides. Often they are not model errors at all. They are unclear inputs, missing context, or a downstream step that expects a different format. Fix those before asking for a better model. Update instructions, change forms, adjust the review step. Each change should be small enough to attribute.
Days 81 to 100: decide on expansion
By now you should be able to answer four questions with evidence rather than opinion.
| Question | Evidence to look for |
|---|---|
| Is it reliable? | Stable error rate over several weeks, not one good week |
| Is it used? | Consistent use by the people it was built for |
| Is it cheaper or faster? | A measured change against the baseline, net of review and compute |
| Is it ready to widen? | Documented handling of exceptions and a trained second owner |
If the answers are mixed, extend the stabilization phase. Expanding a shaky workflow multiplies its problems.
Lessons operators repeat
Three lessons come up often. First, the dull cases matter more than the impressive ones, because they are most of the volume. Second, people trust a system that explains its limits and distrust one that never admits doubt. Third, cost drifts. Usage grows, prompts lengthen, and a workflow that looked cheap in week two can look different in week twelve unless someone watches it.
A hypothetical week-six check
Hypothetical example, for illustration only. A services company launched an AI drafting tool for client reports. At week six, the owner reads twenty accepted drafts and finds that reviewers approved most of them with almost no edits, including two with a wrong figure. Usage looks healthy, but quality checks are thin. The owner adds a short checklist for reviewers, introduces a spot audit of accepted drafts, and tracks the number of corrections found. Usage dips for two weeks as reviewers slow down, then recovers, and the error rate falls.
The dip was the cost of finding a problem that high usage had hidden.
Communicating with the team
Tell people what you are learning. Share the override log in summary, thank the reviewers who found problems, and show what changed because of their input. A system that is visibly improving earns patience. A system that feels imposed earns workarounds. Keep leadership updates short and honest, with the baseline, the current figure and the next decision.
Plan for change
Models, vendors and inputs change during these months. Pin the version in use, test any update against your sample before it goes live, and keep a short change log. Surprises in a live workflow are rarely caused by a single dramatic failure; they are usually small shifts nobody wrote down.
What to ask
If you own or oversee a company that has just rolled out an AI system, ask your team five things. Who owns it today? What did people override last week, and why? What is our rollback rule? What does one unit of work cost now compared with before? And what would make us pause expansion? If any answer is slow to arrive, that is where the first 100 days should start. Our guidance for owners covers how we think about this work alongside operating teams.
This article is for general information only and is not investment, legal, tax or accounting advice.
FAQ
Frequently asked questions
Why 100 days?
It is long enough for usage patterns and failure modes to appear, and short enough to keep urgency. The number is a convenience, not a rule.
Who should own the system after launch?
One named operator with authority over the workflow, supported by engineering. Shared ownership usually means no ownership.
What is the most common failure?
Declaring success at launch, then losing attention before the first real problems appear.
Contact
Building, running or selling an AI-native business?
Tell us a little about it. We aim to reply within two business days.