enceladus · 3 min read
What twenty years of building enterprise solutions taught us about AI
The lessons from two decades of enterprise solutions, integrations and commerce builds turn out to be the lessons that decide whether an AI system reaches production. Five of them.
Enceladus AI is the AI consultancy of a group that has built enterprise solutions, integrations and commerce systems since 2006. Its clients have included Hearst Magazines, Bauer Media, Krispy Kreme, Raspberry Pi and The Royal British Legion. We have built machine learning into that work for most of those twenty years, and the generative wave did not change the lessons that decide whether an AI system succeeds. They are the ones we had already learned, expensively, on everything else. Five of them.
1. The integration is the project
Every platform build we have ever delivered was, in the end, an integration project: the ERP, the warehouse system, the PIM, the payment provider, the courier, the CRM, each with its own conventions and its own owner. AI is the same. A support agent is an integration with the helpdesk and the repositories; a knowledge assistant is an integration with the document stores and the identity provider; a forecasting model is an integration with three systems that disagree about product codes. The model is the easy part. Businesses that choose an AI partner on its model knowledge and not its integration experience find this out in month three.
2. The data is never as described
“The sales history is in the ERP” means it is in three ERP instances, overwritten monthly by the warehouse system, with a manual step in the finance export. We learned to audit before we build, on every platform project, and the discipline transfers unchanged: the data audit is the first scoping task of every data-dependent AI use case, and the audit result decides the sequence. The most consistent finding of our discovery programmes, that data and not technology is the constraint, was not a surprise to anyone who has migrated a product catalogue.
3. Change management is the delivery
A platform that people do not use is a line in a budget. We learned to run champions, phased rollouts, training on real tasks and measurement of what changed, because the alternative was a launch followed by silence. An AI rollout is the same work: governed access by role, enablement on each function’s own tasks, time saved measured on sampled work. The tools are new; the discipline of making a business actually adopt something is twenty years old.
4. The client should never be held hostage
Platforms built on a vendor’s proprietary stack, with the code and the data in the vendor’s service, became hostages when the vendor repriced or disappeared. We learned to build on open foundations, keep the client’s data in the client’s hands, and agree at the start what happens to the system if the relationship ends. In AI that also means a change of model that is a configuration change, not a rebuild.
5. The production path is where projects die
The prototype that impressed everyone and the system that runs are different things, and the distance between them is monitoring, permissions, audit, support, integration and an owner. On platform projects we learned to scope the production path before the build, with the run model and its cost in the quote. On AI projects the same gap is where most pilots stall, and the same fix applies: the evaluation set, the escalation design, the ongoing support, all agreed before a line of code.
What is actually new
The model, and what it can do with unstructured knowledge, code and language. That is a real step change and it is why Enceladus AI exists. But the reason our AI systems reach production is not that we understand models better than a startup; it is that we have spent twenty years learning what happens after the demo, on systems that had to run.
The group’s history is on the about page; what it means for AI builds is under AI development.