Aplicaciones de AI
Probar aplicaciones de AI: qué falla y cómo probarlo.
Una app con LLM falla de formas en que no falla una app web normal. El modelo devuelve algo distinto cada vez, así que no puedes hacer aserciones sobre la respuesta: las haces sobre todo lo que la rodea: que llega una respuesta, que hace streaming, que se detiene, que falla de forma visible, que respeta un límite y que nunca devuelve datos que la persona no puede ver.
Última actualización: 24 de agosto de 2026
¿En qué se diferencia probar una aplicación de AI?
La interfaz es la misma. El contrato no. La automatización de pruebas tradicional se apoya en una aserción que se cumple dos veces: haz clic aquí, ve esto. Un modelo rompe esa suposición en la primera ejecución, y por eso los equipos suelen concluir que sus funciones de AI no se pueden probar por regresión y las publican sin probar.
Sí se pueden. El truco es mover la aserción de la prosa a las partes que son deterministas: la respuesta llegó dentro de un presupuesto, se parseó con el esquema que pediste, citó un documento que este usuario puede leer, un rechazo se mostró como un rechazo, un reintento no cobró dos veces. Todo eso es automatización corriente. Juzgar si la respuesta es buena es un problema de evaluación, necesita tu propio ground truth y pertenece a un arnés junto a tus prompts, no a una suite de regresión.
Lo que realmente falla en una app con LLM
Son comportamientos, no opiniones sobre la calidad de la salida, y eso es lo que los hace comprobables. Cada uno llega a los usuarios como un bug del producto y no como una mala respuesta.
| Fallo | Cómo llega a un usuario | La prueba |
|---|---|---|
| La respuesta llega en streaming y se corta a la mitad | Una conexión caída a mitad del streaming deja una respuesta a medias en pantalla, sin error ni reintento. Los usuarios la leen como la respuesta. | Corta la respuesta a mitad del streaming y comprueba que la UI muestra un estado de fallo, no una respuesta truncada. |
| El modelo es lento y la UI no tiene respuesta para eso | Un p95 de cuarenta segundos mientras la interfaz no ofrece progreso, ni cancelar, ni timeout. La gente vuelve a hacer clic y ahora se cobran dos peticiones. | Mantén la respuesta abierta más allá del timeout y comprueba que hay un estado visible, una forma de cancelar y ninguna petición duplicada al hacer un segundo clic. |
| El proveedor devuelve 429 o 503 | Los límites de uso y las caídas del proveedor son rutina, no excepción. Las apps que los tratan como imposibles muestran un error crudo o un spinner infinito. | Devuelve 429 y 503 desde el proveedor y comprueba que la app degrada a un mensaje con el que el usuario puede actuar. |
| Respuestas vacías, rechazadas o filtradas por seguridad | El modelo se niega, o salta el filtro de seguridad, y la interfaz pinta una burbuja vacía porque solo contempla el camino feliz. | Fuerza un rechazo y una respuesta vacía; comprueba que ninguno produce un mensaje en blanco ni un diseño roto. |
| La conversación pierde su contexto | El historial se recorta para caber en la ventana y el asistente olvida en silencio lo que se le dijo hace tres mensajes. Parece que el producto es tonto. | Lleva una conversación más allá del límite de contexto y comprueba que la app dice qué descartó en lugar de descartarlo en silencio. |
| Las llamadas a herramientas se disparan más de una vez | Un agente reintenta un paso cuya herramienta ya se ejecutó. Lo que esa herramienta hiciera (un correo, un cobro, una escritura) ocurre dos veces. | Haz que una llamada a una herramienta agote el tiempo después de haber tenido éxito y comprueba que el reintento no repite el efecto secundario. |
| La recuperación devuelve el documento de otro tenant | El almacén vectorial se filtra en el prompt en lugar de en la consulta, así que una recuperación que ignora la instrucción devuelve datos que el usuario no debería leer. | Consulta como un tenant un documento que pertenece a otro y comprueba que no está en el conjunto recuperado, y no solo que la respuesta no lo menciona. |
| El coste se dispara sin un techo | Sin límite por usuario, un bucle o una cuenta automatizada se convierte en una factura que nadie nota hasta que llega. | Llama repetidamente al mismo endpoint y comprueba que existe un límite: por usuario, por clave, por minuto. |
Seguridad
Pruebas de seguridad de LLM: la superficie que vale la pena revisar
Una función de AI suele llegar conectada a dos cosas que una función normal no tiene: un endpoint de pago y un componente que sigue instrucciones encontradas en lo que lee. Ambas amplían la superficie de ataque de formas para las que no se escribió una revisión estándar de seguridad de aplicaciones.
Ordenadas a continuación según con qué frecuencia se encuentran de verdad, que no es el orden en que se escribe sobre ellas.
- 01
Claves del proveedor en el bundle del cliente
Una clave de un proveedor de modelos incluida en el JavaScript del front-end, o accesible a través de una ruta proxy sin autenticación delante.
Cualquiera con las herramientas de desarrollador puede gastar tu cuota. Es lo más barato de comprobar de esta lista y lo más caro de pasar por alto.
- 02
Inyección de prompt a través del contenido
Instrucciones ocultas en algo que el modelo lee (un documento subido, una página extraída, un ticket de soporte, el cuerpo de un correo) y que el modelo luego sigue.
El atacante nunca toca tu cuadro de entrada. Todo lo que tu sistema ingiere es una entrada, la hayas diseñado como tal o no.
- 03
Inyección que llega a una herramienta
Instrucciones inyectadas que hacen que un agente llame a una herramienta: enviar un mensaje, escribir un registro, hacer una petición a una dirección interna.
Aquí es donde la inyección deja de ser una vergüenza y se convierte en un incidente. El alcance del daño es todo lo que el agente tiene permitido hacer.
- 04
Divulgación del prompt de sistema y de secretos
Conseguir que el modelo repita sus propias instrucciones, las definiciones de sus herramientas o fragmentos de la configuración que recibió.
El prompt de sistema suele contener reglas de negocio, endpoints internos y, a veces, credenciales que nadie quería poner ahí.
- 05
Recuperación entre tenants
Una recuperación que se delimita pidiéndole amablemente al modelo en lugar de filtrar la consulta.
Un prompt no es un control de acceso. Si el filtro vive en las instrucciones, una instrucción ignorada es una filtración de datos.
- 06
Salida renderizada como markup o código
Salida del modelo colocada en la página como HTML, o en una shell, una consulta o un eval.
Inyección clásica con una fuente nueva. El modelo ahora es una entrada no confiable, y un atacante puede influir en ella.
- 07
Gasto sin límite como denegación de servicio
Un endpoint que llama a un modelo de pago sin límite de peticiones, sin tope por cuenta y sin límite de tamaño en lo que acepta.
El ataque no consiste en tumbarte. Consiste en acumular una factura hasta que te tumbas tú mismo.
- 08
Lo que guardan los logs
Prompts y respuestas escritos en logs y analítica, incluido lo que un usuario haya pegado en ellos.
La gente pega credenciales de producción y registros de clientes en los cuadros de chat. Tu retención de logs ahora es una cuestión de protección de datos.
Lo que QA Spider automatiza, y lo que no
Expresado con la precisión suficiente para que puedas exigírnoslo.
Esto lo automatizamos
- Maneja tu producto en un navegador real, así que los casos de streaming, timeout, reintento, estado vacío y estado de error de arriba son pruebas de UI normales: se ejecutan de forma programada y en cada despliegue.
- Revisa la API que hay bajo la interfaz, incluidas las rutas que tu front-end llama para llegar a un modelo.
- Registra lo que falla como ticket en Jira, Azure DevOps, ClickUp, GitHub o Linear, con los pasos para reproducirlo y una captura de pantalla.
- Hace una pasada de seguridad superficial del sitio público: transporte y cabeceras de seguridad, flags de cookies, contenido mixto, exposición de formularios, DNS y protección contra suplantación de correo.
Esto no lo hacemos
- Por ahora no ofrecemos una suite automatizada de inyección de prompt ni de jailbreak. Si alguien te dice que su crawler lo hace de serie, pídele que te enseñe las aserciones.
- No evaluamos si una respuesta es correcta. Eso es un problema de evals, necesita tu ground truth y es una disciplina distinta de las pruebas de regresión.
Preguntas que hace la gente sobre probar apps de AI
- ¿En qué se diferencia probar una aplicación de AI de probar una app web normal?
- La interfaz es la misma; la salida no. Una app normal devuelve la misma respuesta dos veces, así que puedes hacer aserciones sobre ella. Un modelo devuelve algo distinto cada vez, así que las aserciones pasan a la forma y al comportamiento alrededor de la respuesta: que llega, que hace streaming, que se detiene, que falla de forma visible y que cuesta lo que debe.
- ¿Cómo se escribe una aserción cuando la salida cambia cada vez?
- Haz la aserción sobre el contrato, no sobre la prosa. Que la respuesta llegó dentro del presupuesto, que se parseó con el esquema que pediste, que citó un documento que el usuario puede ver, que un rechazo se muestra como un rechazo. Juzgar la redacción es un eval, que se ejecuta aparte de la suite de regresión.
- ¿Qué es la inyección de prompt y cómo se prueba?
- Instrucciones ocultas en contenido que tu sistema lee (un documento, una página web, un ticket) y que el modelo luego obedece. Se prueba plantando instrucciones en cada canal que llega al modelo y comprobando que el efecto nunca se produce: ninguna herramienta llamada, ningún dato devuelto, ningún prompt de sistema repetido.
- ¿Cuál es el problema de seguridad más común en los productos de AI?
- Los poco glamurosos. Una clave del proveedor accesible desde el navegador, un endpoint de modelo sin límite de peticiones y una recuperación delimitada por una instrucción en el prompt en lugar de un filtro en la consulta. Los tres son más baratos de encontrar que un jailbreak ingenioso y es más probable que estén ahí.
- ¿Puede QA Spider probar mi producto de AI?
- El comportamiento alrededor del modelo, sí: streaming, timeouts, reintentos, rechazos, estados de error, límites de peticiones y la API bajo la interfaz, probados en un navegador real en cada despliegue. Las suites automatizadas de inyección de prompt no las ofrecemos hoy, y preferimos decirlo a que lo descubras después.
- ¿Comprobáis si el modelo da respuestas correctas?
- No. La corrección necesita tu ground truth y pertenece a un arnés de evaluación que tú controlas y versionas junto a tus prompts. Las pruebas de regresión responden a otra pregunta: ¿lo que funcionaba ayer sigue funcionando tras el despliegue de hoy?
Apúntalo a tu producto de AI.
El comportamiento alrededor del modelo —streaming, timeouts, reintentos, rechazos, límites de peticiones y la API bajo la interfaz— probado en un navegador real, en cada despliegue.