Your Own Server Does Not Make an LLM Workflow Lawful
On-premise changes where the model runs. It does not decide purpose, retention, deletion, or whether anyone should have pasted that document into a prompt. Those are still a programme, and legal will ask for the engineering half.
Procurement hears “the model runs in our data centre” and ticks a box labelled GDPR. The box is the wrong shape. The General Data Protection Regulation cares what you do with personal data: why you have it, how little of it you use, how long you keep it, who you share it with, and whether people can exercise their rights. A GPU in a rack you control answers one of those questions — who else receives the data by default — and leaves the rest untouched.
This is an engineering note, not legal advice. Your counsel decides whether a basis applies and whether a DPIA is required. What follows is the list they will ask engineering to show, and the places an on-premise LLM usually has nothing to show.
If the immediate problem is staff pasting contracts into a public chatbot, start with keeping company data out of ChatGPT. On-premise is one possible destination. It is not the policy.
What the server actually changes
Running the weights on hardware you operate, or in a private network you treat as yours, means a public model vendor is not a processor for that request. The prompt does not cross to their API. That matters for transfer assessments and for the list of subprocessors in a customer contract. It is a real benefit. Teams that need it should not pretend a “we do not train on your data” clause is the same thing.
It does not, by itself:
- give you a lawful basis;
- limit the purpose to the one you declared;
- minimise what people paste;
- set a retention period;
- delete a person from a vector index;
- stop an employee from using the tool on data they were never allowed to open;
- make the model’s answer accurate;
- appoint a human where a decision affects someone’s legal position or their access to a service.
On-premise deployment is a place you can build those controls. Without them you have a faster way to concentrate personal data in one log file.
A hybrid design — some workflows local, some on an API — is often the honest architecture. It is also easy to describe as “private” while the sensitive call still leaves. The split has to be a rule you enforce, which is the subject of hybrid private and cloud AI, not a sentence in a slide.
Prompts, logs, and embeddings
A prompt that contains a customer’s name, a support ticket, a CV, or a recording transcript is personal data even when the model is local. The same is true of the completion, if it repeats or infers that data. Storing either “for debugging” is processing. Keep a reason and a lifetime, or do not store it.
Access logs are the usual leak. The reverse proxy logs the body because someone turned on debug during the pilot and never turned it off. The application logs the prompt because a developer wanted to replay a bad answer. The GPU host’s journal has a crash dump with the request still in memory. Treat prompt logging as off by default. When you turn it on, sample, redact, and expire. A 100% prompt log retained for a year is a second database of your customers, with worse access control than the first.
Embeddings are personal data when the source text was. They are not “just maths” in any sense that deletion, access, or a subject access request will accept. A vector index built from support tickets or HR files is a personal-data store. It needs an owner, a retention rule, and a way to remove one person’s chunks without rebuilding your understanding of the entire corpus from scratch. If you cannot delete by document id or by a stable person key, you cannot honour an erasure request against that index. Build the key before you embed the backlog. Retrofitting it means re-indexing, and it means admitting you could not delete anyone for the months you operated without it.
Backups copy the index. A deletion that does not cover backups is a deletion in the primary only. Write down the backup lag: erased in the product within days, gone from backups when those backups age out, and not restored onto a new environment by accident. That sentence belongs in the runbook.
Transcription makes this sharper. Audio of a meeting is personal data, often of people who are not your employees. A local speech-to-text pipeline is still processing. The transcript, the summary, and the embedding of the summary are three stores. Each needs the same retention story. “It never went to a vendor” is not one of them.
Purpose and the paste box
People will paste whatever the box accepts. A general chat next to the company logo invites “summarise this grievance”, “rank these CVs”, “what should we do about this patient-shaped spreadsheet”, and “rewrite this customer’s complaint so they sound unreasonable.” Some of those purposes are incompatible with the reason you collected the file. Some are special-category data. Some are decisions your counsel will not want a model to draft unsupervised.
Constrain the product to workflows you can name. Document search over a policy library is a purpose. A blank chat with the company file share mounted is not a purpose. It is an invitation. If you offer the blank chat anyway, assume the worst paste will happen, log less, and give people a sanctioned place to do the legitimate job so the blank box is not the path of least resistance.
Minimisation is a product decision. Retrieve the passages that match the question; do not stuff the entire personnel file into the context window because it was easier. Show the passage to the human. Prefer a refusal when retrieval misses. A model that always answers will invent a person, a date, or a clause, and you will have processed data into a new inaccurate record. Accuracy is not optional just because the prose sounds smooth.
Shadow use survives the on-premise launch. Staff keep a personal ChatGPT tab because the internal tool is worse, or because the internal tool blocks the paste they wanted to make. If the internal tool is bad, they are telling you the truth. Fix the workflow or accept that the data is leaving. A policy PDF will not close the tab. Measuring egress, where you are allowed to, will tell you whether the programme exists outside the rack.
Who may see what
On-premise does not imply “everyone with a login can ask about everything you embedded.” A private document index that ignores the source system’s permissions is a privilege escalation: the intern asks for salaries because the PDF was in a folder the crawler could read and the chat could not tell the difference.
The retrieval layer has to apply the same authorization as the file store, or a stricter one. Filter before the model sees the text. Filtering the answer afterwards is how a name from a forbidden document appears in a sentence you then try to regex away. If a document’s ACL changes, the index has to change with it, not at the next quarterly crawl.
Administrators who can read the prompt log can read the data. That role should be small, audited, and not the same as “the team who built the demo.” Vendor support, if you still have a managed piece in the stack, needs a path that does not include a raw prompt export “to reproduce the issue.”
Weights, vendors, and the word private
If a vendor fine-tunes or hosts, they are in the processing chain even when the hardware sits in your cage. Read the contract for training on your prompts, for subprocessors, and for where snapshots go. “On-prem appliance” can still phone home for a licence or ship telemetry that includes snippets. Turn telemetry off or route it through a review. Do not discover it from a firewall log after go-live.
Open weights you downloaded are not automatically free of obligations, and they are not automatically a transfer. You still have to operate them. You also have to decide whether customer content is allowed to influence a model you might later reuse on another customer’s data. Fine-tuning on tenant A’s tickets and then serving tenant B is a confidentiality incident even when no public API was involved. Isolate adapters and indexes per tenant unless a human who understands the contract says a shared model is acceptable, and write down what “shared” excludes.
A public API remains legitimate for workflows that do not involve personal data, or that your counsel has accepted with a processor agreement and a transfer tool. Forcing those workflows onto a local model does not increase compliance. It increases the system you must secure. The grown-up outcome is often mixed, chosen per workflow, not a single badge.
What to have before you buy the GPU
Counsel can work with a short pack. Engineering can produce it without pretending to be a law firm:
- The workflow, in one paragraph: who uses it, what they paste or what is retrieved, what comes out, what decision it influences.
- The categories of personal data, including whether audio, employees, or customers are in scope.
- The stores: prompts, completions, embeddings, transcripts, backups, and which of them you intend to keep.
- Retention for each store, and the deletion path, including backups.
- Who can retrieve, and how that maps to existing ACLs.
- Whether a vendor, a telemetry endpoint, or a support channel can receive content.
- What the human checks before the output is acted on.
- What you will do when the model is wrong, and who is allowed to turn the feature off.
If item 1 is “a chatbot for the company,” stop and name a workflow. The rest of the pack cannot be filled in honestly until you do.
A Private AI Readiness Audit from €1,500 is the fixed-scope version of that pack for one workflow, with permission to say “do not deploy a model” or “use the API.” The surrounding offer is private AI on infrastructure you control. Pilots are €300/day. Implementation after a pilot that earned it stays at €300/day. None of those buy a GDPR certificate. They buy a system whose data paths you can show to the person who is allowed to care about the certificate.
Put the model where you can operate it if the data should not travel. Then do the rest of the work the server did not do for you.