Most of the enterprise AI projects we get called into have a perfectly good model. The problems are in the parts nobody demos.
A model in production has to pull from live data, stick to your governance rules and keep people trusting it for months, well past launch week. Someone has to notice when it drifts. None of that comes in the box. You design it, layer by layer, from where the data lives to how agents get watched.
We call that design work enterprise AI architecture. Done properly, it's the reason use case number 3 costs much less to build than use case number 1. We've also seen the other version, where every new agent is a fresh build and one person on the team spends half their week patching the first.
Most enterprise IT was built on a simple assumption: ask a system the same thing twice, get the same thing back. Your ERP doesn't calculate an invoice total differently on a Friday. When something breaks you fail over or roll back, and governance is mostly about who has access, plus a log of what they did. That approach has had 30 years to mature, and for those systems it works.
AI agents don't behave that way. Ask one the same question on Monday and Tuesday and you can get two different answers. Maybe the wording shifted, or it pulled back a different document, or something else was sitting in its context.
And failures are quiet. An agent that grabs the wrong document will answer from it confidently. No error, no alert. Just a wrong answer that sounds right.
That puts more on governance. Access still matters, but you also need rules for what the agent is allowed to do and say.
A lot of teams bolt AI onto the stack they already have and expect the old rules to cover it. They rarely do. You end up planning for uncertainty and testing constantly, which traditional architecture never had to do.
Teams underbuild this layer more than any other, and it's the one that hurts most when it's missing.
Access control is only a small part of it. In practice you need to be able to:
All of that depends on logging. At a minimum: inputs, outputs, what got retrieved, which tools were called and what the agent decided. Without those logs you're trusting a system that makes real decisions and hoping it keeps getting them right.
Most of the agents we build answer from the client’s own material: policy docs, product sheets, contacts. The usual way to do that is RAG, short for retrieval-augmented generation. Someone asks “what’s our refund window for enterprise customers?” and before the model writes a word, the system goes and finds the bit of the contract or policy that covers it.
The model then answers from that, not from whatever it learned in training.
Easy enough to explain. Getting it to work every time, across thousands of documents, is harder, and it mostly comes down to choices that happen upstream:
Most enterprises end up pointing agents at several sources at once: internal docs, product data, customer history, regulatory content. Each source you add needs designing in early.
The build went like this:
Step 2 took the longest. Getting 100 slightly different spreadsheets to agree on how pricing works was most of the project, and the agent is only ever as accurate as that logic.
