Inyección de prompts: lo que los auditores internos deben saber

Una aplicación de IA puede recibir un prompt perfectamente legítimo y aun así terminar obedeciendo a un atacante. Basta con que el sistema consulte una página web, un correo, un documento o una fuente de RAG que contenga instrucciones maliciosas diseñadas para el modelo. El usuario nunca escribió esas instrucciones, pero el modelo puede procesarlas como si fueran parte de la tarea.

Ese es el problema central de la inyección de prompts: en muchas aplicaciones basadas en grandes modelos de lenguaje, los datos y las instrucciones terminan compartiendo el mismo canal de contexto. Para Auditoría Interna, por tanto, no es suficiente preguntar si el chatbot “responde bien”. La pregunta más importante es qué puede ocurrir si el modelo es manipulado y qué límites existen después de esa manipulación.

El riesgo aparece cuando datos e instrucciones comparten el mismo canal

El NIST Generative AI Profile describe la inyección de prompts como una forma de manipular la entrada para que un sistema de IA generativa se comporte de manera no prevista. Distingue dos patrones que son especialmente útiles para una auditoría.

Tipo	Cómo entra la instrucción	Ejemplo de negocio	Foco de auditoría
Directa	El usuario o atacante introduce el contenido malicioso directamente en el chat, formulario o API.	Un usuario intenta ignorar restricciones y solicita revelar información que no debería estar disponible.	Controles de acceso, diseño del prompt del sistema, validación de salida y límites de la aplicación.
Indirecta	La instrucción queda oculta en una fuente que la aplicación recupera o procesa posteriormente.	Un asistente revisa un email, PDF o página web que contiene instrucciones para extraer información o alterar el resultado.	Fuentes no confiables, RAG, archivos, navegación web, permisos y acciones posteriores al modelo.

La segunda modalidad cambia sustancialmente el riesgo empresarial. El atacante no necesita conversar con el modelo. Puede manipular un recurso que otro usuario legítimo hará llegar al sistema. La taxonomía más reciente de NIST sobre aprendizaje automático adversarial refuerza esta idea al tratar la inyección indirecta como un ataque basado en el control de recursos externos que el sistema consume.

Una alucinación puede ocurrir sin atacante y un jailbreak busca superar restricciones de comportamiento. La inyección de prompts, en cambio, explota cómo la aplicación interpreta instrucciones y contenido.

El impacto depende menos del prompt que de lo que el sistema puede hacer

Una inyección contra un chatbot sin acceso a datos sensibles puede producir una respuesta inconveniente. La misma técnica contra un agente conectado al correo, un repositorio documental, un CRM o un sistema transaccional puede convertirse en un problema de confidencialidad, integridad o autorización.

OWASP LLM01:2025 identifica consecuencias como divulgación de información sensible, manipulación del contenido generado, acceso no autorizado a funciones y ejecución de acciones que el usuario no pretendía. NIST añade que las inyecciones indirectas pueden afectar disponibilidad, integridad y privacidad, e incluso manipular agentes para realizar acciones controladas por un tercero.

El riesgo real se mide por el radio de impacto que la arquitectura permite: a qué datos puede acceder el modelo, qué herramientas puede invocar y qué acciones puede ejecutar sin una comprobación independiente.

Esta lógica conecta directamente con el enfoque de control interno. El documento de COSO sobre control interno y GenAI trata la manipulación basada en prompts, los cambios de configuración y otras exposiciones de GenAI como riesgos que deben integrarse en el diseño de controles sobre operaciones, reporting y cumplimiento. No convierte la inyección de prompts en una nueva categoría separada de control interno; obliga a analizar cómo un nuevo vector de ataque puede debilitar controles ya conocidos.

Un buen diseño asume que alguna inyección puede superar la primera barrera

No existe hoy una defensa única y fiable que elimine la inyección de prompts. El NIST AI 100-2e2025 recomienda combinar entrenamiento, detección, procesamiento de entradas y separación de contenido confiable y no confiable, pero también advierte que las mitigaciones actuales no ofrecen protección completa. OWASP llega a una conclusión similar.

Para control y auditoría, los filtros de entrada son una capa, no la estrategia completa. Una arquitectura más resistente combina varios mecanismos:

separación explícita entre instrucciones confiables y contenido externo;
permisos mínimos para el modelo y para las herramientas que puede utilizar;
listas de acciones permitidas y validaciones deterministas fuera del LLM para operaciones críticas;
aprobación humana independiente antes de pagos, cambios de datos, comunicaciones externas u otras acciones de alto impacto;
controles de entrada y salida como defensa adicional, no como única salvaguarda;
pruebas adversariales periódicas que incluyan inyección directa e indirecta, RAG, archivos, web y otros canales relevantes;
registro de contexto, llamadas a herramientas, aprobaciones, resultados e incidentes con suficiente trazabilidad para investigar fallos.

ISO/IEC 42001:2023 aporta aquí una capa de gestión, no una receta técnica específica contra prompt injection. Su lógica exige evaluar riesgos, implementar tratamientos, controlar cambios, monitorear la eficacia y conservar información documentada. Para una organización que utiliza el estándar, una nueva integración, una ampliación de permisos o un cambio importante en las fuentes de datos debería alimentar nuevamente esa lógica de riesgo y control.

Qué debería preguntar Auditoría Interna

El alcance de auditoría debe comenzar por el caso de uso y sus fronteras de confianza, no por una lista genérica de “controles de LLM”. Las Normas Globales de Auditoría Interna requieren que el auditor comprenda la actividad bajo revisión, sus riesgos, procesos de gobierno y control, y que utilice criterios relevantes para diseñar el trabajo. El AI Auditing Framework del IIA complementa esa obligación profesional con una lente práctica sobre gobierno, riesgos, controles de datos, algoritmos y ciberseguridad.

Para una aplicación expuesta a prompt injection, las preguntas más útiles suelen ser:

¿Qué canales pueden introducir contenido no confiable en el contexto del modelo: usuario, archivos, correo, web, RAG, APIs, imágenes u otros sistemas?
¿Está documentado qué parte del contexto representa instrucciones confiables y qué parte representa datos externos?
¿Qué permisos hereda el modelo o agente y se aplican realmente principios de mínimo privilegio y necesidad de conocer?
¿Puede el sistema modificar registros, enviar información, ejecutar código, iniciar transacciones o activar herramientas sin una validación determinista o aprobación independiente?
¿Cómo se valida el contenido recuperado de fuentes externas antes de incorporarlo al contexto o utilizarlo para tomar acciones?
¿Las pruebas de seguridad incluyen escenarios realistas de inyección directa e indirecta, no solo prompts escritos manualmente en el chat?
¿Los logs permiten reconstruir qué instrucciones, fuentes, llamadas a herramientas y aprobaciones intervinieron en una decisión o acción?
¿Los incidentes y cambios relevantes provocan una nueva evaluación de riesgos, ajustes de controles y, cuando corresponda, nuevas pruebas?

En aplicaciones de mayor criticidad, Auditoría Interna puede necesitar apoyo de ciberseguridad o red teaming. El auditor sigue siendo responsable del objetivo, la evidencia y la conclusión.

La evidencia debe demostrar el límite de confianza, no solo la existencia de una política

Una política que prohíbe “prompts maliciosos” no demuestra que una aplicación resista una inyección indirecta. La evidencia útil debe conectar diseño, operación y resultados.

Evidencia	Qué permite comprobar	Procedimiento típico
Diagramas de arquitectura y flujos de datos/contexto	Dónde se mezclan instrucciones, datos externos, RAG y herramientas.	Recorrer el flujo y contrastarlo con configuraciones reales.
Matriz de permisos y credenciales de herramientas	Si el modelo dispone de más privilegios de los necesarios.	Muestrear identidades, scopes, tokens y acciones permitidas.
Resultados de pruebas adversariales	Cobertura y efectividad frente a escenarios directos e indirectos.	Revisar casos, severidad, retesting y excepciones abiertas.
Logs de prompts, contexto y tool calls	Qué ocurrió realmente durante una ejecución o incidente.	Reproducir muestras y correlacionar acciones con aprobaciones.
Registro de incidentes y cambios	Si el control mejora cuando aparece nueva información.	Rastrear incidentes o cambios hasta evaluación, remediación y cierre.

La Norma 14.1 de las Normas Globales exige que la información utilizada por Auditoría Interna sea relevante, fiable y suficiente. Aplicado a este riesgo, significa que una presentación del proveedor o un resultado de laboratorio aislado rara vez bastan. El auditor debería buscar corroboración entre configuración, logs, pruebas, permisos y comportamiento observado.

La misma disciplina aplica al uso de GenAI dentro de Auditoría Interna. La Norma 10.3 exige gestionar los recursos tecnológicos y colaborar con TI y Seguridad de la Información al implementar nuevas tecnologías; sus consideraciones también destacan riesgos de seguridad y privacidad. Un copiloto que procesa papeles de trabajo o evidencia externa puede sufrir el mismo patrón que se está auditando.

La prueba decisiva es qué ocurre después de la instrucción maliciosa

La inyección de prompts no se resuelve pidiendo a un LLM que “ignore instrucciones no autorizadas”. La cuestión de control es más amplia: si una instrucción maliciosa llega al modelo, ¿qué daño puede producir antes de que otra capa la detenga?

Una organización madura reduce ese daño mediante fronteras de confianza explícitas, mínimo privilegio, controles deterministas, aprobaciones humanas donde importa, monitoreo y pruebas adversariales. Para Auditoría Interna, ese enfoque convierte un tema que parece puramente técnico en algo familiar: riesgo, diseño de control, evidencia de operación y respuesta cuando el control falla.