What a 90-Day AI Stabilisation Actually Looks Like

The engagement started with a message that went roughly: we have AI everywhere and it's not working. Come and fix it.

That description, frustratingly common right now, covers a wide range of actual situations. Sometimes it means a business that bought several AI tools, none of which were implemented properly, and is now paying for subscriptions that nobody uses. Sometimes it means a business that built something internally, got it working well enough in a demo, and then watched it degrade in production until it was causing more problems than it solved. Sometimes it means a business where individual teams went off and implemented their own AI workflows, and nobody has a clear picture of what's running, what it's doing, or what happens when something goes wrong.

This particular engagement was the third type, with elements of the first two.

What follows is an anonymised account of a ninety-day stabilisation: what the situation looked like at the start, the sequence of work that brought it under control, and what the business looked like at the end of the engagement. I'm sharing it because the pattern repeats, and because the honest version of this story is more useful than the polished retrospective.

Day One: What We Were Actually Dealing With

The business operated across multiple brands in a services context. Revenue was healthy. The team was small and capable. The CEO had made a genuine commitment to AI adoption eighteen months prior, which meant that by the time I arrived, there was a lot of AI activity, most of it ungoverned.

A rough audit of the first week found: six active AI tool subscriptions across the organisation, three of which overlapped significantly in capability; two internally-built automation workflows that were running in production with no documentation, no error handling, and no monitoring; one AI-assisted customer communication process that had been partially automated by someone who had since left the business; and a general absence of clarity about who owned any of it.

The immediate risk was not that things were broken, although some things were close to breaking. The immediate risk was that nobody had a clear mental model of the system. When something went wrong, which it would, there was no obvious person to call and no obvious place to look.

The first conversation with the CEO was about scope. Not what we were going to build, but what we needed to stabilise before we built anything else. This is usually an uncomfortable conversation because it involves delaying the exciting work in favour of the unglamorous work, and the person who brought you in usually wants to see progress on the exciting work quickly. The honest case for doing it this way is that progress on an unstable foundation is not progress. It is debt that compounds.

To the CEO's credit, she understood this immediately.

Weeks One to Three: Getting Visibility

You cannot fix what you cannot see. The first priority was building a clear picture of every AI system and process in the business, how it worked, what data it touched, who depended on it, and what failure looked like.

This sounds like documentation work, and it partly is. But the more important output is a dependency map: which things break if a specific component fails, which human processes have quietly become dependent on an AI output that was never designed to be critical, and where the data flows in ways that nobody intended or planned for.

In this business, the dependency audit surfaced two significant issues that were not visible from the outside. The first was that a key client reporting process had been quietly augmented by an AI summary step that someone had added as a personal efficiency tool. It had become load-bearing without being acknowledged as such. If the API it called had changed or the account had lapsed, a client deliverable would have failed, and nobody except the person who built it would have known why.

The second was that customer data was passing through three different AI tools in ways that were not reflected in the privacy policy or the terms of service. Not a deliberate decision: a series of individually reasonable choices that collectively created an exposure nobody had thought about.

Both of these were fixable. Neither was pleasant to find.

The output of weeks one to three was a single document: a clear map of every AI system, its inputs and outputs, its dependencies, its owner, and its current status. Boring to produce, invaluable to have.

Weeks Four to Eight: Stabilise Before You Scale

With visibility established, the next phase was stabilisation. This meant addressing the specific risks identified in the audit, implementing basic monitoring and error handling on the production workflows, and rationalising the tool landscape to eliminate redundancy and reduce the maintenance surface.

The tool rationalisation was the most politically sensitive part. People have strong attachments to tools they use daily, even when those tools overlap significantly with something else the business is paying for. The conversation is not "this tool is bad" but "we are paying for three things that do roughly the same job, and maintaining integrations and prompts across all three is creating unnecessary complexity." The outcome in this case was consolidating from six subscriptions to three, with clear ownership and purpose for each.

The monitoring and error handling work was more technical but more immediately impactful. Every production AI workflow got three things added: logging that recorded inputs, outputs, and any errors in a queryable form; a human review checkpoint at the point where the output had the most potential to cause problems if it was wrong; and a simple alerting mechanism that flagged anomalies rather than letting them go unnoticed.

This sounds like adding overhead. In practice, it changes the operational posture entirely. A workflow that runs invisibly and fails invisibly is a liability. The same workflow with logging and alerting is a managed system. The work to add that layer is days, not weeks, and the peace of mind it buys is disproportionate to the investment.

The data handling issues found in the audit were resolved in this phase too, through a combination of routing changes that kept sensitive data within appropriate systems, and an update to the privacy documentation that accurately reflected actual practice. Fixing the documentation to match reality rather than the other way around is occasionally the right answer, but only after you have confirmed that reality is actually defensible.

Weeks Eight to Twelve: Build With Confidence

With a stable, visible, monitored foundation, the final phase was the work the CEO had originally wanted to start with: expanding AI capability in a way that was deliberate, well-designed, and actually likely to hold.

Two new workflows were built in this phase. The first was a structured approach to the client communication process that had previously been a patchwork of individual effort. A clean pipeline using a single well-configured model, grounded in client-specific context through a simple RAG implementation built on the business's existing documents and records, with human review before anything went out. The output quality was substantially more consistent than what had existed before, and the time cost to the team dropped significantly.

The second was an internal knowledge base query system: a way for staff to ask questions of the business's operational documentation and get accurate, sourced answers rather than tracking down the person who remembered where the relevant policy lived. This addressed a recurring friction that had been low on the priority list precisely because it was pervasive and therefore invisible as a cost.

Both systems were documented properly, with clear ownership, defined review cadences, and a process for updating the underlying content as the business evolved. This is not glamorous work. It is the work that determines whether something built in week ten is still running well in month twelve.

The State of Things at Day Ninety

At the end of the ninety days, the situation looked like this. The tool landscape was rationalised and the annual cost was lower than when I arrived, despite the business having more AI capability than before. Every production AI workflow was documented, monitored, and had a named owner. The data handling practices were defensible and reflected in the business's policies. The two new systems were running in production and being used daily. And the CEO had a clear mental model of the AI capability in her business: what it was, what it was doing, and what would need to change as the business grew.

That last point is worth emphasising because it is the one that tends to get overlooked in how AI transformation is described. The goal is not a collection of AI tools. The goal is a leadership team that understands the AI capability in their business well enough to make good decisions about it. Tools change, models improve, costs shift. The understanding of what you have and how it fits your strategy is what persists and compounds.

What This Pattern Looks Like Across Businesses

The specifics of this engagement are particular to this business, but the pattern is common. A period of enthusiastic, ungoverned AI adoption leaves behind a landscape that is more complex and more fragile than it appears. The work of stabilising it is less exciting than the work of building it, and so it tends not to happen until something breaks badly enough to force the conversation.

The businesses that avoid this pattern are the ones that bring in someone with the experience to know what ungoverned AI adoption looks like before it becomes a crisis, and the clarity to have the governance conversation before the chaos makes it unavoidable. That is a more comfortable position than the alternative, and a more efficient use of the investment in AI capability.

If your business has been adopting AI for twelve months or more and you do not have a clear answer to the questions raised in this post: what is running, who owns it, what breaks if it fails, and whether your data handling practices are defensible, that is the starting point worth addressing. Not because something has gone wrong, but because the time to build that clarity is before something does.

The 90-day AI stabilisation is one of the core engagements I run through InfoAddict. If the situation described here sounds familiar, I'm happy to have a direct conversation about what the work would involve for your business. No pitch, just an honest assessment of what you're dealing with and what it would take to address it.