Enceladus is the AI consultancy of a group that has built enterprise platforms, integrations and commerce systems since 2006, for brands from Siemens and Nestlé to Hearst, Krispy Kreme and West Ham United. When we started the AI work, we expected to learn a new discipline. What we found was that the lessons that decide whether an AI system succeeds 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 own what they paid for

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 and hand the client the code. It is why what we build in AI is the client’s: code, prompts, indexes, evaluation set, documentation, no licence, no per-seat fee, and a change of model that is a configuration change.

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 managed service or handover, 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 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 frameworks and agent build.