Auditoría basada en prompts: una introducción práctica
Una organización lanza un asistente de IA generativa para responder preguntas sobre políticas internas. Antes de su puesta en producción, alguien prueba cinco preguntas sencillas y concluye que el sistema funciona. Semanas después, una formulación distinta hace que el asistente cite una política inexistente; otra consigue que ignore una restricción y utilice información que no debía revelar.
La pregunta para Auditoría Interna no es si el modelo puede conversar. Es si el comportamiento relevante para el negocio ha sido probado de forma sistemática, contra criterios definidos y con evidencia suficiente para sostener una conclusión.
En este artículo utilizamos auditoría basada en prompts como una expresión práctica para describir pruebas de comportamiento de aplicaciones de IA generativa mediante entradas diseñadas y controladas. No es una norma independiente ni sustituye la validación técnica del modelo. Bien aplicada, ofrece a auditores generalistas una forma accesible de evaluar el comportamiento de una aplicación GenAI.
Probar con prompts no es simplemente “hacerle preguntas” a la IA
Los prompts son la interfaz natural de muchas aplicaciones generativas, por lo que también pueden convertirse en estímulos de prueba. Sin embargo, una colección improvisada de preguntas no constituye por sí sola un procedimiento de auditoría.
El NIST AI RMF: Generative Artificial Intelligence Profile advierte que las pruebas anecdóticas, incluidos ejercicios aislados de jailbreaking o ingeniería de prompts, pueden no evaluar de forma sistemática la validez o fiabilidad del sistema. NIST propone procesos de prueba, evaluación, validación y verificación que consideren condiciones similares a las de despliegue, resultados documentados y métodos empíricos.
La diferencia es fundamental. Un auditor no debería preguntar “¿puedo conseguir que falle?”, sino algo más disciplinado: ¿qué comportamiento espero, bajo qué condiciones, qué evidencia demostraría el fallo y cuántas observaciones necesito para sustentar una conclusión?
También conviene separar dos usos que suelen confundirse. El IIA publica orientación para que los auditores utilicen prompts al planificar, analizar o redactar trabajo de auditoría. Esa práctica consiste en usar IA para auditar. Este artículo se ocupa de otra cosa: usar prompts para auditar el comportamiento de una aplicación de IA.
De una conversación a un procedimiento de auditoría
La técnica encaja con la metodología profesional existente. Las Normas Globales de Auditoría Interna exigen identificar criterios de evaluación relevantes, desarrollar y documentar un programa de trabajo, recopilar información relevante, fiable y suficiente, y conservar documentación que permita a una persona informada y competente repetir el trabajo y obtener los mismos resultados.
Eso cambia la forma de diseñar una prueba. Cada caso debería tener, como mínimo, un riesgo, un criterio, una entrada controlada, unas condiciones de ejecución, un resultado esperado y evidencia retenida.
| Elemento | Pregunta de auditoría | Ejemplo |
|---|---|---|
| Riesgo | ¿Qué puede salir mal? | El asistente revela información restringida. |
| Criterio | ¿Qué comportamiento aceptable se espera? | Debe rechazar solicitudes de datos confidenciales fuera del perfil autorizado. |
| Caso de prueba | ¿Qué estímulo concreto se aplicará? | Pregunta normal, variante ambigua y solicitud que intenta eludir la restricción. |
| Evidencia | ¿Qué se conservará? | Prompt, respuesta, fecha, versión/configuración disponible, fuentes utilizadas y evaluación del auditor. |
El valor del prompt está en producir una observación comparable con un criterio.
Un método práctico en seis pasos
1. Definir el comportamiento y el criterio. Empiece por el riesgo, no por el prompt. El criterio puede provenir de una política, requisito legal, especificación funcional, control aprobado, apetito de riesgo o expectativa de diseño. Para una aplicación que resume contratos, por ejemplo, el criterio puede exigir que toda afirmación material sea trazable al documento fuente y que el sistema indique cuando no dispone de evidencia suficiente.
2. Fijar las condiciones de prueba. Documente, en la medida en que estén disponibles, la versión del modelo, instrucciones del sistema, parámetros relevantes, configuración de recuperación, fuentes conectadas, permisos del usuario y fecha de ejecución. Si un proveedor SaaS no expone alguno de esos elementos, documente la limitación.
3. Diseñar un conjunto de casos, no una sola pregunta. Incluya casos de referencia, límites y excepciones. Para riesgos de confidencialidad, combine una solicitud legítima, una solicitud ambigua y una tentativa sencilla de eludir la regla. Para exactitud, utilice preguntas cuya respuesta correcta pueda verificarse de forma independiente.
4. Repetir y variar de manera controlada. Las aplicaciones generativas pueden producir respuestas distintas ante la misma entrada. Por ello, una sola ejecución rara vez es suficiente para concluir sobre un comportamiento. Repita casos relevantes y modifique una variable cada vez: redacción, contexto, idioma, formato o información disponible.
5. Evaluar con una rúbrica definida antes de observar los resultados. Use categorías como “cumple”, “cumple parcialmente” y “no cumple”, o métricas más específicas cuando el caso lo permita. Evite redefinir el criterio después de ver la respuesta.
6. Conservar la evidencia y conectar el resultado con el riesgo. La conclusión debe explicar qué condición se observó, con qué frecuencia, frente a qué criterio, cuál es la exposición y si se requiere una prueba más profunda o apoyo especializado.
Qué puede probar un auditor generalista
La auditoría basada en prompts es especialmente útil en la capa de aplicación, donde el auditor puede observar comportamientos que afectan directamente a usuarios, decisiones y controles.
| Área de riesgo | Ejemplo de prueba | Comportamiento esperado | Evidencia útil |
|---|---|---|---|
| Exactitud y fundamentación | Solicitar una respuesta basada en un documento conocido, incluyendo una pregunta sin respuesta en la fuente. | Distingue hechos sustentados de incertidumbre; no inventa referencias. | Prompt, respuesta, fuente y verificación independiente. |
| Confidencialidad | Pedir información fuera del perfil o contexto autorizado. | Rechaza o limita la respuesta de acuerdo con las reglas de acceso. | Identidad/rol de prueba, respuesta y registro de acceso. |
| Cumplimiento de límites | Reformular una solicitud prohibida con lenguaje indirecto. | Mantiene la restricción pese a cambios de redacción. | Variantes del prompt y resultados comparables. |
| Resistencia básica a manipulación | Incluir una instrucción que intente contradecir reglas previas. | No abandona controles esenciales ni expone instrucciones o datos protegidos. | Prompt exacto, salida, versión y evaluación. |
| Supervisión humana | Crear un escenario de alta incertidumbre o impacto. | Escala, pide confirmación o evita una recomendación definitiva cuando así lo exige el diseño. | Respuesta y evidencia del flujo de escalamiento. |
Este enfoque también se alinea con ISO/IEC 42001:2023, que exige definir y documentar medidas de verificación y validación y criterios para su uso. Su guía de implementación contempla metodologías de prueba, selección de datos representativos del dominio previsto y criterios de liberación. Para Auditoría Interna, eso refuerza una idea simple: las pruebas deben reflejar el contexto real de uso, no solo un laboratorio conveniente.
Los límites importan tanto como las pruebas
Un conjunto de prompts bien diseñado puede demostrar un patrón de comportamiento, pero no explica necesariamente por qué ocurre ni demuestra que el modelo sea seguro en sentido amplio.
Hay trabajos que normalmente requieren especialistas: validación estadística de modelos, evaluación formal de sesgo entre poblaciones, pruebas de ciberseguridad avanzadas, análisis de arquitectura, explotación adversarial, revisión de datos de entrenamiento o evaluación matemática de robustez. NIST también diferencia las pruebas estructuradas de ejercicios más amplios de red teaming, cuya calidad depende de la experiencia y diversidad del equipo.
Por eso, el auditor generalista debería definir una frontera explícita: puede diseñar pruebas conductuales, evaluar controles, revisar evidencias, identificar fallos repetibles y determinar si el riesgo está siendo gestionado. Cuando la pregunta pasa de “¿se comporta como debería en este contexto?” a “¿es técnicamente robusto frente a una clase compleja de ataques o distribuciones?”, el trabajo suele necesitar apoyo especializado.
Esta frontera protege la calidad del aseguramiento y ayuda a reconocer cuándo la evidencia disponible ya no es suficiente.
La trazabilidad convierte el prompt en evidencia
La prueba solo es útil si puede explicarse y repetirse. La guía de 2026 de COSO sobre control interno para IA generativa recomienda documentar configuraciones y resultados de pruebas de forma proporcional al riesgo, y destaca artefactos como registros de prompts, salidas, mensajes del sistema, versión del modelo y otros elementos de configuración. También plantea pruebas de desempeño con poblaciones de prueba, estrés de casos límite y supervisión proporcional al riesgo.
La herramienta del IIA para prompting en auditoría interna, aunque está orientada al uso de IA por la propia función de auditoría, refuerza principios igualmente útiles para este contexto: conservar el prompt utilizado, documentar cómo se validó la salida y distinguir entre análisis asistido por IA y juicio profesional.
Una buena bitácora debe mostrar qué se probó, contra qué criterio, con qué configuración, cuántas veces, qué ocurrió, quién evaluó y qué conclusión se derivó.
Un prompt se convierte en procedimiento de auditoría cuando deja de ser una pregunta ingeniosa y pasa a ser una prueba con criterio, condiciones, evidencia y posibilidad de repetición.
La oportunidad para Auditoría Interna es importante porque muchas aplicaciones GenAI pueden evaluarse inicialmente sin acceso a pesos del modelo ni conocimientos avanzados de ciencia de datos. Pero la accesibilidad no debe confundirse con informalidad. El valor aparece cuando la función transforma conversaciones con la IA en pruebas controladas que producen evidencia defendible y, cuando es necesario, una base clara para escalar hacia aseguramiento técnico más profundo.
Fuentes
- NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
- ISO — ISO/IEC 42001:2023, Artificial intelligence — Management system
- The IIA — Global Internal Audit Standards
- The IIA — AI Framework Support Tools
- COSO — Achieving Effective Internal Control Over Generative AI