The honest case for AI in the enterprise

I have now sat through roughly the same meeting in four different decades. A new capability arrives, it demos beautifully, and someone senior asks why we cannot have it by the end of the quarter. In 1999 it was the portal. In 2008 it was enterprise search. In 2015 it was the data lake. In 2026 it is agents.

The pattern is so consistent that it is almost useful. Each time, the technology worked. Each time, the programme struggled — not because the model or the index or the lake was wrong, but because the organisation had never resolved who owned the meaning of its own data.

What the demo hides

A retrieval-augmented chatbot built on a curated set of fifty documents is a genuinely impressive artefact. It is also a fundamentally different system from one built on the twelve million documents your business actually has, and the difference is not scale. It is entropy.

At fifty documents you know which version is current. At twelve million you have:

• Four contradictory versions of the same policy, none marked as superseded
• Documents whose access rules live in a system the retrieval layer cannot see
• A decade of drafts indistinguishable from approved material
• Domain language that means one thing in finance and something else in operations

None of these are AI problems. They are the same information governance problems that sank enterprise search, and a language model does not solve them — it amplifies them, because it will now state the wrong answer fluently and with apparent confidence.

The three preconditions

Before I am willing to put a model in front of a real user in a real business process, I want three things to be true.

One: the corpus has an owner with authority to delete. Not a steward who can comment, an owner who can remove. If nobody can retire the 2019 version of the pricing policy, your retrieval layer will keep finding it forever.

Two: authorisation is enforced at retrieval, not at generation. The most expensive mistake I see is filtering results after the model has already seen them. Permissions belong in the query, not in the prompt.

# Wrong: the model sees everything, then we hope the filter holds.
chunks = index.search(question, k=20)
answer = llm.generate(question, context=chunks)
return redact(answer, user.permissions)
 
# Right: the user's authority is part of the retrieval predicate.
chunks = index.search(
    question,
    k=20,
    filter=acl_filter(user.principal, user.groups),
)
answer = llm.generate(question, context=chunks)

The second version is barely more code. The difference is that the first one is a data breach waiting for an audit, and the second one is a system.

Three: there is a defined answer to "how do we know it got worse?" Every model-led feature drifts, because the corpus underneath it changes daily. If you cannot detect regression, you have not deployed a feature, you have deployed a liability with a friendly interface.

Where it genuinely earns its place

None of this is an argument against the technology. It is an argument about sequencing. The places where I have seen real, durable value share a shape:

Contract review, first-line support triage, code migration, test generation, document classification — all four boxes ticked. These are not glamorous. They are also the ones still running two years later.

The technologies that survive contact with the enterprise are rarely the ones that impressed us most in the demo. They are the ones whose failure modes we understood before we shipped.

What I would tell my younger self

That the interesting question is never can the model do this. By the time you are asking, the answer is usually yes. The interesting question is whether your organisation is capable of maintaining the conditions under which the answer stays yes — and that has been the same question since 1999.

The frontier moved. The homework did not.