Vai al contenuto principale
Se la tua app LLM tratta dati personali UE, tre obblighi GDPR atterrano sul percorso della richiesta stesso: mantieni i dati personali al minimo che il modello necessita (Art. 5), evidenzia dove li manda l’egress dei tool (Art. 44), e onora il diritto alla cancellazione di un soggetto dei dati (Art. 17). Il pack GDPR trasforma quelli in controlli applicati che installi in una sola chiamata — nessuna autorazione di policy da zero. Questa pagina è l’atterraggio gdpr llm: cosa materializza davvero installare il pack, un flusso di installazione concreto, e come funziona la cancellazione end to end. Per il riferimento completo del content- e action-layer, segui i link anziché rileggerli qui.

​
1. Cosa installa il pack GDPR

Sfogliare il catalogo è gratis per qualsiasi Member del workspace; installare è un’azione da Admin del workspace su piano a pagamento (lo stesso gate dell’andare live — vedi Plan gating). Una sola installazione materializza righe reali e modificabili di Guardrail e Firewall mappate su articoli GDPR:
Un guardrail PII che blocca la richiesta quando vengono rilevati identificatori UE (IBAN, numero UK NHS, Steuer-ID tedesco, NIR francese), così i dati regolamentati non raggiungono mai il provider upstream. Gira in fase di input. Vedi Guardrails per l’elenco delle entità e gli override di azione per-entità — puoi passare un’entità coperta da block a mask dopo l’installazione.
Un guardrail PII più ampio che rifiuta in modo netto le richieste contenenti email, numeri di telefono, SSN, numeri di carta di credito o IP, così i dati di categoria speciale e i dati personali ordinari sono intercettati insieme.
Un guardrail di logging che registra ogni decisione del guardrail come evidenza di trattamento — alimentando il report firmato che il tuo auditor legge.
Una regola di egress del firewall che audita le destinazioni in uscita che i tuoi tool riportano al gateway, così una valutazione di trasferimento ha una traccia reale di dove sono andati i dati. Vedi Firewall per il matching di egress.
Il pack è un punto di partenza che possiedi, non una scatola nera. Ogni regola che scrive è una riga ordinaria di guardrail o firewall che puoi modificare, riordinare o disabilitare nella console dopo.

​
2. Installa il pack GDPR (un flusso concreto)

Installa dalla console sotto Compliance → Packs, loggato come Admin del workspace su un piano a pagamento. La console guida la rotta di management per te usando la tua sessione — questa è una rotta UserAuth, mai una chiave di relay (sk-orca-…): 
POST /api/compliance/packs/gdpr/install
Authorization: Bearer <your console session>
Prima di impegnarti, il catalogo ti dice esattamente su quale framework stai mappando — aprilo prima come Member: 
GET /api/compliance/catalog
Authorization: Bearer <your console session>

{
  "key": "gdpr",
  "name": "GDPR",
  "framework": "EU General Data Protection Regulation",
  "jurisdiction": "EU/EEA"
}
Installa prima in observe. La regola di egress del firewall materializzata può girare solo-audit così osservi le destinazioni di trasferimento reali per una settimana prima che qualcuna di esse venga negata — vedi Observe vs enforce.

​
3. Controlli PII sulla richiesta

La minimizzazione dei dati è il controllo GDPR portante, e sul gateway è un guardrail PII. Di default il pack blocca la richiesta in fase di input quando vengono rilevati dati personali UE — la richiesta è rifiutata prima che il modello la veda, così i dati regolamentati non raggiungono mai il provider upstream. Oltre alle entità UE incluse, puoi regolare il guardrail che il pack ha installato: scegli esattamente quali entità coprire, passa un’entità coperta da block a mask, e aggiungi i tuoi pattern di entità personalizzati. L’elenco completo delle entità, gli override di azione per-entità, e le opzioni di entità personalizzata vivono nel riferimento Guardrails.
Se passi un’entità a mask, quel masking è live in fase di input ma sandbox-evaluated in fase di output — il masking live delle risposte del modello è in roadmap. Un block in output è applicato sulle risposte sia streaming che non-streaming. Pianifica la tua minimizzazione attorno alla fase di input, dove sia block che mask sono pienamente live.

​
4. Residency per le tue evidenze gdpr llm

Gli auditor GDPR chiedono dove vivono le evidenze. L’impostazione di data-residency di OrcaRouter marca ogni report di compliance firmato con una regione (us / eu / uk / ap / cn / global) e trattiene qualsiasi report la cui regione marcata non corrisponde più al workspace. Per un programma UE, dichiara eu prima di generare i report su cui il tuo auditor farà affidamento: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
La residency governa l’artefatto report, non dove gira l’inferenza. Non è geo-blocco del traffico del modello. La pagina dedicata Data residency copre la distinzione e cosa succede quando cambi regione dopo che esistono dei report.

​
5. Diritto alla cancellazione (Art. 17)

Una vera app GDPR ha bisogno di un vero percorso di cancellazione, non una promessa. Su OrcaRouter, l’auto-cancellazione dell’account esegue un flusso grazia-poi-scrub:
PassoCosa succede
RichiestaAccount soft-eliminato immediatamente; login bloccato.
GraziaUna finestra cancellabile di 30 giorni prima dello scrub irreversibile.
ScrubPII ripulite; purge a cascata di log delle richieste, match dei guardrail ed eventi del firewall.
La finestra di grazia è cancellabile — e un utente può ancora esportare i propri dati durante di essa prima che lo scrub si attivi (portabilità dei dati, Art. 20). Dopo la finestra, lo scrub è irreversibile e fa cascade attraverso i record che portano identificatori diretti.
I log delle richieste sono governati separatamente dalla cancellazione: la retention di default è 30 giorni, server-clamped a un massimo di 180 giorni. Abbassarla riduce la finestra in cui qualsiasi dato personale sta nei log affatto — vedi Retention.

​
6. Dimostralo con un report firmato

Una volta che il pack è live, genera un report di compliance: è hashato SHA-256 e firmato Ed25519, così un auditor può verificare che è stato prodotto da OrcaRouter e non alterato — pubblicamente, senza un login. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "gdpr" }
Chiunque può verificare la firma contro la chiave pubblica, e puoi consegnare a un auditor un link di condivisione con scope e limitato nel tempo. La meccanica vive in Report firmato e Verifica un report.

​
7. Dove si colloca

Il GDPR è un framework nel loop di compliance più ampio — installa un pack, osservalo, applica, dichiara la residency, poi spedisci evidenze firmate.

Diritto alla cancellazione

Il flusso grazia-poi-scrub e il purge a cascata per intero.

Data residency

Evidenze region-stamped, e perché non è geo-blocco dell’inferenza.

Panoramica sulla compliance

L’intero loop — installa, osserva, applica, e spedisci evidenze firmate.

Guardrails

Il riferimento del content-layer — entità PII, masking e override.
Per il confine tra ciò che il gateway garantisce e ciò che resta tuo sotto il GDPR — dichiarare la residency, classificare i tuoi dati, attivare le cancellazioni — la mappa di Responsabilità condivisa mette il pack GDPR in contesto.