Module 9 — Data privacy through local execution

Every SLM pitch in 2026 ends with a slide that says "your data never leaves the device". Half of the time that slide is true; half of the time it is marketing. This module draws the honest line — what a local model does protect, what it does not, and how to walk into a management meeting with the correct pitch that survives a director of security asking follow-up questions.

What a local model actually protects

The prompt and the completion never reach a third party. The ticket text, the customer name, the reasoning the model produced — none of it travels over the network to a hosted API. That is the real, measurable benefit, and it is what makes the ticket assistant legally shippable in cases where a hosted API would not be.

Third-party training and logging are ruled out. A hosted provider's terms may say they will not train on your data, but proving it requires trust. A local inference cannot train the vendor's next model on your data because the vendor is not in the loop.

Provider outages cannot leak. A misconfigured cloud endpoint, a shared-tenancy incident, a subpoena served on the provider — none of these can expose data that never reached the provider.

For a support-ticket assistant that reads addresses, order numbers and — despite policy — occasional payment card fragments, this is not a nice-to-have. It is the answer to "how do we deploy an AI assistant on this data at all".

What a local model does not protect

The mistake is claiming the argument extends beyond that.

The ticket database still exists. The ticket text lives on a server, in backups, in exports, and is accessible to whoever has access to those. Local inference on top of that stack does not change any of it. The privacy story is about the inference step; the storage layer needs its own controls.

Logs are still logs. If your local service writes ticket_id + suggested_reply to a log file that gets shipped to a central log aggregator, the aggregator has the same data as a cloud API would. The default logging configuration of module 8's FastAPI service is not privacy-preserving; you have to configure it to be.

The machine still leaks. A stolen laptop leaks everything the ticket agent could see. A shared laptop with an unlocked screen leaks it live. A malicious insider dumps history.db and walks out. None of these are LLM problems, but they are the ones a security team will name first when asked about the deployment.

Model updates are downloads. The ollama pull step reaches out. What it downloads is checked against a signature (Ollama does verify), but the network dependency exists — you cannot claim "air-gapped" while also claiming "up to date". You choose one.

The user is still the user. An agent typing a prompt that reveals sensitive reasoning has typed that reasoning into an application that keeps it. A local model does not reduce the value of least-privilege access controls on the ticket tool itself.

The regulatory argument, honestly

The general shape of the argument in most jurisdictions:

GDPR (EU). Processing sensitive personal data with a cloud provider requires a data processing agreement (DPA), often an adequacy decision or SCCs for cross-border transfers, and an updated record of processing activities. Local inference removes the cross-border transfer question and the sub-processor question entirely. It does not remove the record of processing, the DPIA for high-risk processing, or the retention obligations on the ticket store itself.

HIPAA (US, health). Cloud LLM providers offering a BAA exist but are expensive and slow to procure. A local model on a covered entity's controlled device sidesteps the BAA question. The security rule still applies to the device, the storage and the logs.

Sector-specific (banking, defence). Many contracts explicitly forbid cloud LLM calls on regulated data. Local inference is often the only path — but the sector will also require code review, key management and audit logs that a "just install Ollama" pitch does not address.

The pattern is consistent: local inference simplifies the story around the model call itself, and shifts the burden to the parts of the stack that were already regulated. It does not eliminate compliance work; it changes the shape of it.

The pitch for a management team

Two slides, in this order, deliver the honest argument.

Slide 1 — What we ship. "A support-ticket assistant that runs on the agent's laptop. Ticket text never leaves the workstation. No cloud API is called. The model is 2 GB, updated quarterly by a signed pull, and matches the accuracy of a hosted API on our 200-ticket benchmark."

Slide 2 — What is still our responsibility. "The ticket database, its backups and its exports remain governed by our existing controls. Local logs of the assistant's suggestions are configured to redact PII before shipping to central monitoring. The laptops carry the same disk-encryption and endpoint-security posture as before. Model updates require the machine to reach our internal artefact server occasionally, not the vendor's."

A director of security who has heard bad AI pitches will breathe out at slide 2. That slide is what turns "another AI slide" into "a normal deployment decision".

Two tests to catch weak claims

Before you present, run these two tests on your own pitch.

The tcpdump test. Run the assistant end to end on a test machine with tcpdump capturing all outbound traffic. During inference, no packets should leave the machine to any external endpoint. If they do, either the model made an unintended network call (some tokenizers pull vocab from the network on first use, for instance) or a background telemetry beacon is firing. Fix it before shipping.

The audit test. Ask a colleague to answer: "if a customer submits a subject access request about their tickets, where does the data live, and who has access?" If the answer changed with the assistant deployment, the pitch needs updating. If the answer did not change — because the data lives where it always lived — the local-inference story is honest.

In summary

• A local model protects the model call: the prompt and completion do not reach a third party, third-party training is ruled out, provider incidents cannot leak your data.
• A local model does not protect the ticket store, the logs, the physical machine, or the update channel — those need their own controls, unchanged by the deployment.
• The regulatory argument is real (GDPR sub-processor question, HIPAA BAA, sector-specific bans) but simplifies the model-call story without eliminating compliance work.
• The honest management pitch is two slides: what local inference gives you, and what still lives elsewhere and is still your job.
• Two tests before shipping: tcpdump to prove no unintended outbound traffic, and a subject-access-request thought experiment to confirm the data map is unchanged.

Next: the final module — assembling everything into a shippable desktop assistant, evaluating it against the API on 200 real tickets, and drawing the boundary of when a ticket should be routed to the large model anyway.