Most AI conversations still begin with a product decision. Which Copilot to license. Which model to standardise on. Whether to build agents in-house or buy a platform. These are real decisions, but they are rarely the first ones that actually matter.

If you want the fuller argument for why, AI Readiness Is Not an AI Problem — It Is an Architecture Problem covers it in depth: AI rarely fails at the model, it fails at the foundation underneath it. This piece assumes that argument and goes further, into the specific areas of enterprise architecture worth examining before the next tool gets purchased, and a checklist built to be used in a working conversation rather than read once and filed away.

There is no certificate an enterprise earns for being "AI-ready." What exists instead is a set of ordinary architecture questions — most of them older than AI by decades — that AI simply makes urgent again.

The architecture stack AI depends on A vertical stack of seven layers, from AI and agents at the top down through business outcomes, processes and people, information and data, applications and APIs, identity and security, to cloud, infrastructure and connectivity at the base. The AI and agents layer is highlighted in gold to show it is the visible layer, while a bracket marks the six layers beneath it as the architecture that determines whether the AI can be trusted. AI & Agents the layer everyone wants to talk about first Business Outcomes the decision or result meant to change Processes & People who does the work today, and how Information & Data what is trustworthy, current and owned Applications & APIs what can be read, and what can be changed Identity & Security what the AI is allowed to touch Cloud, Infrastructure & Connectivity what everything else runs on THE ARCHITECTURE AI DEPENDS ON AI RELIES ON THE ARCHITECTURE UNDERNEATH IT
AI sits at the top of a stack it did not build. Everything below the gold line is ordinary architecture work — and it decides whether the top layer can be trusted.

Information architecture: trust before intelligence

An AI system does not read documents the way a person does. A person notices that a policy looks outdated, or that two spreadsheets disagree, and quietly applies judgement. An AI system reads whatever it is given access to and answers with the same confidence regardless of which version it happened to find.

This is why information architecture — not a new AI-specific discipline, but the old one, actually practised — becomes the first real constraint. Which source is authoritative. Which is a draft. Which has been superseded but never archived. Who owns each significant data domain, by name rather than by department. What the lifecycle looks like: how information is created, corrected, retired, and eventually removed from anything an AI system can reach.

A practical question surfaces this quickly: if an AI agent finds five different versions of the same record, how does it know which one to trust? In most enterprises today, it doesn't. It picks one and states it as fact. That is a worse outcome than no answer at all, because a confident wrong answer travels further before anyone questions it.

Integration: the gap between answering and acting

A useful distinction is worth holding onto through every AI conversation: AI that can answer is a very different system from AI that can safely act. Answering requires read access and reasonable context. Acting requires the AI to call an API, trigger a workflow, update a record, or interact with a platform on someone's behalf — and that is where most enterprise architecture actually gets tested.

Many core applications were never built to be called by anything other than a person clicking through a screen. There is no clean API, only a database underneath and a UI on top. An agent that needs to act against a system like this either goes through a fragile point of integration someone has to maintain indefinitely, or it doesn't act at all and someone re-types the result manually — which quietly removes most of the value the AI was meant to add.

This is ordinary integration work: APIs with real contracts, event-driven interfaces where they make sense, a clear owner for each integration point, and honesty about which legacy systems genuinely need a modernisation step before an agent should be allowed near them. None of this needs to happen everywhere at once. It needs to be known.

How an enterprise AI agent action is controlled A vertical flow from user to AI assistant or agent, through an identity and policy check, into an enterprise API and integration layer, which branches to three destinations: business applications, enterprise data, and workflow or automation. A dashed boundary and a bottom band labelled audit and observability show that every stage in the flow is logged and traceable, not only the final action. User AI Assistant / Agent Identity + Policy Check what can this agent do — and for whom? Enterprise APIs / Integration Layer Business Applications Enterprise Data Workflow / Automation Audit / Observability every stage above is logged and traceable
Answering needs read access. Acting needs a policy check, an integration contract, and an audit trail — for every stage of the flow, not only the final step.

Identity: the part that decides what AI is actually allowed to do

An AI agent is, from an architecture standpoint, an identity — and it deserves the same discipline any identity gets. Which identity does the agent use when it acts: its own service identity, or the identity of the person it is acting for? What can it see, based on that identity? Can it act on someone's behalf, and if so, within what limits? Which actions require a human to approve before they happen, and which are safe to let run unattended?

None of this calls for a new identity discipline invented for AI. It calls for the identity and access management discipline that already exists — least privilege, clear entitlements, auditable access — actually enforced at the point where an agent, not a person, is making the request. Where identity is loose today, an AI agent does not create that looseness. It simply exposes it at a speed nobody has time to catch by hand.

Technical debt becomes AI debt

Every enterprise carries some technical debt: an unsupported application nobody wants to touch, a hard-coded integration that only one person understands, an undocumented database, master data that disagrees with itself across three systems, an authentication method that predates modern standards. Most of the time, this debt sits quietly and causes no visible harm.

AI changes that. The moment an agent is expected to read from, or act against, a system carrying this kind of debt, the weakness stops being background risk and starts being a live constraint on what the AI can safely be trusted to do.

You do not need to modernise everything before adopting AI. You need to know where architectural weakness creates risk, or quietly limits the value an AI initiative can realistically deliver — and decide, deliberately, which of those weaknesses get fixed first and which get worked around for now.

Governance: enabling AI, not slowing it down

The instinct, once these areas are visible, is often to stand up a new governance body dedicated to AI. That is usually the wrong move. It adds a queue, not a decision.

What tends to work better is lighter and more familiar: Enterprise Architecture, Information Architecture, Security, IAM, Data Governance, Platform Engineering, Risk, and the owners of the applications involved, working from a shared, short set of answers — rather than a new committee reviewing every AI initiative from scratch. The goal is a small number of clear decisions, kept current, not a large body producing documents nobody reads before the next release.

Five questions, one diagnostic

Five architecture questions behind AI readiness A banner reading AI Ready sits above five cards in two rows: Information, Integration and Identity in the first row, and Architecture and Governance in the second row, each with a short diagnostic question. AI Ready? five questions worth asking before the next purchase INFORMATION Can AI understand andtrust our information? INTEGRATION Can AI reliably interactwith our systems? IDENTITY Do we know what AI isallowed to do? ARCHITECTURE Do we understand ourdependencies and debt? GOVERNANCE Can AI decisions andactions be controlled?
The five areas covered above, restated as one diagnostic. Each is an ordinary architecture question — asked together, before the purchase rather than after.

The ten questions below turn those five areas into something you can actually run in a room — a working session with architecture, security, data and the sponsoring business team, rather than a document one person fills in alone.

  1. Do we know which systems contain authoritative information?
  2. Do important applications expose usable APIs?
  3. Can we identify duplicated or conflicting information?
  4. Is data ownership clear, by name?
  5. Is identity and authorization consistently managed?
  6. Can AI actions be audited?
  7. Do we understand our major technical-debt hotspots?
  8. Are critical integrations documented?
  9. Can humans approve high-impact AI actions?
  10. Do we know which business problems actually justify AI?
8–10 Yes

Strong foundation. Proceed with normal architecture discipline.

5–7 Yes

Proceed selectively. Pick a narrow, well-bounded use case first.

0–4 Yes

Fix architectural foundations before scaling AI further.

This is a conversation tool, not an industry certification model. Its value is in the silences it produces — the questions where nobody in the room has a confident, named answer. Those silences are where the next piece of architecture work should go.

Closing

AI readiness is not primarily about buying AI. It is about making the enterprise underneath it understandable, connected, governed, secure, accessible, and changeable — the same qualities architecture has always been responsible for, now under a faster and less forgiving spotlight.

None of this argues against adopting AI. It argues for sequencing the conversation correctly. Before asking which AI platform to buy, understand the architecture it will depend on.

Continue exploring