What happens after AI consulting ends?

The failure most companies never plan for is not a project that goes badly. It is a project that goes well and then quietly stops mattering.

Six months after the consultant leaves, the roadmap is in a shared drive nobody opens, the one thing that got built is still running but nobody has looked at its output since spring, and the person who understood it has changed roles. Nothing broke. It just drifted.

The two ways an engagement ends

With a document. You have a diagnosis and a priority order and nothing built. Perfectly legitimate, and the risk is obvious: a roadmap that is not executed is an expense, not an investment. If you buy this, agree who owns execution and by when, before the final invoice.

With something running. Better, and it introduces a different problem. Live automation is an operational responsibility now, and responsibility without an owner decays.

Drift is the real enemy

Nothing dramatic happens. Several small things do.

Your business changes. You add a service line, drop a product, change your hours, start covering a new area. The automation still confidently answers according to what was true in July.

Your systems change. A tool you integrated with updates its interface, a field gets renamed, someone reorganizes a folder structure. Some of this breaks loudly and some of it breaks silently, and the silent kind is worse because the thing appears to work while producing subtly wrong output.

Your people change. The person who understood how it worked moves on, and their replacement inherits a system nobody can explain.

The models change. What you built on gets updated or deprecated, and behavior shifts underneath you.

None of that is a defect in the original work. It is the normal condition of anything in production, and the mistake is treating a build as finished.

Four things that decide whether it survives

A named owner. One person, by name, accountable for each live automation. Not a committee and not "the ops team". The single strongest predictor of whether something is still working next year.

A number someone looks at. If nobody checks the output, you will not notice degradation for months. Pick one metric per automation and put it in front of whoever owns it, on a schedule. Measurement has to be designed at the start or it never happens.

Documentation aimed at a stranger. Sufficient for somebody who has never met the builder to understand what runs, when, and what to do when it stops. Make a payment milestone depend on this, because it is the most promised and least delivered item in this business.

A decision about who maintains it. Three honest options, and all of them are fine as long as you have chosen one.

The three maintenance models

You run it. Cheapest and requires a technical person who has capacity and will still be there. Works well when the automation is simple and internal. Fails when the person leaves.

They run it. A retainer or managed arrangement. You give up some control and get somebody whose job it is to notice. Sensible for anything customer-facing, because those failures are the expensive kind. Watch that the retainer stays justified: put a review date in the agreement and honor it, since these decay into nobody remembering what they are for.

Nobody runs it. The default when no decision is made, and it is a real choice with real consequences. Acceptable for something small and internal. Not acceptable for anything a customer touches.

Choose deliberately. The worst outcome is assuming the vendor is watching while they assume you are.

Turning the engagement into internal capability

The best possible outcome and it does not happen by accident.

Have somebody on your team present through the build rather than briefed afterward. Have them do the second automation with support instead of watching the first one being done for them. Ask for the configuration and the reasoning, not only the working system.

Firms differ on how much they want this, and how a vendor reacts to the request is informative. Somebody whose model depends on you never learning anything will resist it politely.

What to agree before the last invoice

Who owns each live thing. What the review cadence is. Where the documentation lives. What happens when something breaks, who is called, and whether that is billable. What you receive if you part ways, in what format, at what cost. And a date, three months out, when somebody checks whether any of this is still true.

That last one costs nothing and it is the item that most often saves the work.

How we handle it

We run what we build when clients want that, because customer-facing automation genuinely needs somebody watching and most small companies do not have a spare technical person. We also hand it over when that is the better arrangement, with the configuration in readable form and the accounts in your name, and we would rather set that up at the start than argue about it later.

The roadmap is yours regardless. How the engagement works, and how to keep the exit clean if you want the contractual side.