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%. 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 —claves, contraseñas, tokens— al doble de tasa. 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.
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 que no existen —cerca del 20% del código generado referencia paquetes inexistentes—. 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.
Basado en el documento de trabajo “El auditor interno frente a la IA generativa” (Laura Lamprea Quiroga, junio de 2026), síntesis de 30 fuentes de enero a junio de 2026.