In September, Meta offered customers a 95% discount on its Muse Spark model in return for being allowed to watch how they used it[1]. That sums up the decision. The cheap enterprise option wasn’t cheap; the price was paid in data instead of cash. Palantir’s Alex Karp has made the same point more bluntly, arguing against what he calls the “token industrial complex” and for platforms that give a business real control over its data. Whatever you think of his framing, the choice underneath it is real.

For a regulated advice firm it comes down to this. Host an open model yourself and you keep the data, but a breach is entirely yours. Rent an enterprise API and you get support and some indemnity, but your clients’ data goes off-site. Choose on the risk your firm could survive, not on a benchmark score.

Liability matters more than which model is smarter

The question that decides this is who carries the liability when the data belongs to a client. For a small regulated firm, a few points on a leaderboard barely register next to the cost of a breach and the regulatory attention that follows it.

Under UK GDPR, when you put a client’s personal data into any AI system, you’re the data controller. The responsibility is yours whether the processing happens on a server in your office or on a vendor’s platform abroad. A cleverer model doesn’t change that, and no vendor takes it off you.

So the right model is the one whose way of failing your firm can absorb. A capability question has a tidy answer. A liability question depends on what your particular firm could survive.

Where self-hosted and rented models differ

Data residency. A self-hosted open-weight model keeps client data on hardware you control. An MIT-licensed model, for example, lets a firm avoid per-call cloud costs and keep data in-house[2]. Some open models are now built to run on consumer-grade hardware with roughly 24 to 32GB of video memory, which makes a private, always-on set-up feasible for a small office[3]. A rented API sends the data to wherever the vendor runs.

Cost. Self-hosting swaps per-token fees for fixed hardware and running costs. Renting is cheaper to start and grows with use, but the useful features cost extra. On one provider, a 99.5% uptime guarantee carries a 75% price premium, while keeping data in a chosen region adds only about 10%[4]. Reliability is the expensive part, not residency.

Support. This is where renting earns its money. You get support, service-level guarantees and usually some contractual indemnity. Self-host and you get none of that: you’re the support desk.

Training-data terms. The better enterprise contracts now promise not to store your prompts or train on your data. That standard exists, but it’s a clause to check before you rely on it.

Put side by side, one option buys support at the cost of residency, and the other buys residency at the cost of everything the support was doing for you.

Self-hosting moves the liability onto you

Cycle diagram showing continuous maintenance steps required for self-hosted AI models.
A self-hosted model needs ongoing maintenance to stop it quietly drifting. Research cited by McKinsey puts the possible loss at around 40% of performance. AI-assisted diagram

The “full sovereignty” pitch tends to skip this part. Self-hosting does improve data residency. It doesn’t remove the liability, though. It moves it onto a firm that may not be set up to carry it.

Once the model is yours, so is everything around it: patching, uptime, security hardening and drift. Drift isn’t minor. Research cited by McKinsey found AI systems can lose around 40% of their performance after deployment without active management[5]. A model that was accurate in January can be quietly wrong by summer if nobody is watching. There’s also the homework before download that rarely gets done properly: licence checks, provenance, the real hardware requirement and the data-use terms attached to the weights[6].

“Sovereign” is also a label rather than a fact. A model can be served on EU infrastructure and still be a Chinese lab’s open weights running on someone else’s servers[7]. What counts is where the data physically sits and who runs the stack, not the vendor’s nationality. Honestly defined, sovereignty is data locality plus the skill to run the thing safely. If your firm has that skill, self-hosting is a real option. If it doesn’t, a managed deployment hosted in your region gets most of the residency benefit without pretending you have a platform team. (Our page on open-weight AI models for business goes further into that option.)

What leaves the building when you rent an API

Renting has an exposure that’s easy to state and easy to underestimate. Three things leave the building:

  1. The client data. It goes to the vendor’s servers to be processed. The no-training promise helps, but it’s a contract term you have to confirm applies to your account, not a property of the technology.
  2. Your assumptions about which tier you’re on. Privacy terms for AI APIs are often opaque and vary a lot by pricing tier[8]. The protection you’re counting on may only exist on the paid enterprise tier, not the free or promotional one a firm can drift onto by default.
  3. Control over where regulated work goes. This is the one that catches people out. Regulated data and confidential client work should stay off “contributor” and discount tiers however good the price, because those tiers are cheap precisely because they use your data[9]. The 95% discount and the data-sharing clause are the same deal.

So “enterprise APIs have already solved off-site risk” doesn’t hold on its own. The no-training standard is real, but it has to be checked tier by tier, and the tier a small firm lands on by default often isn’t the one the protection covers.

Three steps to decide which risk your firm can carry

Flowchart showing three evaluation steps to select AI model hosting based on liability.
Separate out the non-sensitive work first, then confirm in writing that the protections apply to your account's tier. AI-assisted diagram

You can make this decision properly this week, without a procurement project.

Sort the data by sensitivity. Separate regulated client data from general-purpose work. A good share of what firms want to automate often doesn’t involve client personal data at all, and that part is easy either way.

Name who carries each failure. Write down who in the firm absorbs a data breach, and who absorbs a day of downtime. If the honest answer to the breach question is “nobody could”, keep that data in-house or keep AI away from it for now. If the honest answer to the downtime question is “nobody could”, rent the uptime rather than build it.

Check the tier terms in writing before any client data goes in. The contract for the exact tier your account is on, not the marketing page. Our guide to reading an AI vendor contract covers which clauses to look for.

This article is for informational purposes only and does not constitute regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.

This article does not constitute legal advice. Data protection obligations vary by circumstance and jurisdiction. Consult a qualified solicitor or data protection adviser for advice specific to your firm.

Sources

[1] TechCrunch, ‘Meta is paying to peek at how you use their latest AI model’, 3 September 2026. Available at: https://techcrunch.com/2026/09/03/meta-is-paying-to-peek-at-how-you-use-their-latest-ai-model/ [2] Digital Applied (2026) ‘Baidu’s unlimited OCR 3B for document automation’. Available at: https://www.digitalapplied.com/blog/baidu-unlimited-ocr-3b-document-automation-2026 [3] Digital Applied (2026) ‘Meta Muse Glimmer 30B: an Apache 2.0 local agent model’. Available at: https://www.digitalapplied.com/blog/meta-muse-glimmer-30b-apache-2-local-agent-model-2026 [4] Digital Applied (2026) ‘Mistral hosts rival open models on regional endpoints’. Available at: https://www.digitalapplied.com/blog/mistral-hosts-rival-open-models-regional-endpoints-2026 [5] Zen van Riel (2026) ‘Understanding data drift detection’, AI Engineer Blog, citing McKinsey research on post-deployment performance decay. Available at: https://zenvanriel.com/ai-engineer-blog/understanding-data-drift-detection [6] Digital Applied (2026) ‘Qwen3-8 open weights: a checklist before you download’. Available at: https://www.digitalapplied.com/blog/qwen3-8-open-weights-checklist-before-download [7] Digital Applied (2026) ‘Mistral hosts rival open models on regional endpoints’. Available at: https://www.digitalapplied.com/blog/mistral-hosts-rival-open-models-regional-endpoints-2026 [8] Digital Applied (2026) ‘Free and promo tier data terms: a census’. Available at: https://www.digitalapplied.com/blog/free-and-promo-tier-data-terms-census [9] Digital Applied (2026) ‘Muse Spark contributor tier economics and trade-offs’. Available at: https://www.digitalapplied.com/blog/muse-spark-contributor-tier-economics-tradeoffs