Local AI and privacy get treated as the same question, but they're two different ones. Whether a model runs locally says nothing about whether your entire setup is privacy compliant: a data processing agreement does become unnecessary once no external provider is involved, but a record of processing activities where one is required, and the requirements of the EU AI Act, still apply regardless of where the model does its computing.
Up front, so it's clear: I'm a developer, not a lawyer. This is not legal advice, just the operator's perspective I use to handle this topic in my own setup, a local model running alongside an AI workforce built on Claude. Everything I write about AI in daily work is collected on the AI page.
The question that almost always gets lost: what exactly does "local" mean once a model, a runner, an agent, and a handful of tools all work together? That is where I start.
What local AI actually means for privacy
A local setup has several layers, and only one of them is automatically privacy-friendly. The model itself, meaning the downloaded weights, sends nothing anywhere; it's a file on your drive. The runner, SGLang in my case, executes the model and answers requests, also without its own cloud connection. The agent or tool sitting on top, say a terminal assistant or an app, is the part that can introduce exceptions: update checks, telemetry, or a single step that does call an external service, like a web search.
"Local AI for business" doesn't automatically mean not a single byte leaves the building. It means the language model itself processes the request without a remote server. What happens around it is a matter of configuration, not the marketing line "runs locally."
What data can still leak out
Even with a model running cleanly on your own hardware, there are places where data can leave your network without you noticing. The runner software sometimes checks for updates and, in doing so, at least signals that it's running, a request that some tools let you turn off and others don't. If an agent uses additional tools, say a web search or an external translation service, text leaves your network at that point too, just not through the language model itself. And the human factor stays: if you copy a result from your local model into a cloud chat afterward to check or continue it, you've given up the privacy advantage of the local setup in that exact moment.
The honest advice: don't trust the claim "runs locally"; check your actual setup once yourself. More on how below.
When local AI is required and when cloud is enough
For most solopreneurs and small businesses, a cloud provider with a suitable data processing agreement is entirely enough. Local AI becomes closer to a requirement when one of the following applies:
| Question |
Cloud is usually enough |
Local AI is more likely needed |
| Is there a data processing agreement that fits your data? |
Yes |
No available provider meets your requirements |
| What kind of data is involved? |
general business data, content you can anonymize |
special categories such as health data, professional secrecy obligations |
| Does a client or a requirement explicitly demand that data never leave your own network? |
No |
Yes, fixed by contract or law |
| Can you actually handle running and maintaining your own server? |
Doesn't have to be |
In place or planned |
In my experience, the cases where local AI genuinely becomes a requirement are rare and usually contractual or industry-specific, not driven by GDPR as a blanket rule. For everything else, a cloud provider with a clean data processing agreement is the faster and usually the cheaper path. The same trade-off without the privacy lens, weighed by task, frequency, and effort, is in Local AI: What Actually Works in 2026, and the cost side of running your own server is in Your Own AI Server: Hardware and Cost.
The processing agreement goes away, the other duties do not
When you switch to a fully local setup, the data processing agreement under GDPR Article 28 becomes unnecessary for that one model, because no external provider processes data there anymore. That holds only for the case described here, with no external processor at all. If the hardware sits in a rented data center, if a service provider has remote access to it, or if parts of the processing still go to the cloud, you still need the agreement. For Claude, which I use for my AI workforce, that role is covered by Anthropic's Data Processing Addendum, which applies to the business plans. What running locally does not remove: whether you have to keep a record of processing activities depends on your processing, not on where the computing happens. GDPR Article 30(5) exempts organisations with fewer than 250 employees, but only as long as the processing is occasional, poses no risk to the people concerned, and involves no special categories of data (regulation text on EUR-Lex). For regular AI use of the kind described here that exemption usually does not apply, and then you do need the record. Whether that is the case for you is a question for individual legal review, not for a blog post. And the EU AI Act sets its own requirements for operating AI systems, which also apply regardless of where the model sits. "Local" shifts one obligation; it doesn't automatically erase all the others.
Evidence instead of a claim: the network capture
Search for local AI and privacy and you mostly land on vendor blogs asserting "runs locally, so it's safe" without showing a single piece of evidence. You can check this yourself: while a request runs through the model, capture the network traffic with a tool like tcpdump and see where the machine actually talks to. In my setup, access to the DGX Spark runs over my own Tailnet, so the machine is not openly reachable from the internet. I do not have a stored raw capture that would let me prove the absence of every outbound connection, so I am not claiming it here.
Anyone can run this check on their own setup, and in my view should, before trusting "it runs locally" at face value. A vendor's promise doesn't replace that check.
In practice: Frieda and the receipts
My AI employee Frieda handles my inbox, scheduling, and receipts. In a normal week, she sorts the receipts that come in by email, mostly invoices from service providers and small-expense receipts, and prepares them for bookkeeping. For that task, Frieda runs on Claude, because a data processing agreement with Anthropic is in place and the receipts themselves are general business data, not health data or someone else's banking details.
One possible example of how that plays out: among the receipts is one that includes a handwritten note with an account number and a health-related remark, clearly scanned in by accident along with the invoice. Her personnel file has a rule for exactly this: stop and flag anything unusual instead of processing it further on her own. So she sets the document aside and flags it, instead of waving it through like the rest. Said plainly: for Frieda to spot the note as sensitive at all, she has to have read the document. The rule prevents further processing and filing, not the first read. If you want to rule that out too, you have to separate up front and keep documents like that out of the folder the AI has access to in the first place. The German data protection authorities point out that even entering personal data into an AI system requires a legal basis and should be avoided through clear routines (the DSK guidance on AI and data protection). Whether and how that one document gets processed any further is my call afterward, not the AI's. That split, routine work runs through the AI, edge cases land on my desk, is the core of my privacy practice, not a single technology choice between cloud and local.
The eight AI employee packages, Frieda included, are ready to go in my community, with access through Skool.
Frequently asked questions
Is local AI automatically GDPR compliant?
No. Running locally saves you the data processing agreement with an external provider, but it changes nothing about the remaining obligations, such as a record of processing activities where one is required and the requirements of the EU AI Act. This is not legal advice, just my experience as an operator.
Do I need a data processing agreement for local AI?
Only if an external provider is genuinely still involved, say for hosting or maintenance. If the model runs entirely on your own hardware with no outside access, that requirement goes away; it changes nothing about your remaining obligations under the GDPR.
Is a Chinese model automatically a privacy risk?
That depends on how you use it, not on where the model was built. An openly licensed model that you download and run entirely on your own hardware sends data nowhere, regardless of where it was developed. The risk shows up once you use a cloud API from the same provider instead and send data there.
What does the EU AI Act mean for users of local AI?
The EU AI Act sets requirements for operating AI systems that apply regardless of whether the model runs locally or in the cloud. The details depend on how your specific use case gets classified; this is not legal advice.
Can I use Claude offline, like a local model?
No, Claude runs exclusively as a cloud service; there's no offline option. If you need to get work done with no internet connection at all, you need a locally running model like the one described in this post, not Claude.
Where to go from here
For the Claude side of the same topic, meaning what applies for privacy and GDPR with a cloud provider, see Claude Privacy and GDPR: What Applies. For how I handle client data across my AI workforce in general, regardless of local or cloud, see AI and Privacy: What the AI Gets to See. And for the bigger picture on what local AI can do in 2026, see Local AI: What Actually Works in 2026.
