Field note
Local AI vs Cloud AI: Privacy and Trade-offs
Map the whole data path for both options, including prompts, logs, model files, telemetry, updates, operators and backups, before deciding which is more private for your business.
Map the whole data path for both options, including prompts, logs, model files, telemetry, updates, operators and backups, before deciding which is more private for your business.
The question behind the question
When a UK business owner asks whether local AI is more private than cloud AI, the real question is usually one of three: "Will my customer data end up training someone's model?", "Will my data leave the UK?", or "Who can read what my staff type?". Each has a different answer, and "local" only settles the first one cleanly.
Local AI here means a model running on hardware you control: a workstation with Ollama or LM Studio, or a server in your office or a UK data centre you rent. Cloud AI means a vendor service such as ChatGPT, Claude, Gemini or Microsoft 365 Copilot, on a business plan.
Side-by-side comparison
| Question | Local AI | Cloud AI (business plan) |
|---|---|---|
| Does the prompt leave your network? | No, if the service is bound to localhost or your LAN and no remote features are enabled | Yes, to the vendor's infrastructure; region depends on the vendor and plan |
| Used for model training? | No | The main vendors document that business-plan content is not used for training by default; consumer plans differ |
| Who can read prompts and outputs? | Anyone with access to the machine, its logs and its backups | Vendor staff under their access controls, plus your own admins via audit tools |
| Access control and audit | Whatever you build; Ollama's API has no built-in authentication | Single sign-on, admin roles, audit logs and retention settings are standard |
| Retention | You decide, but you must also implement it | Configurable within vendor limits; documented retention periods |
| Model quality and capacity | Limited by your hardware; smaller models | Frontier models, no local hardware, usage limits |
| Patching and updates | Your job, including the model runtime and every plugin | Vendor's job |
| Cost pattern | Hardware and admin time up front | Per-seat subscription |
| UK GDPR position | You are controller and processor in one; no international transfer | Vendor is a processor; check data processing terms and transfer mechanism |
The point of the table is that "local" removes a network transfer and a vendor, and in exchange makes you responsible for everything the vendor was doing. For a business with no IT lead, that trade often reduces privacy in practice, because the local machine ends up shared, unpatched, exposed on the office Wi-Fi and backed up to a personal cloud drive.
Where local AI is genuinely better
Local is the right answer when the data must not leave your control at all. Examples: a solicitor summarising privileged material where firm policy forbids third-party processing; an engineering firm handling export-controlled material; an accountancy practice testing whether a model can classify transactions before it goes near client data. It also suits experiments where you want to learn what a model can do without any account, plan or terms to review.
Local is only better if you do the work. Bind the service to localhost, keep the machine patched, keep model files and logs off shared drives, and include the machine in your backup and retention rules. Our note on securing Ollama on port 11434 covers the specific settings.
Where cloud AI is genuinely better
Cloud is the right answer for most UK SMEs doing everyday work: drafting, summarising, meeting notes, code, spreadsheets and customer replies. The business plans give you a processor agreement, documented retention, admin controls, audit logs and single sign-on. Those are the controls the ICO expects you to be able to show, and they cost far more to build yourself than to switch on.
The privacy work moves from "keep it off the network" to configuration and policy: choose the business plan rather than personal accounts, set retention, disable features you do not need, decide which data classes may be entered, and put those decisions in writing. Our AI governance review turns those choices into a maintained control set.
Recommendation by business situation
- Under ten staff, no IT lead, general office work. Cloud, on a business plan, with personal accounts blocked. Local AI on someone's laptop is a shadow IT risk, not a privacy control.
- Regulated professional practice with client confidentiality rules. Cloud on a business plan for general work; local for the specific matters your professional body or client contract says must stay in-house. Write down which is which.
- Firm with a competent IT lead and a real reason to keep data in-house. Local on a dedicated, patched machine with access control in front of the API, plus cloud for everything that does not involve the sensitive data.
- Developer or founder testing what is possible. Local, with synthetic or redacted data, and no live customer records until a proper plan and controls exist.
- Any business handling special category data, such as health or criminal records. Neither option is safe by default. Do a data protection impact assessment first, then choose.
Two mistakes to avoid
The first is comparing a cloud business plan against a local model on paper while staff are actually using free consumer accounts on their phones. Fix the real data flow before optimising the theoretical one.
The second is assuming a local model is offline. Desktop AI tools add cloud fallback, remote model catalogues, update checks and telemetry. Read the settings, block outbound traffic you did not intend, and check again after each update.