← Writing
Running the program

The first ninety days of an AI program

A new AI leader should spend the first quarter on inventory, instrumentation, and one paved road, not on a flagship build. The organizations that start with a showcase spend the second year rebuilding it.

Korey Dillon · Fractional AI Executive · 2026 · 8 min · Share on LinkedIn

Most new AI leaders I have met inherit a mandate and a flagship. The board has seen a demo, someone senior is attached to a use case, and the first ninety days are expected to produce the thing in the demo, at scale, with a logo on it. I understand the pull. It is also the most expensive way to spend a first quarter, because a flagship built in a vacuum has no identity layer, no telemetry, and no owner, and all three get retrofitted in year two, in my experience at a cost that exceeds the original build. The first quarter is not for building the showcase. It is for building the road that the showcase, and the twenty workflows after it, will travel on.

Why the flagship arrives first

The flagship comes attached to the mandate because it is the only AI artifact the organization has seen with its own eyes. A demo is concrete and a road is not. Nobody on a board that I have seen has been moved by a gateway.

Here is what a flagship built in the first ninety days usually contains. It runs on whichever API key the prototype team happened to have, so every call looks like the same user. It logs whatever the framework logs by default, so when an output is wrong there is no trace to replay. It is sponsored, which is not the same as owned: the sponsor wants it to exist, and nobody has agreed to be paged when it misbehaves. Of the three gaps, the identity gap is the one I have watched teams declare unrecoverable and start over. The cloud era taught the same lesson. The organizations I watched let every team open its own account in year one spent year two on consolidation, tagging, and FinOps. The demo is a sunk cost that looks like an asset. The road is an asset that looks like overhead.

Weeks 1 to 2: inventory

Shadow AI is the default state, so the first two weeks are an inventory, not a kickoff. The question is not whether staff are using models. They are. The question is which models, with which data, paid for how, and the answers are in no system of record because nobody built one.

Three sources have given me most of it. Expense reports, because personal subscriptions to model products show up as small recurring charges on corporate cards and on reimbursement claims. Browser extension audits, if your endpoint tooling can produce one, because a meaningful share of the ungoverned use I have found runs through an extension that pastes page content into a model. And people, asked plainly and without threat. A message that says “we are building an approved path and want to know what you already rely on, and nothing you tell us will be used against you” produces a longer and more honest list than any scan I have run. Then keep the promise. The output is a plain table: tool, team, data class it touches, what it would cost to lose. That table tells you where real demand is, which is rarely where the flagship is.

Weeks 3 to 6: the paved road

The paved road is the smallest set of shared infrastructure that lets a team ship a workflow without negotiating risk from scratch. In my experience it has five parts, and none of them is a model.

Approved model access behind a gateway, with logging. Every call from every team goes through one door, which authenticates the caller, records inputs, outputs, latency, token counts, and model version, and issues a key per user and per workflow rather than per prototype. This is the identity layer and the telemetry layer in one component, and the identity half is the part I have not seen retrofitted.

A data-class map. Which classes of data may reach which model under which terms, decided once, written down, and enforced at the gateway where possible. The tenth team should not have to ask.

Cost attribution tags on every call. Tenant, workflow, step, and unit of work, so cost per outcome is a query and not a research project. Attribution is cheap on day one and almost never happens on day two hundred.

One evaluation harness. A shared way to run a fixed set of cases against a workflow and get a score, so a change can be gated and a regression can be seen. It does not have to be sophisticated. It has to exist and be the same for everyone.

A written escalation path. Who is paged, who can pull which lever, what is rolled back in what order. Written in week four, because during an incident nobody writes anything.

The temptation is to make the gateway a platform. Resist it. It is a door with a logbook.

Weeks 7 to 10: three workflows, three owners

With the inventory and the road in hand, pick the first three workflows. Not the flagship by default, and not thirty. Three is enough to learn from and few enough to own.

Two filters do most of the work. The first is the regime map from the two-number business case: where a step takes a person tens of minutes, value per dollar of run cost is high and the decision turns on adoption, and where a step takes a minute at high volume, run cost is the business case and a frontier model may not clear the 3x threshold I use as a working floor. Start in the first regime. The second filter is governance friction: how many approvals, which regulator, who signs. Low friction in the high regime is the corner to begin in, and it usually contains at least one workflow from the shadow inventory.

Then, before a line is written, assign a named production owner to each. One person, on the hook, with authority to change, roll back, or stop the system. Not a sponsor, not a steering committee. In engagements I have led, the owner who exists before the build pulls the rest of the checklist into the design, and the owner named at launch too often inherits a system they did not shape and quietly stops maintaining it. If nobody will own a workflow, that is the answer. Drop it and pick another.

Weeks 11 to 13: ship one, publish the numbers

Of the three, one ships inside the quarter. It is instrumented from the first call, because it rides the gateway, and that is what lets you do the thing almost no first quarter does: publish measured numbers instead of forecast ones.

Two numbers, with a band. Cost per unit of work, which is runs per unit times consumption per run times price, and which the attribution tags turn into a query. Hours returned, from timestamps on the residual human work, not from a survey of how people feel. Until telemetry gives you the real spread, a lopsided placeholder of 0.75x on the low side and 1.6x on the high side is more honest than a symmetric one, because per-run consumption in these systems has a long right tail and no matching left one. A few weeks of production data will start to make the band empirical, but the sample behind it will be small. Say so. A number with a stated band and a stated sample is credible in a way a point estimate is not.

The day-90 report

The temptation at day ninety is a strategy deck, and the organization will accept one. Do not give it one. The report that earns the second quarter fits on a page.

Two numbers and a band. Cost per unit, hours returned, and the band around both, for the one workflow that shipped, with the date range and volume they were measured on.

One owner per workflow. Three names next to three workflows, with the one that shipped marked and the two that are queued marked.

One paved road. What sits behind the gateway, which data classes are mapped, what the evaluation harness covers, and where the escalation path is written down.

A list of what was turned off. The shadow tools retired because the approved path replaced them, and the ones that were not, with the reason. This is the line I have seen boards remember, because it is the line that shows risk went down rather than up.

What not to do, and what does not transfer

Three patterns recur in first quarters that stall. A center of excellence with no deliverable, which produces standards nobody has tested against a shipped workflow. A vendor bake-off before a use case, which chooses a model before anyone knows which regime the work is in. A policy before a path, which bans the ungoverned tools without offering a governed one and so pushes the same usage out of sight. Each feels like progress because it generates documents. None changes what is running in production.

What I am less sure of is how the calendar transfers. In a small company the inventory takes an afternoon and the road may be one engineer’s week. In a heavily regulated one the data-class map can take the whole quarter, and the honest plan ships nothing in ninety days and says so up front. The ordering, inventory, then road, then owners, then one measured ship, is the part I would defend anywhere. The week numbers are a prior.

The first quarter is for the road, not the car. Build the car first and you build the road anyway, in year two, under traffic. Build the road first and the cars arrive on their own.

Related: Governance is the strategy, not the checkbox and The business case for AI has two numbers.