Our privacy approach, in technical detail

The short version is here. This page is the long version: the exact flow, the models used, and how our architecture enforces it.

The "PII sandwich"

No third-party cloud AI ever sees your personal data in the clear. This is not a contractual promise — it's an architectural constraint. Here's the full flow when you upload a CV and we generate a cover letter:

1. Your CV arrives on our servers in Switzerland (Geneva / Meyrin GE).
   Sovereign hosting — hardware we operate ourselves,
   not a rented cloud instance.
        ↓
2. Our local AI engine (Phi-4 / Qwen2.5, run locally on our
   GPUs in Geneva) reads your CV and REPLACES each
   identifying piece of data with a marker:
        "Marie Dupont"          → [PERSON_A]
        "marie@email.ch"        → [EMAIL_X]
        "Banque Exemple SA"     → [COMPANY_Y]
        "+41 78 234 56 78"      → [PHONE_1]
        "Rue du Rhône 14, 1204" → [ADDRESS_1]
        ↓
3. ONLY AT THIS STEP, and only the anonymised version, leaves
   for a cloud model — under an EU data processing agreement (DPA),
   zero retention:
        The cloud model sees:  "[PERSON_A] worked at [COMPANY_Y]
                                for 4 years as [ROLE]…"
        The cloud model NEVER sees: "Marie Dupont … Banque Exemple SA …"
        ↓
4. The response comes back with the markers. Our local engine
   replaces them with your real data BEFORE sending it to you.
        ↓
5. The final letter reaches you, complete and personalised — without
   any cloud AI ever having seen your identifying information.

The two "slices of bread" (anonymisation + de-anonymisation) are local. The cloud "filling" only ever touches markers.

Which model handles what, and where

We don't use the same AI for everything. Each task is routed to a sensitivity tier, and the tier determines the provider — the caller never chooses freely.

Hard rule: the router never switches from one tier to another. If our local engine is unavailable, a kill-switch makes the PII call fail rather than redirecting it to a cloud provider. We prefer an error message to a leak.

Enforced by architecture, not a marketing promise

Sensitivity routing is implemented at the core of the backend: a single provider is wired per tier at startup, and every LLM call must go through this router. Concretely:

• a PII call can never reach a cloud provider;
• if the local engine is unavailable, the kill-switch makes PII calls fail instead of rerouting them;
• every call is logged.

An automated test suite continuously checks these three guarantees, on every change to the code.

Audit trail (FDPIC / nFADP / GDPR evidence)

Every LLM call is recorded in an audit log with a SHA-256 hash of the input — never the plaintext. We thus keep a verifiable trace (who called what, which tier, which provider, when) without duplicating any personal data. Our administrators can export this log as CSV to make it available for an audit (FDPIC, processor, GDPR expert). Audit-access request to legal@ninjob.ch.

An honest comparison

Based on competitors' public documentation (as of 2026):

We don't say the others "steal" your data — most have DPAs and TLS encryption. But TLS encryption is transparent to the cloud AI that receives the content: it sees your CV in the clear. With us, it never sees it, because what leaves Switzerland are markers.

Cloud processors

No cloud processor receives identifying candidate data. The up-to-date list of processors is also in our privacy policy.

Your rights

Compliant with the nFADP (Switzerland) + GDPR (EU):

• Access all your data: /account/export
• Correct whatever you want
• Delete your account → all your data erased within 30 days
• Portability: full export in JSON or CSV
• Withdraw consent: at any time, without justification

Going further

• How our privacy works (simple version)
• Full privacy policy
• Terms of service

A privacy question not covered here? Write to legal@ninjob.ch — a person, not a bot.