Saltar al contenido principal
Si tu app de LLM procesa datos personales de la UE, tres obligaciones de GDPR aterrizan en la ruta misma de la solicitud: mantener los datos personales al mínimo que el modelo necesita (Art. 5), evidenciar a dónde los envía el egress de herramientas (Art. 44), y honrar el derecho al borrado de un sujeto de datos (Art. 17). El pack de GDPR convierte esos en controles aplicados que instalas en una llamada — sin autorar políticas desde cero. Esta página es el aterrizaje de gdpr llm: qué materializa realmente instalar el pack, un flujo de instalación concreto, y cómo funciona el borrado de principio a fin. Para la referencia completa de las capas de contenido y acción, sigue los enlaces en vez de releerlas aquí.

​
1. Qué instala el pack de GDPR

Navegar el catálogo es gratis para cualquier Member del espacio de trabajo; instalar es una acción de plan de pago, de Admin del espacio de trabajo (la misma compuerta que poner en marcha — ver Restricciones por plan). Una instalación materializa filas reales y editables de Guardrail y Firewall mapeadas a los artículos del GDPR:
Un guardrail de PII que bloquea la solicitud cuando se detectan identificadores de la UE (IBAN, número NHS del Reino Unido, Steuer-ID alemán, NIR francés), así que los datos regulados nunca llegan al proveedor upstream. Se ejecuta en la etapa input. Ver Guardrails para la lista de entidades y las anulaciones de acción por entidad — puedes cambiar una entidad cubierta de block a mask tras la instalación.
Un guardrail de PII más amplio que rechaza de forma dura las solicitudes que contienen correos, números de teléfono, SSNs, números de tarjeta de crédito o IPs, así que los datos personales de categoría especial y los ordinarios se atrapan juntos.
Un guardrail de registro que registra cada decisión de guardrail como evidencia de procesamiento — alimentando el reporte firmado que lee tu auditor.
Una regla de egress de firewall que audita los destinos salientes que tus herramientas reportan al gateway, así que una evaluación de transferencia tiene un rastro real de a dónde fueron los datos. Ver Firewall para la coincidencia de egress.
El pack es un punto de partida que posees, no una caja negra. Cada regla que escribe es una fila ordinaria de guardrail o firewall que puedes editar, reordenar o deshabilitar en la consola después.

​
2. Instala el pack de GDPR (un flujo concreto)

Instala desde la consola en Compliance → Packs, con sesión iniciada como Admin del espacio de trabajo en un plan de pago. La consola conduce la ruta de gestión por ti usando tu sesión — esta es una ruta UserAuth, nunca una clave de relay (sk-orca-…): 
POST /api/compliance/packs/gdpr/install
Authorization: Bearer <your console session>
Antes de comprometerte, el catálogo te dice exactamente a qué framework estás mapeando — ábrelo como Member primero: 
GET /api/compliance/catalog
Authorization: Bearer <your console session>

{
  "key": "gdpr",
  "name": "GDPR",
  "framework": "EU General Data Protection Regulation",
  "jurisdiction": "EU/EEA"
}
Instala en observe primero. La regla de egress de firewall materializada puede ejecutarse en solo-audit para que observes los destinos reales de transferencia durante una semana antes de que se deniegue alguno — ver Observar vs aplicar.

​
3. Controles de PII en la solicitud

La minimización de datos es el control GDPR que soporta la carga, y en el gateway es un guardrail de PII. Por defecto el pack bloquea la solicitud en la etapa de entrada cuando se detectan datos personales de la UE — la solicitud se rechaza antes de que el modelo la vea, así que los datos regulados nunca llegan al proveedor upstream. Más allá de las entidades de la UE incluidas, puedes ajustar el guardrail que el pack instaló: elige exactamente qué entidades cubrir, cambia una entidad cubierta de block a mask, y agrega tus propios patrones de entidad personalizados. La lista completa de entidades, las anulaciones de acción por entidad y las opciones de entidad personalizada viven en la referencia de Guardrails.
Si cambias una entidad a mask, ese enmascarado está en vivo en la etapa de entrada pero evaluado en sandbox en la etapa de salida — el enmascarado en vivo de las respuestas del modelo está en la hoja de ruta. Un block de salida se aplica tanto en respuestas en streaming como sin streaming. Planifica tu minimización en torno a la etapa de entrada, donde tanto block como mask están totalmente en vivo.

​
4. Residencia para tu evidencia de gdpr llm

Los auditores de GDPR preguntan dónde vive la evidencia. El ajuste de residencia de datos de OrcaRouter estampa cada reporte de cumplimiento firmado con una región (us / eu / uk / ap / cn / global) y retiene cualquier reporte cuya región estampada ya no coincida con el espacio de trabajo. Para un programa de la UE, declara eu antes de generar los reportes en los que se fiará tu auditor: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
La residencia gobierna el artefacto del reporte, no dónde se ejecuta la inferencia. No es geo-fijación del tráfico de modelo. La página dedicada Residencia de datos cubre la distinción y qué pasa cuando cambias de región después de que existen reportes.

​
5. Derecho al borrado (Art. 17)

Una app de GDPR real necesita una ruta de borrado real, no una promesa. En OrcaRouter, la autoeliminación de cuenta ejecuta un flujo de gracia-luego-limpieza:
PasoQué pasa
SolicitudCuenta eliminada suavemente de inmediato; inicio de sesión bloqueado.
GraciaUna ventana cancelable de 30 días antes de la limpieza irreversible.
LimpiezaPII limpiada; purga en cascada de registros de solicitud, coincidencias de guardrail y eventos de firewall.
La ventana de gracia es cancelable — y un usuario aún puede exportar sus datos durante ella antes de que la limpieza se dispare (portabilidad de datos, Art. 20). Tras la ventana, la limpieza es irreversible y cascada a través de los registros que portan identificadores directos.
Los registros de solicitud se gobiernan por separado del borrado: la retención por defecto es de 30 días, recortada en el servidor a un máximo de 180 días. Bajarla reduce la ventana en que cualquier dato personal reside en los registros en absoluto — ver Retención.

​
6. Demuéstralo con un reporte firmado

Una vez que el pack está en marcha, genera un reporte de cumplimiento: está hasheado con SHA-256 y firmado con Ed25519, así que un auditor puede verificar que fue producido por OrcaRouter y no alterado — públicamente, sin un inicio de sesión. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "gdpr" }
Cualquiera puede verificar la firma contra la clave pública, y puedes entregar a un auditor un enlace de compartición acotado y con límite de tiempo. La mecánica vive en Reporte firmado y Verificar un reporte.

​
7. Dónde encaja esto

GDPR es un framework en el bucle de cumplimiento más amplio — instala un pack, obsérvalo, aplica, declara la residencia, luego entrega evidencia firmada.

Derecho al borrado

El flujo de gracia-luego-limpieza y la purga en cascada al completo.

Residencia de datos

Evidencia estampada por región, y por qué no es geo-fijación de inferencia.

Visión general de cumplimiento

El bucle completo — instalar, observar, aplicar y entregar evidencia firmada.

Guardrails

La referencia de la capa de contenido — entidades de PII, enmascarado y anulaciones.
Para la frontera entre lo que el gateway garantiza y lo que sigue siendo tuyo bajo GDPR — declarar la residencia, clasificar tus datos, desencadenar eliminaciones — el mapa de Responsabilidad compartida pone el pack de GDPR en contexto.