n8n has established itself as a reference in automation. Its visual editor, hundreds of connectors and ability to self-host make it a powerful tool to wire services together: receive an e-mail, extract an attachment, summarise it with a language model, create a ticket, notify a team. When these workflows involve AI, n8n orchestrates the chain very well. One question remains that no orchestration tool answers for you: what does the model provider see when a node sends it text?
Orchestrating and protecting data are two different problems
A self-hosted n8n workflow keeps your automations on your premises. But the precise moment a node calls a cloud-hosted language model, the content it sends (a CV, a contract, a customer e-mail, an invoice) leaves your perimeter as-is. n8n is not meant to anonymise that content: it is not its job, and indeed it is a recurring request from its community, which everyone currently answers with one-off workarounds.
This is exactly where CLEVYA comes in. Not as a replacement for n8n, but as a complement: a sovereign building block that sits between your workflow and the model, replaces detected identifiers locally with codes before any send, and keeps the data local when in doubt (fail-closed).
The diagram: CLEVYA sits between the AI node and the model
In a typical workflow, the AI node sends its text straight to the model. With CLEVYA, the flow goes through one extra, local step:
n8n workflow → the text to process → CLEVYA (local anonymisation + egress log) → the model only receives tokens → response → local re-substitution → back into the n8n workflow.
The model never sees “Sophie Martin”, “FR76…” or a customer number: it receives typed, consistent tokens, reasons over them, and the response is reconstructed on your server. The table linking tokens to real values never leaves your perimeter.
Three concrete examples
Human resources. An n8n workflow receives CVs by e-mail and summarises them with a model to pre-screen applications. Without protection, names, addresses, phone numbers and salary expectations go to the provider. With CLEVYA in between, the model only sees markers: it summarises the skills without knowing the candidate’s identity.
Customer support. A workflow automatically classifies incoming tickets using a model. E-mails, customer references and order numbers travel through the cloud. CLEVYA masks them before sending; the classification stays accurate, the data stays with you.
Accounting and legal. A workflow extracts key information from invoices or contracts. IBANs, named amounts and company names appear in clear text. CLEVYA acts as a firewall: what identifies a party is replaced, what enables the calculation or analysis is kept.
The real value: proof, not just masking
Masking data before an LLM call is not a new idea, and several tools do it. CLEVYA’s stance comes down to one word: defensible proof. The architecture is built around an egress log that records, on every send, what went out and what was masked. The goal: a log a data protection officer can read, to show (not merely claim) what was masked and what actually left the server, on every send. Detection is not perfect - zero risk does not exist - but the log makes every send verifiable, and the guiding principle stays the same everywhere: when in doubt, the system blocks rather than lets through.
It is this ability to demonstrate that turns a use case often forbidden by legal teams today into an authorised, auditable one. The European AI Act, applicable from 2 August 2026, makes this traceability all the more tangible for the organisations concerned.
Keep n8n, add the trust
The message is simple: already using n8n, or another orchestrator? Keep it. CLEVYA does not aim to replace it, but to fill the blind spot no orchestration tool covers: replacing detected identifiers locally with codes before any send, keeping the data local when in doubt, and tracing what went out in a verifiable log. Orchestration stays with n8n. Sovereign proof belongs to CLEVYA.