Evalúe la prueba de concepto de un agente de IA con criterios de éxito escritos antes de construirlo, sobre un conjunto fijo de casos reales que incluya los difíciles. Mida la precisión, el coste por tarea y la latencia, compruebe a qué datos y herramientas puede acceder y cómo falla, y escale solo cuando los resultados se sostengan fuera de la demo.
Una demo convincente no es una prueba
Una demo muestra al agente de IA en su mejor versión, porque se ejecuta con ejemplos que quienes lo construyeron eligieron y ensayaron. La pregunta antes de escalar es otra: ¿con qué frecuencia hace bien el trabajo real, cuánto cuesta cada tarea y qué pasa los días en que se equivoca?
Trate la prueba de concepto como un experimento que termina en una decisión: escalar, cambiar o parar. Esa decisión necesita criterios escritos antes de que lleguen los resultados; si no, casi cualquier resultado puede leerse como prometedor.
Escriba los criterios de éxito antes de construir el agente
Defina qué significa «suficientemente bueno» para el negocio y conviértalo en cifras que se puedan medir. Para un agente que clasifica solicitudes de soporte, podría ser el porcentaje de solicitudes enviadas al equipo correcto, el porcentaje que rechaza con acierto y el tiempo que una persona dedica a revisar cada una.
- Tasa de éxito en casos realistas, con una definición escrita de lo que es un resultado correcto
- Los errores que puede tolerar y los que no, como una respuesta equivocada enviada a un cliente
- Coste por tarea completada, incluidos el uso del modelo y el tiempo de la persona que revisa el trabajo
- Un tiempo de respuesta adecuado al flujo de trabajo, según si alguien espera la respuesta o no
- La referencia de partida: cuánto tardan hoy las personas en hacer la tarea y con qué frecuencia la hacen bien
Pruebe con un conjunto de evaluación fijo creado a partir de casos reales
Reúna entradas reales de su propio historial, anote el resultado correcto de cada una y mantenga el conjunto fijo. Incluya casos fáciles, ambiguos, poco frecuentes y algunos que el agente debería rechazar. Un conjunto pequeño de casos bien elegidos le dice más que uno grande de casos fáciles.
Ejecute el agente sobre todo el conjunto cada vez que cambien el prompt, el modelo, las herramientas o los datos, y compare los resultados con la ejecución anterior. Las respuestas de un modelo varían de una ejecución a otra, así que ejecute cada caso más de una vez y fíjese en la consistencia, no solo en la mejor respuesta. Mantenga los casos fuera del prompt y de cualquier ejemplo que vea el agente, o la puntuación lo favorecerá.
Revise también cómo puntúa. Las comprobaciones automáticas funcionan con salidas estructuradas. El texto libre suele necesitar a una persona, o un segundo modelo cuyos juicios haya comparado con los de una persona en una muestra.
Mida el coste y la latencia con el volumen que espera
Una prueba de concepto que gestiona unas pocas decenas de solicitudes al día puede ocultar costes que pesan cuando son miles. Registre las llamadas al modelo, los tokens y las llamadas a herramientas por tarea, y el tiempo que tarda cada una. Los agentes que entran en bucle, reintentan o leen documentos largos pueden costar mucho más que la media con ciertas entradas, así que estudie los casos más lentos y más caros, no solo la media.
Después, proyecte el coste con el volumen previsto y compárelo con lo que cuesta hoy el trabajo, incluido el tiempo que las personas seguirán dedicando a la revisión. Fije límites estrictos por tarea en pasos, tokens y tiempo, para que una sola entrada problemática no dispare la factura. El OWASP Top 10 for LLM Applications recoge este riesgo como consumo ilimitado.
Diseñe la revisión humana con intención y mídala
La revisión humana forma parte del diseño, no es una red de seguridad temporal. Decida qué acciones puede realizar el agente por su cuenta, cuáles solo puede proponer y cuáles no debe realizar nunca. Todo lo irreversible o visible para los clientes, como enviar un mensaje, modificar un registro o gastar dinero, debería esperar la aprobación de una persona hasta que el agente tenga una larga trayectoria.
Mida la propia revisión: cuánto tarda, con qué frecuencia los revisores cambian el resultado y con qué frecuencia aprueban sin revisar de verdad. Si revisar lleva casi tanto tiempo como hacer la tarea, el agente todavía no ahorra tiempo. Si su caso de uso pudiera considerarse de alto riesgo según el Reglamento de IA de la UE, la supervisión humana efectiva es una obligación legal en virtud del artículo 14, no una preferencia de diseño, así que implique pronto a sus asesores jurídicos.
Fije los límites de datos y de seguridad antes de escalar
Escalar trae más datos, más usuarios y más herramientas, y es entonces cuando los límites débiles empiezan a pesar. El OWASP Top 10 for LLM Applications sitúa la inyección de prompts en primer lugar: un texto que lee el agente, como un correo, una incidencia o una página web, puede contener instrucciones que lo desvíen. También incluye la agencia excesiva, es decir, más funciones, permisos o autonomía de los que requiere la tarea. Resuelva estos puntos antes de que crezca el piloto.
- Qué datos puede leer el agente y si se envían datos personales o confidenciales a un proveedor de modelos, con qué contrato y qué condiciones de conservación
- Qué herramientas puede llamar, con los permisos más restringidos y credenciales propias para cada agente
- Qué puede modificar, y si cada cambio se puede rastrear y revertir
- Qué se registra: cada llamada a herramientas con sus entradas y salidas, sin filtrar datos personales
- Cómo se mantienen los datos de cada cliente o equipo separados de los del resto
Estudie cómo falla y después decida
Antes de decidir, lea los fallos, no solo la puntuación. Clasifíquelos por tipo: respuestas erróneas dadas con aplomo, rechazos correctos, pasos omitidos, uso incorrecto de herramientas, tiempos de espera agotados. Un agente que falla pidiendo ayuda es mucho más fácil de desplegar que uno que falla en silencio con una respuesta verosímil.
Después, decida. Escale si se cumplen los criterios en el conjunto de evaluación y los fallos restantes son de los que su proceso puede absorber. Reduzca el alcance si el agente solo rinde bien en una parte de la tarea. Pare si no supera la referencia de partida y guarde el conjunto de evaluación para el siguiente intento. Nuestros proyectos de agentes de IA siguen la misma secuencia: una tarea, ejemplos reales, revisión por parte de su equipo y más alcance solo cuando el agente se ha ganado la confianza. Si tiene una prueba de concepto que evaluar, puede describirla en nuestro formulario «Empezar un proyecto».
Puntos clave
- Escriba los criterios de éxito y una referencia de partida antes de construir el agente, para poder juzgar el resultado con honestidad.
- Pruebe con un conjunto fijo de casos reales, incluidos los difíciles y los ambiguos, y vuelva a ejecutarlo tras cada cambio.
- Mida el coste por tarea y la latencia con el volumen previsto, mirando los peores casos además de la media.
- Diseñe la revisión humana con intención y mida cuánto tarda y qué detecta.
- Fije los límites de datos, herramientas y registros antes de escalar, porque la inyección de prompts y la agencia excesiva son riesgos conocidos.
Preguntas frecuentes
¿Cuántos casos necesita el conjunto de evaluación de un agente de IA?
No hay un número fijo. Necesita casos suficientes para cubrir las principales variantes de la tarea, los difíciles y ambiguos, y los que el agente debería rechazar. Empiece por los que pueda etiquetar con cuidado y añada cada fallo real que encuentre después.
¿Puede otro modelo puntuar los resultados del agente?
Sí, para las salidas de texto libre difíciles de comprobar automáticamente, pero solo después de haber comparado sus juicios con los de una persona en una muestra de casos. Vuelva a comprobar esa concordancia cada vez que cambie el modelo o el prompt.
¿Cuándo hay que detener la prueba de concepto de un agente de IA?
Cuando no supera la forma actual de hacer la tarea según sus criterios de éxito, o cuando la revisión que necesita cuesta tanto tiempo como el que ahorra. Una parada clara es un resultado útil: guarde el conjunto de evaluación, porque un modelo más reciente o una tarea más acotada podrían superarlo más adelante.