Set your data boundaries.
We classify what can use external services, what stays local and what must stay out of the model. Passwords and keys always stay outside the model.
Your AI. Your rules.
Privacy and AI strategy for your organisation. We define what your AI can use, where the data is processed and who gets access.
Control where and how your AI works.
Control how data is processed.
For confidential work, we design local data flows. We review the whole path, from documents and models to logs, backups and support access.
Apply your own rules.
Together, we define who can use which AI, for what purpose and for how long data is kept. A local server alone cannot replace these rules.
Cloud AI can be privacy-compliant too. The right choice depends on the data, the purpose and the assessed safeguards.
Built around your organisation. Not the other way around.
We start with your use cases, existing IT and privacy requirements. Together with the people responsible, we turn them into concrete decisions for rollout and operation.
Clear data-use rules
Approved content, permitted purposes and boundaries your team can follow.
The right architecture
Local and external services with documented data flows.
Defined responsibilities
Ownership, access permissions and deletion rules before rollout.
The thinking behind the decisions.
Explore the data classes, technical boundaries and legal requirements in detail.
Data classes in detail
- Public and approvedNon-personal information
- Approved external AI services may be used. First check content rights, hidden metadata and any remaining confidentiality requirements.
- Internal documentsProcesses, manuals, internal documentation
- External processing requires approval and a review of provider terms. Apply stricter rules if personal data or trade secrets are involved.
- Personal dataCustomer contacts, contracts, employee records
- Process only what is necessary. Establish the legal basis, recipients, access and deletion periods. This data can also require a very high level of protection.
- Particularly sensitiveHealth records, legal case files, confidential employee data
- Assess specific legal requirements and safeguards. Prefer a protected environment under your control; allow external processing only after a documented review and approval.
- Trade secretsNon-public source code, calculations, development plans
- Keep processing local by default. External disclosure requires explicit approval from the responsible business and security teams.
- Credentials and keysPasswords, API keys, private keys
- Do not include them in prompts or AI knowledge stores, even locally. Keep credentials in secret management, outside the model context.
Do not send data externally while its classification is unclear. Publicly available personal data remains personal data; pseudonymisation is not anonymisation.
Privacy and processing in detail
What happens during processing
In typical LLM inference, text is converted into tokens and numerical representations. This is not encryption. The processing software needs access to the content in a form it can use for computation.
Encryption in transit and at rest alone does not prevent access during processing. Special approaches such as confidential computing or computation on encrypted data use different protection models and require a separate assessment.
No training does not automatically mean no storage or no access. Tokenisation and embeddings do not automatically anonymise data.
To run an LLM locally, assess the entire data path: documents, prompts, responses, embedding services, logs, backups and support access. A local language model alone is not enough if other components send confidential content outside your environment.
More than a local server
Privacy-compliant AI requires an appropriate legal basis, data minimisation, transparency, data subject rights, permissions, retention periods and suitable safeguards.
Cloud AI can also be used lawfully. Depending on the use case, assess processor arrangements, third-country access and the need for a data protection impact assessment. We consider the GDPR, the Swiss FADP and sector-specific rules according to their respective scope.
Together with your IT and data protection teams, we define data approvals, architecture and operational responsibility: permitted purposes, local and external services, controlled data flows, access permissions and deletion rules.
Background and further reading
Fight fire with fire.
Attackers use AI. Your security testing should too. For authorised penetration tests and code reviews, we use abliterated open-weight models with reduced refusal behaviour when analysing exploits and malware.
On our Swiss servers or at your premises. For qualified customers, with an agreed scope, written authorisation and prioritised findings.
Request a security review