Por qué los avisos del sistema no son controles de cumplimiento
Cuando las organizaciones implementan agentes de IA en flujos de trabajo con datos regulados, el enfoque de gobernanza más común es un prompt de sistema bien diseñado. Se le indica al modelo que no acceda a ciertas categorías de datos. Se le pide que permanezca dentro de límites definidos. Se configura para que rechace ciertos tipos de solicitudes. Para muchos equipos de seguridad y cumplimiento, esto parece gobernanza: está documentado, es revisable y limita visiblemente el comportamiento del agente durante las pruebas.
No es un control de cumplimiento. Es una instrucción. La distinción es fundamental, porque cuando un auditor de HIPAA, una persona evaluadora de CMMC o una persona examinadora de la SEC revisa la implementación de un agente de IA, no evalúa lo que se le dijo al modelo que hiciera. Evalúa lo que la capa de datos impidió técnicamente que ocurriera. Son cosas fundamentalmente distintas, y la distancia entre ambas es donde las empresas reguladas están acumulando exposición de cumplimiento a gran escala.
Esta publicación explica las razones técnicas por las que los prompts de sistema no pueden funcionar como controles de cumplimiento, los modos de fallo que esto genera en entornos regulados, lo que realmente exigen los reguladores como evidencia de control de acceso y por qué la gobernanza en la capa de datos es la única arquitectura que produce cumplimiento defendible para el acceso de agentes de IA a datos regulados.
Resumen Ejecutivo
Idea principal: Los prompts de sistema, los límites de seguridad de IA, el ajuste fino del modelo y los filtros de seguridad operan todos en la capa del modelo. Limitan lo que el modelo hará bajo condiciones normales, pero no pueden impedir el acceso a los datos, no generan evidencia defendible en auditoría y no resisten los vectores de ataque que reguladores, personas evaluadoras y adversarios conocen y aplican. Solo la gobernanza aplicada en la capa de datos —independiente del modelo, el prompt y el framework del agente— constituye un control de acceso que cumple con los requisitos de HIPAA, CMMC, SEC, PCI DSS o SOX.
Por qué te debe importar: Las organizaciones que creen que sus implementaciones de IA están gobernadas porque han configurado prompts de sistema y límites de seguridad están asumiendo una exposición de cumplimiento que desconocen. Cada interacción de un agente de IA con datos regulados gobernada solo en la capa del modelo es una interacción que no puede generar el registro de autenticación, la documentación de la política de acceso ni la trazabilidad de auditoría a prueba de manipulaciones que exigen los reguladores. Cuando llega la auditoría, «le dijimos al modelo que no lo hiciera» no es evidencia de un control. Es evidencia de una suposición.
Puntos clave
- Un prompt de sistema es una instrucción, no un control. Las instrucciones le dicen al modelo qué hacer. Los controles impiden acciones no autorizadas sin importar lo que se le diga o decida el modelo. Un prompt de sistema que dice «no accedas a registros de pacientes fuera de este encuentro» no impide técnicamente que el agente consulte cualquier registro de paciente al que la cuenta de servicio tenga acceso. Solo expresa una preferencia de comportamiento que el modelo seguirá hasta que algo lo sobreescriba.
- Los prompts de sistema pueden ser eludidos mediante prompt injection —y esto es una vulnerabilidad estructural, no un problema de configuración. El prompt injection permite a una persona atacante insertar instrucciones en el contenido que el agente de IA lee, sobreescribiendo o complementando el prompt de sistema original. Un estudio de red-team en febrero de 2026 realizado por investigadores de Harvard, MIT, Stanford, Carnegie Mellon y otras instituciones documentó agentes que eludieron límites a nivel de modelo en un entorno real —no un sandbox— e identificó cinco fallos OWASP Top 10 para aplicaciones LLM en el proceso. No es un riesgo teórico. Es el comportamiento documentado de agentes de IA implementados.
- Los reguladores exigen evidencia de lo que fue impedido técnicamente, no de lo que fue instruido. La norma de seguridad de HIPAA §164.312(a)(1) exige políticas y procedimientos técnicos que permitan el acceso solo a personas o programas autorizados. CMMC AC.1.001 exige controles de acceso autorizados. La regla 204-2 de la SEC exige registros atribuibles. Ninguna de estas normas se satisface con una instrucción documentada. Todas requieren un mecanismo que aplique la restricción independientemente de si el modelo de IA la sigue.
- Las actualizaciones del modelo pueden cambiar silenciosamente cómo se interpretan los prompts de sistema. Cuando un proveedor de IA actualiza el modelo subyacente, el comportamiento que produce el mismo prompt de sistema puede cambiar. Un prompt que limitaba el acceso de forma fiable en una versión del modelo puede producir un comportamiento distinto en la siguiente. Los controles de cumplimiento no pueden depender de la versión. Un control de gobernanza que cambia sin conocimiento ni consentimiento de la organización cada vez que el proveedor actualiza el modelo no cumple la definición de control.
- Los prompts de sistema no generan trazabilidad de auditoría sobre sus propios fallos. Cuando un prompt de sistema es eludido, sobreescrito o malinterpretado, normalmente no hay ningún registro que indique que se violó la restricción prevista. El agente actuó fuera de su alcance previsto, accedió a datos que no debía y no dejó registro que distinga ese acceso del autorizado. Una trazabilidad de auditoría a prueba de manipulaciones no se puede reconstruir a partir de un prompt de sistema que falló silenciosamente.
Tres formas en que los prompts de sistema fallan como controles de cumplimiento
Los modos de fallo de la gobernanza a nivel de modelo no son hipotéticos. Son propiedades estructurales de cómo los agentes basados en modelos de lenguaje procesan instrucciones, y han sido documentados tanto en investigaciones académicas como en incidentes en producción.
Prompt injection: la vulnerabilidad estructural
El prompt injection permite a una persona atacante insertar instrucciones maliciosas en el contenido que el agente de IA lee —un documento, correo electrónico, página web o registro de base de datos. El agente trata las instrucciones insertadas como parte de su contexto y puede ejecutarlas, sobreescribiendo el prompt de sistema original. En el estudio Agents of Chaos de febrero de 2026, investigadores de Harvard, MIT, Stanford, Carnegie Mellon y otras instituciones documentaron agentes que rechazaron una solicitud directa de datos sensibles pero accedieron cuando se les pidió reenviar un contenedor con esos datos, demostrando la elusión de límites mediante instrucciones indirectas en un entorno real. Los agentes también aceptaron identidades suplantadas en distintos canales tras detectarlas en uno, y un agente compartió voluntariamente una directiva de comportamiento plantada externamente con un segundo agente, ampliando el control del atacante sin más intervención.
Para el cumplimiento, la implicación es directa: el prompt injection no es un fallo de configuración que se pueda parchear. Es una característica estructural de cómo los agentes basados en LLM procesan instrucciones. Un prompt de sistema que limita el comportamiento en condiciones normales no garantiza el mismo comportamiento cuando el agente encuentra contenido manipulado —precisamente el escenario que buscan crear los adversarios.
Actualizaciones del modelo: deriva de comportamiento silenciosa
Los proveedores de IA actualizan los modelos subyacentes de forma rutinaria —para mejorar capacidades, reforzar la seguridad y cambiar la infraestructura. Cuando el modelo se actualiza, la respuesta al mismo prompt de sistema puede variar. Un prompt que limitaba de forma fiable a un agente en una versión puede producir un comportamiento distinto en la siguiente, sin que la organización sea notificada ni cambie el texto del prompt.
Esto genera un fallo de cumplimiento especialmente difícil de detectar: el control de gobernanza se desvió porque el modelo cambió, pero todo parece igual desde fuera. El incidente de Microsoft Copilot en febrero de 2026 ilustra el riesgo: un error de código provocó que los controles a nivel de aplicación de Microsoft —etiquetas de sensibilidad y políticas DLP— fallaran simultáneamente, permitiendo que Copilot procesara contenido confidencial, incluyendo información de salud protegida y comunicaciones legales, durante semanas antes de ser detectado. Cuando los controles de aplicación y modelo están dentro de la misma plataforma, un solo fallo a nivel de plataforma puede comprometer todos los controles a la vez. No había una defensa independiente en la capa de datos para evitarlo.
Manipulación indirecta: límites que ningún prompt de sistema puede imponer
Aun sin ataque activo, los prompts de sistema no pueden imponer los límites precisos que exige el cumplimiento. Un prompt puede expresar la intención —»accede solo a los datos relevantes para este encuentro»— pero no puede imponer técnicamente esa intención en la capa de acceso a datos. Si las credenciales de la cuenta de servicio permiten acceso a un conjunto de datos más amplio, el agente tiene acceso técnico a esos datos sin importar lo que diga el prompt de sistema. Un control de cumplimiento se evalúa por lo que impide técnicamente, no por lo que pretende. Un agente con acceso técnico a 10,000 registros de pacientes pero instruido para leer solo tres no cumple con el estándar mínimo necesario de HIPAA, porque nada impidió el acceso a los otros 9,997.
¿Qué estándares de cumplimiento de datos importan?
Lee ahora
Lo que realmente exigen los reguladores
Las normas de cumplimiento que rigen el acceso a datos regulados exigen evidencia de que el acceso fue controlado técnicamente, no evidencia de que se pretendía controlar. Esta distinción es la diferencia entre una postura de cumplimiento que supera una auditoría y una que genera hallazgos.
Qué significa «control de acceso» para un regulador
La norma de seguridad de HIPAA exige políticas y procedimientos técnicos para «permitir el acceso solo a aquellas personas o programas de software a quienes se hayan concedido derechos de acceso». La palabra clave es «permitir»: el sistema debe permitir técnicamente solo el acceso autorizado, no simplemente instruir a quien accede a limitarse. Cuando una persona evaluadora de CMMC pide ver los controles de acceso autorizados para un flujo de trabajo de agente de IA, la evidencia esperada es un registro de aplicación de políticas: qué acceso se solicitó, qué evaluación de política se aplicó, qué se permitió o denegó y cuándo. Un documento de configuración de prompt de sistema no genera esta evidencia. Un motor de políticas de datos que evalúa cada solicitud de agente contra una política ABAC sí lo hace.
Qué significa «trazabilidad de auditoría» para un regulador
HIPAA §164.312(b), CMMC AU.2.042 y la regla 17a-4 de la SEC exigen registros de lo que realmente ocurrió, no de lo que se pretendía. Un prompt de sistema configurado y documentado genera un registro de intención. Un registro de auditoría a prueba de manipulaciones y a nivel de operación que capture cada evento de acceso a datos por parte de un agente —identidad del agente, datos accedidos, tipo de operación, evaluación de política, marca de tiempo— genera un registro de lo que realmente sucedió. Solo esto cumple con lo que imponen estas regulaciones. Y cuando la persona auditora pregunta qué datos accedió un agente de IA el martes pasado, la respuesta debe venir de un registro de auditoría, no de una inferencia sobre lo que el prompt de sistema debió haber impedido.
Por qué «nuestro proveedor de IA cumple» no es una respuesta
Las certificaciones de cumplimiento de proveedores de IA —SOC 2, ISO 27001, FedRAMP— abordan la postura de seguridad del propio proveedor. No abordan si los controles de acceso, trazabilidad de auditoría, aplicación del acceso mínimo necesario y cadenas de delegación de la entidad regulada cumplen con sus propias obligaciones regulatorias. El cumplimiento de HIPAA, la certificación CMMC y la preparación para exámenes de la SEC son obligaciones organizacionales que no se pueden externalizar con la declaración de un proveedor. Cuando la persona auditora pide el registro de acceso de un agente de IA a un registro de paciente específico el martes pasado, el informe SOC 2 del proveedor no responde a la pregunta.
Qué significa realmente la gobernanza en la capa de datos
La gobernanza en la capa de datos significa que los controles de gobernanza de datos se aplican en el punto donde se accede a los datos, independientemente del modelo, el prompt y el framework del agente. Es el único enfoque arquitectónico que produce evidencia de lo que fue controlado técnicamente y no solo de lo que fue instruido.
Lo que hacen los controles en la capa de datos y que los prompts de sistema no pueden
Un control de gobernanza en la capa de datos intercepta cada solicitud de acceso antes de que llegue a los datos regulados. Verifica la identidad del agente, la vincula con la persona que autorizó el flujo de trabajo y evalúa la solicitud contra una política ABAC: ¿este agente está autorizado para acceder a estos datos específicos, realizar esta operación específica, en este contexto específico? Si la política lo permite, el acceso se concede y se registra. Si no, se deniega y se registra la denegación, sin importar lo que se le haya dicho al modelo o si se eludió el prompt de sistema.
Cuando un ataque de prompt injection sobreescribe un prompt de sistema e instruye a un agente para acceder a datos fuera de alcance, un control de gobernanza en la capa de datos deniega ese acceso, porque la política de acceso no se cumplió, independientemente de la instrucción al modelo. El modelo está comprometido; la gobernanza de datos no. Esa es la diferencia entre teatro de cumplimiento y cumplimiento real.
La evidencia que genera la gobernanza en la capa de datos
La gobernanza en la capa de datos produce exactamente la evidencia que exigen los reguladores: un registro de auditoría a prueba de manipulaciones y a nivel de operación de cada evento de acceso a datos por parte de un agente, con identidad autenticada del agente, persona autorizadora, datos específicos accedidos, tipo de operación, evaluación de política de acceso y marca de tiempo. Este registro lo crea la capa de gobernanza independientemente del comportamiento del modelo; no depende de que el modelo siga instrucciones. Cuando la persona auditora pregunta qué datos accedió un agente de IA el martes pasado, la respuesta es un informe de la capa de gobernanza, generado en horas, no reconstruido a partir de registros de inferencia durante días.
Cómo Kiteworks ofrece gobernanza en la capa de datos para agentes de IA
La Red de Datos Privados de Kiteworks se sitúa entre los agentes de IA y los datos regulados a los que necesitan acceder. Cada solicitud de datos de un agente pasa por cuatro puntos de control de gobernanza antes de que se mueva cualquier dato: identidad autenticada, evaluación de política ABAC, cifrado validado FIPS 140-3 y registro de auditoría a prueba de manipulaciones, todo independiente del modelo, el prompt y el framework del agente. Cuando el modelo es comprometido, actualizado o manipulado, Kiteworks sigue aplicando la política.
Verificación de identidad independiente del modelo
Cada agente de IA que accede a datos a través de Kiteworks se autentica antes de que ocurra el acceso, usando una credencial única por flujo de trabajo vinculada a la persona que autorizó la tarea. Esta autenticación la aplica la capa de gobernanza de datos, no el modelo. Un ataque de prompt injection no puede sobreescribirla, porque la verificación ocurre en la capa de datos, antes de que la solicitud del agente llegue a los datos, no dentro de la ventana de contexto del modelo donde una persona atacante puede manipularla.
Aplicación de políticas que resiste actualizaciones de modelo
El motor de políticas de datos de Kiteworks evalúa cada solicitud de datos de un agente contra una política ABAC multidimensional: el perfil autenticado del agente, la clasificación de los datos solicitados, el contexto del flujo de trabajo y la operación específica. Esta evaluación la realiza la capa de gobernanza, no el modelo. Cuando el modelo subyacente se actualiza y su interpretación de los prompts de sistema cambia, la aplicación de la política de datos no lo hace, porque no depende del comportamiento del modelo. La política de gobernanza de datos la define la organización y se aplica de forma consistente sin importar la versión del modelo.
Un registro de auditoría útil para los reguladores
Cada interacción de datos de un agente a través de Kiteworks se captura en un registro de auditoría a prueba de manipulaciones y a nivel de operación: identidad del agente, persona autorizadora, datos accedidos, tipo de operación, resultado de la evaluación de política y marca de tiempo. Este registro se integra en el SIEM de la organización y se conserva en un formato que respalda solicitudes de evidencia regulatoria. Cuando una persona auditora de HIPAA, una persona evaluadora de CMMC o una persona examinadora de la SEC solicita evidencia de controles de acceso sobre un flujo de trabajo de agente de IA, la respuesta es un paquete de evidencia exportable, no un documento de configuración de prompt de sistema ni un registro de inferencias que nunca fue diseñado para cumplir un estándar de auditoría regulatoria.
Para las organizaciones que quieren implementar agentes de IA a gran escala sin acumular exposición de cumplimiento, Kiteworks ofrece la arquitectura que convierte la gobernanza de IA en algo real y no asumido. Descubre más sobre Kiteworks Compliant AI o solicita una demo.
Preguntas frecuentes
Los prompts de sistema son instrucciones para un modelo de IA, no controles técnicos sobre el acceso a los datos. Regulaciones como HIPAA §164.312(a)(1), CMMC AC.1.001 y la regla 204-2 de la SEC exigen mecanismos que limiten técnicamente el acceso a datos regulados, no preferencias de comportamiento documentadas. Los prompts de sistema pueden ser eludidos mediante prompt injection, sobreescritos por actualizaciones del modelo o malinterpretados por el modelo en flujos de trabajo de varios pasos. No generan trazabilidad de auditoría sobre sus propios fallos. Solo la gobernanza aplicada en la capa de datos, independiente del modelo, constituye un control de acceso defendible en auditoría bajo estos estándares regulatorios.
El prompt injection es una técnica en la que se insertan instrucciones maliciosas en el contenido que un agente de IA lee —un documento, correo electrónico o registro de base de datos— haciendo que el agente ejecute esas instrucciones en lugar de, o además de, su prompt de sistema original. Un estudio de red-team en febrero de 2026 realizado por investigadores de Harvard, MIT, Stanford y Carnegie Mellon documentó agentes que eludieron límites mediante instrucciones indirectas en un entorno real, no en un sandbox. Para el cumplimiento, la implicación es clara: un control de gobernanza que puede ser eludido por el contenido que lee el agente no es un control confiable para proteger datos regulados. La gobernanza en la capa de datos aplica la política de acceso independientemente del comportamiento del modelo, haciéndola resistente a elusiones de una forma que los controles a nivel de modelo no pueden igualar.
No. La certificación SOC 2 de un proveedor aborda el propio programa de seguridad del proveedor: cómo protege su infraestructura, gestiona el acceso a sus sistemas y responde a incidentes. No genera evidencia de que los datos regulados de tu organización hayan sido accedidos solo por agentes autorizados, bajo políticas de acceso documentadas y con registros de auditoría a nivel de operación vinculados a personas autorizadoras. HIPAA, CMMC y los requisitos de la SEC son obligaciones de cumplimiento organizacional. Exigen evidencia de los controles de acceso a los datos de tu organización, tus registros de auditoría y tu aplicación de políticas, no declaraciones sobre la postura de seguridad del proveedor. Las certificaciones de proveedores y el cumplimiento organizacional son cosas distintas.
Pregunta: ¿Puedes mostrar un registro de auditoría a nivel de operación que indique qué registros de datos específicos accedió este agente, bajo qué autorización, vinculado a qué persona autorizadora y con una marca de tiempo a prueba de manipulaciones? ¿Puedes demostrar que el acceso se aplica en la capa de datos, independiente del modelo, de modo que un ataque de prompt injection o una actualización del modelo no puedan sobreescribir la política de acceso? ¿Puedes mostrar que el acceso mínimo necesario se aplica por operación, no por sesión? Si las respuestas del proveedor involucran configuraciones de prompts de sistema, filtros de seguridad del modelo o registros de sesión, la afirmación no se sostiene en una auditoría que exige evidencia de control de acceso en la capa de datos.
La arquitectura mínima defendible en auditoría para el acceso de agentes de IA a datos regulados requiere cuatro componentes, todos aplicados en la capa de datos e independientes del modelo: identidad autenticada del agente vinculada a una persona autorizadora para cada evento de acceso; control de acceso basado en atributos evaluado por operación según la clasificación de datos y el contexto del flujo de trabajo; cifrado validado FIPS 140-3 para todos los datos en tránsito y en reposo en cada ruta de datos de agente; y un registro de auditoría a prueba de manipulaciones y a nivel de operación que capture identidad del agente, persona autorizadora, datos específicos accedidos, tipo de operación y marca de tiempo. Los cuatro deben ser aplicados por una capa de gobernanza que opere de forma independiente al modelo de IA, de modo que el compromiso, actualización o manipulación del modelo no desactive los controles.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - 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.