Protezione dei dati

Le modalità di rilevamento, la libreria di 60 rilevatori, il rilevamento delle entità con i suoi modelli selezionabili, la scansione di sicurezza, l'avviso al modello e la 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». Solo i token raggiungono il provider, 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.

# 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 intercettare solo con pattern. Sluis aggiunge cinque livelli opzionali: euristiche di contesto (titoli onorifici, formule di saluto, firme; solo persone), correlazione email (deriva i nomi dagli indirizzi nello stesso testo), una rubrica di nomi del tenant, un dizionario dei nomi incluso e NER: un modello di riconoscimento gestito da Sluis come sidecar interno alla rete, così il testo non lascia mai il perimetro dell'installazione per essere analizzato. NER trova persone, organizzazioni e luoghi nella prosa libera.

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

Due livelli bilanciano latenza e tasso di rilevamento: swift (spaCy xx_ent_wiki_sm) risponde in pochi millisecondi con copertura multilingue di base; deep (GLiNER2-PII su base mDeBERTa-v3, Apache-2.0) rileva sensibilmente di più, con una latenza maggiore per segmento analizzato. Scegli per organizzazione in Policy → Protezione dei dati; una chiave può scegliere un modello diverso tramite i suoi option overrides, ma non può mai attivare il livello quando l'organizzazione lo tiene spento.

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. log registra i rilevamenti nel registro di audit senza toccare il traffico; block rifiuta la richiesta con un 403 permission_error sigillato ("request refused: prompt-injection scan flagged this request"). La soglia di attivazione si configura per organizzazione, e la scansione fallisce in apertura: un guasto dello scanner non ferma mai il traffico.

La scansione aggiunge circa 20 ms su un prompt corto e circa 620 ms su uno lungo (1500 caratteri), misurato su un benchmark interno; il caso peggiore è limitato, perché lo scanner pone un tetto alle finestre da 512 token valutate per richiesta. Gira in parallelo con la scansione NER, quindi la latenza aggiunta combinata è vicina al maggiore dei due, non alla somma. Il rilevamento è un classificatore, non una prova: testo benigno dall'aria di istruzione può risultare injection, una realtà nota in tutto il settore, ed è per questo che log è la modalità di partenza consigliata.

Ogni rilevamento è divulgato nel registro di audit come sec:injection:<score>, quindi la revisione non richiede strumenti aggiuntivi. Le deviazioni per chiave passano dagli stessi option overrides della protezione dei dati.

Built with Llama. The scan model is Llama Prompt Guard 2 86M (multilingual), used under the Llama 4 Community License.

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 scheda 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. Disattiva la conservazione per un registro di soli metadati; questo disattiva anche le 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.

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.

Option overrides per chiave

Le deroghe via header di richiesta non esistono più: le deviazioni sono configurazione di chiave permanente e governata. Un owner o admin imposta option_overrides sparsi su una chiave, nella vista API keys della Console o via POST/PUT /admin/keys: la modalità di protezione dei dati (incluso off), il modello NER e la modalità della scansione injection. Ciò che non è impostato eredita la policy dell'organizzazione, e una chiave non può mai attivare un livello che l'organizzazione tiene spento.

# per-key option overrides are standing key config, set by an owner or admin
curl -X PUT https://api.sluis.ai/admin/keys/{key_id} \
  -H "Authorization: Bearer $SLUIS_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "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. Una richiesta che lo porta ancora, con qualsiasi valore, viene rifiutata con 400 e un rimando agli option overrides della chiave. Ogni deviazione in vigore è divulgata sulla riga di audit sigillata, così il registro mostra sempre quale configurazione è stata effettivamente eseguita.