Skip to content
suus
All insights

The model is the smallest part of the system.

Enterprise AI projects rarely fail because the model was not clever enough. They fail on data, evaluation, integration and operations. That is where the engineering should go.

SUUS5 min

Model choice takes up a disproportionate amount of enterprise AI conversations. Which provider, which version, which benchmark. It is the most visible decision and, in most production systems, one of the least consequential.

Models are increasingly interchangeable. Frontier models converge, open-weight models catch up, prices fall. A system built well can swap its model in an afternoon. A system built badly cannot be saved by a better model.

Where the system actually lives

  • Data: what the system may know, how it is retrieved, how permissions are enforced at retrieval time, and where it physically lives.
  • Evaluation: a test set built with domain experts, run before every release and continuously in production. Without it, quality is an opinion.
  • Integration: the systems of record, the identity provider, the event streams. Intelligence that cannot act on real data is a demo.
  • Operations: tracing, cost per request, latency, fallbacks, human escalation. The three-in-the-morning question.
  • Governance: audit trails, access control, approval steps where decisions carry weight.

None of these are model problems. All of them are engineering and product problems, and they are the reason a system either earns trust inside an organisation or quietly gets switched off.

Sovereignty is a design decision, not a checkbox

For European organisations, where data is processed is not a footnote. It shapes the architecture: which models can be used, whether inference runs in a public cloud, a private one, on-premise or on device, and what the fallback is when a provider changes terms. Deciding this late is expensive. Deciding it early is just design.

A system built well can swap its model in an afternoon. A system built badly cannot be saved by a better model.

So when the conversation turns to which model, we try to turn it back. Where does the data live. How will we know it works. What does it connect to. Who is called when it fails. Answer those, and the model becomes what it should be: a component.

Tell us what should exist.

Bring the brief you are not sure anyone can build.

Start a project