Why financial data should never leave the building
Sending your general ledger to a hosted model is a business decision dressed up as a technical one. The question is not whether the vendor is trustworthy today — it is what happens to your financial history across a decade of contract renewals, ownership changes, jurisdiction shifts and subprocessor updates you will approve by not replying to an email. For controlling data specifically, the sovereign answer has become cheap enough that the convenience argument no longer holds.
What actually leaves when you use a hosted model
People underestimate the payload. A controlling assistant does not send “a question” — it sends the context needed to answer it. In practice that is customer names next to overdue balances, project margins, salary aggregates, supplier terms, and the forecast you have not shown your bank yet.
Three consequences follow, none of them about a vendor behaving badly:
- Concentration. Your competitors’ financial context sits in the same system. Any future policy change about training, retention or analytics applies to all of it at once.
- Jurisdiction. Where inference happens determines which authority can compel disclosure. Contracts allocate liability; they do not relocate servers.
- Durability. Model endpoints get deprecated. Your obligation to explain a 2026 forecast to an auditor in 2031 does not.
What running locally now costs
The economics changed quietly. A controlling workload is not a chatbot for ten thousand users; it is a handful of long-running analytical passes over structured data, mostly at night. The characteristics that make general-purpose hosted inference attractive — elastic demand, unpredictable spikes — barely apply.
Open-weight models in the small-to-mid parameter range now handle the tasks that matter here: extracting structure from documents, classifying transactions, summarising deviations, drafting explanations. Reasoning about a variance is not the same problem as writing poetry; you can be several capability rungs below the frontier and still be right about why margin moved.
The real cost is not the GPU. It is operations: someone has to own model versioning, evaluation and the boring discipline of checking that last month’s prompt still produces last month’s quality. That work is real, and it is exactly the work you are paying a vendor to hide from you — which is fine until the number in the board pack is wrong and nobody in the room can explain why.
Sovereignty is not the same as isolation
A sovereign system is not one that refuses to touch the internet. It is one where you decide, per data class, what crosses the boundary.
A workable split for a finance function looks like this:
- Never leaves: ledger lines, customer identities, salaries, forecasts, board material.
- May leave, anonymised: aggregate benchmarks, industry statistics.
- Comes in freely: public market data, regulatory texts, supplier news, currency rates.
The intelligence a CFO needs about the outside world is mostly public. The data that must stay inside is mostly yours. Once you draw that line explicitly, the “we need the cloud for capability” argument mostly dissolves — you need the cloud for public signal, which is not where the risk lives.
The audit argument nobody makes early enough
Here is the version that wins the internal discussion faster than any privacy argument: an auditor asks how a figure in the annual report was produced. If the answer involves a hosted model whose weights have since been retired and whose prompt logs were retained for thirty days, there is no answer.
Local deployment makes reproducibility a matter of keeping a container image and a weights file. That is a solved problem in every other part of the finance stack, and it is the reason sovereign AI in controlling is less an ideological position than an accounting one.
- local LLM
- data sovereignty
- controlling
- security