El pentest de IA es la prueba de penetración aplicada a sistemas construidos sobre modelos de lenguaje — chatbots, agentes autónomos y pipelines RAG. Simula ataques reales para encontrar fallas como prompt injection, fuga de datos y abuso de herramientas antes de que lo haga un adversario, con evidencia reproducible y severidad clasificada por impacto al negocio.
El término toma prestada la etiqueta del pentest tradicional, pero la práctica difiere en casi todo lo que importa. Un pentest de aplicación web asume una frontera nítida entre código y datos; un pentest de IA parte de la premisa opuesta. Esta guía explica qué significa ese cambio en la práctica, cómo se conduce el ejercicio, qué sistemas lo necesitan y dónde entran las categorías del OWASP LLM Top 10 2025.
¿Qué es exactamente el pentest de IA?
El pentest de IA es la evaluación ofensiva de un sistema que usa un modelo de lenguaje para tomar decisiones, generar texto o disparar acciones. El objetivo no es medir la calidad de las respuestas del modelo, sino demostrar cómo un atacante manipula el sistema a su alrededor: la interfaz, las herramientas conectadas, las fuentes de datos y los permisos de la sesión.
La diferencia de fondo está en la frontera entre código y datos. En el software tradicional, un binario ejecuta instrucciones y un archivo de configuración aporta parámetros; la explotación ocurre cuando el atacante logra mover datos hacia el lado del código. En un LLM, esa separación no existe. El system prompt, la entrada del usuario, el documento recuperado de un vector store y la salida de una herramienta llegan al modelo por el mismo canal: texto. El modelo no tiene un mecanismo estructural para distinguir la instrucción legítima del operador de una instrucción plantada dentro de un PDF que el pipeline acaba de indexar.
La consecuencia práctica es directa: todo dato que entra al contexto es potencialmente ejecutable. Un pentest de IA prueba exactamente esa realidad en lugar de ignorarla.
¿Cómo funciona un pentest de IA?
Un pentest de IA sigue fases que van del mapeo de la superficie a la demostración del impacto. Cada fase produce evidencia reproducible, no solo una respuesta indeseada del modelo. Los pasos que aplicamos, en orden:
- Mapeo de la superficie. Documentar endpoints, autenticación, límites de tasa, el system prompt completo, cada herramienta que el modelo puede invocar, el pipeline RAG y el flujo de datos — qué entra al contexto, qué sale, qué se persiste. Sin ese mapa, la prueba se vuelve ensayo y error contra una caja negra.
- Acceso inicial. Probar que una instrucción del atacante llega al modelo — por prompt injection directo (el usuario es el atacante) o indirecto (la instrucción llega dentro de un documento, correo, ticket o página que el sistema consume).
- Escalación de privilegios. Evadir guardrails, extraer el system prompt y desbloquear llamadas de herramienta que deberían estar restringidas al operador.
- Reconocimiento. Enumerar capacidades reales: qué herramientas invoca el agente, qué fuentes de datos alcanza, qué credenciales están en el alcance de la sesión.
- Persistencia. Verificar si existe algún lugar escribible que el modelo relea después — memoria de largo plazo, documentos en el vector store, reglas de proyecto — y usarlo para sobrevivir al fin de la sesión.
- Acción sobre el objetivo. Demostrar el impacto concreto: exfiltración de datos, una acción de escritura no autorizada, movimiento lateral hacia el entorno tradicional o fraude.
- Reporte. Entregar un camino de ataque con evidencia en cada paso, severidad por impacto al negocio y un orden de corrección justificado.
Lo que separa un pentest serio de una batería de prompts adversariales es dónde se detiene. Correr cincuenta jailbreaks y reportar que "el modelo es vulnerable a prompt injection" mide solo la fase 2. El valor está en mostrar qué haría un adversario después.
¿Qué sistemas de IA necesitan pentest?
Necesita pentest de IA todo sistema en el que un modelo de lenguaje influye sobre datos sensibles, dispara herramientas o toma decisiones que afectan a los usuarios. En la práctica, tres arquitecturas concentran el riesgo:
- Chatbots y asistentes. Interfaces conversacionales expuestas a clientes o empleados. El riesgo crece con el acceso: un chatbot que solo responde preguntas es una superficie pequeña; uno que consulta datos de cuenta, abre tickets o procesa pagos es otra cosa. Aquí probamos fuga entre usuarios, extracción de system prompt y acciones disparadas por texto.
- Agentes autónomos. Sistemas que planifican y ejecutan tareas con múltiples llamadas de herramienta, muchas veces sin revisión humana en cada paso. Son la arquitectura de mayor severidad, porque la autonomía multiplica el impacto de cualquier injection. En pipelines multiagente, un agente confía en la salida de otro por la misma razón que confía en la entrada del usuario — todo es texto.
- Pipelines RAG. Sistemas que recuperan documentos de un vector store y los inyectan en el contexto. El punto crítico rara vez es el modelo; es quién puede escribir en el índice. Si un ticket de soporte enviado por un cliente termina indexado, el control de acceso de escritura al vector store se vuelve un control de seguridad de primer orden.
La pregunta que define el alcance no es "¿usamos IA?", sino "¿qué alcanza este sistema cuando alguien lo convence de actuar?".
¿Qué cubre el OWASP LLM Top 10 2025?
El OWASP LLM Top 10 (revisión 2025) organiza los riesgos más relevantes de las aplicaciones con LLM en diez categorías. Funcionan como la columna vertebral de alcance de un pentest de IA:
- LLM01 — Prompt Injection. Entradas manipuladas que alteran el comportamiento del modelo o disparan acciones no intencionadas; incluye el vector indirecto, el más explotado en incidentes reales.
- LLM02 — Sensitive Information Disclosure. Exposición de PII, secretos o datos de otros usuarios vía respuestas o canales laterales.
- LLM03 — Supply Chain. Modelos, datasets, plugins y extensiones de terceros que cargan vulnerabilidades o procedencia comprometida.
- LLM04 — Data and Model Poisoning. Manipulación de datos de entrenamiento, fine-tuning o embeddings para introducir sesgos o backdoors.
- LLM05 — Improper Output Handling. Salida del modelo consumida aguas abajo sin validación, convertida en XSS, SSRF, inyección de comandos o de SQL — la categoría que convierte un problema de IA en RCE.
- LLM06 — Excessive Agency. Permisos o autonomía más allá de lo necesario, explotables para acciones arbitrarias; el multiplicador de severidad de todas las demás.
- LLM07 — System Prompt Leakage. Fuga del system prompt, que describe herramientas, límites de autorización y la estructura de los datos accesibles — el mapa de la red en lenguaje natural.
- LLM08 — Vector and Embedding Weaknesses. Fallas en cómo se generan, almacenan y recuperan los embeddings, incluido el control de acceso en la recuperación y la fuga entre tenants.
- LLM09 — Misinformation. Salidas incorrectas o fabricadas tratadas como confiables por los sistemas o usuarios aguas abajo.
- LLM10 — Unbounded Consumption. Operaciones que degradan el desempeño, inflan el costo o tumban el servicio — en arquitecturas con agentes, una sola entrada puede disparar una cascada de llamadas pagas.
Cubrir las diez categorías no significa leer las diez descripciones. Significa tener, para cada una, un objetivo concreto en el sistema y evidencia de explotación o de su ausencia.
Pentest de IA y pentest tradicional: ¿cuál es la diferencia?
El pentest de IA y el pentest tradicional comparten el objetivo — encontrar fallas antes que el atacante — pero divergen en premisa, vector y evidencia. La tabla resume dónde se separan:
| Dimensión | Pentest tradicional | Pentest de IA |
|---|---|---|
| Frontera código/datos | Bien definida | Inexistente — todo es texto en el mismo canal |
| Vector principal | Inyección vía parámetros y protocolos | Prompt injection directo e indirecto |
| Superficie de persistencia | Archivos, bases de datos, cuentas | Memoria del agente, embeddings, contexto |
| Determinismo | Alto — misma entrada, misma salida | Bajo — respuestas probabilísticas |
| Evidencia que cuenta | Payload que produce respuesta del sistema | Payload que hace que el modelo ejecute una acción |
| Alcance de datos | Definido por permisos explícitos | Ampliado por lo que el modelo alcanza en la sesión |
La implicación para quien contrata es que un pentest de IA no reemplaza al pentest tradicional — lo complementa. El sistema de IA casi siempre vive dentro de una aplicación, una red y una nube que también deben probarse. Un camino de ataque completo suele empezar en lenguaje natural y terminar en una vulnerabilidad convencional.
¿Cuándo hacer un pentest de IA?
El mejor momento es antes de que el sistema alcance datos o acciones sensibles en producción, y de forma recurrente a medida que la superficie cambia. Disparadores concretos que justifican una prueba:
- Antes del go-live de cualquier sistema de IA que consulte datos reales, dispare herramientas o hable con clientes.
- En cada cambio de agencia — cuando el asistente gana una herramienta nueva, acceso de escritura o una integración con credencial de servicio.
- Al conectar un nuevo pipeline RAG o abrir el vector store a contenido enviado por terceros.
- En ciclos de compliance, cuando la gobernanza de IA pasa a ser exigida por regulación sectorial o por normas como la ISO/IEC 42001.
La seguridad de IA no es una prueba única en el lanzamiento. La superficie está viva: cada herramienta nueva, cada fuente de datos agregada y cada cambio de permiso reabre el alcance.
Cómo lo ejecuta Berghem
Berghem conduce el pentest de IA como un ejercicio ofensivo estructurado, no como una batería de prompts. Partimos del mapeo de la superficie, aplicamos las fases del acceso inicial a la acción sobre el objetivo y entregamos un camino de ataque con evidencia reproducible en cada paso, severidad por impacto al negocio y orden de corrección priorizado por retorno.
El alcance se calibra al sistema: chatbot, agente autónomo o pipeline RAG reciben objetivos y vectores distintos, siempre anclados en las categorías del OWASP LLM Top 10 2025. Para ver la metodología completa, el alcance y el formato de entrega, conoce nuestro servicio de pentest de sistemas de IA y LLM. Cuando el riesgo se concentra en agentes con autonomía elevada, el trabajo se extiende a la seguridad de agentes de IA y, en el plano de gobernanza, a la certificación ISO/IEC 42001.
Preguntas frecuentes
¿El pentest de IA es lo mismo que el Red Team de IA?
No. El pentest de IA evalúa un sistema con alcance y plazo definidos, cubriendo sus categorías de riesgo de forma sistemática. El Red Team simula un adversario con un objetivo específico y sin alcance cerrado, para probar detección y respuesta. Los dos se complementan: el pentest mapea fallas, el Red Team mide la capacidad de reaccionar ante ellas.
¿Cuánto tarda un pentest de IA?
Depende de la superficie: número de herramientas conectadas, fuentes de datos, integraciones y nivel de autonomía del sistema. Un chatbot de alcance restringido exige mucho menos esfuerzo que un agente autónomo con acceso de escritura a múltiples sistemas. El plazo se define tras el mapeo inicial, cuando la superficie real se hace visible — no por un número fijo anunciado de antemano.
¿El pentest de IA reemplaza al pentest tradicional?
No. Los dos son complementarios. El sistema de IA vive dentro de una aplicación, una red y una nube que también deben probarse, y un camino de ataque completo a menudo empieza en prompt injection y termina en una vulnerabilidad convencional. Lo ideal es combinar el pentest de IA con pruebas de aplicación, API y cloud.
Berghem es una empresa de seguridad en IA que atiende a Brasil y LATAM.