Por qué las industrias reguladas no pueden añadir la privacidad a sus proyectos de IA como un complemento
Una responsable de cumplimiento en un banco regional de tamaño medio observa una demostración piloto de un chatbot de IA, y la primera pregunta que hace no es «¿funcionará?», sino «¿a dónde va la información de nuestros clientes?». Ese instinto, descrito en un reciente artículo de opinión de David Balaban en SC World, es el correcto, y aún así demasiadas organizaciones de servicios financieros, salud y seguros lo pasan por alto al lanzar un piloto.
El argumento de Balaban es sencillo y, para los sectores regulados, incómodo: la privacidad no puede ser una preocupación de segunda fase en los proyectos de IA. Un minorista que expone información personal identificable de sus clientes puede corregir el error en el siguiente sprint y seguir adelante. Un hospital que actúa igual se enfrenta a una violación de la ley HIPAA, obligaciones de notificación de brechas y una conversación a nivel de junta directiva sobre cómo ocurrió esto. Los riesgos no son simétricos, y tratar un piloto de IA como un lanzamiento de software común ignora esa diferencia.
No hay una brecha, incidente ni acción de cumplimiento específica detrás de este texto; es liderazgo de pensamiento, no un caso de estudio. Lo que lo hace relevante para Kiteworks es su enfoque: el artículo recorre el mapeo de flujos de datos, la política de retención, los registros de acceso y el Marco de Gestión de Riesgos de IA del NIST, usando el GDPR y la ley HIPAA para enmarcar los riesgos financieros y regulatorios. Son exactamente los dos marcos frente a los que Kiteworks está certificado, y las recomendaciones del artículo se alinean estrechamente con cómo debe funcionar en la práctica una capa de datos gobernada.
Esta publicación repasa el argumento de Balaban, verifica la única cifra concreta que menciona y conecta las prácticas que recomienda —mapear los datos antes de entrenar, buscar información personal identificable, mantener a personas en decisiones reguladas y realizar pruebas adversarias— con lo que una persona responsable de cumplimiento o una CISO debería esperar de una implementación de intercambio seguro de datos de Kiteworks que respalde iniciativas de IA en un entorno regulado.
Puntos Clave
1. La privacidad debe diseñarse antes del piloto, no parchearse después.
Las organizaciones de servicios financieros, salud y seguros enfrentan obligaciones de notificación de brechas, escrutinio regulatorio y escalamiento a la junta directiva que un error de software común nunca desencadena. Por eso, las decisiones sobre el manejo de datos de IA deben tomarse antes de escribir el primer prompt, no después de recibir una queja.
2. Los LLM no distinguen datos protegidos de texto común.
Registros de entrenamiento, transcripciones de chat, tickets de soporte y hojas de cálculo sin depurar son solo tokens para un modelo, lo que significa que la higiene de datos de la organización, no el criterio del modelo, es lo único que separa un conjunto de entrenamiento de una violación de cumplimiento.
3. Los auditores buscan tres elementos concretos: un diagrama de flujo de datos, una política de retención documentada y registros de acceso.
Promesas vagas sobre «IA responsable» no convencen a un evaluador. Poder entregar esos tres elementos bajo demanda es el verdadero estándar, y el Marco de Gestión de Riesgos de IA del NIST ofrece un lenguaje común para construirlos.
4. La responsabilidad regulatoria no se transfiere al proveedor de IA.
El GDPR, la Ley de IA de la UE y el historial de la FTC tratan a la organización que implementa la solución, no al proveedor del modelo, como responsable de lo que ocurre con los datos. Una suscripción a una herramienta de IA de terceros no traslada esa responsabilidad.
5. La gobernanza debe cubrir el acceso humano y de agentes bajo una sola política, no dos.
Cualquier iniciativa de IA que maneje datos regulados necesita los mismos controles de acceso, reglas de retención y registros de auditoría aplicados de forma consistente, ya sea una persona o un agente de IA quien realice la consulta.
La primera pregunta de la persona responsable de cumplimiento: ¿A dónde va la información de nuestros clientes?
La escena inicial de Balaban merece atención. Una responsable de cumplimiento de un banco observa una demo de chatbot y pregunta por el destino de los datos antes que por la funcionalidad. Ese orden no es paranoia; es su trabajo. En sectores regulados, «¿funciona?» es una pregunta de producto. «¿A dónde van los datos?» es una cuestión legal y reputacional, y debe responderse antes incluso de plantear la pregunta de producto, porque la respuesta determina si el piloto puede existir.
Este es el perfil para el que Kiteworks escribe por defecto: la CISO o Subdirectora de CISO que asume el riesgo de IA sin importar quién implementó la herramienta, y la persona responsable de cumplimiento o líder de GRC que debe presentar evidencias cuando un regulador las solicita. Ninguno de estos roles se beneficia de la confianza de un proveedor en que «el modelo se comporta bien». Se benefician de controles de acceso, una estructura de gobernanza de datos documentada y una trazabilidad de auditoría que pueda entregarse a un examinador sin prisas de última hora.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
Por qué los servicios financieros, la salud y los seguros no pueden salir del paso con parches tras un fallo de privacidad en IA
El contraste que plantea Balaban es el punto más claro del artículo: un minorista que expone información personal identificable de clientes corrige el fallo y publica una solución en el siguiente sprint. Un hospital que actúa igual se enfrenta a una violación de la ley HIPAA, notificaciones obligatorias de brechas y una junta directiva que quiere saber por qué nadie detectó esto antes del lanzamiento. Las aseguradoras y las instituciones financieras están en la misma situación: la GLBA, los reguladores estatales de seguros y los reguladores bancarios tratan los datos financieros y de salud de los clientes con un nivel de seriedad distinto al historial de compras de un programa de lealtad minorista.
Esa asimetría es el argumento principal para construir la privacidad desde el primer día. No es que las organizaciones reguladas se muevan más despacio por precaución; es que el coste de un fallo de privacidad en estos sectores es categóricamente distinto, y ningún esfuerzo de limpieza posterior recupera el tiempo de notificación, la atención del regulador ni la confianza del cliente. El enfoque de cumplimiento de Kiteworks, la autorización FedRAMP de impacto moderado, el cifrado validado FIPS 140-3 y las opciones de implementación de tenencia única existen precisamente porque este tipo de cliente necesita evidencias, no promesas, antes de que los datos lleguen a un modelo.
Los LLM son voraces: cómo la ingestión de datos de entrenamiento expone información no gestionada de salud e identificable
La descripción de Balaban de los grandes modelos de lenguaje como «voraces» es un atajo útil para un problema técnico real. Los LLM absorben registros de entrenamiento, transcripciones de chat, tickets de soporte y hojas de cálculo sin depurar, y ninguno de esos datos llega etiquetado. Como él dice, ninguno sabe que es información de salud protegida o un número de seguridad social de un cliente; para el modelo, son solo tokens. El modelo no tiene un concepto innato de clasificación de información de salud protegida o información personal identificable; ese criterio debe aplicarse antes de la ingestión, no durante.
Por eso la clasificación de datos y la gobernanza de acceso deben estar antes de cualquier modelo, no dentro de él. Si un ticket de soporte que contiene el número de cuenta y el código de diagnóstico de un cliente termina en un set de ajuste fino porque nadie mapeó dónde vivía ese ticket o quién podía consultarlo, el modelo ya aprendió algo que no debía, y no hay forma fiable de hacer que lo olvide. La clasificación de datos y la minimización de datos no son opcionales en un proyecto de IA; son el único mecanismo que previene este tipo de exposición antes de que ocurra.
Mapear el flujo de datos antes de escribir un prompt
El consejo práctico de Balaban es mapear el flujo de datos antes de escribir un solo prompt: dónde viven los datos, quién puede consultarlos y si el proveedor retiene registros de conversaciones para entrenamiento, y por cuánto tiempo. Son preguntas básicas, y el hecho de que aún sorprendan a los equipos dice mucho sobre cómo suelen empezar los pilotos de IA, con una mentalidad de prueba de concepto que omite la diligencia debida que un proyecto de datos en producción exigiría por defecto.
Un mapa de flujo de datos no es un diagrama por sí mismo. Es el artefacto que permite al equipo de cumplimiento responder, de forma concreta, qué sistemas toca una función de IA, cuáles de esos sistemas contienen datos regulados y qué ocurre con una consulta o documento una vez que sale del control de la organización. Sin ese mapa, «creemos que el proveedor no retiene nuestros datos» es una esperanza, no un control. Los principios de intercambio de datos de confianza cero —verificar cada solicitud de acceso, registrar cada transacción, nunca asumir confianza por ubicación de red— ofrecen una manera concreta de construir ese mapa en vez de adivinarlo.
Lo que realmente quieren los auditores: diagramas de flujo de datos, políticas de retención y registros de acceso
Balaban es específico sobre lo que esperan ver los auditores: un diagrama de flujo de datos, una política de retención documentada y registros de acceso. Es una lista corta, pero cada elemento debe poder entregarse bajo demanda, en un formato que un evaluador externo pueda leer y verificar, no reconstruirse después de recibir el aviso de auditoría.
Los registros de acceso, en particular, son donde fallan muchos pilotos de IA. Si una organización no puede responder claramente a «quién consultó este sistema de IA, cuándo y con qué datos», da igual lo buenas que sean las barreras del modelo; la ausencia de evidencia es el hallazgo en sí. Este es el problema más característico de la persona responsable de cumplimiento: un registro de auditoría que técnicamente existe en algún archivo de log no es lo mismo que uno de calidad probatoria que pueda presentarse dentro del plazo del regulador, en vez de semanas después de la solicitud.
El Marco de Gestión de Riesgos de IA del NIST como lenguaje común
Balaban menciona el NIST CSF y su contraparte para IA, el Marco de Gestión de Riesgos de IA del NIST, como la herramienta que da a los equipos legales, de seguridad, ciencia de datos y compras un lenguaje común para hablar de riesgos de IA. Ese enfoque es válido: las funciones de Gobernar, Mapear, Medir y Gestionar del AI RMF están diseñadas para dar a los equipos multifuncionales, y a los auditores y reguladores con los que interactúan, una estructura común para describir qué controles existen y por qué.
Vale la pena precisar qué es y qué no es este marco. El AI RMF del NIST es voluntario y no es algo para lo que una organización pueda certificarse; nadie audita a una empresa «según» el AI RMF como una C3PAO evalúa el cumplimiento CMMC. Su valor aquí es exactamente el que describe Balaban: un lenguaje común para el diagrama de flujo de datos y el registro de riesgos, no una casilla de cumplimiento en sí misma.
Cuatro prácticas que diferencian a las organizaciones que superan auditorías de IA
Balaban enumera cuatro prácticas que distinguen a las organizaciones que superan auditorías de IA de las que no:
- Mapear cada fuente de datos antes de iniciar el entrenamiento. Saber qué sistemas alimentan el modelo y cuáles contienen datos regulados antes de la primera sesión de entrenamiento, no después de que surja una pregunta en la revisión.
- Buscar información personal identificable en los conjuntos de entrenamiento con herramientas específicas. Balaban menciona Microsoft Presidio y AWS Macie como ejemplos de herramientas diseñadas para detectar datos personales ocultos en un corpus de entrenamiento.
- Mantener a personas en el circuito para decisiones reguladas. Decisiones de crédito, determinaciones de reclamaciones y soporte diagnóstico deben formar parte de un flujo de trabajo donde una persona revise y pueda anular la salida del modelo, no donde la decisión final la tome el modelo.
- Probar los modelos con prompts adversarios. Intentar activamente que el modelo filtre datos que no debería tener, antes de que lo haga un investigador externo o un cliente curioso.
Ninguna de estas prácticas es exótica. Lo notable es cómo omitirlas correlaciona con las organizaciones que terminan explicando una brecha a un regulador en vez de mostrar un control ya implementado.
La responsabilidad no se transfiere con una suscripción: GDPR, la Ley de IA de la UE y la FTC
El artículo de Balaban se apoya en dos regímenes regulatorios concretos para ilustrar la responsabilidad, y ambos resisten el análisis. Según el GDPR y la Ley de IA de la UE, los reguladores han dejado claro lo que Balaban afirma: la responsabilidad no se transfiere solo porque una organización compre una suscripción. Comprar una herramienta de IA a un proveedor no convierte a ese proveedor en responsable de cómo se usan los datos de la organización; la responsabilidad sigue siendo de la organización que implementa.
También menciona a la Comisión Federal de Comercio de EE. UU. (FTC), señalando que ya ha sancionado a empresas por reutilizar datos de clientes para entrenar modelos sin autorización. Esa afirmación coincide con el patrón de cumplimiento más amplio: la FTC ha perseguido a varias empresas en los últimos años por entrenar IA o crear perfiles con datos de usuarios recolectados bajo términos distintos a los usados después para entrenar modelos, y ha exigido la eliminación de datos y modelos como remedio en más de un caso.
La única cifra concreta en el artículo de Balaban es el tope legal del GDPR: las multas pueden llegar hasta el 4% de la facturación anual global. Esa cifra es correcta, con una matización: el texto del GDPR establece el límite superior en hasta 20 millones de euros o el 4% de la facturación global anual de la empresa en el ejercicio financiero anterior, lo que sea mayor, no «ingresos». Los dos términos suelen usarse indistintamente en comentarios y el fondo del argumento se mantiene: para un banco, sistema de salud o aseguradora multinacional, el 4% de la facturación global supera con creces el tope fijo en euros y es la cifra que llama la atención de la junta directiva.
Gobernar el acceso a datos para personas y agentes de IA bajo un solo plano de control
Cada una de las cuatro prácticas de Balaban parte de una premisa que los sectores regulados deben dejar clara: las mismas reglas de acceso, límites de retención y requisitos de registro aplican tanto si quien consulta los datos regulados es una persona como un agente de IA. La ley HIPAA no distingue si un analista humano o un agente de IA accede sin autorización a un registro de paciente; la infracción es la misma. El principio de responsabilidad del GDPR tampoco se suaviza porque el acceso lo haya iniciado un agente en vez de un empleado.
Esa es la lógica detrás del enfoque de Kiteworks Control Plane para la gobernanza de IA: una sola capa de políticas que rige el acceso, uso e intercambio de datos para personas y agentes de IA juntos, no una política para humanos con una excepción posterior para agentes. Presentar esto como que la gobernanza se «extiende» a los agentes implica que antes operaban fuera de cualquier política, lo cual es un error conceptual y de diseño de control. El modelo correcto es un solo conjunto de reglas —quién puede ver qué datos, bajo qué condiciones, y cómo se registra— que tanto usuarios humanos como agentes de IA cumplen desde el inicio.
Cómo Kiteworks cierra la distancia entre la ambición de IA y la realidad regulatoria
Las recomendaciones de Balaban —mapear datos antes de entrenar, buscar información personal identificable, mantener a personas en decisiones reguladas, probar adversarialmente y producir diagrama de flujo de datos, política de retención y registros de acceso bajo demanda— describen resultados. No explican cómo una organización construye la infraestructura para lograr esos resultados a escala en decenas de iniciativas de IA y unidades de negocio.
Ahí es donde dos capacidades específicas de Kiteworks se alinean con el argumento del artículo. Kiteworks Compliant AI gobierna qué contenido puede recuperar un sistema de IA y aplica esa política en el punto de recuperación, en vez de depender del propio modelo o de una limpieza posterior para detectar datos protegidos después del hecho. Esa es la respuesta arquitectónica al problema de ingestión de Balaban: si el sistema de IA no puede recuperar información de salud protegida o información personal identificable sin depurar desde el principio, no hay nada que «desentrenar» después.
En el ámbito de la auditoría, el Control Plane de Kiteworks produce el registro unificado y los registros de acceso que se alinean directamente con lo que, según Balaban, buscan los auditores: un historial de quién accedió a qué, cuándo y bajo qué política, consolidado para correo electrónico, uso compartido de archivos, transferencia de archivos gestionada y acceso de IA, en vez de estar disperso en múltiples logs de sistemas desconectados. El programa de cumplimiento de Kiteworks cubre los requisitos de cumplimiento de la ley HIPAA y cumplimiento del GDPR, los mismos dos marcos que Balaban usa para enmarcar los riesgos en su artículo, e incluye la Autorización FedRAMP, la atestación SOC 2 Tipo II y controles alineados con ISO 27001 que se extienden a las obligaciones de NIS2 y DORA. Para una persona responsable de cumplimiento cuya primera pregunta sobre cualquier piloto de IA es «¿a dónde van nuestros datos?», esa es la respuesta que debe existir antes de que empiece el piloto, no después de que lo solicite un examinador.
Si quieres saber más sobre cómo mapear flujos de datos de IA, generar registros de acceso listos para auditoría y gobernar el acceso de agentes de IA junto al acceso humano bajo HIPAA y GDPR, agenda una demo personalizada hoy.
Preguntas frecuentes
Depende totalmente de a qué puede acceder el chatbot, no de su propósito declarado. Si el sistema puede consultar o recuperar cualquier registro que contenga información de salud protegida, incluyendo un ticket de soporte que haga referencia a un diagnóstico o número de cuenta de paciente, está gestionando información de salud protegida, sin importar el alcance original del piloto. El enfoque más seguro es gobernar la recuperación en la capa de datos con Kiteworks Compliant AI para que el chatbot físicamente no pueda acceder a información de salud protegida que no estaba autorizado a ver, en vez de confiar en el caso de uso previsto para mantenerlo fuera de alcance. Consulta la página de cumplimiento de la ley HIPAA de Kiteworks para ver cómo se aplica la Security Rule a los flujos de trabajo asistidos por IA.
Los auditores en este ámbito suelen pedir tres elementos concretos: un diagrama de flujo de datos que muestre cómo se mueven los datos, una política de retención documentada que indique cuánto tiempo se conservan los datos y los registros, y registros de acceso que detallen quién consultó qué y cuándo. Una declaración de intenciones no sustituye la entrega de esos tres elementos bajo demanda. Una trazabilidad de auditoría consolidada de todos los sistemas que intervienen en el flujo de IA es lo que convierte «tenemos una política» en evidencia verificable para un evaluador.
No. El AI RMF del NIST es una guía voluntaria, no un esquema de certificación; no existe un equivalente a un evaluador CMMC que valore a una organización según este marco. Su valor está en ofrecer una estructura compartida (Gobernar, Mapear, Medir, Gestionar) que los equipos legales, de seguridad, ciencia de datos y cumplimiento pueden usar para describir el riesgo de IA de forma coherente entre sí y ante los reguladores. Las organizaciones siguen necesitando marcos concretos como la ley HIPAA y el GDPR, junto con atestaciones auditadas como SOC 2, para demostrar cumplimiento real.
No bajo el GDPR, la Ley de IA de la UE ni el historial de cumplimiento de la FTC, que consideran responsable a la organización que implementa la solución por lo que ocurra con sus datos, sin importar qué modelo de proveedor los procese. Los términos de servicio del proveedor pueden limitar su propia responsabilidad, pero no transfieren la responsabilidad regulatoria de la organización que implementa. Por eso la gobernanza de acceso y los registros de auditoría deben estar bajo el control de la organización, no solo dentro de la «caja negra» del proveedor.
La organización que implementa es responsable en ambos casos; la ley HIPAA, el GDPR y la GLBA regulan los datos, no la identidad de quien los accede. En la práctica, esto significa que los controles de acceso, reglas de retención y registros deben aplicarse de forma idéntica a usuarios humanos y agentes de IA bajo una sola capa de políticas, que es la lógica del enfoque Kiteworks Control Plane: un conjunto de reglas gobernadas para ambos, en vez de una política para humanos con una excepción para agentes. Las organizaciones sin una persona responsable del comportamiento de los agentes son las que más probablemente descubrirán esta brecha durante una auditoría en vez de antes.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección de privacidad asequible en IA - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.