Local models and data sovereignty, in plain words
A local model is an AI model that runs on a computer you own. Data sovereignty means you decide where your data lives. Here is when the two matter for your company, and when they don't.
Paste a customer's file into a chatbot and it leaves your building. It goes to a computer owned by the company that makes the chatbot. For a lot of work that's fine. For some of it, it's a problem you won't find out about until a client or a regulator asks where the file went.
What a local model is
A local model is an AI model that runs on a computer you own. It can sit in a closet in your office or in a rack you rent space for. You type, it answers, and nothing crosses the internet.
Running a model means it answers questions. Training it means you've fed it your own documents, so its answers know your terms and sound like your company. You can do both on your own hardware.
The models you can run this way are smaller than the biggest cloud models. Not long ago that made them toys. It doesn't now. A good local model can read documents, pull out the numbers, draft replies, sort incoming email and answer questions about your own files. That's a lot of the daily work in an office.
What data sovereignty means
It means you decide where your data lives, who can read it and which country's law applies to it.
When your data sits in a vendor's system, the answer to those questions is whatever the contract says this year. When it sits in your own database on your own hardware, you can point at the room it's in and name who has the key.
When it matters
The clearest case is data that's somebody else's secret, like patient files, tenant records or deal documents under an NDA. Your own financials during a sale count too. If you handle patient files, you already know this conversation.
The second case is heavy, steady use. A model that reads every inbound document all day is cheap to rent in a trial and expensive to rent forever. Hardware is a purchase you make once.
Training is another. Training teaches a model how your company writes a proposal or prices a job. Plenty of owners don't want that living on someone else's servers.
And sometimes a contract or a regulator settles it for you by saying the data stays put. That's the dull half of this subject, and it's the half that gets companies in trouble. If a rule says certain records stay under your control, a system that never sends them anywhere is the simplest way to show you followed it.
When it doesn't
A lot of our own AI work still runs on cloud models. For hard reasoning they're better. For work with nothing sensitive in it, there's no reason to buy hardware.
A small team trying AI for the first time should rent. Find out what's useful before you buy a machine.
There's a middle path, and it's where we'd steer a lot of companies. Keep the sensitive work on your own machine and send the rest to the cloud.
What owning the hardware costs you
You take on the machine. It needs power, cooling, updates and someone who notices when it stops.
We know because we run our own. Our CRM and our booking system run on a server we own. In August it went down because log files filled the disk. We cleared them and set the logs to rotate. Nobody at a cloud company was going to do that for us.
So count that in. If nobody on your team will notice a dead machine on a Saturday, you need someone who will.
What we do about it
We size the hardware for the work and set it up. We install the models and train them on your documents. Then we run it. We do this for one office, and we do it at enterprise scale.
Before any of that, we'll tell you which of your work belongs on your own hardware and which doesn't. Sometimes the answer is none of it yet.
Want to talk through a build for your company?
Talk to the Team