- An AI layer inherits the content model, the data ownership and the permissions beneath it. It cannot fix any of them.
- A CMS compromised through a deactivated plugin is a platform problem. No amount of AI or SEO touches it.
- Run the four diagnoses in order. Three of the four answers usually point at platform work rather than a model.
The request usually arrives in the same shape. An assistant on the site — answers questions, checks order status, points people at the right product. Reasonable ask. The interesting part is never the model. It is the twenty minutes afterwards, when you ask where the answers would come from.
A composite of what that answer tends to look like. The warranty terms sit inside a block of formatted text that also holds a hero image and two buttons. Order status lives in a finance system a third party operates. Product data is authoritative in one place, except for the items marketing corrected somewhere else. Nobody can say which system wins.
None of that is an AI problem. All of it becomes one the moment an AI layer is placed on top.
That is the modelling failure. Platforms fail in cruder ways.
At AEGEX Technologies we inherited a CMS that had been partially compromised. The way in was a plugin deactivated but never removed and never updated — deactivating a plugin does not take its code off the server. From that foothold the compromise spread until the platform could no longer be trusted to be what it claimed, and a rebuild was the only real option.
No amount of AI or SEO was going to touch that. The symptoms presented as a visibility problem, which is how the conversation began. The real problem was that nobody could say with confidence what the platform was serving. You cannot build an assistant on a system whose contents you are unsure of, and there is no point optimising a site you do not control.
An AI layer inherits everything underneath it
This is the part that gets skipped. A model does not hold a private, well-organised copy of your business. It has whatever your systems hand it and whatever permissions you gave it. It is another way of displaying your platform, and a far less forgiving one than a website: a badly organised page still looks like a page to a human reader, while a badly organised piece of content produces a confident sentence that is wrong.
Our position is narrower and more testable than “get your data ready”. Six things decide whether an AI feature can create durable value: how your content is structured, who owns each piece of data, how reliable the connections between systems are, what those systems will hand over, how permissions are enforced, and whether anyone can measure what happened. Every one of those is an engineering decision that predates the AI conversation by years.
Content that is written for a page cannot be read off it
Two pages can look identical to a visitor and be completely different objects underneath. One holds its facts as separate labelled fields — this is the price, this is the warranty period, this is the lead time — that another system can ask for directly. The other holds the same facts as a paragraph inside a layout. Vendor documentation is explicit about the difference, and the second kind is, in one CMS vendor’s own phrasing, not convenient to retrieve programmatically.
That inconvenience is the whole problem. An assistant cannot quote a returns policy that exists only as a sentence inside a marketing layout. It can only paraphrase the layout, and paraphrase is where confident errors come from.
We have learned this in a different shape. Wiring translation into a product built without it exposes every place where copy was treated as decoration rather than data: text welded into components, meaning carried by layout, the same label written four different ways. None of it is broken until something other than a person has to read it. An AI assistant is the newest reader, and the least tolerant of ambiguity.
Data you do not own is data you cannot answer from
Answering reliably requires that somebody can say where a fact lives, who is allowed to change it, and how fresh it is. Split ownership breaks all three at once. When the product description is authoritative in one system and also editable in another, the assistant has two truths and no rule for choosing between them. Publishing an AI feature over that is not automation. It is the automated distribution of an argument nobody settled.
This is why we hand over repositories, accounts and design source from the first commit. Not only as a stance on lock-in, but because you cannot govern a source of truth you cannot see inside.
Permissions are architecture, not configuration
Most platforms we inherit enforce permissions in the interface. Hide the button and the customer cannot press it. That works because people reach the data through screens.
An assistant does not use your screens. It reads from a store of content prepared in advance, and unless that store knows who may see what, it will happily return one customer’s material in answer to another customer’s question. The OWASP security project names this directly, and names the related failure too: giving a system more reach than its task requires, such as a read-only feature connecting through an account that can also delete.
Reliability decides whether an answer becomes an action
An assistant that answers questions needs good content. One that does things needs reliable connections between systems, and reliability here has a precise meaning: the same instruction can arrive twice without the thing happening twice. Stripe’s documentation describes the standard approach — each request carries a marker, and if it arrives again the original result is replayed rather than repeated.
Now consider a model that retries when something is slow. If your order-creation step cannot recognise a repeat, you have not built an AI feature. You have built a duplicate-order generator with excellent manners — a problem our colleagues take apart properly in the piece on agent-facing APIs. The same goes for measurement: if analytics and error monitoring were bolted on late, you will not be able to tell whether the AI feature helped, and you will hear about failures from customers.
When a tactical AI layer is still the right call
The strongest objection is that this reasoning, taken too far, becomes a rule that nobody may ship anything until the platform is perfect. No platform is ever perfect. Some of the most valuable AI work we see sits on top of systems that genuinely are a mess, and it is rational in at least four cases.
When the feature only advises and a person decides, the worst case is a suggestion someone rejects. When AI is used to make the mess legible rather than act on it — sorting a sprawling content estate to size a migration — the poor data is the input, not the dependency. And when the feature is a bounded experiment with a stated end date, buying information about demand is a legitimate use of two weeks.
What these share is scope discipline. They are tactical on purpose, and everyone knows it. The failure is not building them. It is quietly promoting one into something the business depends on, at which point the platform debt underneath becomes the feature’s debt. As we argue elsewhere, the AI feature is the easy part.
Four diagnoses, taken in order
Before scoping any applied AI work, run these in sequence. The first one that fails is your real project.
One — do you have a platform problem? Pick five facts a customer might ask about. Can each be handed over as a discrete labelled field, without something reading it off a layout? If not, you have a content problem, and the feature will inherit it.
Two — do you have a data problem? For each fact, name the owning system, the person who may change it and how stale you can afford it to be. Any fact with two owners or none is not ready.
Three — do you have a workflow problem? Trace the action end to end. Can the write step survive being told twice? Are permissions enforced beneath the interface? Does someone see a failure before the customer does?
Four — only now, do you have an AI opportunity? A genuine one has a task with judgment in it, evidence the model can actually reach, a measurable outcome, and a defined behaviour when it is wrong.
Three of those four point at platform work, not at a model. That is not a disappointing finding. It is a cheaper one, and it is what a two-week fixed-scope discovery is for: you leave with a plan you own, and sometimes that plan says the AI feature should wait a quarter. If that is a conversation worth having, start there.