IA en la auditoría de TI: más allá de una vulnerabilidad marcada como «resuelta»

Un ticket de vulnerabilidad aparece como «resuelto». Sin embargo, los comentarios indican que la corrección apenas se había integrado al código, y el registro de despliegue muestra que llegó a producción días después. Durante ese tiempo, ¿la aplicación seguía expuesta? La respuesta depende de qué signifique «resuelto» en la política de la organización y de lo que ocurrió con la versión afectada.

Un asistente de IA aprobado para el trabajo de auditoría puede ayudar a detectar casos así. Las notas de cierre, los resultados de los análisis y los registros de cambio no siempre usan las mismas palabras para describir lo ocurrido. El asistente puede señalar una posible contradicción, pero esa alerta todavía no es un hallazgo. La auditora debe comprobar los registros originales, la política vigente y la explicación de quien maneja el proceso.

El IIA describe cómo la IA generativa puede apoyar tareas de planificación, recopilación de evidencia, comunicación de resultados y seguimiento. Aquí la tarea es más concreta: leer notas dispersas para encontrar casos que ameriten una revisión. La responsabilidad por la evidencia y la conclusión sigue siendo de la auditora.

Dónde comienza la duda

Supongamos que un análisis detecta una dependencia vulnerable en una aplicación. Renovate o Dependabot prepara una actualización, pero las pruebas fallan. Una persona del equipo hace otro cambio de código; luego se revisa, se obtiene la aprobación requerida y finalmente se despliega. En algún punto del proceso, el ticket de vulnerabilidad se cierra con la nota «corrección completada».

Renovate y Dependabot automatizan actualizaciones a partir de reglas e información sobre dependencias. La solicitud de cambio que preparan no es, por sí sola, un uso de IA. La IA podría usarse aparte para sugerir una corrección de código, pero en este caso la usa la auditora: le pide a un asistente autorizado que compare lo escrito en los tickets cerrados con los registros de análisis, aprobación y despliegue.

Si solo queremos saber si el ticket se cerró antes del despliegue, basta una consulta SQL. Lo difícil es interpretar las notas. «Corregido», «integrado», «mitigado» y «riesgo aceptado» no significan lo mismo, y la explicación puede estar escondida entre varios comentarios. La IA puede agrupar registros relacionados y señalar dónde las palabras y las fechas parecen contradecirse. Luego hay que confirmar los identificadores y las fechas en los sistemas originales.

Digamos que el asistente marca ese ticket. La auditora revisa la alerta inicial, el historial del ticket, el merge request, el registro de excepciones y el despliegue. Si la política exige que la corrección llegue a producción y se confirme con otro análisis antes de cerrar el caso, esa secuencia, una vez verificada, podría sustentar un hallazgo. Si la política permite cerrar el ticket cuando la corrección se integra y su despliegue posterior queda documentado, las fechas por sí solas no demuestran un incumplimiento. Aun así, vale preguntar si presentar el caso como «resuelto» le permite a la gerencia entender el riesgo que todavía existe en producción.

También importa el ambiente. Que la corrección esté en pruebas no significa que ya esté en producción. Un análisis sin hallazgos de otra rama o versión tampoco resuelve la duda. Hay que relacionar la alerta con la aplicación afectada, la versión corregida y el ambiente donde se desplegó. Incluso un mismo ticket puede cubrir varias aplicaciones con fechas de liberación diferentes. Es fácil perder esos detalles en una nota breve de cierre.

Cómo usar la IA en esta revisión

1. Aclarar qué cuenta como «resuelto». Primero se revisa la política de la organización, incluida la aceptación de riesgos, los controles compensatorios y el manejo de emergencias. El asistente debe trabajar con esos criterios, no inventarlos.
2. Reunir todos los casos. Hay que relacionar las alertas de vulnerabilidad con las aplicaciones afectadas, los tickets y los registros de despliegue. Si solo se entregan tickets cerrados, quedarán invisibles las alertas que nunca tuvieron uno.
3. Hacer una pregunta concreta. En un entorno aprobado, se le dan al asistente únicamente los registros necesarios para buscar contradicciones o explicaciones ausentes. El código, los datos de clientes, las credenciales y los detalles sensibles de las vulnerabilidades se protegen según la política de la organización.
4. Comprobar lo que señala. Se cotejan los identificadores de tickets y versiones, se comparan las fechas con una consulta que pueda repetirse y se leen los comentarios originales. Si un estado o una excepción no están claros, se consulta con la persona responsable del control.
5. Revisar también lo que no señaló. Se toma una muestra de los casos que el asistente dejó pasar, sobre todo cambios complejos o de emergencia conocidos. Una lista corta y convincente de excepciones sirve de poco si quedaron casos importantes sin detectar.
6. Documentar cómo se llegó al resultado. En los papeles de trabajo deben quedar la política, el total de casos, el método, la evidencia verificada, las limitaciones y el razonamiento de la auditora. La IA puede ayudar a redactar un resumen, pero cada conclusión debe poder rastrearse a la evidencia.

El criterio de evidencia del IIA aplica también aquí: la información que sustenta una conclusión debe ser relevante, confiable y suficiente. Una respuesta de IA que no se puede rastrear hasta los registros originales es una pista para investigar, no una prueba.

La herramienta de IA también entra en la revisión

Usar IA abre otra pregunta para el equipo de auditoría: ¿cuán confiable fue el trabajo del asistente? El Marco de Auditoría de IA del IIA aborda responsabilidades de gobierno, gestión y auditoría interna. El Marco de Gestión de Riesgos de IA de NIST organiza los riesgos mediante las funciones Govern, Map, Measure y Manage. Ambos ayudan a estructurar la evaluación; ninguno valida por sí solo una respuesta del asistente.

La auditora necesita saber qué herramienta y versión se usaron, qué registros podía leer, si tenía permiso para ejecutar acciones y cómo se comprobaron las respuestas. El modelo podría relacionar el ticket equivocado con un pase, omitir un caso o afirmar con seguridad que se hizo un análisis que nunca ocurrió. Incluso un comentario en un ticket o un archivo del repositorio podría contener instrucciones para confundir al asistente que lo lea. Limitar los accesos, definir bien la tarea, volver a las fuentes y buscar casos omitidos ayuda a reducir esos riesgos.

Antes de utilizar el asistente con muchos tickets, el equipo puede probarlo con casos que una persona ya revisó. Así puede ver qué casos útiles encuentra, cuáles señala por error y qué diferencias reales deja pasar. Conviene repetir esa prueba si cambian las fuentes de datos, la tarea o el asistente. Guardar las instrucciones usadas y las verificaciones hechas después facilita explicar el trabajo y repetirlo.

También habría que examinar otro uso de IA si el equipo de desarrollo la emplea para proponer correcciones. GitHub Copilot Autofix, por ejemplo, puede sugerir cambios para ciertas alertas de análisis de código. Eso es distinto a la actualización de dependencias que preparan Renovate o Dependabot. En ambos casos, la auditora puede verificar quién revisó el código propuesto, si corrieron las pruebas y los análisis de seguridad, y quién podía descartar un hallazgo o aprobar el pase. El bot puede proponer el cambio; los controles de la organización determinan si llega a producción.

Conclusión

La IA puede ayudar a encontrar un «resuelto» dudoso entre muchos comentarios y notas. Ahorra tiempo en la búsqueda, pero la conclusión depende de revisar todas las vulnerabilidades pertinentes, entender la política y confirmar qué ocurrió en producción. Al comprobar tanto los tickets marcados por el asistente como una muestra de los que dejó pasar, la auditora mantiene su juicio anclado en evidencia.

Referencias

1. The IIA. Solving the Riddle: Harnessing Generative AI for Internal Audit Activities.
2. The IIA. Artificial Intelligence Auditing Framework, 2nd Edition.
3. The IIA. Global Internal Audit Standards, Standard 14.1.
4. NIST. Artificial Intelligence Risk Management Framework.
5. Renovate. How Renovate Works; GitHub. Dependabot Version Updates.
6. GitHub. About Autofix for Code Scanning.
7. OWASP GenAI Security Project. LLM01:2025 Prompt Injection.