Protezione dei dati

Modalità di rilevamento, libreria di 60 rilevatori, rilevamento delle entità con modelli selezionabili, scansione di sicurezza e conservazione.

La protezione dei dati gira su ogni richiesta prima dell'inoltro. La modalità predefinita è tokenize: ogni valore rilevato viene sostituito con un token tipizzato stabile come «EMAIL_1». I valori rilevati raggiungono il provider solo come token, e la risposta viene ripristinata ai valori reali sulla via del ritorno verso di te, in streaming o no. La mappa dei token vive in memoria per la durata della richiesta e non viene mai conservata. La pseudonimizzazione è a senso unico: protegge ciò che invii. In Sluis Workspace, i risultati pubblici della ricerca web e l’output del modello prodotto prima nello stesso turno non vengono tokenizzati di nuovo; un valore già tokenizzato nella conversazione resta sostituito dal suo token, e il registro di audit indica quando è successo.

# tokenize mode (the default): what you send
curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "sluis/auto", "messages": [{ "role": "user",
        "content": "Mail j.devries@acme.nl that IBAN NL91ABNA0417164300 is active." }] }'

# what the model provider receives — only stable typed tokens
{ "role": "user",
  "content": "Mail «EMAIL_1» that IBAN «IBAN_1» is active." }

# what you get back — restored at the single client egress, streaming included
{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "Draft: Dear j.devries@acme.nl, your account NL91ABNA0417164300 is active…"
    }
  }]
}

Altre modalità: mask riscrive i valori rilevati in modo irreversibile, block rifiuta la richiesta con 422, e allow_log la lascia passare segnalando la riga di audit.

60 rilevatori integrati sono inclusi da subito: 28 per i dati personali, dal numero di Social Security USA a un pacchetto di identificativi nazionali di 12 paesi UE validati tramite checksum, e 32 per segreti e credenziali. Ciascuno è attivabile per organizzazione, e i termini personalizzati (testo semplice o regex) coprono qualsiasi cosa specifica della tua attività:

Rilevazione entità

Persone, organizzazioni e luoghi sono difficili da rilevare solo con pattern. Sluis combina euristiche di contesto, correlazione email, rubrica del tenant, dizionari inclusi e NER opzionale. Il modello NER opera come sidecar interno alla rete: il testo resta nel perimetro dell’installazione. Questi livelli analizzano anche il testo estratto dai documenti e tramite OCR quando la protezione documenti è attiva. Con il NER attivo, una richiesta può nominare fino a 100.000 entità distinte; oltre questo limite la scansione conta come incompleta. Un nome che il modello rileva una volta viene sostituito ovunque ricompaia nella richiesta, come la stessa parola intera con le stesse maiuscole e lo stesso token, anche nei messaggi in cui il modello non lo ha segnalato. Parole generiche isolate e sigle brevi coprono solo l’occorrenza segnalata dal modello.

Il dizionario dei nomi è la controparte deterministica del NER: nomi propri e cognomi compilati da dati aperti della pubblica amministrazione in un dizionario fornito dentro il gateway. Coglie i nomi completi e i nomi preceduti da un titolo onorifico, senza latenza aggiunta e senza che nulla lasci il tuo perimetro. I nomi che sono anche parole comuni vengono colti solo con un contesto di forma nominale; i nomi rari restano compito della rubrica o del NER.

Modelli NER selezionabili

Scegli Base, Esteso o Approfondito in Protezione dei dati. Base usa rilevatori integrati e sei livelli deterministici dei nomi, senza chiamate a un modello; è il valore iniziale delle nuove organizzazioni. Esteso aggiunge Swift (spaCy); Approfondito aggiunge invece GLiNER2-PII. Entrambi i profili IA richiedono un’ispezione completa e bloccano errori del modello o scansioni incomplete. Approfondito richiede più elaborazione, senza garantire un richiamo superiore. Personalizzato permette regolazioni individuali. Policy esistenti, esclusioni, rubriche e deroghe dei workload restano invariate; le parole sconosciute restano disattivate nei tre profili. Un workload non può attivare NER se l’organizzazione lo disattiva. Il riconoscimento dei nomi con IA è fatturato una volta per ogni richiesta del cliente ispezionata: 0,005 € con Swift (Esteso), 0,01 € con GLiNER2 (Approfondito); Base è incluso. Le chiamate successive che Sluis esegue nella stessa richiesta non vengono fatturate di nuovo, e un’ispezione incompleta non costa nulla. Ogni addebito è una ricevuta di audit collegata che conta nei tuoi budget.

Approfondito aggiunge una latenza significativa prima che il modello scelto inizi a generare una risposta. Il tempo di scansione di Swift e GLiNER2 dipende dalla lunghezza del testo, dal numero di messaggi e dall’hardware. Il limite copre l’intera scansione NER di messaggi, allegati e finestre di una richiesta, non ogni finestra: 30 secondi fino a 320.000 caratteri, più 30 secondi per ogni ulteriore blocco di 320.000 caratteri, al massimo 10 minuti. È un massimo, non la latenza tipica. L’ispezione LLM ospitata facoltativa aggiunge un’attesa separata prima della generazione della risposta, in base al testo, al carico del fornitore e ai nuovi tentativi; è fuori da questo limite NER.

Misurato il 2026-08-12 su un benchmark interno: frasi di test WikiANN in sei lingue (NL, EN, DE, FR, ES, IT; 150 per lingua), valutate come micro-F1 su coppie (etichetta, testo) a livello di testo con il filtro anti falsi positivi di produzione applicato, su una macchina di sviluppo Apple Silicon in FP32. WikiANN è materiale Wikipedia annotato automaticamente ed è il terreno di addestramento di spaCy: leggi i numeri come indicazione relativa tra i livelli, non come accuratezza assoluta sul campo.

Scansione di sicurezza

Rilevamento opzionale di prompt injection e jailbreak alla chiusa, analizzato prima del dispatch. Tre modalità: off | log | block. off salta l’analisi. log registra i rilevamenti senza bloccare il traffico. block rifiuta gli attacchi rilevati e blocca se il modello non è disponibile o la classificazione fallisce o è incompleta. Nessun cambio automatico di modello.

La sicurezza usa sempre Llama Prompt Guard 2 86M (sluis/prompt-guard-2-86m), all’interno di Sluis senza trasferire il testo all’esterno. 0,01 EUR per analisi logica completata, una sola volta indipendentemente da finestre e verdetto, inclusi gli estratti sicuri; nessun supplemento a token. Disattivato, rifiuti preliminari ed errori tecnici non sono fatturati. Le finestre sovrapposte di massimo 512 token del modello mantengono i segmenti, nel budget totale configurato da 4096 a 65536 token. La soglia fissa è 0,8. L’analisi segue la protezione dei dati, che può conservare dati personali se disattivata o limitata al registro. Le analisi aggiungono latenza e hanno tempi massimi. Gli input lunghi usano estratti; un verdetto sicuro copre solo il testo ispezionato. Audit registra byte ispezionati e totali. Built with Llama. Meta Llama 3.1 Community License.

Ogni analisi ha una voce di audit fatturabile separata e collegata: security.scan. Possono esserci addebiti anche se la richiesta originale è bloccata o servita dalla cache. Le eccezioni per workload possono cambiare la modalità di analisi. Separatamente, l’ispezione della privacy Nemotron opzionale usa Nebul secondo la tua policy di residenza ed è fatturata a token.

Separatamente, il rilevamento opzionale di anomalie nel comportamento delle chiavi gira come job in background, senza alcuna latenza sulle richieste: baseline per chiave da statistiche robuste con stagionalità ora-della-settimana, più un livello multivariato a isolation forest. Gli alert sono spiegabili, mai un punteggio nudo, e arrivano nella vista Sicurezza della Console, con email opzionale.

Avviso al modello

Quando la tokenizzazione ha riscritto una richiesta, Sluis inietta un messaggio di sistema iniziale che dice al modello che i token «…» sono segnaposto opachi da mantenere intatti; è questo a rendere affidabile il ripristino. Attivo per impostazione predefinita; personalizzalo o disattivalo per organizzazione.

Conservazione e fedeltà dell'audit

La conservazione dei contenuti (i body di richiesta e risposta per il log di audit) è attiva per impostazione predefinita e cifrata a riposo; la fedeltà dell'audit sceglie se il contenuto conservato memorizza i token o i valori originali. Il contenuto conservato resta finché non lo cancelli, a meno che tu non imposti un periodo di conservazione in giorni in Console → Protezione dei dati. Una pulizia giornaliera applica il periodo in vigore al contenuto già memorizzato, quindi accorciarlo rimuove anche il contenuto più vecchio. Il contenuto delle chat di Sluis Workspace viene eliminato dopo il più breve tra quel periodo e il periodo di Workspace per i valori personali nelle chat (7 giorni per impostazione predefinita). Il registro dei metadati di audit viene mantenuto e mai modificato. Disattiva la conservazione per un registro di soli metadati; questo disattiva anche la cache di risposta.

Anonimizzazione di documenti

Invia un file docx, pdf, immagine o testo a POST /v1/documents/anonymize e lo stesso documento torna con PII e segreti sostituiti da tag come «PERSON_NAME_1» nel testo, e sfocati in immagini e pagine PDF. L'elaborazione resta locale alla gateway, OCR incluso; l'operazione viene sigillata nella catena di audit e fatturata per pagina/immagine. La mappa dei token viene restituita solo se la chiedi e non viene mai salvata. I PDF oscurati mantengono uno strato di testo invisibile e ricercabile costruito dal testo anonimizzato. Per i documenti grandi, accoda un job asincrono e recupera il risultato in seguito con un URL firmato a tempo. Nelle scansioni, le righe che l’OCR non riesce a leggere in modo affidabile, come firme e grafia illeggibile, e l’inchiostro fuori da ogni riga di testo riconosciuta, come sigle e timbri, vengono distrutti invece di essere indovinati. Compaiono come «UNREADABLE» nel livello di testo e la risposta segnala la categoria UNREADABLE_REDACTED.

La stessa protezione vale in transito: con la policy dlp_documents attiva, i file caricati via /v1/files e i documenti OCR inline vengono anonimizzati prima di uscire verso un provider, rifiutati in modalità block e analizzati in modalità allow_log.

# enqueue a large document (202 + job id; Idempotency-Key honoured)
curl https://api.sluis.ai/v1/documents/anonymize/jobs \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -F file=@archive.pdf

# poll until succeeded; the signed download_url then needs no API key
curl https://api.sluis.ai/v1/documents/anonymize/jobs/9c31… \
  -H "Authorization: Bearer $SLUIS_KEY"

{
  "id": "9c31…",
  "state": "succeeded",
  "filename": "archive.pdf",
  "summary": { "pages": 12, "images": 3, "categories": ["PERSON_NAME", "EMAIL"], "downgraded": false },
  "download_url": "https://api.sluis.ai/v1/documents/deliverables/9c31…?tenant=…&exp=…&sig=…"
}

Embeddings

I token pseudonimizzati sono stabili all'interno di una richiesta, non tra richieste; gli embedding di testo tokenizzato possono quindi differire tra le chiamate. L'impostazione dlp_embeddings controlla se la scansione copre /v1/embeddings: attiva per impostazione predefinita, impostarla su off invia gli input di embedding al provider senza scansione. Ogni chiamata esente è registrata nel registro di audit.

Termini da rimuovere per richiesta

Ogni richiesta JSON del piano dati — chat completions, completions, embeddings, responses e gli ingress nativi Anthropic — può portare un'estensione sluis di primo livello. La sua lista remove nomina i termini che la gateway deve rimuovere dal prompt prima dell'invio: una stringa semplice, oppure un oggetto con un text e un kind tra person | organization | location | term. Al massimo 128 voci, ciascuna non vuota dopo il trim e lunga al massimo 256 caratteri; il confronto avviene ai confini di parola e ignora maiuscole e minuscole. L'estensione stessa è un costrutto della gateway e viene sempre rimossa prima dell'invio: non raggiunge mai un provider, la cache o il contenuto conservato.

# name the terms the gateway must remove — the top-level "sluis" object never leaves the gateway
curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "mistral/mistral-large-latest",
        "messages": [{ "role": "user",
          "content": "Bas Alderding did a good job, send an email explaining how happy you are with that" }],
        "sluis": { "remove": [{ "text": "Bas Alderding", "kind": "person" }, "Project Nightingale"] } }'

# provider receives  → "«PERSON_NAME_1» did a good job, send an email explaining how happy you are with that"
# you receive back   → "Dear Bas Alderding, I am delighted with your work on Project Nightingale…"
# audit note         → dlp:tokenize:person_name(request)|dlp:tokenize:term(request)

# the OpenAI SDKs forward the gateway extension through extra_body
resp = client.chat.completions.create(
    model="mistral/mistral-large-latest",
    messages=[{"role": "user", "content": "Bas Alderding did a good job…"}],
    extra_body={"sluis": {"remove": [{"text": "Bas Alderding", "kind": "person"}]}},
)
# the originals are restored on the way out — the provider only ever saw «PERSON_NAME_1»
print(resp.choices[0].message.content)

Ogni corrispondenza diventa un token reversibile — «PERSON_NAME_1» — che si unisce alla normale pseudonimizzazione: in modalità tokenize, quella predefinita, i valori originali sono ripristinati nella risposta, streaming incluso; in modalità mask il termine è sostituito da [REDACTED:<kind>]; in modalità block la richiesta è rifiutata con 422. L'istruzione è sempre onorata, anche se la chiave imposta dlp: off, l'organizzazione gira in allow_log o /v1/embeddings è esentato: può solo rafforzare la protezione, mai indebolirla, ed è per questo che è ammessa per richiesta dove l'header ritirato x-sluis-dlp non lo era. Il termine elencato non raggiunge mai il provider.

Una direttiva malformata non viene mai ignorata in silenzio: un kind sconosciuto, una voce oltre i limiti o un campo sconosciuto dentro l'estensione vengono rifiutati con 422. Ciò che è stato realmente eseguito è divulgato sulla riga di audit sigillata, dove i termini forniti dal chiamante portano il livello request — dlp:tokenize:person_name(request) — distinto dai livelli (ner) e (directory), così il registro mostra da dove è arrivata ogni rimozione. La stessa lista è accettata come opzione remove su /v1/documents/anonymize e sui suoi job asincroni.

Deroghe del workload

Le deroghe appartengono al workload e si applicano a tutte le sue credenziali. Un owner o admin configura option_overrides in Console → Workloads o con POST /admin/workloads alla creazione. Le opzioni non impostate ereditano la policy dell'organizzazione. Per modificarlo, PATCH /admin/workloads/{workload_id} richiede tutte le impostazioni modificabili, inclusi nome, stato, limiti e budget; le sostituisce senza unire i singoli campi.

# create a workload with governed overrides; keys inherit its settings
curl -X POST https://api.sluis.ai/admin/workloads \
  -H "Authorization: Bearer $SLUIS_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "document-review", "option_overrides": {
        "dlp": { "mode": "off" },
        "ner_model": "deep",
        "security": { "prompt_injection": { "mode": "block" } } } }'
# sparse: absent fields inherit org policy; every deviation is sealed in the audit trail

L'header di richiesta x-sluis-dlp è stato rimosso. Le richieste che lo includono ricevono 400; configura il workload. Le deroghe effettive sono registrate nel registro di audit sigillato.