Inyección de prompts y los límites de los filtros de seguridad de IA en entornos regulados
Cuando un ataque de inyección de prompts hace que un agente de IA acceda a datos para los que no tenía autorización, la pregunta de cumplimiento no es si el modelo generó una salida dañina. Es si se produjo un acceso no autorizado a datos regulados. Son cuestiones diferentes —y los filtros de seguridad de IA solo responden a la primera.
Para los equipos de cumplimiento que gestionan implementaciones de agentes de IA en sanidad, servicios financieros o contratistas de defensa, la distinción importa. HIPAA, CMMC, SEC y NYDFS regulan qué datos se accedieron y si ese acceso estaba autorizado. Los filtros de seguridad regulan lo que dice el modelo. Un filtro que aprueba una salida como aceptable no dice nada sobre si el acceso subyacente a los datos cumplía con las normas.
En este artículo se explica la exposición de cumplimiento que crea la inyección de prompts en entornos de datos regulados, por qué las defensas a nivel de modelo no pueden cerrarla y qué arquitectura realmente la contiene.
Resumen ejecutivo
Idea principal: Los ataques de inyección de prompts tienen éxito cuando hacen que un agente realice acciones que no fueron autorizadas por la persona que delegó el flujo de trabajo. En entornos regulados, el acceso no autorizado a datos causado por una inyección es un fallo de cumplimiento bajo los mismos marcos que regulan el acceso no autorizado por parte de humanos. Solo los controles de acceso aplicados en la capa de datos —independientes del modelo— pueden evitar que una instrucción inyectada genere un incidente de cumplimiento.
Por qué te debe importar: Un estudio de red team de febrero de 2026 realizado por Harvard, MIT, Stanford y Carnegie Mellon documentó agentes de IA exfiltrando datos y ejecutando operaciones no autorizadas en entornos empresariales reales. Las medidas de seguridad a nivel de modelo no ofrecieron protección fiable. Para las organizaciones que implementan agentes sobre datos regulados, esto es un riesgo operativo activo —no un escenario de laboratorio.
Puntos clave
1. La inyección de prompts es un vector de fallo de cumplimiento, no solo de seguridad. Lo importante es si se produjo acceso no autorizado a datos regulados —no si la salida del modelo fue marcada como dañina.
2. Los filtros de seguridad evalúan la salida; el cumplimiento exige gobernanza del acceso a los datos. Un filtro que bloquea una salida dañina del modelo no soluciona el acceso no autorizado que pudo haber ocurrido antes de esa salida.
3. La inyección indirecta a través de documentos es el vector de mayor riesgo. Los agentes que procesan documentos, correos electrónicos y registros de bases de datos como parte de flujos de trabajo autorizados están procesando posibles superficies de inyección en cada operación. El modelo no puede distinguir entre contenido legítimo e instrucciones inyectadas.
4. Las actualizaciones de modelos pueden cambiar silenciosamente cómo los agentes responden a la inyección. Un agente que rechazaba intentos de inyección de manera fiable en una versión del modelo puede no hacerlo tras una actualización. La gobernanza que depende de un comportamiento consistente del modelo no es una gobernanza duradera.
5. La gobernanza en la capa de datos contiene la exposición de cumplimiento sin importar el comportamiento del modelo. Si una instrucción inyectada hace que el modelo intente acceder a datos sin autorización y la capa de datos lo bloquea, la exposición de cumplimiento nunca se materializa. La inyección tuvo éxito en la capa del modelo. Falló en la capa de gobernanza —que es la única que importa para el cumplimiento.
Por qué los filtros de seguridad no resuelven el problema de cumplimiento
Los filtros de seguridad están diseñados para evitar que un modelo genere salidas dañinas. No están diseñados para aplicar autorizaciones de acceso a datos, y no pueden hacerlo. HIPAA exige que el acceso a la información de salud protegida esté limitado a personas o programas de software autorizados. CMMC exige que el acceso a la información no clasificada controlada esté limitado a usuarios y procesos autorizados. Estas son exigencias de acceso a datos —lo que el agente puede alcanzar, no lo que puede decir. Un filtro de seguridad que opera sobre la salida del modelo está evaluando la capa equivocada.
Además, los filtros de seguridad pueden ser eludidos. El jailbreaking mediante escenarios de roles, descomposición de instrucciones en varios pasos y variaciones de codificación ha sido documentado repetidamente. Y las actualizaciones de modelos cambian el comportamiento del filtro sin previo aviso —el incidente de drift de configuración de Microsoft Copilot en febrero de 2026 mostró que una actualización rutinaria del modelo cambió silenciosamente los resultados de control de acceso en producción. La gobernanza que depende de controles en la capa de modelo que se comportan de manera consistente es una gobernanza que puede fallar sin advertencia.
¿Qué estándares de cumplimiento de datos importan?
Lee ahora
Los cuatro vectores de inyección que importan en entornos regulados
| Vector | Cómo funciona | Datos regulados en riesgo |
|---|---|---|
| Inyección directa | El usuario o atacante sobrescribe el prompt del sistema a través de la interfaz del agente | Todo lo que la cuenta de servicio del agente pueda alcanzar |
| Inyección indirecta vía documento | Instrucciones maliciosas incrustadas en un contrato, formulario de ingreso o entrega de proveedor que el agente procesa | Repositorios de información no clasificada controlada, sistemas de información de salud protegida, almacenes de datos de clientes |
| Envenenamiento de pipeline RAG | Contenido inyectado insertado en la base de datos vectorial que alimenta el contexto de recuperación del agente | Todos los datos en el corpus RAG que el agente pueda recuperar |
| Contaminación cruzada entre agentes | La inyección tiene éxito contra un agente upstream; las instrucciones se propagan por el pipeline hacia agentes downstream | Todos los datos regulados accesibles para los agentes downstream |
La inyección indirecta a través de documentos merece especial atención para los contratistas de defensa. Los paquetes de datos técnicos y entregables de subcontratistas llegan de partes cuya postura de seguridad es desconocida. Un documento inyectado colocado en un repositorio de información no clasificada controlada tiene una vía para hacer que un agente autorizado exfiltre datos controlados —con registros de auditoría que parecen idénticos a la actividad legítima del flujo de trabajo.
Dónde están más expuestas las empresas reguladas ahora mismo
La mayoría de las empresas ya han abordado la inyección directa —el filtrado de entradas y el refuerzo del prompt del sistema se han vuelto prácticas estándar. Las brechas que quedan son estructurales, no de configuración.
Las organizaciones sanitarias que usan agentes de documentación clínica procesan formularios de ingreso de pacientes, solicitudes de autorización previa y correspondencia de seguros de docenas de partes externas. Cada documento es una posible superficie de inyección. El agente no tiene mecanismo para distinguir un formulario manipulado de uno legítimo. Si los controles de acceso del agente solo se aplican mediante su prompt de sistema, una inyección indirecta exitosa tiene vía libre hacia información de salud protegida que el agente nunca estuvo autorizado a alcanzar.
Los contratistas de defensa enfrentan la misma exposición en flujos de trabajo de información no clasificada controlada. Los paquetes de datos técnicos de proveedores de nivel inferior ingresan regularmente a los repositorios antes de ser revisados. Un agente que procesa esos documentos tiene acceso autorizado al repositorio —lo que significa que una instrucción inyectada en un documento de proveedor hereda ese alcance de acceso autorizado. El evento de exfiltración, si ocurre, genera registros de auditoría que son indistinguibles de la actividad normal del flujo de trabajo. Sin registros a nivel de operación que muestren qué se accedió y por qué, el incidente puede pasar desapercibido indefinidamente.
Para las empresas de servicios financieros, la bandeja de entrada de correo electrónico es la superficie más subestimada. Los agentes desplegados para monitorear, clasificar o resumir correspondencia de clientes procesan contenido externo sin validación previa. Un actor de amenazas que pueda enviar un mensaje a una bandeja monitoreada puede entregar instrucciones de inyección al agente —con una posible vía hacia datos de clientes regulados por la Regla 204-2 de la SEC y el Reglamento S-P.
El hilo común: en cada caso, el flujo de trabajo autorizado del agente proporciona el acceso. La inyección lo redirige. Y el riesgo escala con la velocidad operativa del agente —cuantos más datos procesa, mayor es el radio de impacto potencial de una inyección exitosa.
Cómo es realmente la contención
La propiedad arquitectónica que hace que la exposición de cumplimiento por inyección de prompts sea contenible es sencilla: aplica la autorización de acceso a los datos en la capa de datos, independientemente de lo que el modelo haya recibido como instrucción. Si el acceso a los datos por parte del agente está gobernado por una política ABAC aplicada antes de que la solicitud llegue a los datos regulados, una instrucción inyectada que hace que el modelo intente un acceso no autorizado se bloquea en la capa de gobernanza. La inyección tuvo éxito en la capa del modelo. El evento de cumplimiento no ocurrió.
Esto es independiente del modelo por diseño. Una actualización del modelo que cambie cómo responde ante intentos de inyección no puede cambiar la evaluación de la solicitud de acceso por parte del motor de políticas de datos. La capa de gobernanza evalúa las solicitudes de acceso a datos según la política —sin importar el comportamiento del modelo, ni lo que se haya inyectado.
Los intentos de acceso denegados por inyección también deben aparecer en el registro de auditoría. Un patrón de solicitudes bloqueadas contra categorías específicas de datos durante el procesamiento de documentos es una señal de detección —evidencia de que una campaña de inyección está probando el límite de control de acceso. Sin registros a nivel de operación que alimenten un SIEM, esa señal es invisible.
Cinco prácticas que reducen la exposición de cumplimiento por inyección de prompts
Las defensas a nivel de modelo y la gobernanza en la capa de datos abordan cuestiones distintas. Ambas importan —pero solo una cierra la brecha de cumplimiento.
1. Aplica la autorización de acceso en la capa de datos. Implementa ABAC que evalúe cada solicitud de datos del agente según la identidad autenticada, la clasificación de datos, el contexto del flujo de trabajo y el tipo de operación —antes de que la solicitud llegue a los datos regulados. Esto es lo que bloquea que una inyección exitosa se convierta en un evento de cumplimiento.
2. Registra las solicitudes denegadas, no solo las exitosas. Un registro de auditoría a nivel de operación que capture intentos de acceso bloqueados —identidad del agente, datos solicitados, motivo de denegación, marca de tiempo— y lo envíe a un SIEM convierte la exploración por inyección en una señal de detección. Sin esto, la campaña es invisible hasta que tiene éxito.
3. Trata las defensas a nivel de modelo como reductores de riesgo, no como controles de cumplimiento. La sanitización de entradas, el refuerzo de prompts y el filtrado de salidas reducen la tasa de éxito de la inyección. No cumplen los requisitos regulatorios de autorización de acceso. Construye la arquitectura de cumplimiento asumiendo que la inyección ocasionalmente tendrá éxito.
4. Trata las fuentes de datos RAG como entradas no confiables. Sanitiza el contenido antes de indexarlo, restringe la contribución al corpus y aplica controles de acceso a la base de datos vectorial. La recuperación es un evento de acceso a datos —requiere la misma gobernanza que cualquier otro acceso a datos regulados.
5. Revalida la postura de gobernanza tras cada actualización del modelo. Prueba si los resultados de control de acceso permanecen dentro del alcance autorizado tanto en condiciones estándar como adversas. Documenta los cambios. Los controles aplicados en la capa de datos no requieren revalidación —las actualizaciones de modelo no les afectan. Los controles en la capa de modelo requieren pruebas cada vez que el modelo cambia.
Cómo Kiteworks contiene la exposición de cumplimiento por inyección de prompts
La Red de Datos Privados de Kiteworks se sitúa entre los agentes de IA y los datos regulados a los que acceden. Cada solicitud de datos pasa por verificación de identidad autenticada, evaluación del motor de políticas de datos, cifrado validado FIPS 140-3 y registro a prueba de manipulaciones antes de que se mueva cualquier dato —independientemente del modelo, el prompt y el framework del agente.
Cuando una instrucción inyectada hace que un agente intente acceder a datos fuera de su alcance, la solicitud se deniega en la capa de políticas y se registra con atribución completa. El evento de cumplimiento no ocurre. El intento de inyección es visible en el registro de auditoría. Cuando el proveedor de IA actualiza el modelo, la postura de gobernanza no cambia —porque los controles residen en la capa de datos, no dentro del modelo.
Las capacidades de Gestión de Archivos Gobernada y Operaciones de Carpetas Gobernadas de Kiteworks Compliant AI limitan aún más la superficie de acción: una instrucción inyectada para reenviar archivos externamente no puede ejecutarse si la transmisión externa no está dentro del alcance de políticas autorizadas para el agente. Los controles RBAC y ABAC limitan lo que una inyección exitosa puede lograr realmente.
Para las organizaciones que necesitan contener la exposición de cumplimiento sin importar el comportamiento del modelo, Kiteworks proporciona la arquitectura que lo hace posible. Descubre más sobre Kiteworks Compliant AI o agenda una demo.
Preguntas frecuentes
La moderación de contenidos evalúa la salida del modelo. La HIPAA §164.312(a)(1) regula la autorización de acceso a los datos —lo que el agente puede alcanzar. Una inyección que haga que el agente acceda a información de salud protegida para la que no tenía autorización es un fallo de cumplimiento sin importar cuál fue la salida del modelo. Los dos controles actúan en capas diferentes.
La inyección directa requiere que el atacante tenga acceso a la interfaz del agente. La inyección indirecta solo requiere la capacidad de colocar contenido en un repositorio que el agente procesa —una barrera mucho menor cuando los flujos de trabajo CMMC incorporan regularmente entregas de terceros. Los eventos de acceso resultantes parecen idénticos a la actividad legítima en un registro de auditoría estándar.
Los guardarraíles a nivel de modelo cambian su comportamiento cuando el modelo cambia. La gobernanza en la capa de datos evalúa las solicitudes de acceso según la política, independientemente del comportamiento del modelo. Una inyección exitosa que cambia lo que el modelo intenta no puede cambiar lo que permite el motor de políticas de datos. Esa independencia es lo que hace que la gobernanza en la capa de datos sea el control duradero.
Prueba si los resultados de control de acceso se mantienen dentro del alcance autorizado tanto en flujos de trabajo estándar como adversos. Actualiza tu evaluación de riesgos para documentar cualquier cambio de comportamiento. Los controles aplicados en la capa de datos de forma independiente al modelo no requieren revalidación —las actualizaciones de modelo no los afectan.
Trata cada fuente externa que alimente el pipeline RAG como una superficie de inyección no confiable: sanitiza el contenido antes de indexarlo, restringe la contribución al corpus y aplica clasificación de datos y controles de acceso a la propia base de datos vectorial. El paso de recuperación es un evento de acceso a datos —requiere el mismo alcance ABAC que cualquier otro acceso a datos regulados.
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 «–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.