Choose the model for the job, the data and the operating environment.
A company does not need to own a new foundation model to have a company-specific AI application. Most requirements can be addressed by selecting an approved model, integrating the right knowledge and designing the surrounding system carefully.
What is the least complex model arrangement that meets the job?
Evaluate representative tasks and operating restrictions first. Add hosting ownership or customization only when it resolves a measured requirement.
Select the arrangement, not just the model.
Different needs, different mechanisms.
Current company knowledge
Governed retrieval and source updates
Fine-tuning does not keep changing documents current
Repeatable task behavior
Prompting, structured output and application evaluation
A model leaderboard cannot establish application quality
Specialized learned behavior
Consider fine-tuning with a labeled dataset
Require measurable benefit and a lifecycle plan
The most powerful model may be the wrong component.
A smaller or managed model can be sufficient. Self-hosting moves obligations into infrastructure and operations; it does not remove cost or dependency risk.
Inspect the task evaluation before the model choice.
- Realistic task distribution, adversarial and negative examples
- Observed quality, latency and cost with stated limitations
- Documented terms, retention, location, licensing and upgrade expectations
The complete model deployment argument
For CTO, Head of AI, CIO
The situation behind the request
A technology team is comparing three deployment options: managed enterprise inference, private-cloud infrastructure and licensed open-weight hosting. Each can satisfy some requirements while introducing different security, cost, operations and feature trade-offs.
Where the obvious solution falls short
Model marketing benchmarks do not describe performance on a particular business task. Fine-tuning does not keep changing documents up to date. Self-hosting can move costs into infrastructure, operations, upgrades and security responsibility.
How we would approach the work
We define target tasks and restrictions, run representative evaluations, compare model quality/latency/cost and plan integration, monitoring and lifecycle changes. Fine-tuning is considered only when a labeled dataset and measurable improvement justify it.
What the engagement may include
- Requirements and deployment decision record.
- Representative task tests and vendor/model comparison.
- Approved inference layer, observability and fallback design.
- Fine-tuning feasibility or private hosting plan when justified.
The choices worth making explicitly
The most powerful model is not always the best system component. A smaller or managed model may be sufficient. A model provider may change capabilities, costs or terms; architecture should manage those dependencies explicitly.
What we would test before calling it ready
Evaluate on actual task distribution including adversarial inputs and negative examples. Document data handling, licensing, location, retention, allowed usage and response expectations for selected providers.
A sensible first step
Choose an application problem and an evaluation set before choosing the model. A credible decision follows observed performance and operating constraints.