Qué pasa cada día de un pentest de IA, qué recibes al final, qué necesitas tener listo antes de empezar y las cosas que este test no te va a contar.
Un pentest de IA es un test de intrusión cuyo objetivo resulta que contiene un modelo. La NIST SP 800-115 define el pentest como una prueba de seguridad en la que quien evalúa imita ataques reales para encontrar formas de rodear las funciones de seguridad de una aplicación, un sistema o una red. Que haya un modelo en la pila no cambia eso.
Lo que cambia es la superficie de ataque. El sujeto es el asistente o el agente que rodea al modelo: el prompt que ensambla el contexto, los documentos que recupera, las herramientas que puede invocar, la identidad con la que corren esas herramientas y la aplicación que pinta lo que vuelve. La mayoría de los hallazgos con impacto real viven en esa fontanería, no en los pesos.
No es una prueba comparativa de tu modelo, y no es una evaluación de seguridad de contenidos ni de sesgos; ninguna de las dos cosas es lo que responde un informe de pentest. La forma comercial está en la página de pentesting de IA; esto es el método.
No se toca nada hasta que el alcance está firmado. La NIST SP 800-115 dice que el plan de evaluación, que es como llama a las rules of engagement, responde a cinco preguntas: alcance, autorización, logística, tratamiento de datos sensibles y qué pasa en caso de incidente. Hay cuatro más que son propias de la IA:
Listo el primer día: la funcionalidad de IA activada en ese entorno; credenciales de cada rol que importe, y dos inquilinos si el producto es multiinquilino; las herramientas que el modelo puede invocar y los permisos que tiene cada una; los prompts de sistema si el test es de caja gris; y una persona de contacto técnica con nombre.
El descubrimiento es donde se toca algo por primera vez, y en los sistemas de IA se gana el sueldo, porque el inventario del que partes suele estar mal.
Enumeramos cada punto de entrada que llega a un modelo (ventana de chat, API pública, proceso por lotes, webhook, complemento del entorno de desarrollo), cada modelo que hay detrás de ellos, cada fuente de recuperación y el camino que recorre un documento hasta entrar en ella, y cada herramienta que el modelo puede invocar con sus ámbitos. Esto casi siempre saca a la luz algo que el equipo de plataforma no sabía que estaba en marcha: un endpoint que todavía sirve un prompt de sistema anterior, un modelo de reserva más barato, un asistente interno cableado a datos de producción.
El resto del reconocimiento dibuja por dónde entra contenido no confiable en la ventana de contexto: ficheros subidos, páginas rastreadas, correo entrante, cuerpos de tickets, invitaciones de calendario y los servidores de terceros con los que habla un agente.
Esto no es un test de web con un chat atornillado. Cuatro capas, por orden, y cada hallazgo etiquetado contra el OWASP Top 10 for LLM Applications de 2025.
La inyección de instrucciones, o prompt injection, es LLM01, y se parte en dos. La inyección directa es un usuario hablando con el modelo; la inyección indirecta es el modelo leyendo instrucciones dentro de contenido que controla otra persona. La segunda escala, porque el atacante no toca nunca tu pantalla de inicio de sesión.
El texto de OWASP es tajante: dada la influencia estocástica que hay en el corazón del funcionamiento de los modelos, no está claro que existan métodos infalibles de prevención de la inyección de instrucciones. Así que la pregunta no es si se puede inyectar un prompt, sino qué puede alcanzar: permisos, no redacción. La fuga del prompt de sistema, LLM07, va en la misma pasada.
Cuando el sistema usa generación aumentada por recuperación, el corpus es superficie de ataque: LLM08, vulnerabilidades de vectores y de embeddings. Probamos si los documentos de un inquilino aparecen en las respuestas de otro, y si un documento con instrucciones enterradas dentro cambia el comportamiento para quien lea a continuación.
Donde el modelo puede actuar, el impacto deja de ser teórico. LLM06, exceso de autonomía, nombra tres causas: exceso de funcionalidad, exceso de permisos y exceso de autonomía. Desmontamos el registro de herramientas y preguntamos qué hace cada función con argumentos que controla el atacante: autorización a nivel de objeto dentro de su propia API, falsificación de peticiones en todo lo que descargue una URL, inyección en todo lo que construya una consulta o lea un fichero. Y después las encadenamos: un agente que puede leer un ticket y llamar a una API interna está a dos pasos de un camino de datos que nadie dibujó. Y ahí está el punto que conviene no perder: el fallo casi nunca es la inyección de instrucciones, es el registro de herramientas que le da algo que hacer.
El tratamiento inadecuado de la salida, LLM05, es donde las funcionalidades de IA reintroducen vulnerabilidades que la web resolvió hace una década: salida pintada como HTML, una URL de imagen que da el modelo usada como canal de exfiltración, SQL generado y ejecutado sin parametrizar. Para el modelo en sí trabajamos con la taxonomía de aprendizaje automático adversario de NIST, la AI 100-2 E2025, que separa los ataques de evasión, envenenamiento y privacidad sobre sistemas predictivos de los de envenenamiento, instrucción directa e inyección indirecta de instrucciones sobre los generativos. El consumo sin límites, LLM10, cierra la capa: cuando la inferencia se paga por uso, una denegación de servicio es además una factura.
La 800-115 traza la raya que importa: mientras los escáneres de vulnerabilidades solo comprueban la posible existencia de una vulnerabilidad, la fase de ataque de un pentest la explota para confirmar que existe. Un asistente al que se convence de ser grosero no es un hallazgo; uno que lee la factura de otro cliente sí.
Aquí hay dos costumbres propias. El encadenado: buscamos el camino que va del contenido que escribe alguien de fuera, pasando por una llamada a una herramienta que lleva tus privilegios, hasta datos que salen por un canal que controlamos. Y la repetibilidad: la salida de un modelo es estocástica, así que cada hallazgo se relanza un número fijo de veces y se informa con la tasa a la que funcionó, diez de diez o dos de diez. Una técnica que salta una vez de cada cincuenta sigue siendo un hallazgo, y conviene saber cuál es cuál.
Y cuando la corrección corresponde a la telemetría y no al prompt, eso es un problema aparte: hay que poder ver el abuso de una herramienta en los registros sin llenar de fricción el trabajo diario de quien desarrolla, porque un control que estorba se apaga.
La 800-115 describe el entregable como un informe que identifica las vulnerabilidades encontradas, presenta una calificación de riesgo y da orientación para mitigarlas. El nuestro deja que tres públicos lean un solo documento:
Se entrega en una sesión de trabajo con los técnicos que tienen que actuar sobre él.
El número se acuerda por escrito antes de empezar, y los días de retest van dentro y no añadidos después. Qué lo mueve:
Los días de trabajo se ponen por escrito una vez hemos visto la superficie.
Los marcos que cambian lo que se hace de verdad:
Si el sistema es de alto riesgo según el Reglamento Europeo de Inteligencia Artificial, su artículo 15 exige que esos sistemas sean resistentes a los intentos de terceros no autorizados de alterar su uso, sus resultados o su rendimiento aprovechando vulnerabilidades del sistema, y espera soluciones técnicas que aborden el envenenamiento de datos, el envenenamiento del modelo, los ejemplos adversarios y la evasión del modelo. Un pentest es evidencia de cara a ese deber, no cumplimiento de él.
Un hallazgo no está cerrado porque esté cerrado un ticket. Entre las responsabilidades que la 800-115 asigna a quien evalúa está realizar exámenes y pruebas adicionales cuando haga falta para validar las acciones de mitigación. Eso es el retest.
Relanzamos cada hallazgo tal como se reprodujo la primera vez, la misma clase de hallazgo en otros sitios, y la cadena completa, porque una corrección en el medio a veces solo la desplaza. En los hallazgos de IA repetimos el mismo número fijo de intentos: un filtro que baja una tasa de éxito de diez de diez a dos de diez ha reducido el ruido, no ha resuelto el problema, y el informe lo dice.
Recibes un informe actualizado con un estado y una fecha por hallazgo, que es lo que piden los cuestionarios de seguridad. Para aplicar esto a tu propia arquitectura, empieza por un proyecto de pentesting de IA.
Qué es el ciclo de vida de desarrollo seguro, qué se hace en cada fase, qué aportan SAST, DAST y SCA, y por dónde empezar si hoy no tenéis nada montado.
Qué riesgos trae la IA generativa en empresa, por qué la inyección de prompts no es el problema real y qué se prueba en un pentest de IA.
Qué es un pentest, qué fases tiene, qué recibes al final, cuánto dura y en qué se diferencia de un análisis de vulnerabilidades.
Si algo de aquí se parece a un problema que llevas encima, media hora de llamada para acotarlo con un pentester senior vale más que leer otro artículo.
Hablar con un pentester seniorElige la hora que mejor te venga. Nos cuentas qué necesitas y en qué punto estás, y te explicamos cómo trabajamos y de qué forma podemos ayudarte.
