Passer au contenu principal
Si votre application LLM traite des données personnelles de l’UE, trois obligations GDPR atterrissent sur le chemin de requête lui-même : garder les données personnelles au minimum dont le modèle a besoin (Art. 5), attester où l’egress des outils les envoie (Art. 44), et honorer le droit à l’effacement d’une personne concernée (Art. 17). Le pack GDPR transforme celles-ci en contrôles appliqués que vous installez en un seul appel — aucune rédaction de politique à partir de zéro. Cette page est l’atterrissage GDPR LLM : ce que l’installation du pack matérialise réellement, un flux d’installation concret, et comment l’effacement fonctionne de bout en bout. Pour la référence complète des couches de contenu et d’action, suivez les liens plutôt que de les relire ici.

​
1. Ce que le pack GDPR installe

Parcourir le catalogue est gratuit pour tout Member de l’espace de travail ; installer est une action d’Admin de l’espace de travail sur un plan payant (la même barrière que le passage en production — voir Plan gating). Une installation matérialise des lignes Guardrail et Firewall réelles et éditables mises en correspondance avec les articles GDPR :
Un guardrail PII qui bloque la requête lorsque des identifiants de l’UE (IBAN, numéro NHS du Royaume-Uni, Steuer-ID allemand, NIR français) sont détectés, de sorte que les données réglementées n’atteignent jamais le fournisseur amont. Il tourne sur le stage input. Voir Guardrails pour la liste d’entités et les surcharges d’action par entité — vous pouvez basculer une entité couverte de block vers mask après l’installation.
Un guardrail PII plus large qui rejette en dur les requêtes contenant des emails, numéros de téléphone, SSN, numéros de carte de crédit, ou IPs, de sorte que les données de catégorie spéciale et les données personnelles ordinaires sont attrapées ensemble.
Un guardrail de journalisation qui enregistre chaque décision de guardrail comme preuve de traitement — alimentant le rapport signé que lit votre auditeur.
Une règle d’egress firewall qui audite les destinations sortantes que vos outils rapportent à la passerelle, de sorte qu’une évaluation de transfert ait une piste réelle de l’endroit où les données sont allées. Voir Firewall pour la correspondance d’egress.
Le pack est un point de départ que vous possédez, pas une boîte noire. Chaque règle qu’il écrit est une ligne guardrail ou firewall ordinaire que vous pouvez éditer, réordonner, ou désactiver dans la console ensuite.

​
2. Installer le pack GDPR (un flux concret)

Installez depuis la console sous Compliance → Packs, connecté en tant qu’Admin de l’espace de travail sur un plan payant. La console pilote la route de gestion pour vous en utilisant votre session — c’est une route UserAuth, jamais une clé de relais sk-orca-… : 
POST /api/compliance/packs/gdpr/install
Authorization: Bearer <your console session>
Avant de vous engager, le catalogue vous dit exactement à quel framework vous correspondez — ouvrez-le d’abord en tant que Member : 
GET /api/compliance/catalog
Authorization: Bearer <your console session>

{
  "key": "gdpr",
  "name": "GDPR",
  "framework": "EU General Data Protection Regulation",
  "jurisdiction": "EU/EEA"
}
Installez d’abord en observe. La règle d’egress firewall matérialisée peut tourner en audit seul de sorte que vous observiez les destinations de transfert réelles pendant une semaine avant qu’aucune d’elles ne soit refusée — voir Observer vs appliquer.

​
3. Contrôles PII sur la requête

La minimisation des données est le contrôle GDPR porteur, et sur la passerelle c’est un guardrail PII. Par défaut, le pack bloque la requête au stage input lorsque des données personnelles de l’UE sont détectées — la requête est rejetée avant que le modèle ne la voie, de sorte que les données réglementées n’atteignent jamais le fournisseur amont. Au-delà des entités UE groupées, vous pouvez ajuster le guardrail que le pack a installé : choisissez exactement quelles entités couvrir, basculez une entité couverte de block vers mask, et ajoutez vos propres patterns d’entités personnalisés. La liste d’entités complète, les surcharges d’action par entité, et les options d’entités personnalisées vivent dans la référence Guardrails.
Si vous basculez une entité vers mask, ce masquage est en direct sur le stage input mais évalué en sandbox sur le stage output — le masquage en direct des réponses du modèle est sur la roadmap. Un block en sortie est appliqué sur les réponses streaming et non-streaming. Planifiez votre minimisation autour du stage input, où block et mask sont tous deux pleinement en direct.

​
4. Résidence pour vos preuves GDPR LLM

Les auditeurs GDPR demandent où vivent les preuves. Le réglage de résidence des données d’OrcaRouter estampille chaque rapport de conformité signé avec une région (us / eu / uk / ap / cn / global) et retient tout rapport dont la région estampillée ne correspond plus à l’espace de travail. Pour un programme de l’UE, déclarez eu avant de générer les rapports sur lesquels votre auditeur va se fier : 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
La résidence gouverne l’artefact de rapport, pas l’endroit où l’inférence s’exécute. Ce n’est pas un géo-épinglage du trafic de modèle. La page dédiée Résidence des données couvre la distinction et ce qui se passe quand vous changez de région après l’existence des rapports.

​
5. Droit à l’effacement (Art. 17)

Une vraie application GDPR a besoin d’un vrai chemin d’effacement, pas d’une promesse. Sur OrcaRouter, l’auto-suppression de compte exécute un flux grâce-puis-purge :
ÉtapeCe qui se passe
RequêteCompte supprimé de façon douce immédiatement ; connexion bloquée.
GrâceUne fenêtre annulable de 30 jours avant la purge irréversible.
PurgePII purgées ; purge en cascade des logs de requêtes, correspondances de guardrail, et événements firewall.
La fenêtre de grâce est annulable — et un utilisateur peut encore exporter ses données pendant celle-ci avant que la purge ne se déclenche (portabilité des données, Art. 20). Après la fenêtre, la purge est irréversible et cascade à travers les enregistrements qui portent des identifiants directs.
Les logs de requêtes sont gouvernés séparément de l’effacement : la rétention par défaut est de 30 jours, bornée par le serveur à un maximum de 180 jours. La réduire diminue la fenêtre pendant laquelle des données personnelles restent dans les logs tout court — voir Rétention.

​
6. Prouvez-le avec un rapport signé

Une fois le pack en production, générez un rapport de conformité : il est hashé SHA-256 et signé Ed25519, de sorte qu’un auditeur peut vérifier qu’il a été produit par OrcaRouter et non altéré — publiquement, sans connexion. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "gdpr" }
Quiconque peut vérifier la signature contre la clé publique, et vous pouvez remettre à un auditeur un lien de partage à portée limitée et limité dans le temps. Les mécaniques vivent dans Rapport signé et Vérifier un rapport.

​
7. Où cela s’inscrit

Le GDPR est un framework dans la boucle de conformité plus large — installer un pack, l’observer, appliquer, déclarer la résidence, puis livrer des preuves signées.

Droit à l'effacement

Le flux grâce-puis-purge et la purge en cascade en entier.

Résidence des données

Des preuves estampillées par région, et pourquoi ce n’est pas un géo-épinglage de l’inférence.

Vue d'ensemble de la conformité

La boucle complète — installer, observer, appliquer, et livrer des preuves signées.

Guardrails

La référence de la couche de contenu — entités PII, masquage, et surcharges.
Pour la frontière entre ce que la passerelle garantit et ce qui reste le vôtre sous le GDPR — déclarer la résidence, classer vos données, déclencher les suppressions — la carte Responsabilité partagée met le pack GDPR en contexte.