The demo is going well. On the screen, an AI assistant is summarising a long policy document in seconds, answering follow-up questions in fluent, confident sentences, and even drafting a reply email for the reviewer to send. Around the table, heads nod. Someone from the business asks whether it can be extended to procurement, then to HR, then to customer service. The energy in the room is the kind that usually only appears when a technology finally seems to be doing what it promised.

Then the questions begin. They are polite at first.

Security asks which repositories the assistant is reading from. The answer is a shared drive plus "a few SharePoint sites." Data asks who owns the policy document being summarised, and whether the version on that drive is still the current one. Nobody in the room is entirely sure. Compliance asks how a wrong answer would be detected, and how it would be traced back to a source. Operations asks who will support the assistant on a Sunday evening when it starts responding strangely to routine questions. Someone from finance asks, gently, what business problem this is actually solving — and how success will be measured six months from now.

The model has not changed. It is exactly as capable as it was two minutes ago. What has changed is that the demo ran on a curated slice of data in a controlled setting, and the enterprise being asked to adopt it is not curated at all.

This is the pattern worth understanding. AI does not magically fix enterprise complexity. It exposes it — faster and more publicly than almost any technology before it.

AI readiness is mostly architecture readiness

Most conversations about AI readiness start with models, tools, and vendors. Which platform, which copilot, which model family. These are real decisions, but they are rarely where AI initiatives actually struggle.

AI initiatives struggle at the seams — where data ownership was never settled, where integrations were held together by goodwill, where identity controls were coarse, where governance existed on paper but not in practice. AI does not create these weaknesses. It inherits them, amplifies them, and then answers questions with them.

A useful way to think about readiness is as a set of layers sitting underneath the model. Each layer is ordinary architecture work. None of it is glamorous. All of it decides whether AI becomes dependable or dangerous.

Data readiness. An AI system is only as trustworthy as the sources it reads. That means knowing which sources are authoritative, which are stale, which are drafts, and which should never be read at all. It means each significant data domain having a named owner — a person, not a committee. And it means a lifecycle: how data is created, corrected, retired, and removed. If the organisation cannot answer "which version of this document is the truth?", the AI cannot either. It will simply pick one, confidently.

Identity readiness. Every AI interaction is an access event. Who is allowed to ask, what are they allowed to see, and who approves the exceptions? An assistant that reads broadly and answers anyone becomes the fastest data-leak mechanism ever installed. AI does not need new identity principles — it needs the existing ones, actually enforced. Least privilege, clear entitlements, auditable access. If identity is loose today, AI turns loose into visible.

Integration readiness. AI creates value when it sits inside real workflows — the service desk, the approval path, the document process people already use. It loses value when it becomes another disconnected portal that people must remember to visit. Integration readiness asks a plain question: where in the existing flow of work will this sit, and what systems must it connect to reliably, with proper contracts rather than heroic glue?

Governance readiness. AI systems make or shape decisions, so the decision boundaries must be explicit. What may the AI decide alone? What may it only recommend? What must always reach a human? Who owns the risk when the boundary is drawn wrongly? Governance readiness is not a policy document. It is a small set of clear answers that everyone involved can repeat without checking.

Operations readiness. The demo never shows day two. Someone has to monitor answer quality, handle the incident when the assistant starts behaving oddly after a data change, roll back a bad update, keep audit trails of what was asked and answered, and support the users who depend on it. An AI system without an operating model is a pilot that never really ended — it just quietly became production without anyone signing for it.

Cost and value readiness. Finally, the unfashionable question: what business problem is this solving, and how will anyone know it worked? Clear use cases, expected outcomes, adoption owners, and a way to measure results. Not because measurement is fashionable, but because AI costs compound — inference, integration, data preparation, operations — and value that is never defined is never delivered.

Put simply: AI does not make bad architecture intelligent. It makes bad architecture faster.

What the architect should do before the AI pilot

The instinct, once these gaps become visible, is either to say yes to everything or to slow the whole thing down until the architecture is perfect. Neither is useful. The architect's job in an AI conversation is not to block the pilot. It is to slow the conversation just enough to make the pilot safe — and then let it move.

A short list of quiet, unshowy work tends to be enough.

Map the data sources the assistant will actually read. Not the ones it might read someday — the ones it will read on day one. Write them down.

Identify a named owner for each of those sources. If an owner cannot be named, that source is not ready to be read by an AI.

Confirm the identity and access boundaries. Who can query the assistant, what it is allowed to surface for each group, and how exceptions are approved. The existing identity model should carry this; if it cannot, that is the first project, not the AI.

Define what the AI may answer directly, what it may only recommend, and what it must never decide. Three lines on a page are enough. What matters is that everyone involved agrees.

Agree the support and audit responsibilities before go-live. Who monitors quality, who responds to incidents, who keeps the audit trail, who signs it off. A pilot without an operating model quietly becomes production, and production without an operating model quietly becomes a problem.

Connect the pilot to one real business outcome. Not three, not a portfolio — one. Something that can be measured, and someone who owns the measurement.

None of this blocks AI. It simply ensures that when the pilot succeeds, the organisation is ready to keep it; and when it fails, the organisation can tell why.

The questions to ask before buying anything

The healthiest moment in any AI initiative is before the purchase, when the questions are still cheap. A short list does most of the work.

What data will the AI use — and who owns it?
If ownership is unclear, that is the first project, not the AI.

Who is allowed to access what it knows?
If the answer is "everyone, probably," pause.

What happens when it gives a wrong answer?
Not if. When. Who notices, who corrects, who is accountable?

How are its decisions audited?
If a regulator, an auditor, or an unhappy user asks "why did it say that?", can anyone reconstruct the answer?

Who supports this after go-live?
A team, a budget, a rota — or a hope?

What problem are we actually solving?
If the honest answer is "we need to be seen doing AI," the architecture conversation has not started yet.

None of these questions require deep AI expertise. They require ordinary architectural honesty. Before asking which AI tool to buy, ask what the enterprise is ready to expose.

The calm conclusion

There is a quiet reassurance in all of this. Organisations that have done the unglamorous work — clean data ownership, disciplined identity, honest integration, working governance, real operations — find AI adoption far less dramatic than the headlines suggest. The foundations carry the new load, because that is what foundations do.

Organisations that skipped that work will find that AI is not a shortcut around architecture. It is a stress test of architecture.

AI does not remove the need for architecture. It punishes the absence of it.

Before the pilot begins