Why Enterprise AI Is an Architecture Problem

The common framing of enterprise AI is a model question: which one, how good is it, how does it score. That framing survives about a week past the pilot. In eighteen years of enterprise systems work — SAP, finance, treasury, the programmes where a mistake shows up on a bank statement — I have never seen model quality decide whether a capability shipped. What decides it is the layer underneath: which system owns the data the AI is reading, what it is permitted to write, under whose identity that write happens, what it does when the system it depends on is unavailable, and whether anyone can explain the chain six months later when a controller asks why a record changed.

That is not a model problem. It is an architecture problem, and it is the same one I have spent a career on: getting systems that were never designed to talk to each other to agree on what is true.

Nobody deploys onto a blank page

The demo is always built against a clean surface. A prompt, a file, a plausible answer. The enterprise version of the same capability has to land in a landscape that already exists — an ERP with twenty years of configuration in it, a scheduling layer, an identity provider, an interface estate, a change process, and a set of controls that predate everyone in the room.

Every one of those is a constraint the demo never met. The capability does not get to define where the data lives; the landscape already decided. It does not get to invent an approval; there is one, and it has an owner. The real design work is not building the AI part. It is deciding where the AI part sits relative to everything that was already there, which is precisely the question the enterprise AI systems layer exists to answer.

Which system owns the record

The first question I ask of any AI capability is the oldest question in integration: what is the system of record here, and is the AI reading it or reading a copy of it?

This is not pedantry. A treasury management system and an ERP can both hold what looks like the same balance, and they are authoritative for different things. An AI reading the convenient copy — the extract, the warehouse table, the export somebody set up years ago for a report — will confidently answer from data that is a day stale, filtered, or scoped to a subset nobody documented. The answer looks right. It is wrong in a way that no amount of model capability can detect, because the model has no way of knowing what it was not given.

So ownership gets named before anything else: one authoritative source per data domain, the AI reads that or reads a copy whose staleness is known and stated, and nothing the AI produces becomes a second competing version of the truth.

What it may write, and as whom

Reading is the easy half. The moment a capability can write, two questions become load-bearing at once.

The first is scope: exactly which objects may it create or change, and which may it only read? "It has access to the system" is not a scope. A scope is a list, it is narrow, and it is enforced by the target system's own authorisation model rather than by an instruction in a prompt. Anything enforced only in the prompt is not a control — it is a suggestion the model is free to reinterpret.

The second is identity: under whose account does the write happen? An action attributed to a shared technical user is an action nobody is accountable for. It also breaks segregation of duties quietly, because a service identity broad enough to be convenient is usually broad enough to both create and approve — which is the exact combination the control was written to prevent. If a person is meant to be accountable for the outcome, the trail has to lead to that person, not to a service account with a name like AI_INTEGRATION.

"

You can swap the model in an afternoon; you cannot swap the decision about which system owns the record, because by the time you want to, a hundred other things depend on the answer.

The interesting failures happen between systems

Here is the part that makes this familiar rather than novel. Everything I learned building interfaces applies again, unchanged.

Retries duplicate work unless the receiving end is idempotent. If the AI's action is "post this" and the call times out after the target committed but before the response came back, a retry posts it twice — and an agent that retries eagerly is a duplicate-generation machine pointed at a system that keeps score. The fix is the same as it always was: an idempotency key the target honours, or a check-before-write, or both. It is not a model setting.

Rate limits, throttling and batch windows still exist. An AI that generates work faster than the downstream system accepts it does not fail loudly; it queues, backs up, and then floods the moment the window opens.

Reconciliation is still the only proof. Whatever the AI did, something has to compare what it believes it did against what the systems actually hold, on a cadence, with a break report that a human reads. Without that, the first time you learn the two disagree is when someone downstream notices the number is odd.

None of that is AI-specific. It is what you already do between an ERP and a bank, or between a forecasting process and the ledger. AI does not exempt you from it. It raises the volume, and it removes the natural rate limit that a human doing the work used to provide.

The day something upstream is unavailable

Enterprise systems go down, get patched, run month-end, and lock. The design question is what the AI capability does during those hours, and there are only a few honest answers: it waits and resumes, it queues and replays safely, or it stops and tells someone.

The dishonest answer — the one that ships by accident — is that it proceeds on partial data and produces a confident output anyway. That is the failure mode worth designing against explicitly, because it is invisible: nothing errored, the output arrived, and the fact that a source was missing is only visible in a log nobody read. The same output contract and failure-handling discipline that keeps a product honest applies here with more at stake, because the consumer is not a user who can shrug — it is a downstream process that will act on it.

Versioning, and the way back

Every enterprise system I have worked on had an answer to "how do we undo this." Transport paths, change records, a defined rollback, an environment where you saw it work first.

An AI capability needs the same answers, and the moving parts are unusual. A prompt change is a functional change. A model version change is a functional change — one you may not have initiated, which is the genuinely new problem: the behaviour of a component can shift without a change record on your side. That is why prompts and model versions belong under version control with the same seriousness as configuration, and why the environment path matters as much for AI as for anything else: you should have seen this exact prompt, against this exact model, on this data shape, somewhere that was not production.

The rollback question is the sharp one. If a prompt change caused a week of subtly wrong outputs, can you identify which outputs, and can you reverse them? For a read-only capability the answer is "regenerate." For a writing capability, it is a data-correction exercise — which is a very different conversation, and one worth having before you grant the write, not after.

Logging for a question asked later

The logging standard in enterprise work is not "we have logs." It is that someone can reconstruct a specific transaction months later, without you in the room.

Applied to an AI capability, that means recording the request, the proposal, the action actually taken, the identity used, the downstream response, and the prompt and model versions behind it. Get that right and you have something better than an audit trail — you have production observability, the thing that turns "it seems worse lately" into a number you can point at. Get it wrong and you have a capability that is trusted exactly as long as nobody asks a hard question about it.

What I would decide

Treat the model as the most replaceable part of the design and spend your architecture effort on everything else. Name the system of record before you build anything. Keep the AI read-only until write scope, identity and reversal are all decided, and enforce scope in the target system rather than in a prompt. Assume retries, so demand idempotency. Reconcile on a cadence and let a human read the breaks. Version prompts and models like configuration, and know your way back. Then decide, deliberately, where the agent actually sits relative to your existing systems — because that placement, not the model, is what determines how much damage a bad day can do.

See also how AI agents fit into existing enterprise systems and production AI observability.