Every month a new model is the best one. The organizations that will be glad of that in three years are the ones that designed their AI systems so the model could be replaced on a Tuesday afternoon. For everyone else, the model choice quietly became the architecture.
The question we hear most from leadership teams is some version of which model should we use. It is a fair question and it is the least durable decision in the whole system. Capability, price and terms move every quarter. What does not move, and what decides whether an AI system is an asset or a liability, is everything built around the model: the data it is allowed to see, the actions it is allowed to take, the way its output is checked, and what happens when it is wrong.
What the system is actually made of.
Strip the vendor names away and a production AI system is five things. A data layer that decides what the model sees, with contracts about freshness, lineage and permission. An orchestration layer that decides what the model does, in what order, with what tools, and when a person is in the loop. An evaluation layer that measures whether the output was right, continuously, against cases the business owns. A governance layer that logs what happened, who approved it and what the model could and could not touch. And a fallback: the behavior of the system on the day the model is down, degraded, or replaced.
The model is one component inside that. An important one, in the way an engine is important to a car. Nobody buys a car for the engine's brand and then discovers it has no brakes.
A vendor that can only build on one model is selling you their contract, not your system.
Where it runs is a governance decision.
The second question, usually asked later than it should be, is where the model runs. There are five honest answers and each is right for someone. Hosted frontier models under enterprise terms, where no training on your data is contractual and retention can be set to zero. Models inside your private cloud, under your keys and your network boundary. Open-weight models on premises, where nothing leaves the building. Privately trained or fine-tuned models the organization owns outright. And air-gapped deployments for sovereign and regulated environments, where the question is not cost but jurisdiction.
A client in Doha with public-sector data has a different right answer from a consumer company in Miami, and a different one again from a fund in London with fiduciary obligations. The engineering is not harder in any of them. The mistake is choosing the deployment after the system has been designed around one, when it should be the first constraint the architecture inherits.
What to ask a vendor.
If you are evaluating a firm to build an AI system, four questions sort the field quickly.
- Show me a system you built where the model was changed after launch. What had to be rewritten?
- Where does the evaluation set live, who owns it, and how often does it run?
- If we required this to run on premises next year, what would change?
- Which part of your fee depends on which model or platform we choose?
The last one is the quiet one. A firm that resells a platform, or holds a partnership that pays on volume, is not lying to you when it recommends that platform. It is simply unable to recommend anything else. Agnosticism is not a slogan; it is the absence of that incentive, and it is the only condition under which the recommendation can be the answer to your problem rather than the answer to theirs.
- Decide where it may run before you decide what it does. Jurisdiction, data classification and regulator first; model second.
- Own the evaluation set. Real cases, scored by your people, run on every change. This is the asset that outlives any model.
- Put the model behind an interface. Swapping it should be a configuration change and a test run, not a project.
- Design the fallback on day one. What the system does when the model is wrong, slow or gone is part of the system.
- Keep the keys. Repositories, prompts, data contracts and logs belong to you from the first commit.
Why we build this way.
ZTG resells no products and holds no model partnership that pays on usage. Our engineers hold the certifications enterprise clients expect, including Microsoft, cloud platform and security credentials, so the system is built on the stack your estate already runs. The model inside it is whichever one your data, your regulators and your risk allow, and the system is designed so that answer can change. The five deployment options are on the AI engineering page; the assessment that tells you which one you need is the AI lens of the Compass Program.
The model is a component. The system is the product. Build the product.