Cómo evaluar un agente de IA antes de ponerlo en producción

Imagen ilustrativa del archivo visual de Pufers.

Un agente que resuelve una demostración puede fallar cuando recibe una solicitud incompleta, encuentra dos clientes con nombres parecidos o depende de un sistema que no responde. Antes de darle acceso al trabajo diario, conviene comprobar cómo se comporta en situaciones que tu equipo reconoce.

Para una empresa que prepara un piloto, proponemos una evaluación centrada en una decisión concreta: qué tareas puede asumir el agente y cuáles deben seguir bajo revisión. Esta guía reúne referencias técnicas y un método ilustrativo; no anuncia un lanzamiento ni presenta resultados de clientes.

Define qué cuenta como una tarea bien resuelta

Imagina un agente que clasifica solicitudes de soporte y prepara su derivación. Es un ejemplo ficticio. Una respuesta amable no demuestra que haya identificado al cliente correcto, elegido el área adecuada o conservado los antecedentes necesarios.

Escribe primero el resultado esperado. Por ejemplo: dejar una solicitud en la cola correcta, con los campos obligatorios completos y sin inventar información. Si falta un identificador, debe pedirlo; si el caso está fuera del alcance, debe derivarlo a la persona definida.

La guía de Anthropic sobre evaluación de agentes, publicada en enero de 2026, distingue el registro de ejecución del estado final del entorno. Aplicado a este ejemplo, revisa dónde quedó la solicitud, no solamente el mensaje que dice que fue derivada.

Construye una muestra que represente tu operación

Nuestra propuesta es reunir casos habituales y excepciones con quienes atienden el proceso. Usa datos ficticios o preparados conforme a las reglas de privacidad de tu empresa. No copies información sensible a un entorno de pruebas sin autorización.

Para cada caso, conserva la solicitud inicial, los datos disponibles, el resultado aceptable y el motivo de una eventual derivación. En el ejemplo de soporte, la muestra podría incluir:

• Una consulta completa que pertenece claramente a un área.
• Una solicitud sin el dato necesario para identificar al cliente.
• Dos registros similares que requieren aclaración.
• Un problema que involucra a más de un equipo.
• Una petición fuera del servicio contratado.

Evita elegir solo consultas bien redactadas. Las abreviaturas y los mensajes incompletos también forman parte de la operación. Reserva algunos casos que no se utilicen para ajustar las instrucciones, de modo que la revisión final no sea una repetición de ejemplos ya corregidos.

Acuerda cómo se calificará cada resultado

Prepara una pauta breve antes de ejecutar la prueba. Para este piloto, proponemos revisar tres preguntas: ¿la derivación es correcta?, ¿los antecedentes son suficientes?, ¿el agente respetó el alcance autorizado?

Define qué significa aprobar cada punto. “Buena respuesta” permite demasiadas interpretaciones. “Identificó el área de destino y conservó el número de solicitud” se puede comprobar. Cuando dos revisores discrepen, ajusta la pauta y registra el criterio acordado.

Anthropic describe evaluadores basados en código, modelos y revisión humana. También recomienda varias ejecuciones por tarea, porque el comportamiento puede variar. Una aplicación sencilla es automatizar la comprobación de campos y dejar los casos ambiguos a un responsable del proceso. No trates la calificación de otro modelo como una verdad independiente de revisión. Referencia técnica.

Separa los errores corregibles de los bloqueantes

Una categoría poco precisa puede requerir un ajuste. Consultar datos de una cuenta no autorizada exige detener el piloto y corregir el control de acceso. Promediar ambos errores en una sola nota ocultaría la diferencia.

OWASP identifica los permisos, las funciones y la autonomía excesivas como causas de acciones perjudiciales. Recomienda limitar capacidades y aplicar la autorización en los sistemas que ejecutan las operaciones.

Como criterio de prueba propuesto, cualquier acceso indebido observado debe bloquear la ampliación hasta investigar y corregir su causa. Que la muestra no detecte incidentes tampoco demuestra que el sistema sea seguro en todas las situaciones. La evaluación debe acompañar los controles técnicos, no reemplazarlos.

Compara el costo de resolver el mismo trabajo

La documentación de Google Cloud sobre diseño de sistemas con agentes propone considerar latencia, presupuesto y participación humana. También advierte que tareas predecibles pueden resolverse con alternativas sin agentes.

Para decidir en tu empresa, compara el piloto con el procedimiento actual usando los mismos casos. Nuestra propuesta es contabilizar el consumo técnico, los minutos de revisión y el trabajo necesario para corregir cada resultado. Anota además las tareas que quedaron sin resolver: excluirlas haría parecer más conveniente una solución que abandona los casos difíciles.

Antes de comparar cifras, verifica que ambas opciones entreguen una calidad aceptable. Después observa dónde se concentra el gasto. Si el equipo debe rehacer gran parte del trabajo, reducir el precio del modelo puede tener poco efecto en el costo total.

Conserva una prueba que puedas volver a ejecutar

Registra qué versión del modelo, instrucciones y herramientas utilizaste. Repite la muestra cuando cambie alguno de esos componentes y compara los errores por categoría, no solo el promedio.

El marco de gestión de riesgos de IA del NIST es voluntario y contempla el diseño, uso y evaluación de los sistemas. No constituye una certificación automática de un piloto.

El entregable útil es una decisión documentada: qué alcance se aprueba, qué queda pendiente, quién revisará las incidencias y en qué condiciones se suspenderá el uso. Con esa evidencia puedes ampliar gradualmente, corregir el proceso o concluir que una automatización más sencilla resuelve mejor la tarea.

Fuentes consultadas el 1 de noviembre de 2026.