Auditoría de seguridad para aplicaciones creadas con IA: qué incluye y qué no

Quien solicita una auditoría de seguridad para una aplicación creada con IA se enfrenta a menudo a dos preguntas concretas: qué se comprobará realmente y qué queda fuera del perímetro. La respuesta depende del tipo de aplicación: una web app clásica generada con IA requiere WAPT, Code Review y verificación de configuraciones; una aplicación que integra LLM requiere además pruebas sobre prompts, RAG, tool calls y salidas.

El punto no es juzgar a la IA como herramienta de desarrollo. Es mucho más práctico: entender qué controles se necesitan cuando el código o los flujos de trabajo generados o acelerados por la IA entran en un producto, en un proceso empresarial o en un entorno con datos reales.

[Callforaction-WAPT]

Por qué una aplicación que funciona no es necesariamente segura

Las herramientas de IA reducen el tiempo necesario para crear código, interfaces, flujos de trabajo y configuraciones. Sin embargo, esta velocidad puede comprimir pasos que normalmente hacen que el software sea fiable: modelado de amenazas (threat modeling), revisión, gestión de secretos, controles de roles, validación de entradas, verificación de dependencias y pruebas manuales de las rutas críticas.

Una demo funciona con un solo usuario, datos ficticios y permisos implícitos. La misma lógica puede fallar cuando llegan clientes reales, múltiples inquilinos (tenants), roles diferentes, APIs públicas, integraciones, datos personales, pagos o automatizaciones con efectos externos. La seguridad debe evaluarse según el comportamiento real de la aplicación, no por la promesa de la herramienta que la generó.

Qué se necesita para iniciar una auditoría

Para realizar una auditoría seria se requieren: repositorio o build, URL y entornos de prueba, definición de los roles de usuario, flujos críticos, esquema de datos, integraciones externas, pipelines CI/CD, configuraciones cloud relevantes e indicación de qué partes han sido generadas o modificadas con IA.

Qué incluye una auditoría proporcionada

Una auditoría proporcionada cubre autenticación, autorizaciones, APIs, gestión de datos, secretos, dependencias, configuraciones, registro de eventos (logging), gestión de errores, pipelines y superficies expuestas. Si la aplicación utiliza LLM, incluye también inyección de prompts, gestión de salidas, recuperación (retrieval), memoria, tool calls y límites de tasa (rate limits).

Qué no incluye

Una auditoría no es una certificación de la herramienta de IA utilizada para desarrollar, no garantiza la ausencia de errores futuros y no sustituye la gobernanza, el monitoreo, la aplicación de parches y la remediación continua. Sin acceso al código, a los roles y a un entorno representativo de la producción, la auditoría se vuelve inevitablemente parcial.

Riesgos principales a controlar

Perímetro ambiguo entre WAPT, Code Review, VA y pruebas de IA: definir de antemano qué superficies entran en la prueba y cuáles no.
Entorno de prueba no representativo de la producción: los datos ficticios y los permisos simplificados ocultan vulnerabilidades reales.
Roles y datos no proporcionados al tester: sin acceso a los roles reales, los controles sobre las autorizaciones quedan incompletos.
Código generado no rastreado en los diffs: las partes generadas con IA que no han sido revisadas manualmente son un punto ciego.
Riesgos de LLM ignorados para aplicaciones que usan modelos: la inyección de prompts, las tool calls no controladas y las salidas no validadas son vectores concretos.
Riesgos clásicos ignorados porque la aplicación es “de IA”: la autenticación, las autorizaciones y la gestión de secretos siguen siendo críticos independientemente de cómo se haya escrito el código.
Entregables sin prioridad de remediación: un informe sin distinción entre hallazgos bloqueantes y riesgo residual no ayuda a la toma de decisiones operativas.

La combinación correcta de controles depende del impacto, no del nombre de la herramienta. Una aplicación expuesta requiere pruebas de aplicación manuales; una modificación crítica al código requiere revisión; un flujo de trabajo interno requiere control de permisos y credenciales; una aplicación agentica requiere pruebas sobre prompts, herramientas y salidas.

Controles mínimos antes del go-live

Mapear usuarios, roles, datos reales, integraciones, entornos y propietarios del servicio.
Identificar qué partes han sido generadas o modificadas con IA y quién las ha revisado.
Verificar autorizaciones del lado del servidor, aislamiento de inquilinos (tenant isolation) y funciones administrativas.
Buscar secretos en código, prompts, logs, variables de entorno, builds y el historial del repositorio.
Controlar dependencias, licencias, paquetes, plantillas, plugins y componentes generados.
Probar entradas hostiles, gestión de errores, logging, límites de tasa y rutas no previstas.
Separar correcciones bloqueantes, remediación planificada y riesgo residual aceptado conscientemente.
Repetir la prueba o realizar un retest después de correcciones que afecten a flujos críticos.

Cuándo se necesita una verificación independiente

Se necesita una verificación independiente cuando la aplicación o el flujo de trabajo gestiona datos reales, usuarios externos, roles, APIs, integraciones empresariales, pagos, almacenamiento, flujos de trabajo automáticos o código crítico generado con IA. También es necesaria cuando el equipo no puede demostrar qué partes han sido revisadas y qué controles bloquean regresiones o abusos.

El perímetro recomendado por ISGroup en este caso incluye: Web Application Penetration Testing, Code Review, Vulnerability Assessment y, para las aplicaciones con LLM, AI Application Testing. La mejor revisión produce hallazgos reproducibles, prioridades de remediación, indicación del riesgo residual y, cuando es necesario, retest después de las correcciones.

Preguntas operativas para fundadores, CTOs y equipos de seguridad

¿Qué datos reales entran en el sistema y dónde se guardan, registran o envían?
¿Qué roles existen y qué acciones están bloqueadas del lado del servidor, no solo en la interfaz?
¿Qué secretos, tokens, webhooks o credenciales permitirían el acceso a sistemas críticos?
¿Qué partes han sido generadas o modificadas por la IA y cuáles han sido revisadas por una persona competente?
¿Qué pruebas cubren el abuso, los errores, los diferentes roles y los diferentes inquilinos, no solo el camino feliz (happy path)?
¿Qué evidencia puede mostrarse a clientes, auditorías, compras o dirección?

Información adicional útil

Penetration test para SaaS y aplicaciones de IA: cómo configurar una prueba en productos SaaS o aplicaciones que integran componentes de IA, con enfoque en el perímetro y la metodología.
Controles de seguridad para aplicaciones de IA antes del go-live: lista operativa de los controles a completar antes de poner en línea una aplicación desarrollada con IA.
AI Application Testing: profundización en las pruebas específicas para aplicaciones que integran LLM, agentes y flujos de trabajo autónomos.

Preguntas frecuentes (FAQ)

¿Qué diferencia hay entre auditoría, WAPT y Code Review?
El WAPT verifica el comportamiento de la aplicación expuesta simulando un atacante externo. La Code Review analiza el código fuente en busca de vulnerabilidades lógicas y malas prácticas. La auditoría combina controles proporcionados al perímetro y puede incluir configuraciones, procesos y riesgos específicos de la IA.
¿Cuándo se necesita AI Application Testing?
Cuando la aplicación integra LLM, RAG, agentes, tool calling, memoria o flujos de trabajo autónomos. Si la IA se ha utilizado solo para escribir código, por lo general los controles prioritarios siguen siendo WAPT y Code Review.
¿Qué materiales debo preparar antes de la auditoría?
URL, definición de roles, flujos críticos, repositorio o build, arquitectura, integraciones, datos de prueba, pipeline CI/CD y lista de las partes generadas o modificadas con IA.
¿Qué tan amplio debe ser el perímetro?
Lo suficiente como para cubrir lo que puede causar un impacto real: datos, usuarios, roles, APIs, funciones administrativas, almacenamiento, pagos, integraciones y despliegue.
¿El informe es suficiente para salir a producción?
Solo si los hallazgos bloqueantes han sido corregidos o aceptados conscientemente. La decisión final debe incluir una evaluación de la remediación completada y del riesgo residual.

Fuentes y referencias

Si estás a punto de poner en línea una aplicación o un flujo de trabajo desarrollado con IA, ISGroup puede ayudarte a elegir el control adecuado: prueba de aplicación, Code Review, evaluación arquitectónica o verificación dirigida a los riesgos específicos de la IA.

[Callforaction-WAPT-Footer]