Custom Domain Models vs Frontier APIs for Regulated Teams

For most regulated teams the answer is both. A frontier API is usually the stronger choice for open-ended reasoning, drafting and work where the questions are hard to predict. A custom domain model, adapted from open weights and hosted under your control, earns its place on narrow, repeatable tasks where you need pinned behaviour, data that stays where you put it, and an audit trail you can reproduce months later. The practical design routes routine domain work to your own model and sends the hard cases to a frontier model, under one policy.

That is a short answer to a question with real trade-offs on each side. Financial services firms, health providers and public bodies face the same underlying tension: the most capable models are hosted by someone else, and the duties to explain, reproduce and control sit with you. This post sets out where each option wins, where it costs you, and how a hybrid fits together. For the product side, see custom models on Swfte.

What does control mean in practice?

With a frontier API, you control the request and you read the response. The weights, the serving stack, the safety layer and the update schedule belong to the provider. Contract terms can narrow how your data is used, and many providers offer enterprise options, but the model itself is a service.

With a custom domain model, you hold the weights. You decide where they run, who can call them, what logging surrounds them and when they change. That is the core of owning your model: the artefact is yours to keep, inspect, move and retire.

Neither is automatically better. Holding weights means holding responsibility for everything the provider used to do for you.

Where does the data go?

Data residency is often the first question from a risk committee. With a hosted API, the prompt and any retrieved context travel to the provider's infrastructure. Regional endpoints and contractual commitments help, and they need careful reading: where inference runs, where logs are stored, who can access them for support, and which jurisdiction the provider answers to. Our piece on what in-region inference must mean goes through those questions in detail.

A self-hosted model removes the transfer for the requests it serves. The data stays in your environment or in a dedicated deployment you chose. That simplifies the residency story for the work routed to it, though the rest of your estate, including retrieval stores and logs, still needs the same scrutiny.

Can you reproduce last quarter's answer?

This is where the two options differ most for regulated work. Suppose a supervisor or an internal auditor asks why a model classified a transaction the way it did in March. To answer properly you need the input, the output, the policy that applied and the exact model that produced it.

With pinned weights you can reload the precise version, with its checksum, and re-run the case. With a hosted model, the version behind an endpoint name can change, and older versions are eventually withdrawn. You can log every input and output, which you should do in any case, but you may not be able to reproduce the behaviour that produced them.

How fragile is relying on a hosted model?

Hosted models get updated, deprecated and sometimes altered in ways that change outputs. Safety layers are tuned, system prompts change, older snapshots are retired. Providers announce most of this, and good teams track it, but each change is a revalidation event you did not schedule. For a workflow that a regulator expects to behave consistently, an unplanned change is a governance problem as well as a technical one.

There is also concentration risk. If one provider carries every model-dependent process, an outage, a commercial dispute or a change in terms affects all of them at once. A self-hosted model is not immune to failure, but its failure modes are yours to manage.

Are frontier models simply better?

On open-ended reasoning, long and messy documents, unfamiliar questions and broad general knowledge, the strongest hosted models are usually ahead of anything most organisations can host themselves. Pretending otherwise leads to poor decisions.

The gap narrows sharply on narrow tasks. Classifying a complaint against a fixed taxonomy, extracting fields from a standard form, drafting a summary in a mandated structure: these reward consistency more than breadth. A smaller open-weight model adapted on good examples can match or beat a general model on such a task, and it will behave the same way in the thousandth case as in the first. The only way to know for your task is to measure both on the same held-out set. The evaluation burden is part of the choice.

How does the cost shape differ?

A frontier API is pure usage cost: you pay per call, nothing up front, and the bill grows with volume. It suits low or unpredictable volume and tasks where capability matters more than unit price.

A custom model moves cost earlier and into people. You pay for data preparation, evaluation, safety testing, serving capacity and an owner for the model's lifetime. Once that is in place, the marginal cost of each request on a well-utilised deployment tends to be lower. High, steady volume on a narrow task is where that shape works out. Our analysis of private AI and on-premises economics covers when owning capacity makes sense more generally.

Who carries the safety and evaluation burden?

With a hosted model, the provider runs its own safety training and testing, and you add your own controls on top. With a custom model, the whole burden moves to you. Fine-tuning can weaken safety behaviour the base model had, so a tuned candidate needs refusal, over-refusal and prompt-injection testing before release, and again after every change. You also own drift monitoring, incident response and retirement.

Operations follow the same pattern. Someone has to patch the serving stack, size capacity, watch latency, rotate credentials and keep the deployment documented. Teams that underestimate this tend to end up with a model nobody wants to touch.

What does a hybrid pattern look like?

The pattern most regulated teams arrive at puts a gateway in the middle. Applications and agents call one API. Behind it, routine domain work goes to your own model, and anything outside its scope, such as an unusual case, a long free-text question or a low-confidence result, goes to a frontier model that your policy allows for that data class.

On Swfte, the pieces for this exist today. You upload weights you have trained into Model Vault, which records a checksum manifest and the base model, keeps versions and promotes them through stages before deploying to a dedicated endpoint; see deploy and serve. Connect then provides one OpenAI-compatible API in front of that endpoint and the frontier providers you use, with routing, failover, usage caps, cost tracking, content-policy checks with redaction, and an audit event stream. For hosting open-weight models more broadly, deploy models covers the options.

What is not built: Swfte does not yet run managed fine-tuning for customers, and named domain evaluation suites and automated red-teaming are on the roadmap. You bring trained weights; the hosting, routing and audit around them are in place.

What do regulators expect, in general terms?

Expectations differ by sector and jurisdiction, and this is not legal advice. Across financial services, healthcare and the public sector, some common threads appear: know which models you use and for what, assess the risk of each use, keep records that let you explain and reconstruct decisions, keep humans accountable for consequential outcomes, and manage third-party dependencies.

Frameworks such as the EU AI Act and GDPR shape an organisation's obligations, and its posture under them depends on the use case, jurisdiction, deployment and configuration. No model choice delivers that posture on its own. What a platform can do is provide technical controls and evidence that help an organisation meet its own obligations: version records, audit logs, access controls, data that stays in a chosen place, and evaluation results kept with the model. Swfte's company attestations and security approach are set out on the trust page.

A decision checklist

Work through these for each task you are considering:

1. Is the task narrow and stable, with a clear definition of a correct output?
2. Is the volume high and steady enough to justify an owner and serving capacity?
3. Does the data class allow it to leave your environment, and under what terms?
4. Do you need to reproduce outputs exactly at a later date?
5. Have you measured a frontier model and a candidate domain model on the same held-out set?
6. Can you staff safety testing and re-testing after every change?
7. Is the base model's licence, read from the file shipped with the exact weights, acceptable for your use?
8. What happens to the process if the hosted model you rely on is changed or withdrawn?
9. Who owns the model, and who decides when it is retired?

If most answers point towards control, reproducibility and steady volume, a custom domain model is worth building for that task. If they point towards breadth, low volume and fast iteration, a frontier API under good policy is the sensible default. Most organisations will find tasks in both columns, which is why the gateway in the middle matters more than the choice of any single model.

Further reading: Open-Weight vs Closed Models: Risk for Regulated Teams.