Solution 07 · PrivatPrompt
The model sees the task, never the identity
PrivatPrompt is the gateway between your applications and every external language model. Every API call in the organisation has to pass through it: people, companies, addresses, account numbers and identifiers are replaced by placeholders on your infrastructure before the prompt leaves the house. The answer comes back, is translated into the real values and checked for usefulness. The mapping never leaves your network.
The provider keys sit in the gateway alone, and the applications know only the gateway. Sanitisation is therefore not a choice left to the individual, it is a property of your infrastructure: the performance of the best frontier models, without customer data ending up in someone else's data centre.
Neutrality of data · as a mechanism, not as a rule
Most policies on AI use rest on trust: staff are asked not to enter customer data, developers are asked to keep it in mind. PrivatPrompt replaces the policy with a construction that takes effect before every call. The technical term for it is prompt sanitisation: a prompt is cleaned up before a model sees it, and the answer becomes usable only once it has been translated back.
Sanitisation on your own infrastructure
People, companies, places, addresses, email, phone, IBAN, AHV number, credit card, access credentials. Swiss formats with their own detectors, identifiers with a checksum. Detection, masking and mapping stay inside your network.
Mandatory, not optional
The gateway speaks the usual interfaces of the providers. Applications, agents and automations point at it instead of at the provider, the access keys sit there alone, the direct route out is blocked. There is no call that bypasses sanitisation.
Choose model and provider freely
Per application: a frontier model through the provider's API, a provider operating in Switzerland, or a model in your own data centre. A switch changes nothing in the applications, only the mapping in the gateway.
Rule set per use case
Customer correspondence, contract review, code, free text: every profile settles how strictly masking applies and what must never go out. The answer translated back is checked for fit, and the rule set learns when an external model is not worth it for a task.
Three zones: original, levels, answers
At the workplace the app shows what the gateway does: on the left the original prompt with entities marked in colour, in the middle the history of the masking levels, on the right the answers per round. For every API call from an application the same history sits in the job log. Every relaxation is a visible, logged decision.
Company A (a customer) · Rule: company → enriched · Origin: round 2 · Level L2The name stays hidden, the role becomes readable.
- L3 · StrictAll five entities sent as placeholders.
- Query from the model«Who is Person 1?» Fit 0.41. Type at fault: company without context.
- L2 · Company enriched«Company A (a customer)», person and identifiers stay masked.
- Answer fitsFit 0.86, references resolved.
Thank you for your quote. We are glad to accept it and look forward to working with Nordwind Solutions AG. Please send the invoice to CH93 0076 2011 6238 5295 7, queries reach us at …
Six steps · one of them outside the house, and that one masked
Detection, masking, translating back and checking run inside your network, at the workplace on your own machine, for applications on the server of the gateway. Only the masked version reaches the language model. What it returns is made readable again before it is delivered.
As much masking as needed, as little as possible
Too much masking takes the context away from the model, too little gives data away. The ladder settles this in levels: it starts strict and relaxes only the type the answer fails on. For applications the rule set fixes the level per use case; at the workplace the person writing the prompt decides, within the same limits.
Strict: everything as a placeholder
People, companies, places, addresses, email, phone, account numbers, AHV numbers, credit cards, access credentials. The model sees a category and a number, nothing else. For many tasks that is enough already.
People and identifiers stay masked, companies gain context
Companies and places become a category with a letter: «Company A», «Place B». On request enriched with the role from your knowledge base: «Company A (a customer)», «Person A (head of purchasing at Company A)». The name stays hidden, the task becomes solvable for the model.
Identifiers only
Email, phone, IBAN, AHV number, credit card and access credentials stay masked, everything else goes out in plain text. The automatic process never goes below this level. If it reaches no fitting answer, the rule set reports the limit and names the ways out: answer locally, rephrase the prompt, or deliberately without masking.
Passthrough: without masking, after a report
The prompt goes out unchanged. For applications only where the rule set expressly allows it for that use case, never at the request of the caller; at the workplace only after the gateway has shown what it detected in the prompt. Intended for tasks with no personal data: public texts, general questions, research with web access. Web access is permitted here only, because a search query would otherwise give away the masked details.
| Version of the same value | What the model sees | What is disclosed |
|---|---|---|
| Placeholder | ‹ORGANIZATION 1› | Nothing |
| Category | «Company A» | Category and distinguishability |
| Category with role | «Company A (a customer, mechanical engineering)» | Role and business relationship, never the name |
| Plain text | «Nordwind Solutions AG» | The value itself, only if the rule set allows it for this type |
Neutrality of data: a precondition, not an extra
The strongest models run in data centres that belong to someone else. Whoever used them has paid with customer data so far. Masking separates performance from identity, and for most of a company's data that is no option but the condition.
| Frontier models without data leaving | The performance of the best models for contract questions, customer correspondence and analyses, without names and identifiers leaving the house. |
| The policy becomes a mechanism | «Do not enter customer data» is a guideline. An application that can reach the provider only through the gateway is a construction. It holds on a Friday evening too, and in every script someone wrote two years ago. |
| Provable what was disclosed | Every job logs the lowest level that was sent and the types that were relaxed. Never the values themselves. |
| One key, one place | The provider keys sit in the gateway alone. No key in applications, in scripts or with staff, no shadow access that nobody knows about any more. Changing provider is an entry in the gateway, not a change to the application. |
| Fit instead of flying blind | A masked answer is only useful if it fits the task. The local check says when that is not the case, and when an external model is not worth it for a task at all. |
| Honest limits | Masking is pseudonymisation, not anonymisation. Industry, place and size together can make a company recognisable. The detection rate is measured, not promised; account numbers and identifiers are verified by checksum. |
Data handling
- Detection
- On your infrastructure, with no connection to the outside
- Mapping table
- Inside your network, encrypted, with an expiry date; never leaves it
- Provider keys
- In the gateway only, never in applications or with staff
- Jobs and answers
- A log of the disclosure per call; contents deleted automatically after a set period
- Fit check
- A model inside your network, or masked through the provider; never with plain text
- Language model
- Selectable per application: a frontier model through the provider's API, a provider operating in Switzerland, your own data centre
No additional cloud service in between, no copy of your prompts at an intermediary. The contract with the provider stays your contract.
Three ways in, one core
The core runs as a service on your infrastructure. For applications it is the gateway that no route gets past. For assistants it is a tool, for the workplace an app.
As a gateway on the company network
Applications, agents, automation platforms and chat tools call the gateway the way they would call the provider itself, through the same interface. The gateway sanitises, calls the provider with its own key and delivers the answer translated back.
- Switching an application: address and key, nothing else
- Direct connections to the provider blocked
- Rule set and log per application
In AI assistants
As a tool in assistants that speak the open tool protocol MCP. The assistant calls «ask an external model in masked form», everything else runs in the core.
- The same tools for every client
- Checking, masking and translating back also usable on their own
- Its own access key per client, separate views
At the workplace
Select text in any application, hand it to PrivatPrompt through a service, apply the answer. The app shows masking, levels and answers and needs no system permissions.
- Its own app on the machine, also through existing subscriptions
- No window monitoring, no reading along in the clipboard
- Hand over as text, as a file or into the knowledge base
As a project in three steps
Clarify use cases and data classes
Which applications and tasks go to external models, which data may go out at which level, and which never? Along with the contractual basis at the provider, because the gateway adds to the data processing agreement, it does not replace it. Result: the rule set per use case.
Put the gateway into operation
Provider keys into the gateway, applications switched over to the gateway, direct routes blocked. Tune detection to your data: companies from your customer base, Swiss identifiers, your own terms that must never go out. Tested on real texts with a measured hit rate instead of an assumption.
Pilot and roll-out
Start with one application or one team. Feedback sharpens the starting level and the limits per profile. Only when the fit check agrees with your own judgements may it release answers on its own. Then the remaining applications follow.
The gateway in front of every external model
Wherever an application, an assistant or an agent calls a language model, PrivatPrompt sits in front of it: for reply drafts in the Activity Cockpit, for minutes from PrivatTranscript, for the route to the frontier model in the target picture of the knowledge layer. The model stays exchangeable, the neutrality of the data remains.
Target picture of all solutions →The summary as a PDF
The gateway for every API call, the masking ladder, the six-stage process with processing locations, the three ways in and the data handling, compact for the decision paper.
PrivatPrompt
The model sees the task, never the identity: gateway, ladder, process, ways in and data handling on three pages.
Which prompts containing company data leave your house today?
In a first conversation we count the applications that call a provider directly today, and clarify which data may go out at which level. No obligation, at eye level.
Get in touch → All solutions