Nuestro LLM es solo un chatbot sobre docs. ¿De verdad necesita pruebas?

Depende de a qué puede llegar. Un chatbot sin herramientas, sin datos privados y sin consumidores posteriores de su salida tiene superficie limitada. En el momento en que recupera documentos internos, renderiza salida en una UI o llama funciones, adquiere los modos de falla de esta página — y la mayoría de los productos 'solo un chatbot' ya adquirieron los tres en silencio.

¿La inyección de prompts se puede 'arreglar' de verdad?

No en el modelo: con las arquitecturas actuales no hay un mecanismo confiable que separe instrucciones de datos dentro de un prompt. Se contiene en la aplicación: herramientas de mínimo privilegio, encoding de salida, confirmación humana para acciones de consecuencia, y aislamiento entre tenants. La evaluación prueba si su contención realmente aguanta, que sí es una pregunta de ingeniería respondible.

Ya hacemos red team de prompts internamente. ¿Qué suma esto?

El red team interno de prompts suele probar el comportamiento del modelo. Esta evaluación prueba la aplicación: a qué puede llegar una inyección una vez que aterriza — sus herramientas, sus almacenes de datos, sus navegadores renderizando salida del modelo, su facturación. También trae años de pentest convencional, porque la mayoría de los compromisos reales de apps LLM encadenan un truco de capa de modelo con una falla clásica de web o API.

¿Esto es una auditoría de alineación del modelo o de AI safety?

No. Esto es testing de seguridad de aplicaciones: qué puede hacer un atacante que su sistema haga. Propiedades de alineación, medición de sesgo y evaluación de políticas de contenido son disciplinas distintas y quedan explícitamente fuera de alcance.

Pentesting de IA y LLM

Si su equipo lanzó una feature encima de un modelo de lenguaje grande — un asistente de soporte, un Q&A sobre documentos, un agente que abre tickets o escribe en su CRM — sabe que necesita revisión de seguridad. Lo que probablemente nadie le explicó con claridad es qué debería contener esa revisión. Esta página es esa explicación.

Si desea el marco general de qué es una prueba de penetración y cómo se diferencia de un escaneo o de un red team informal de prompts, ese artículo es el punto de partida; aquí bajamos a la superficie específica de productos con LLM.

El problema de fondo: su modelo no distingue instrucciones de datos

Todo lo que ve un LLM es un solo flujo de tokens. El system prompt que escribió, la pregunta del usuario, el artículo de soporte recuperado, el asunto del correo que está resumiendo — el modelo no tiene un mecanismo confiable para tratar uno como política de confianza y otro como contenido no confiable. Quien pueda poner texto delante de su modelo puede intentar programarlo.

Esa sola propiedad genera la mayor parte de la superficie de ataque de LLM. También significa que el objetivo de las pruebas no es “hacer que el modelo rechace prompts malos”: es verificar que cuando (no si) el modelo se manipula, el radio de explosión lo contiene la aplicación que lo rodea.

Qué se prueba en la práctica

Cada área abajo se mapea al OWASP Top 10 for LLM Applications, la taxonomía de referencia para este trabajo.

Inyección de prompts — directa e indirecta (LLM01)

La inyección directa es el usuario escribiendo instrucciones adversarias. La indirecta es la peligrosa: instrucciones escondidas en contenido que su sistema alimenta al modelo en nombre del usuario — un documento recuperado, una página scrapeda, un correo que se resume, un nombre de archivo, un caption de imagen. La evaluación planta payloads en cada canal que ingiere su pipeline y traza qué pueden hacerle al sistema.

En productos LATAM esto importa doble: muchos equipos afinan filtros y system prompts en inglés, mientras usuarios y datos llegan en español (y a veces en portuñol o mezcla). Un bypass que falla en inglés a menudo funciona en español; la prueba lo incluye de forma deliberada, no como nota al margen.

Manejo inseguro de la salida (LLM05)

La salida del modelo es input no confiable para lo que la consume. Si su UI renderiza Markdown o HTML escrito por el modelo, la inyección se vuelve XSS. Si la salida alimenta una query SQL, un comando de shell o una llamada a API, se vuelve inyección en el sentido clásico. Aquí el testing de LLM se encuentra con el testing de aplicaciones web, y aquí suelen vivir los hallazgos de mayor severidad.

No basta con “el modelo no debería generar HTML”. Hay que ver qué hace el frontend, el backend y cualquier worker que tome esa salida como si fuera de confianza. Encoding, sanitización y límites de tipo son controles de aplicación — no de modelo.

Agencia excesiva: herramientas, funciones y flujos agenticos (LLM06/LLM08)

Los agentes actúan. Las preguntas que importan: ¿qué herramientas puede invocar el modelo, con privilegios de quién, validadas por qué? ¿Puede una instrucción inyectada encadenar leer-archivo → enviar-correo → borrar-registro? ¿Algo de consecuencia se ejecuta sin confirmación? La evaluación mapea cada tool call como un límite de autorización y lo ataca como un pentest de API ataca endpoints — porque eso es lo que son las tool calls.

En la práctica revisamos: scopes de tokens que el agente usa, allowlists de acciones, confirmación humana para escrituras, y si el modelo puede ampliar su propio privilegio pidiendo “ayúdame a llamar X con más permisos”. Un agente con acceso a CRM, facturación o tickets sin gates de confirmación no es un chatbot: es un operador remoto con UI conversacional.

Fuga de system prompt y de datos de entrenamiento (LLM02/LLM07)

Si su system prompt contiene algo sensible — URLs internas, identificadores de tenant, comportamiento de APIs, llaves (pasa) — los intentos de extracción forman parte de la prueba. También se sondea data memorizada de entrenamiento o fine-tuning cuando afinó sobre material propietario. La corrección correcta suele ser arquitectónica: nada secreto pertenece a un prompt. El informe lo dice en concreto, con el material extraído como evidencia.

Jailbreaks y bypass de guardrails

El entrenamiento de rechazo, los filtros de contenido y las capas de moderación son topes de velocidad, no límites. La prueba mide qué tan rápido cae cada capa ante técnicas conocidas y novelas — role-play, encoding, manipulación multi-turno, pivotes cross-lingüísticos (sus guardrails probablemente se afinaron en inglés; sus usuarios en LATAM no atacan en inglés) — y, más importante, qué queda alcanzable una vez que caen.

Un jailbreak “exitoso” que solo logra que el modelo diga algo ofensivo tiene poco valor de negocio. Un jailbreak que desbloquea una tool call privilegiada, filtra un documento de otro tenant o fuerza una acción irreversible sí lo tiene. Evaluamos el segundo caso.

Pipeline RAG y envenenamiento del vector store (LLM03/LLM08)

La generación aumentada por recuperación agrega un pipeline de ingestión, un paso de embeddings y una base vectorial — cada uno un límite de confianza. La prueba cubre: quién puede escribir al corpus y con qué validación; si los documentos de un tenant se pueden recuperar en el contexto de otro; si un documento envenenado puede dirigir respuestas o cargar payloads de inyección indirecta; y si los controles de acceso filtran en el momento de la recuperación o solo en la ingestión.

También importa el ciclo de vida: documentos borrados que siguen en el índice, re-embedding parcial, y logs que mezclan queries de un tenant con snippets de otro. En productos B2B multi-tenant en la región, el aislamiento en el vector store suele ser el hallazgo de mayor impacto cuando falla.

Cadena de suministro de modelos y plugins (LLM05)

¿De dónde salen sus pesos, adapters, embeddings y plugins? ¿Versiones pineadas o un tag móvil en un hub público? ¿Qué ve un plugin de terceros cuando se ejecuta, y qué pasa con su modelo de amenaza cuando su proveedor se compromete? La evaluación inventaría estas dependencias como una auditoría de código inventaría paquetes.

Denial-of-wallet y agotamiento de recursos (LLM10)

Las llamadas a LLM son cómputo medido. Rate limits faltantes, stuffing ilimitado de contexto, loops recursivos de agentes y rutas de recuperación caras permiten que un atacante convierta su API en su presupuesto de cómputo. La prueba sondea estos límites y documenta el costo de una campaña de abuso sostenido contra sus controles actuales — útil para finanzas y para el equipo de plataforma, no solo para AppSec.

Aislamiento de datos multi-tenant

Si su producto atiende a más de un cliente, el aislamiento es la pregunta de mayor severidad de la página. ¿Pueden aparecer prompts, documentos, embeddings, historial de conversación o resultados de tool calls del Tenant A en el contexto del Tenant B? La prueba trata cada componente compartido — vector store, prompt cache, session store, pipeline de logging — como un canal potencial cross-tenant.

Mapeo a estándares y regulación

OWASP Top 10 for LLM Applications — taxonomía primaria; cada hallazgo del informe lleva mapeo LLM Top 10 donde aplique.
NIST AI Risk Management Framework — la evaluación produce evidencia que puede adjuntar a las funciones Measure y Manage (pruebas adversarias de sistemas desplegados).
ISO/IEC 42001 — los sistemas de gestión de IA esperan cada vez más testing de seguridad de aplicaciones habilitadas por IA; ver nuestra guía de ISO 42001.
EU AI Act — sistemas puestos en el mercado de la UE enfrentan obligaciones de conformidad y gestión de riesgo; el testing de seguridad de la capa de aplicación es una pieza de esa evidencia. Ver testing de seguridad EU AI Act.

Para equipos que venden a clientes con SOC 2 u otros frameworks tradicionales, los hallazgos de LLM también alimentan controles de AppSec y de change management: no son un silo “de IA” separado del resto de su programa.

Qué esta evaluación no cubre

Claridad de alcance evita gastar de más:

No es una auditoría de alineación del modelo ni de AI safety. Medición de sesgo, preference optimization y evaluación de políticas de contenido son disciplinas distintas.
No es una revisión de la infraestructura del proveedor del foundation model. Probamos su aplicación y los límites de confianza que controla.
No sustituye el testing convencional de aplicaciones. Una feature de LLM se sienta encima de una app web y de APIs. Los releases de alta confianza emparejan esta evaluación con testing web y de API.

Entregables

Recibe un informe con pasos de reproducción (prompts, payloads, trazas), mapeos al OWASP LLM Top 10, notas de arquitectura sobre límites de confianza, y mitigaciones escritas como cambios de ingeniería — herramientas de mínimo privilegio, encoding de salida, gates de confirmación, aislamiento de tenants — no “agrega un guardrail”. Los hallazgos corregidos se re-prueban. Hay carta de atestación disponible para clientes, auditores y revisiones de gobernanza de IA.

Pentesting de aplicaciones de IA y LLM