Escenario ilustrativo. El proveedor enseña el agente de soporte: responde bien a seis preguntas y la sala aplaude. Se factura el hito. Tres semanas después, la responsable de atención al cliente dice que aquello «no está terminado» porque se pierde con los pedidos devueltos; el proveedor contesta que eso nunca estuvo en el alcance. Ninguno miente. Nadie escribió qué quería decir «terminado».
La tesis en una línea: un agente de IA no se entrega cuando funciona en la demo, sino cuando cumple unos criterios de aceptación escritos antes de empezar y firmados por alguien del negocio. Sin ese papel, el proyecto no termina nunca o termina por cansancio.
¿Qué son los criterios de aceptación de un agente de IA y por qué no basta la demo?
Los criterios de aceptación de un agente de IA son las condiciones medibles que el agente debe cumplir, sobre casos reales y durante un periodo acordado, para que el cliente lo dé por entregado. En un formulario web, «funciona» es binario: o guarda el dato o no. Un agente responde distinto cada vez y acierta una proporción de las veces, así que «funciona» siempre es una pregunta incompleta: ¿con qué frecuencia, sobre qué casos y con qué coste cuando falla?
La demo no contesta a ninguna de las tres, porque la elige quien vende: los mejores casos, en el mejor día (lo desarrollamos en la demo usaba tus mejores casos). Y el problema de fondo no es técnico. El análisis de RAND sobre por qué fracasan los proyectos de IA, basado en entrevistas con ingenieros y científicos de datos, sitúa entre las causas más habituales que el problema a resolver se entendió o se comunicó mal (RAND, 2024). Los criterios de aceptación son esa conversación puesta por escrito, con fecha y con nombres.
¿Qué debe incluir el acta de aceptación de un agente?
Seis cosas, y las seis se pueden escribir en una página. Si alguna no cabe, es que todavía no sabéis qué estáis comprando.
- Casos de prueba que salen de tu operación, no del proveedor. Un conjunto cerrado de casos reales, con los difíciles y las excepciones dentro, congelado antes de empezar. Si el conjunto cambia durante el proyecto, el resultado no es comparable. Cómo se evalúa: evaluar la calidad de los agentes de IA y evals: sin medir no sabes si funciona.
- El error tolerado, por tipo de error. No un «95 % de acierto» global: equivocarse en el tono no cuesta lo mismo que prometer un reembolso que la política no permite. Por qué la media engaña: el 95 % de acierto no basta en producción.
- Qué hace cuando no sabe. Criterios de escalado: en qué situaciones pasa a una persona, con qué contexto y en cuánto tiempo. El diseño está en qué hace un agente cuando no sabe.
- Qué puede tocar y hasta dónde. Qué sistemas lee, cuáles escribe y qué acciones exigen aprobación humana, según los niveles de autonomía de un agente.
- Cómo se mide y durante cuánto tiempo. Un periodo de prueba en producción real, supervisado, con la métrica definida de antemano. Qué medir sin autoengañarse: medir el rendimiento de tus automatizaciones.
- Quién firma. Un nombre y un cargo del negocio, no un departamento.
¿Quién tiene que firmar que el agente está terminado?
La persona que sufre las consecuencias si falla: el dueño del proceso. No quien compra la tecnología ni quien la construye. El proveedor propone los criterios y demuestra que se cumplen; el negocio decide si le valen. Si firma solo el área de tecnología, lo que se acepta es que el sistema está en pie, no que el trabajo se hace bien.
La firma incluye el derecho a rechazar. Un acta que solo se puede firmar es un trámite. Y conviene una segunda firma, la de quien va a mantener el agente después: aceptar algo que nadie sabrá operar es dejar el problema para el mes siguiente (ver quién mantiene los agentes de IA cuando ya están en producción).
| Qué se escribe antes de empezar | Qué pasa si no se escribe | Quién lo define |
|---|---|---|
| Conjunto de casos reales | El proveedor prueba con lo que sabe que funciona | El negocio aporta, el proveedor ayuda a cubrir huecos |
| Error tolerado por tipo | Una media bonita esconde el error caro | El negocio, según lo que le cuesta cada fallo |
| Cuándo escala a una persona | El agente improvisa justo donde no debe | Negocio y proveedor, juntos |
| Permisos y acciones con aprobación | Se descubre el alcance real el día del incidente | Negocio y responsable de seguridad |
| Periodo de prueba y métrica | «Terminado» se mide por sensaciones | El negocio, con el proveedor como consultor |
| Firma | El proyecto no termina o termina por cansancio | Un cargo del negocio con nombre propio |
¿Qué pasa si no hay criterios de aceptación?
Hay dos finales posibles y ninguno es bueno. En el primero, el proyecto no termina nunca: cada petición nueva se vive como un fallo del agente, el proveedor siente que el alcance crece sin límite y el cliente siente que paga por arreglar lo que ya compró. En el segundo, termina por cansancio: se da por bueno porque nadie aguanta una reunión más, y el agente entra en producción sin que nadie conozca su tasa de error real.
El segundo final es el peor, porque parece un éxito. Es la versión contractual de lo que explicamos en por qué fracasan los proyectos de automatización con IA: el proyecto no falla en la demo, falla en el vacío entre lo que cada parte daba por entendido.
¿Cómo se redacta un criterio que se pueda comprobar?
Con tres ingredientes: un conjunto de casos, un umbral y una condición de fallo que no admite negociación. Un ejemplo de redacción (las cifras son ilustrativas; las tuyas las fijas tú, según lo que te cueste cada error):
Fíjate en la asimetría: el umbral se pacta, la condición de fallo no. Hay errores que se toleran en una proporción y errores que no se toleran. Escribirlo evita la discusión más cara del proyecto, la que ocurre cuando el fallo ya ha llegado a un cliente.
¿Cuándo no hace falta un acta formal?
Cuando es un prototipo declarado como tal, un experimento interno sin clientes ni datos personales, o un caso en el que equivocarse es barato y reversible. Ahí basta una frase y una fecha: «esto es una prueba y se revisa el día X». En cuanto el agente toca clientes, dinero o datos personales, la página se escribe.
Si ya tienes un agente en marcha y nadie recuerda qué se aceptó, el momento de escribir el acta es ahora, antes de la siguiente ampliación. Y si estás a punto de contratar uno, evaluar la calidad de los agentes de IA es el trabajo que convierte esta página en un conjunto de casos y un umbral que se pueden ejecutar.
La línea para llevarte: un agente no está terminado cuando impresiona, sino cuando alguien del negocio, con nombre y cargo, firma que cumple lo que se escribió antes de empezar.
Fuentes (consultadas el 27 de octubre de 2026): «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed», RAND Corporation (2024). El escenario del inicio y las cifras del ejemplo son ilustrativos, no un caso real.