You Don’t Have an AI Strategy. You Have a Dependency.

A lot of businesses are moving quickly with AI at the moment, and I am glad they are. There is still far too much work inside good organisations that is slow, repetitive, and unnecessarily manual. There are teams spending hours summarising information, rewriting the same kinds of emails, searching through internal documents, triaging requests, preparing reports, and trying to turn messy inputs into something useful. If AI can remove some of that friction, it should.

So the problem is not that businesses are experimenting with AI. They absolutely should be.

The problem is that speed can hide fragility.

A workflow gets quicker. A report becomes easier. A support process improves. Someone inside the business quite reasonably says, “This is useful, let’s use it elsewhere.”

And before anyone has really stepped back to think about it, the business has built a growing dependency on one model, one provider, and one set of behaviours it does not control.

That is not really an AI strategy.

It is a dependency that happens to be working today.

When people talk about resilience, they often jump straight to outages. What happens if the API goes down? What happens if the provider has a bad day? What happens if the service is unavailable for a few hours?

Those are valid concerns, but they are also the easy ones to understand. When something is down, everyone knows it is down. You can see the failure, communicate around it, and put a fallback in place.

The more difficult risk is subtler than that.

The model still works. The API still responds. The dashboard is still green. But the behaviour changes.

The tone becomes slightly different. The answers become more cautious. The structure of the output shifts. A classification task that used to be reliable starts producing edge cases that need more review. A support assistant that used to sound like your business starts sounding more generic. An internal knowledge tool that was once direct and helpful starts hedging its answers because the model underneath it has changed how it handles uncertainty.

Put that into human terms for a moment. If a junior member of staff turned up tomorrow and behaved like a completely different person, you would not shrug and carry on. If their judgement, tone, confidence, and approach bore little resemblance to how they worked yesterday, you would treat it as a management issue. You would want to understand what had changed, how much it affected their work, and whether they could still be trusted in the role.

Yet with AI, we often accept that kind of behavioural drift as if it is just the cost of progress.

Nothing has technically broken, but the system no longer behaves quite the way people expect.

That is where trust starts to leak away. Not all at once, but slowly. People begin checking the outputs more often. Managers become less confident using the results. Staff start working around the tool rather than through it. The efficiency gain that looked so compelling at the start begins to shrink because the process now needs more human oversight.

That is the kind of risk businesses underestimate, because it does not look like a failure at first. It looks like friction.

And friction is easy to ignore until it becomes part of the cost of running the business.

One reason this happens is that many AI systems are still being built as if the prompt is the system.

The prompt tells the model what role to play, how to behave, what format to return, what tone to use, and what rules to follow. If the output is not quite right, the prompt gets tweaked. If the model misses something, the prompt gets longer. If the edge cases become awkward, the prompt gets another paragraph of instructions.

There is nothing wrong with careful prompting. It matters. But a prompt is not the same thing as control.

A prompt is a request.

It can guide behaviour, but it does not guarantee it. It does not give you a stable contract. It does not ensure the same interpretation across different models, or even across different versions of the same model over time.

That matters when AI is sitting inside a real business process.

If you are using AI to help draft an occasional article, a bit of variation may be fine. You can review it, reshape it, and move on. But if AI is triaging customer issues, preparing compliance-related summaries, supporting sales conversations, or helping staff make decisions, then behaviour matters. Consistency matters. Predictability matters.

At that point, you need more than a well-written prompt.

You need architecture.

This is where the conversation often gets confused. When I say businesses should move towards owning their AI architecture, I do not mean they need to train their own large language model. For most organisations, that would be unnecessary, expensive, and a distraction from the real problem.

Owning the architecture means owning the system around the model.

It means your application does not talk directly to one provider as if that provider is the permanent brain of the business. Instead, you create a layer in between. That layer handles how requests are structured, which model is used, what context is provided, how outputs are validated, and what happens when something does not look right.

The model should be something you can replace, not something the whole process is wrapped around.

If the model is the system, every model change becomes your problem. If the model is one part of the system, you have options. You can route different tasks to different models. You can test alternatives without rewriting everything. You can introduce validation before an output reaches a customer or member of staff. You can maintain your own standards for quality, tone, and format rather than hoping the model continues to behave as it did during testing.

Architecture, in this context, is not about drawing clever diagrams. It is about deciding where control lives.

There is a tendency to talk about AI as though the model is the valuable part. Which one is best? Which one is fastest? Which one has the biggest context window? Which one performs better on this benchmark or that benchmark?

Those questions are not irrelevant, but they can distract from the more important point.

For most businesses, the model is not the lasting asset.

Your context is.

Your data, your processes, your customer knowledge, your tone of voice, your internal language, your judgement, your way of working. That is the material that makes an AI system useful inside your organisation.

A generic model can produce generic intelligence. Useful, certainly, but not defensible. The real value starts to appear when the system understands the specific environment it is operating in.

That might mean connecting to internal documents, project history, CRM data, support tickets, policies, previous decisions, or examples of good work. It might mean structuring workflows so that the model is not asked to do everything in one magical step, but is given the right context at the right moment and asked to perform a clearly defined task.

That is where businesses should be putting their energy. Not just into “using AI”, but into designing how AI interacts with the knowledge and processes that already make the business valuable.

Because if that context lives in your architecture, you can change the model underneath it. If that context only exists as a long prompt wrapped around one provider’s behaviour, you are much more exposed.

One of the simplest tests of an AI strategy is this:

How painful would it be to change models?

If the answer is “very”, then the business is not model agnostic in any meaningful sense. It may know other models exist, but it cannot actually move without disruption.

That is the difference between theoretical flexibility and practical resilience.

A business with a sensible AI architecture can make model choice a reversible decision. It can use one model for summarisation, another for structured extraction, another for reasoning-heavy tasks, and perhaps a cheaper or faster model for high-volume internal processes. It can test new models as they appear. It can respond to pricing changes. It can move away from a provider if quality drops, terms change, or a better option becomes available.

That does not mean constantly switching for the sake of it. Stability still matters. But it does mean you are not stuck.

And in a market moving this quickly, not being trapped has real commercial value.

The immediate appeal of building on a single platform is obvious. It is quicker. There are fewer moving parts. The demos look good. The first version gets out of the door faster.

There is nothing wrong with that as a starting point. In fact, it is often exactly how you should begin. You do not need an elaborate architecture to test whether AI can improve a process.

The danger is when the prototype becomes the foundation.

That happens all the time in software. A quick internal tool becomes business-critical. A temporary integration becomes a permanent workflow. A one-off prompt becomes the basis for a customer-facing feature. Nobody means to create fragility. It just accumulates through a series of reasonable short-term decisions.

The problem is that AI amplifies this pattern because the outputs feel intelligent. People trust the thing that seems to work. They build confidence quickly, sometimes faster than the underlying system deserves.

Then, when the behaviour changes, the business has to absorb the consequences.

The cost might show up as extra checking. It might show up as inconsistent customer experience. It might show up as staff losing trust in a tool they had started to rely on. It might show up as rework when a model update forces prompts and processes to be revisited across multiple teams.

None of that feels dramatic enough to appear on a risk register at the beginning.

But it is real cost.

Once AI starts influencing how work gets done, it stops being a novelty and becomes part of the operating model.

That means it needs the same kind of thinking you would apply to any other important system. What depends on it? What happens when it behaves unexpectedly? How do we monitor quality? How do we change suppliers? Where does the business logic live? How do we know whether the outputs are good enough?

These are not abstract technical questions. They are leadership questions.

Because the decision is not really about whether to use one model or another. It is about how much control the organisation wants over a capability that may become central to how it serves customers, supports staff, and makes decisions.

There is a big difference between using AI to assist people and allowing a vendor’s model behaviour to become embedded in the way your business operates.

One is a tool.

The other is a dependency.

A better approach does not need to become a grand technical programme.

For many businesses, the first step is simply to stop treating the model as the centre of the system. Put a service layer in front of it. Keep prompts versioned and testable. Define expected outputs clearly. Validate important responses. Log failures and edge cases. Separate business rules from model instructions. Store useful context in systems you control.

In practical terms, that might mean an internal AI gateway that all applications call. It might mean using structured output schemas so downstream systems are not relying on whatever prose the model happens to produce. It might mean building retrieval properly, so the model uses current and relevant business information rather than guessing. It might mean having evaluation sets that test whether a workflow still behaves correctly when you change a model, a prompt, or a data source.

None of this is especially glamorous.

But it is what turns AI from an impressive demo into something a business can rely on.

It also gives you a healthier relationship with AI providers. You can still use the best models available. You can still benefit from the pace of innovation. But you are no longer building as if one platform will always be the right answer.

That is the balance businesses should be aiming for: take advantage of external capability, but keep ownership of the architecture that makes it useful.

The popular question is still, “Which AI platform should we use?” It is a fair question, especially when the market is moving quickly and every week seems to bring another model, another benchmark, another impressive demo. But it is not the question that tells you whether the business is building something resilient.

The better question is much more uncomfortable: if this model changed tomorrow, what would actually happen to the way we work?

That question gets past the hype quite quickly. It forces you to look at where AI is really being used, who depends on it, what assumptions have been built around it, and how much of the business would wobble if the behaviour underneath it shifted. For a few low-risk experiments, the answer might be “not much”, and that is fine. But if customer experience, internal operations, decision-making, reporting, or staff support would all need to be checked, repaired, or rethought, then the business has probably allowed a useful tool to become a fragile dependency.

It is also a good way of exposing whether the organisation has any real ability to move. Could you test another model without disrupting users? Could you compare outputs properly rather than relying on gut feel? Would your business rules, context, and examples come with you, or are they buried inside a collection of prompts that only really work with one provider? Those answers tell you far more than the name of the platform being used.

Many businesses are not at risk because they have failed to adopt AI. They are at risk because they are adopting it too casually.

That may sound harsh, but it is the pattern I think leaders need to pay attention to. Useful things are being built, and some of them will genuinely save time, improve service, and reduce the weight of repetitive work on people. But usefulness is not the same as durability. A process can work today and still be poorly prepared for tomorrow. A tool can produce impressive outputs and still sit on top of assumptions nobody has properly tested.

That is understandable. Everyone is learning. The pace is ridiculous, and the pressure to show progress is real. Most businesses are not trying to create fragile systems. They are trying to move, learn, and keep up with a technology that is changing faster than any planning cycle can comfortably handle.

But there comes a point where “we’re experimenting” stops being a good enough explanation. Once AI starts touching customers, staff, operations, or decisions, the architecture around it matters. Not because architecture is interesting for its own sake, but because it determines whether you are building a capability the business can trust, or simply accumulating dependencies that happen to be working at the moment.

The businesses that handle this well will still use external models. Of course they will. There is no virtue in trying to build everything yourself when the market is producing extraordinary tools at speed. But they will be clearer about what they own. They will own the context that makes the system useful. They will own the workflows that decide how AI is applied. They will own the quality standards that determine whether an output is good enough. And, crucially, they will own enough of the layer around the model to adapt when the market changes.

That is where the real advantage will sit. Not in having picked today’s best model, because today’s best model may not be tomorrow’s. It will sit with the businesses that can benefit from whatever comes next without having to rebuild every time the ground shifts underneath them.

It is a bit like building a critical business process around one supplier, without a backup, without a clear agreement about what happens when their product changes, and without any easy way to move if the relationship stops working. You might get away with it for a while. Many businesses do. But it is a fragile way to build something you intend to rely on.

The first step is not to rebuild everything. It is to map where AI is already being used and ask a few awkward questions.

That exercise does not need to be dramatic. It is closer to a dependency audit than a transformation project. You are simply trying to understand where AI is helping, where it is becoming embedded, and where the business may be relying on something it does not properly control.

From there, the next step is usually clearer. Some experiments can stay lightweight. Some internal tools may only need better logging or prompt versioning. But anything touching customers, decisions, operations, or staff confidence probably deserves a more deliberate architecture around it.

That is the line worth drawing.

Use AI quickly, absolutely. Learn by doing. Build momentum.

But once it starts to matter, do not leave the foundations to chance. If AI is going to become part of how the business works, it deserves more than a clever prompt and a hopeful assumption that the model will behave tomorrow as it did today.