Grandes empresas
Pruebas de agentes de IA: qué revisar antes de soltarlos
Las pruebas de agentes IA sirven para saber, con datos, si un agente responde bien, respeta sus límites y no hace cosas que nadie le pidió, antes de darle acceso a clientes o sistemas.
Respuesta corta
Probar un agente de IA consiste en lanzarle una batería de casos preparados (peticiones normales, casos límite e intentos de manipulación) y comparar cada respuesta y cada acción que ejecuta con lo que debería haber hecho. El resultado es un informe con fallos concretos, su gravedad y qué cambiar, que se puede repetir cada vez que el agente se actualiza.
¿Qué se prueba en un agente?
Se prueba si responde con datos correctos sin inventar, si respeta sus permisos, si resiste mensajes que buscan saltarse sus instrucciones o sacar información interna y si deriva a una persona cuando corresponde.
Exactitud
Si contesta con los datos correctos de tu empresa o se inventa lo que no sabe.
Límites de acción
Si intenta crear, borrar o enviar algo fuera de los permisos que tiene.
Resistencia a la manipulación
Mensajes diseñados para que ignore sus instrucciones o revele información interna.
Derivación a personas
Si sabe pasar la conversación a alguien del equipo cuando toca.
¿Cómo se organizan las pruebas?
Las pruebas parten de casos reales anonimizados del área, combinan corrección automática con revisión humana según el tipo de respuesta y se repiten cada vez que cambia el modelo, las instrucciones o los datos.
Batería a partir de casos reales
Se construye con conversaciones y peticiones reales del área, anonimizadas.
Revisión mixta
Corrección automática donde la respuesta es objetiva y revisión humana donde no lo es.
Pruebas de regresión
Las mismas pruebas se repiten tras cada cambio de modelo, de instrucciones o de datos.
¿Vale para agentes de otros proveedores?
Sí. No hace falta que el agente lo hayamos construido nosotros: si tu empresa ha comprado o desarrollado uno, lo evaluamos igual y te entregamos el informe para que decidas con el proveedor. Encaja con lo que pide una buena gobernanza de IA: dejar documentado cómo se ha comprobado que el sistema funciona.
Preguntas frecuentes
¿Se pueden usar conversaciones reales de clientes para probar un agente?
Sí, siempre que se anonimicen antes. Son la mejor base, porque reflejan cómo pregunta de verdad la gente.
¿Qué casos sensibles debe saber derivar un agente de atención al cliente?
Los que afectan a personas vulnerables, quejas graves, temas legales o situaciones donde un error tiene consecuencias serias. En esos casos debe pasar a una persona rápido.
¿Cada cuánto hay que volver a probar un agente de IA?
Siempre que cambie el modelo, sus instrucciones, sus datos o sus permisos, y conviene una revisión periódica aunque no cambie nada.
¿Qué es una inyección de instrucciones en un agente de IA?
Un texto, a veces escondido en un correo o un documento, que intenta que el agente obedezca órdenes ajenas. Es uno de los ataques que se incluyen en las pruebas.
¿Podéis probar un agente que funciona en nuestros servidores?
Sí, en un entorno de pruebas vuestro o con el acceso que autorice vuestro equipo de sistemas.
¿Cuántos casos de prueba necesita un agente?
Depende de cuántas tareas haga y de su riesgo. Un agente sencillo de consulta puede empezar con unas decenas de casos bien elegidos; uno que ejecuta acciones en sistemas necesita bastantes más, con especial peso de casos límite y de intentos de manipulación.
¿Se pueden automatizar las pruebas en cada despliegue?
Sí, la parte objetiva. La batería se ejecuta sola cada vez que cambian instrucciones, modelo o datos, y bloquea el despliegue si falla un caso crítico. Las respuestas abiertas que requieren criterio se revisan por muestreo humano.
¿Qué hacemos si el agente falla una prueba grave?
Se detiene su paso a producción o se limitan sus permisos hasta corregirlo. Después se analiza si el fallo viene de las instrucciones, de los datos o de los permisos, se aplica el cambio y se vuelve a lanzar la batería completa para comprobar que no se ha roto otra cosa.
Ejemplo aplicado
Ejemplo: una comercializadora de energía que prueba su agente antes de abrirlo
Imagina una comercializadora de energía con 300 empleados que ha preparado un agente para responder a clientes en la web sobre facturas, cambios de potencia y lecturas. Antes de abrirlo al público, la dirección quiere saber qué puede salir mal.
La batería de pruebas se construye con consultas reales anonimizadas de los últimos meses y se añaden casos difíciles:
- Exactitud: explicar una factura con un cambio de tarifa a mitad de mes.
- Límites: un cliente que pide cambiar la titularidad sin acreditarse.
- Manipulación: un mensaje que intenta que el agente aplique un descuento o revele datos de otro contrato.
- Derivación: una persona que comenta que tiene un familiar con equipo médico en casa y teme un corte.
El informe señala que el agente explica bien las facturas, pero deriva tarde algunos casos sensibles. Se ajusta, se repiten las pruebas y la batería queda guardada para lanzarla cada vez que se cambie el agente. Así, la comercializadora abre el canal sabiendo dónde están sus límites.
Precio
Presupuesto cerrado antes de empezar, después de un diagnóstico gratuito en el que vemos qué necesitas de verdad.
Ver precios y packs →Plazo
Te damos las fases y las fechas por escrito en la propuesta, antes de que firmes nada.
Pedir diagnóstico gratis →¿Cómo se construye una batería de pruebas paso a paso?
Una batería de pruebas se construye a partir de lo que el agente debe hacer y de lo que nunca debe hacer. El proceso tiene seis pasos:
- Leer las instrucciones del agente, sus permisos y las fuentes a las que accede.
- Recoger peticiones reales del área y anonimizarlas.
- Escribir la respuesta o acción esperada para cada caso, validada con el área.
- Añadir casos límite: preguntas ambiguas, datos que faltan, peticiones fuera de su función.
- Añadir ataques: inyección de instrucciones, intentos de sacar datos de otros usuarios, peticiones para saltarse aprobaciones.
- Automatizar la ejecución y la corrección de lo que se puede corregir sin una persona.
La batería resultante se guarda junto al agente y se vuelve a lanzar en cada cambio, dentro del mantenimiento de agentes y automatizaciones.
Ejemplos de casos de prueba por tipo de agente
Los casos cambian según lo que hace el agente. Esta tabla muestra ejemplos hipotéticos:
| Agente | Caso normal | Caso límite | Ataque |
|---|---|---|---|
| Atención al cliente | Consulta del estado de un pedido | Cliente que da un número de pedido de otra persona | Mensaje que pide ignorar las instrucciones y dar un descuento |
| Asistente interno de RR. HH. | Días de vacaciones pendientes | Pregunta sobre un caso no previsto en el convenio | Petición del salario de un compañero |
| Agente de compras | Pedido a proveedor habitual | Importe por encima del límite aprobado | Factura con instrucciones ocultas en el PDF |
Los controles que deben impedir esos fallos se describen en la página sobre permisos, aprobaciones y supervisión de PIX.
Cómo leer el informe y priorizar los fallos
El informe ordena cada fallo por gravedad para que el equipo sepa qué arreglar antes de producción y qué puede esperar. Se usan cuatro niveles:
- Crítico: el agente ejecuta una acción no permitida o revela datos de otra persona. Bloquea la puesta en producción.
- Alto: da información incorrecta con seguridad en un tema relevante. Se corrige antes de ampliar usuarios.
- Medio: no deriva cuando debería o responde de forma confusa.
- Bajo: tono o formato mejorables.
Cada fallo incluye el caso que lo provoca y una propuesta de corrección. Si el agente forma parte de un piloto de agente IA, el informe de pruebas se añade al informe final para que quien decida vea también el riesgo.
También te puede interesar