Cómo evaluar un piloto de IA antes de pasar a producción

Para evaluar un piloto de IA, comprueba qué tareas resuelve, cuánto trabajo deja a las personas y si respeta los límites acordados. Antes de darle acceso operativo a clientes o sistemas, necesitas resultados revisables sobre casos representativos y una decisión escrita sobre lo que puede hacer a continuación.

Esta guía sirve para cerrar un piloto con tu equipo o con un proveedor. Incluye una plantilla de aceptación para decidir entre ampliar el uso, mantener una prueba limitada o volver a trabajar el alcance. No necesitas elegir una herramienta de evaluación para empezar: primero debes acordar qué evidencia permitiría aceptar el trabajo.

TL;DR — Qué pedir antes de aprobar el piloto

• Define la decisión que debe resolver. Aceptar un asistente para preparar respuestas no equivale a autorizarle a enviarlas.
• Compara con el proceso actual. Registra calidad y trabajo humano sobre tareas equivalentes antes de atribuir una mejora al agente.
• Pide resultados por tipo de caso. Una media puede ocultar que todas las solicitudes ambiguas se resuelven mal.
• Revisa lo que hizo y lo que respondió. La explicación del agente debe corresponderse con sus consultas y acciones reales.
• Acuerda condiciones de parada. Un fallo relevante puede impedir ampliar el uso aunque otras pruebas salgan bien.
• Cierra con un alcance concreto. Anota la versión evaluada, los usos admitidos, los pendientes y quién revisará la siguiente etapa.

Qué debe demostrar un piloto de agente de IA

El piloto debe resolver una incertidumbre de tu proceso y dejar evidencia suficiente para decidir el siguiente paso. “La IA funciona” no define una entrega. “El equipo puede revisar y utilizar las respuestas sobre nuestro catálogo sin tener que reconstruirlas” sí permite formular pruebas.

Escribe primero qué ocurre hoy: quién recibe la solicitud, qué consulta, cómo comprueba el resultado y qué suele corregir. Microsoft recomienda capturar una referencia previa a la implantación y basar las decisiones de ampliar, ajustar o retirar agentes en resultados medidos. Microsoft: estrategia empresarial para agentes.

Nuestra propuesta es separar dos preguntas al encargar el piloto: si la tarea queda bien resuelta y si el equipo puede sostener la revisión que necesita. Un borrador rápido que obliga a comprobar cada dato desde cero puede tener poco valor operativo. Si el problema se resuelve mejor con reglas estables, revisa antes la comparación entre agentes de IA y automatización.

Qué pruebas debe entregar el proveedor

Pide un conjunto de casos con entradas, resultados esperados, ejecuciones y valoración del responsable del proceso. Conserva también los fallos. Un informe compuesto solo por ejemplos elegidos después de ver que salían bien no permite valorar el alcance completo.

Anthropic describe las evaluaciones como tareas con criterios de éxito y distingue cada intento de ejecución. Como las respuestas pueden variar, explica el uso de varios intentos para obtener una lectura más consistente. También señala que las valoraciones realizadas por modelos necesitan contrastarse con evaluadores humanos. Anthropic: evaluación de agentes.

Para tu encargo, agrupa las solicitudes según el trabajo real: habituales, ambiguas, incompletas y fuera de alcance. Pide al equipo operativo que aporte casos y reserve algunos para comprobar la entrega, sin utilizarlos todos para ajustar el agente. Decide cuántos repetir según la variabilidad observada y las consecuencias del error; esta guía no propone un tamaño de muestra universal.

Solicita además un registro de las herramientas utilizadas y del resultado obtenido. Google documenta por separado la evaluación de la respuesta final y la secuencia de llamadas a herramientas. Google Cloud: evaluación de agentes. En términos de negocio: hay que poder comprobar si el agente consultó la fuente adecuada y si terminó la tarea que afirma haber completado.

Plantilla para cerrar la aceptación del piloto

La aceptación debe vincular cada conclusión con una evidencia y una persona responsable. Puedes copiar esta tabla como documento de trabajo. Es una propuesta de Apogeo para organizar la entrega; no es una certificación ni una garantía de fiabilidad.

Debajo de la tabla, añade esta frase y complétala: “Aceptamos la versión ___ para ___, con revisión de ___; quedan excluidos ___ y volveremos a evaluar cuando ___.” Así evitas que una prueba limitada se convierta, por interpretación, en permiso para automatizar todo el proceso.

Si el agente va a escribir en un CRM, utiliza también la ficha para conectar un agente de IA al CRM. Esa guía concreta la integración; esta plantilla registra la decisión de aceptar su uso.

Cómo decidir si ampliar, ajustar o parar

Decide por los resultados de cada grupo de casos y por las consecuencias de los fallos, además del resultado agregado. Clasifica cada condición como comprobada, incumplida o pendiente de evidencia. “No lo hemos probado” debe seguir visible como incertidumbre.

Proponemos estas tres salidas para el cierre:

1. Ampliar de forma limitada: las condiciones del alcance revisado se cumplen y hay una persona que puede supervisar la siguiente etapa. Deja por escrito qué usuarios y tareas se añaden.
2. Mantener el piloto: el resultado es prometedor, pero faltan pruebas o una corrección concreta. Asigna responsable y condición de salida antes de seguir invirtiendo.
3. Parar y replantear: el agente incumple un límite relevante, exige demasiado trabajo de corrección o no resuelve la necesidad que justificaba el encargo.

Por ejemplo, si el alcance solo permite preparar mensajes, una prueba que consiga enviarlos debe bloquear la ampliación hasta corregir y volver a evaluar ese control. OWASP recomienda limitar funciones, permisos y autonomía, y exigir aprobación humana antes de acciones de alto impacto. OWASP: autonomía excesiva.

Para ordenar la inversión de la siguiente etapa, consulta qué partidas forman el coste de un agente de IA. La decisión de aceptación y el presupuesto deben referirse al mismo alcance.

Ejemplo: aceptar un asistente que consulta un catálogo

Un asistente puede quedar aprobado para preparar respuestas internas sin estar aprobado para responder directamente a clientes. Imagina un piloto que consulta un catálogo y redacta una propuesta para el equipo comercial. Es un ejemplo hipotético, no un resultado de un cliente de Apogeo.

En un caso de aceptación, una persona solicita información sobre una referencia que no figura en el catálogo vigente. El resultado esperado es señalar que falta información y dejar la respuesta pendiente de revisión. La evidencia incluye el catálogo consultado, el borrador y la ausencia de envío al cliente.

Si el asistente inventa una característica, el caso queda incumplido aunque la redacción sea clara. Si deriva correctamente la consulta, puede considerarse resuelto conforme al alcance: pedir ayuda era la conducta esperada. Conviene distinguir esa derivación prevista de una intervención necesaria para corregir un error.

Al cerrar el piloto, la empresa podría autorizar únicamente consultas internas sobre el catálogo probado. Incorporar otra fuente, otro idioma o el envío automático abriría un nuevo alcance que necesita evaluación. Esa decisión es más útil que calificar al agente simplemente como “aprobado”.

Preguntas frecuentes

Estas respuestas ayudan a convertir la revisión del piloto en una decisión operativa concreta.

¿Qué porcentaje de acierto necesita un agente para pasar a producción?

No hay un porcentaje universal que autorice cualquier uso. Acordad qué significa acertar para cada tarea y qué errores impiden continuar. Una respuesta con un matiz de estilo mejorable y una acción no autorizada tienen consecuencias distintas. Presenta los resultados por grupos y conserva los casos fallidos para revisarlos.

¿Cuántos casos hay que probar?

La cantidad debe responder a la variedad de tareas y al nivel de confianza necesario para la decisión. Empieza identificando las situaciones que no pueden faltar y registra qué queda fuera de la prueba. Para inferir fiabilidad estadística necesitas un diseño de evaluación específico; una colección pequeña de ejemplos no la demuestra.

¿Quién debería aceptar el piloto dentro de la empresa?

La aceptación debe incluir a quien responde por el proceso que va a utilizar el agente. El equipo técnico puede comprobar la integración, pero hace falta valorar también la utilidad de las salidas y la carga de revisión. Nuestra recomendación es nombrar un responsable de la decisión y registrar sus condiciones junto a la entrega.

¿Pedir revisión humana cuenta como un fallo?

Solo si contradice el comportamiento que se había acordado para ese caso. En una solicitud ambigua, pedir ayuda puede ser el resultado correcto. Registra por separado las derivaciones previstas y las correcciones provocadas por errores, junto con el trabajo que requieren. Así sabrás qué parte del proceso sigue dependiendo del equipo.

¿Hay que volver a evaluar cuando cambia el agente?

Sí: los resultados corresponden a la versión y al alcance que se probaron. Conserva los casos aceptados para comprobarlos tras cambios en instrucciones, herramientas o modelo, y añade ejemplos del trabajo reciente. Anthropic distingue estas comprobaciones de regresión de las pruebas destinadas a ampliar capacidades. El piloto no sustituye el seguimiento posterior.

Recomendación final

Antes de aceptar el piloto, pide una sesión de revisión basada en casos y termina con el alcance aprobado por escrito. Deben participar quien construye el agente y quien responde por el proceso. Si no podéis explicar por qué un caso pasa o falla, aclarad primero el criterio; añadir más pruebas con una regla ambigua no resuelve esa decisión.

En resumen

• Define qué vas a aceptar. La autorización debe describir tareas y usuarios concretos.
• Recoge una referencia previa. Compara el piloto con el trabajo que ya realiza el equipo.
• Examina las excepciones. Los casos difíciles deben aparecer en el informe, aunque empeoren la media.
• Comprueba la ejecución. La respuesta final tiene que corresponderse con lo que ocurrió.
• Cuenta el trabajo humano. Revisar, corregir y atender derivaciones forma parte de la operación.
• Conserva la incertidumbre visible. Una condición pendiente de prueba no está aprobada.
• Decide el siguiente alcance. Amplía, ajusta o para con un responsable y evidencia documentada.

Fuentes y referencias

Las fuentes respaldan los principios de evaluación y control; la plantilla de aceptación y el ejemplo son propuestas de Apogeo. Consultadas el 6 de noviembre de 2026.

• Anthropic: Demystifying evals for AI agents.
• Google Cloud: Evaluate Gen AI agents.
• Microsoft: estrategia empresarial para agentes.
• OWASP: Excessive Agency.

El siguiente paso

Trae el proceso que quieres probar y la decisión que necesitas tomar al terminar el piloto. En el servicio de agentes de IA para empresas podemos definir el alcance, preparar la evaluación y desarrollar la solución. Cuéntanos qué necesita comprobar tu equipo.