The model is a decision, not a default.
Most providers quietly build everything on one AI model and hope it fits. We don't. The right model depends on your data, your rules, and what the work actually needs — so we choose deliberately, and we're honest about the tradeoffs. Here's how, and why it matters more than almost anyone admits.
Almost everyone is using AI. Almost no one is getting value from it.
That sounds like a contradiction. It isn't. Adoption has gone nearly universal in two years, but the share of organizations that can point to real money saved or earned has barely moved. The gap between "we use AI" and "AI changed our bottom line" is the central fact of this moment — and it's the reason we built the practice the way we did.
Use is everywhere. Scaling past a pilot is rare. Measurable bottom-line impact is rarer still — roughly one company in twenty. Two independent studies, McKinsey and MIT, landed on nearly the same figure.
The model was never the hard part.
When projects fail, people blame the AI. The research says otherwise. McKinsey's own framing is that getting value from AI is roughly 20% the algorithm and 80% organizational rewiring — and that the companies who succeed don't bolt a model onto the tools they already have. They rebuild the process around it, and they re-platform their content and knowledge so the system has something reliable to work from.
That is the unglamorous middle of the work, and it's where most of the value and most of the failure live. Choosing a capable model is necessary. It is nowhere near sufficient. The structure underneath it is what decides whether the thing works in production or quietly gets abandoned after the demo.
Cost savings cluster in engineering, IT, and operations. Revenue gains cluster in marketing, sales, strategy, and product. Different work needs different tools — which is exactly why a single default model is the wrong starting point.
Three ways to build it. We pick for the job, not for a vendor.
Here is the actual choice, in plain terms. Each option is right some of the time. Most of what makes us useful is knowing which one fits your situation, and saying so.
It runs in your environment
We deploy the model inside an environment you control rather than sending your information to an outside company's service. Your data, your documents, and the model that reads them all stay within your boundary. For the technically inclined: this is what open source models make possible — models you can host yourself instead of renting through an API.
For an organization with confidentiality obligations — client files, legislative strategy, regulated records — this isn't a nice-to-have. It's often the only version that's allowed. It also makes your costs predictable and frees you from another company's pricing changes, terms, or decisions to retire a model you depend on.
Privacy, compliance, or cost control lead the decision. Sensitive or regulated data. You want to own what you run.
The most capable models aren't always the ones you can self-host, so raw capability can trail the absolute frontier.
The most capable models available
Sometimes the work needs the strongest model that exists, and the data involved is fine to process through a leading provider. When that's the case, we use it. There's no virtue in hobbling a project to make a point about hosting.
The judgment is matching the data to the method: a public-facing tool working with non-sensitive information is a very different risk picture than a system handling confidential records, and we treat them differently.
Maximum capability matters most and the data permits it. Public or low-sensitivity information. Fast-moving needs.
Data is processed by an outside provider, costs scale per use, and you depend on their pricing and terms.
A blend of both
Often the smartest answer is neither extreme. One system can keep sensitive work inside your environment and reach for a frontier model only on the steps where the data is safe and the extra capability earns its place. The boundary holds where it needs to; the power shows up where it helps.
This is where the deliberate, case-by-case approach pays off most — and where a provider wedded to a single model simply can't follow.
Different steps have different needs. You want control where it counts without giving up capability elsewhere.
More moving parts to design and maintain. Worth it when the work genuinely has both kinds of step.
How we decide
There's no universal answer, only the right answer for your situation. These are the questions we work through with you before a line of code gets written.
How sensitive is the data?
Client records, regulated information, and legislative strategy set the floor. The more sensitive the data, the stronger the case for keeping it in your environment.
What are the rules you answer to?
Industry regulation, contractual confidentiality, and internal policy can make private deployment a requirement rather than a preference.
What does the work actually require?
Some tasks need the strongest model that exists. Many don't. Matching capability to the real need keeps you from overpaying for power you won't use.
What do you need spending to look like?
Per-use pricing can scale against you as adoption grows. A model you host yourself trades that for predictable, controllable cost.
The right answer depends on your situation.
Tell us about the work and the data behind it, and we'll tell you straight which approach fits — including when the honest answer is "you don't need much here yet."
Start a conversation