Some businesses have spent twenty or thirty years making their IT a differentiator.

Not a cost centre. Not a back-office nuisance. A differentiator.

The system grew with the business. It knows the weird product rules, the customer promises, the warehouse reality, the exception process, the pricing logic, the stock language, the compliance shortcuts that are not really shortcuts, and the bits that no SaaS vendor ever quite understood.

Then AI arrives.

And someone walks into the room with a demo and says, "We should connect this to the core system."

I would be very careful with that sentence.

If your company has been building its own systems since the 1990s, or even just for the last twenty years, there is probably a reason. The people protecting those systems are not always blockers. Sometimes they are the immune system.

They know what works. They know what breaks. They know what happens when an enthusiastic project gets a little too close to the central buttons.

So do not start there.

Start at the edge.

The old system is not the enemy

There is a fashionable way of talking about legacy systems as if they are just technical debt wearing an old jumper.

Sometimes they are.

But sometimes they are the operating memory of the company. They are the place where the business learned how to serve customers, price risk, route work, handle exceptions, and survive.

The old system may be awkward. It may be expensive. It may be short of documentation. It may be running on technology that makes modern developers quietly put their head in their hands.

But it may also be the reason the company exists.

That is why the AI conversation can get emotional very quickly. The AI people see opportunity. The core-system people see blast radius.

Both are right.

McKinsey's 2025 state-of-AI work shows the same broad pattern many leaders are feeling: AI use is spreading, but many organisations are still in pilot mode and have not embedded it deeply enough into workflows to get enterprise-level value. That matters because it means the risky move is not "small POC first". The risky move is pretending a clever demo is the same as operating change.

Do not touch the central buttons first

If the core system runs orders, money, customer records, supply chain, safety, compliance, production, underwriting, clinical decisions, student records, or anything else that can hurt people or the business, do not make it the first AI playground.

Not because AI is useless.

Because the first lesson you need is not whether the model can produce a plausible answer.

The first lesson is whether the organisation can introduce AI without losing control.

NIST's AI Risk Management Framework is useful here because it frames AI risk as something organisations have to govern, map, measure, and manage. The UK NCSC's secure AI guidance says the same thing in security language: AI systems need secure design, development, deployment, and operation, not just a quick build and a hopeful launch.

That is the discipline.

Before the agent can write to the core, you need to prove the human system around it works.

Infographic showing a protected core system in the centre, with safe AI proof of concepts starting at the business edge through read-only copies, human review, and expansion gates.

The edge is where trust is built

The edge is not unimportant work. It is work with a boundary.

It might be a copied folder. A read-only export. A small set of anonymised cases. A queue of old support tickets. A training pack. A set of policy documents. A non-production report. A product catalogue. A synthetic dataset. A shadow version of a process where the AI produces advice and a human compares it with the real decision.

The point is separation.

The AI can inspect, summarise, classify, compare, draft, test, and explain. It cannot yet push the live button.

That gives the people protecting the core something sensible to say yes to.

"We are not connecting this to production. We are not giving it credentials. We are not letting it alter live records. We are going to test one bounded use case, with copied or read-only data, and a human review gate."

That is a very different conversation from, "Trust us, the model is good now."

Good first POCs

For a company with a valuable old system, I would look for proof of concepts that sit around the system rather than inside it.

  • Documentation assistant: read old process notes, interface files, decision logs, and support runbooks, then produce a clearer map of how the system works.
  • Exception explainer: take historical exceptions and help staff understand which ones are common, which ones are risky, and which ones need escalation.
  • Read-only report companion: explain a report, find likely anomalies, and suggest questions for a human analyst to check.
  • Customer-response draft: draft replies from approved public or internal guidance, with no sending authority.
  • Test-case generator: create test scenarios for known business rules without touching production.
  • Legacy-knowledge capture: interview experienced staff and turn tacit knowledge into reviewed notes, checklists, and training material.

None of those require the AI to own the core system.

All of them can create value.

More importantly, they reveal the real blockers: data quality, missing documentation, unclear ownership, nervous users, weak review rhythms, hidden exceptions, and the places where nobody agrees what good looks like.

Never ridicule the distrust

A lot of people in these businesses do not trust cloud providers, AI vendors, consultants, or platform promises.

Fine.

Do not start by arguing with that. Start by designing a POC that does not require blind trust.

No secrets. No production credentials. No broad data dump. No live writes. No automated customer contact. No hidden model calls with sensitive material. No "temporary" integration that quietly becomes permanent.

Write the controls down.

  • What data can the AI see?
  • Where is that data copied from?
  • Who approved the copy?
  • What must not be included?
  • What can the AI suggest?
  • What must a human approve?
  • Where are the logs?
  • What is the stop rule?
  • What would let this POC expand?

This is not bureaucracy. This is how you let a cautious organisation move.

The first win is not transformation

The first win is a group of sensible people saying, "That was useful, and it stayed inside the boundary."

That is gold.

Once you have that, you can move the boundary carefully.

Maybe the next POC gets a larger read-only dataset. Maybe it gets better retrieval. Maybe it connects to a non-production environment. Maybe it generates test cases against a clone. Maybe it supports a team during month end, but still cannot post anything. Maybe it becomes part of training.

That is how trust compounds.

Small. Real. Separated. Reviewed. Then wider.

The practical route

If I were leading this in a company where the core system is precious, I would not begin with a grand AI transformation programme.

I would begin with two or three edge POCs.

One around knowledge. One around exceptions. One around reporting or testing.

Each would have a named business owner, a named technical owner, a named reviewer, a written boundary, a weekly rhythm, and a clear expansion gate.

I would also make peace with the fact that some people will say, "Not here. Not yet."

Good.

That is useful information.

The goal is not to win an argument with the people who know the old system. The goal is to give them a way to let new capability approach the business without threatening the thing that already works.

So start gently.

Stay away from the central buttons.

Find the edge where the work is real, the boundary is clear, and the consequence is contained.

Then keep moving.

Never give up, but do not be daft about where you start.

Research notes