Technology selected for the project – not the other way around.

Model selection is an architecture decision

A model can perform very well for one use case and be unnecessarily expensive or unsuitable for another. We therefore consider not only output quality but also latency, cost, data processing, context length, structured outputs, tool use, availability and the ability to change providers later.

Tests on your own tasks matter more than generic rankings

Public benchmarks can provide orientation, but they cannot replace evaluation with representative inputs from your own process. For production systems, we define test cases and expected quality criteria before committing to a provider.

Open source and on-premise

Local or self-hosted models can make sense where data control, specialised infrastructure or particular operating requirements are important. They are not automatically cheaper or safer: hardware, updates, scaling, access controls and evaluation all need to be included in the decision.

Security and risk management belong in the architecture

For production AI capabilities, access controls, output validation, permission boundaries, monitoring and deliberate handling of non-deterministic outputs are part of the engineering work. External frameworks such as the NIST AI Risk Management Framework and the OWASP GenAI Security Project can provide useful orientation. They do not replace project-specific security analysis, but they can support a systematic review of risks.

Limit provider dependency where it makes sense

Where appropriate, we separate business logic from provider-specific APIs. Models are still rarely completely interchangeable because capabilities, prompting and tool use differ. Those differences should be tested and documented rather than hidden behind an overly simplistic abstraction.