Privedge Las leyes. Los artículos. La solución.
Análisis normativo artículo por artículo
Este documento recoge el análisis técnico-legal de cómo la arquitectura de Privedge satisface los requisitos concretos de cada normativa. Cada artículo incluye el texto del requisito y el control técnico que lo cubre. Diseñado para DPOs, CISOs y equipos legales.
Un dataset se considera desidentificado si se eliminan los 18 identificadores: nombres, fechas, teléfonos, emails, SSN, MRN, números de cuenta, etc.
Privedge detecta y redacta exactamente esos identificadores (nombres vía NER; SSN, MRN, fechas, teléfono, email vía regex) antes de que el prompt salga del nodo. El payload cumple Safe Harbor.
El uso o divulgación de PHI debe limitarse al mínimo necesario para el propósito.
El modo Edge elimina la divulgación por completo: el PHI nunca se divulga a un tercero porque la inferencia ocurre en el nodo.
Compartir PHI con un proveedor (OpenAI) exige un BAA firmado.
Si OpenAI nunca recibe PHI, no hay relación de business associate que documentar. El proveedor de IA queda fuera del perímetro HIPAA.
Toda brecha de PHI no cifrado obliga a notificar a afectados y a HHS en plazos estrictos.
Una brecha en el proveedor de IA no expone PHI: solo vio tokens. Se reduce drásticamente el riesgo de notificación obligatoria.
El responsable debe aplicar medidas técnicas apropiadas, incluyendo la seudonimización y el cifrado de los datos personales.
La seudonimización reversible de Privedge es literalmente la medida que pide el Art. 32(1)(a). No la "cumples": tu arquitectura la implementa.
La privacidad debe estar integrada en la arquitectura, no añadida como política.
El edge como punto de anonimización es privacy-by-design en estado puro: el dato no puede fugarse porque nunca sale del nodo.
Tras la anulación del Privacy Shield, transferir a EE. UU. exige SCCs + medidas técnicas suplementarias.
Si solo salen datos anonimizados, no hay transferencia de datos personales (Considerando 26). Se eliminan SCCs y Transfer Impact Assessment para la llamada de IA.
El RGPD no se aplica a información anónima que no permite identificar a una persona.
El payload que llega a OpenAI cae fuera del ámbito material del RGPD. Este es el argumento jurídico central de Privedge.
El procesador debe ofrecer garantías suficientes y operar bajo contrato.
Privedge actúa como encargado bajo DPA. El triángulo queda limpio: cliente (responsable) → Privedge (encargado) → IA (fuera de ámbito, solo ve tokens).
Toda violación de datos personales debe notificarse a la autoridad en 72 h.
Una brecha en el proveedor de IA solo expone tokens. Si no hay violación de datos personales, no se dispara la obligación del Art. 33/34.
El número de tarjeta (PAN) debe quedar ilegible mediante truncado, tokenización o cifrado.
Privedge tokeniza el PAN antes de que el prompt salga. La nube nunca recibe el número real de tarjeta.
La tokenización reduce el scope de auditoría PCI de los sistemas que ya no almacenan PAN real.
Al no enviar nunca PAN real al proveedor de IA, ese flujo sale del scope PCI. Menos sistemas que auditar = auditoría más barata.
La información desidentificada queda excluida de la definición de "información personal".
El payload anonimizado que llega a la IA es deidentified information: fuera del alcance de CCPA/CPRA.
CPRA creó la categoría de SPI (SSN, geolocalización, datos de salud, financieros) con régimen reforzado.
Privedge detecta y redacta SPI antes de cualquier procesamiento por terceros.
Los datos anonimizados no se consideran datos personales salvo que el proceso de anonimización pueda revertirse con esfuerzo razonable.
El dato que sale del nodo está anonimizado; el mapa de reversión nunca abandona la frontera. Fuera del ámbito de la LGPD para el tercero.
La transferencia internacional exige país adecuado o garantías específicas aprobadas por la ANPD.
Sin datos personales en el payload, no hay transferencia internacional de datos personales que autorizar.
Control nuevo en la revisión 2022: el enmascaramiento de datos para limitar la exposición de información sensible.
Privedge implementa data masking en el flujo de IA como control técnico directo y demostrable ante el auditor.
Medidas de prevención de fuga de datos aplicadas a sistemas que procesan información sensible.
El proxy es exactamente un control DLP en el canal de IA: detecta y bloquea la fuga de PII y secretos (API keys, JWTs).
La información confidencial debe identificarse y protegerse durante su ciclo de vida.
Privedge identifica el PII en tiempo real y evita su divulgación a subprocesadores. El dashboard documenta cada detección.
Recopilación, uso, retención y divulgación de información personal conforme a los compromisos de la entidad.
Los logs de Privedge —qué PII, qué estrategia, qué nodo, qué latencia— son la evidencia que el auditor SOC 2 pide.
Los sistemas de IA de alto riesgo deben aplicar prácticas de gobernanza de datos con minimización y salvaguardas.
Privedge es la capa de gobernanza de datos en la entrada del sistema de IA: controla qué datos personales se procesan y cómo se minimizan.
Los sistemas de alto riesgo deben registrar automáticamente eventos para garantizar trazabilidad.
El dashboard de Privedge registra cada petición, detección y estrategia aplicada: trazabilidad lista para el expediente técnico del AI Act.
El uso secundario de datos sanitarios exige entornos seguros de procesamiento y datos anonimizados o seudonimizados.
La arquitectura edge de Privedge es exactamente lo que el EHDS exige: el dato clínico se anonimiza en el nodo o no sale de él.
El uso de proveedores TIC externos (un proveedor de IA) exige evaluación y mitigación del riesgo de concentración.
Al no enviar datos identificables al proveedor de IA, se reduce drásticamente el riesgo del tercero TIC: su compromiso no expone datos de clientes.
| Certification | Status | Provider | Scope |
|---|---|---|---|
| SOC 2 Type II | Active | Cloudflare, Inc. | Compute, network, data center operations |
| ISO 27001:2022 | Active | Cloudflare, Inc. | Information security management |
| HIPAA-eligible | Active | Cloudflare Workers | PHI processing on Cloudflare infrastructure |
| PCI DSS Level 1 | Active | Cloudflare, Inc. | Network infrastructure |
| SOC 2 Type II | Roadmap (2026) | Privedge | Application-level controls |
- PII detection and tokenization in every prompt
- Token maps never written to persistent storage
- TLS 1.3 for all data in transit
- V8 isolate per request — zero cross-request state
- Audit metadata logging (no prompt content, no PII values)
- Breach notification to Customer within 24 h of discovery
- Deletion of all retained data within 30 days of contract end
- Determining applicable regulations for their industry
- Configuring detection profiles for their data types
- Conducting their own DPIA / ISMS assessment
- Handling data subject requests from their users
- Compliance of their application layer and user interface
- Regulatory filings and engagement with supervisory authorities
- Ensuring their users do not deliberately encode PII as tokens
Note: Privedge does not provide legal advice. Customers must engage their own legal counsel to determine the adequacy of these controls for their specific regulatory obligations.
Privedge Documento confidencial · No distribuir · privedge.io