Blog técnico · Criterio profesional

El auditor que promueve IA generativa no tiene que elegir entre prohibir por miedo o adoptar por fe. Esa es una falsa disyuntiva, y este artículo explica cómo salir de ella.

La auditoría interna lleva décadas conviviendo con tecnología que no entiende línea por línea: sistemas ERP, modelos actuariales, algoritmos de scoring. Nunca por eso renunció a auditarla. Lo hizo aplicando controles, no leyendo cada instrucción. Con la IA generativa que produce código y soluciones aplica el mismo principio, pero antes hay que darle la mano al que objeta.

El reproche tiene parte de razón

Cuando un especialista en ciberseguridad pregunta cómo se promueve una herramienta que puede traer código malicioso, no está siendo obstruccionista: describe una amenaza documentada. La evidencia reciente le da munición. Solo el 55% de las instancias de código generado por IA resultaron seguras al evaluarse; la tasa lleva estancada entre 45% y 55% desde 2023, mientras la corrección sintáctica subió de 50% a 95% [1]. La IA aprendió a escribir código que funciona mucho más rápido de lo que aprendió a escribir código seguro.

Hay más. El código asistido por IA tiene entre 1,5 y 2 veces más probabilidad de introducir una vulnerabilidad que el escrito por una persona, y expone secretos como claves, contraseñas y tokens al doble de tasa [2]. En febrero de 2026, una red social construida íntegramente con IA y sin revisión de seguridad expuso 1,5 millones de tokens de autenticación y 35.000 correos por una base de datos mal configurada [3].

Un riesgo que conviene nombrar primero

Existe una amenaza específica del código generado por IA que el auditor gana si menciona antes que su interlocutor: el slopsquatting. Los modelos inventan nombres de librerías: cerca del 20% del código generado referencia paquetes que no existen [4]. Un atacante observa qué nombres alucina la IA con frecuencia, registra ese paquete en un repositorio público y le inyecta código malicioso. El siguiente desarrollador que siga la sugerencia instala la trampa. Ya hay casos reales documentados.

Dos argumentos que conviene retirar

Primero: “que venga el código documentado”. La documentación describe lo que el código dice que hace, no lo que hace. Es una práctica razonable de mantenibilidad, pero no es un control de seguridad: no prueba ausencia de vulnerabilidades, ni de secretos expuestos, ni de dependencias maliciosas.

Segundo: “los directores de las empresas de IA dicen que se puede confiar”. Ese es un argumento de autoridad que además proviene de la parte interesada en vender la tecnología. Para un auditor, cuyo oficio se funda en el escepticismo profesional, apoyarse ahí es casi una contradicción en los términos.

El reencuadre: controles, no fe

La posición defendible es la de siempre en auditoría: la confianza no se deposita en la herramienta, se deposita en el sistema de control que la rodea. Análisis de dependencias antes de instalar. Escaneo de vulnerabilidades sobre el código generado. Entornos segregados para probar. Revisión humana en los puntos de decisión. Y evidencia de todo lo anterior, organizada para que un tercero la revise.

Ese es exactamente el terreno del Método RTA-IA: soluciones con inteligencia artificial construidas para ser reproducibles, trazables y auditables desde el diseño. No se trata de leer cada línea; se trata de que cada línea opere dentro de un ambiente de control que deja rastro.

El día que un hallazgo dependa de “lo dijo el proveedor”, el auditor perdió la discusión. El día que dependa de evidencia verificable, la ganó antes de empezar.

Implicación para auditoría interna

La respuesta no es bloquear la IA ni aceptarla sin control. La respuesta es definir criterios, validar resultados, documentar decisiones y dejar evidencia suficiente para revisión. Quien audita código generado por IA no necesita leer cada línea: necesita verificar que existieron el análisis de dependencias, el escaneo de vulnerabilidades, el entorno segregado de pruebas y la revisión humana registrada. Esa evidencia es el papel de trabajo.

Referencias

  • Veracode. GenAI Code Security Report (2025). Evaluación de seguridad de código generado por más de 100 modelos de lenguaje sobre 80 tareas.
  • Apiiro. Análisis de repositorios con asistentes de código sobre incidencia de vulnerabilidades y exposición de secretos (2024).
  • Wiz Research. Análisis de seguridad de una red social construida con IA, con base de datos expuesta (2026).
  • Spracklen, J. y otros. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. USENIX Security 2025. arxiv.org/abs/2406.10279

Los datos enviados por los formularios de este sitio se usan únicamente para responder la solicitud, entregar el recurso pedido o enviar el boletín autorizado. No se comparten con terceros y puede pedir su corrección o eliminación por cualquiera de los canales de contacto.