Why AI is harder in a business that already works

There is a version of AI adoption that is genuinely easy. A new team, a clean problem, no system of record to integrate with, no compliance step to preserve, nobody whose job changes. That version is what most AI demonstrations are built on, and it is not the situation any established business is actually in.

For an incumbent, the AI is rarely the hard part. The hard part is everything already in place: twenty years of process, systems that predate the cloud, constraints that exist for reasons nobody in the room remembers, and domain knowledge that lives in people rather than documents.

The instinct is to treat all of that as friction — the legacy drag slowing down the interesting work. That instinct is what produces pilots that impress and never ship.

Three ways the existing organization is misread

Process read as inefficiency. A workflow has nine steps and six of them look redundant. Some of them are. But at least one exists because of an audit finding, and another because of a bad month in 2019 that nobody wants to repeat. An agent that routes around those steps is not faster. It is unreviewed.

Systems read as obstacles. The system of record is old, the API is bad, and writing to it is unpleasant. So the pilot writes to a spreadsheet instead, demonstrates beautifully, and cannot go to production — because the business runs on the system of record and always did. The integration was not a detail to handle later. It was the project.

Domain knowledge read as absent. The rules are not written down, so it is tempting to conclude there are no rules. There are. They are in the head of the person who has done the work for eleven years, and they are the difference between an output that is correct and one that is merely plausible.

The constraints are the specification

This is the reframe that changes how the work goes.

An established business does not arrive with a blank page and a list of requirements to be discovered. It arrives with a working system — imperfect, expensive, full of exceptions, and functioning. Every constraint in it is a compressed statement about what the business has already learned matters: what must be checked, who must approve, what must never be got wrong.

Read that way, the constraints are not the obstacle in front of the specification. They are the specification, and they are a far better one than a greenfield project ever gets, because they have been tested against reality for years.

The work is not removing them. It is deciding, one at a time, which are load-bearing and which are habit — and that is a judgement that requires the domain expert in the room, not an inference the model can make on its own.

What this changes in practice

The sequencing inverts. A greenfield build starts with the capability and finds users for it. An incumbent build starts with the constraint set and finds where a capability fits inside it.

Concretely, that means the first serious questions are not about models:

1. What must remain true after this change? Approvals, audit trail, retention, segregation of duties. These are non-negotiable and they are cheaper to design for than to retrofit.
2. Where does the output have to land? If it does not reach the system of record, it did not happen. Establish that path before building the thing that produces the output.
3. Who currently catches the mistakes? That person is your reviewer and your best source of evaluation criteria. Their objections are not resistance; they are test cases.
4. Which exceptions are frequent enough to design for? Every established workflow has a long tail. You do not need to handle all of it, but you need to know where it starts and what happens when the agent meets it.

None of these are AI questions. All of them determine whether the AI ships.

The advantage nobody counts

There is a reason to find this encouraging rather than discouraging.

A company with years of accumulated process has something a well-funded startup cannot buy: a detailed, battle-tested map of what actually matters in its domain. That map is expensive to acquire and impossible to fake, and it is exactly what an AI system needs in order to be trusted with anything that counts.

The organizations that struggle with AI are not the ones with the most constraints. They are the ones that treat their constraints as an embarrassment to be automated away, rather than as the most valuable input they have.