2 min di lettura · Aggiornato 2026-05-22

Come deployare una knowledge base AI GDPR-compliant

Playbook end-to-end per spedire un assistente AI customer-facing che soddisfa GDPR + EU AI Act — checklist, architettura, trappole comuni.

di helpcode engineering team · Engineering @ helpcode

Perché conta

Un assistente AI customer-facing processa dati personali — come minimo il transcript della conversazione, spesso l'email del cliente, l'ID account e il dispositivo di cui si sta lamentando. Questo lo mette in pieno dentro al GDPR (obblighi di titolare / responsabile) e, dal 2026, dentro all'EU AI Act (trasparenza, monitoraggio post-mercato, audit log). Costruire l'architettura sbagliata significa o non superare il procurement o pagare un rebuild a metà anno. Costruire quella giusta significa rilasciare più velocemente della concorrenza.

Questa guida è il playbook end-to-end che helpcode segue quando mette su un deployment knowledge base per un cliente UE.

Architettura di riferimento

Tre piani, separati by design:

  1. Piano di ingestion — preleva i documenti sorgente (Confluence, SharePoint, Drive, PDF) e fa chunking, OCR ed embedding. Indice per-tenant — il retrieval cross-tenant non è nemmeno possibile.
  2. Piano di retrieval — hybrid retrieval sull'indice per-tenant, pass del reranker, assemblaggio top-K. Tutto in-region (Francoforte).
  3. Piano di generation — la chiamata LLM. Scegliete un endpoint modello che resta in UE (Mistral Paris, Anthropic EU, OpenAI EU). Ogni risposta è loggata insieme alle citazioni usate.

La separazione conta perché ciascun piano ha un threat model diverso e una lista di sub-processor diversa.

Flusso dati & residenza

Due regole dure:

  • Nessun documento cliente lascia mai la UE a riposo. S3 bucket a Francoforte; backup a Francoforte.
  • La chiamata LLM rispetta l'endpoint regionale del provider del modello. Se scegliete anthropic.eu, prompt + snippet recuperati viaggiano dentro la UE e la risposta torna dentro la UE.

Documentate tutto nell'appendice del DPA e tenete la lista dei sub-processor pubblica — il procurement del vostro cliente la controllerà.

L'AI Act art. 50 richiede che l'utente sappia che sta parlando con un'AI. Due implementazioni pratiche:

  • Widget chat: un disclaimer di una riga sopra il campo di input. Non nascondetelo in un tooltip.
  • Voce: una frase di apertura "Ciao, sono l'assistente AI di ACME — dite 'umano' in qualunque momento per essere trasferiti." parlata nella lingua dell'utente.

Tracciate nell'audit log che la disclosure è stata renderizzata, così potete dimostrarlo in seguito.

Audit log & tracciabilità

L'AI Act art. 12 si aspetta che siate in grado di ricostruire ogni risposta. helpcode logga, per turno di conversazione:

  • il messaggio utente
  • i risultati di retrieval con i loro score di rilevanza
  • gli score del reranker
  • modello LLM + versione
  • il prompt finale + la risposta finale + le citazioni

Export CSV e accesso API on demand. È ciò che vuole il vostro auditor — e ciò di cui il vostro team di engineering ha bisogno per rilasciare miglioramenti di eval.

Checklist pre-lancio

  • Indice per-tenant, mai condiviso
  • Lista sub-processor solo-UE, pubblica
  • DPA firmato, SCC annessi
  • Disclosure AI renderizzata + loggata a ogni turno
  • Retention audit log ≥ 13 mesi
  • Clausola di data residency nel master agreement
  • Template FRIA compilato per il vostro specifico deployment
  • Percorso di handoff umano testato end-to-end

Quando tutte e otto passano, si rilascia.

L'autore

HE

helpcode engineering team

Engineering @ helpcode