No preguntes cuántos agentes tienes. Pregunta cuántas de sus respuestas dejas pasar sin revisar

La pregunta «¿cuántos agentes tienes?» suena en cada reunión sobre automatización. Es cómoda: tiene respuesta, se puede poner en una presentación y comparar con la del año pasado. Lo incómodo es que de esa respuesta no se desprende ninguna decisión: ni sobre el presupuesto, ni sobre contrataciones, ni sobre si se le puede dar al agente el siguiente proceso.

¿Por qué el adoption rate mide la intención y no el resultado?

El adoption rate es la proporción de empresas, equipos o empleados que empezaron a usar una herramienta. La métrica viene del SaaS, donde cumplía su función: si una persona entra todos los días al CRM y hace algo en él, lo está usando, y para evaluar la implantación con eso basta.

Con los agentes ese vínculo se rompe. Un agente al que un empleado le relee cada respuesta antes de enviarla y un agente que cierra las solicitudes solo, de principio a fin, cuentan los dos como implantados. En el informe dan la misma línea. En el presupuesto, no: el primero te cuesta el sueldo del empleado más la factura del modelo; el segundo, solo la factura del modelo.

Lo peor es que el adoption no se puede comparar ni siquiera dentro de una misma empresa. Un agente en soporte y un agente en gestión documental pueden tener la misma cobertura y una madurez opuesta, y ninguna reunión que se guíe por ese número lo va a ver.

Tasa de aceptación: ¿qué hay que contar exactamente?

La tasa de aceptación es el porcentaje de respuestas del agente que siguieron adelante sin intervención humana. «Adelante» significa una acción concreta: el correo se envió, el campo del CRM se escribió, el ticket se cerró, el documento se envió a procesar. El denominador son todas las respuestas que el agente emitió en ese proceso durante el período, incluidas las que no llegaron a la acción.

La métrica hay que formularla de modo que se pueda calcular sin una reunión. Si para obtener el número hay que reunir gente y ponerse de acuerdo sobre qué cuenta como corrección, todavía no tienes una métrica: tienes un tema de discusión.

¿Qué tres eventos no se pueden sumar en uno?

Los paneles suelen mostrar un solo número: «intervención humana». Dentro se esconden tres eventos distintos, y dos de ellos tienen un significado opuesto.

• Corrección. El agente entregó un resultado, una persona lo cambió y lo envió. Es un problema de calidad: el agente está cerca, pero no lo suficiente.
• Escalado. El agente se detuvo solo y le pasó el caso a una persona porque se sale de los límites que le marcaste. No es un fallo: es exactamente aquello por lo que pagaste.
• Infracción de los guardrails. El agente hizo o intentó hacer algo que no tenía permitido. Es un problema de seguridad, y no se arregla con cambios en el prompt.

Un agente con cero escalados no es mejor que uno con un diez por ciento. Lo más frecuente es que sea peor: no reconoce sus propios límites y lleva hasta el final lo que debía entregarle a una persona. Un cero en escalados es motivo para revisar si la regla de traspaso funciona siquiera, no para celebrar en la reunión.

¿Qué encontraron quienes ya lo midieron?

La medición pública de la tasa de aceptación con metodología abierta la hizo GitHub sobre su propio producto. En el estudio de Ziegler y colegas (2022, 2631 respuestas en la encuesta, 2047 de ellas cruzadas con la telemetría del IDE) se comprobó qué métrica de uso predice mejor la sensación de productividad del desarrollador. Ganó la proporción de sugerencias aceptadas: en la cohorte de participantes del estudio fue del 27%. La correlación en sí es débil (ρ = 0,24): la métrica resultó la mejor de las evaluadas, no fuerte por sí misma.

El segundo trabajo está más cerca de los agentes. En 2024, investigadores de Sierra AI mostraron con el benchmark τ-bench que un agente que resolvió una tarea con éxito una vez no necesariamente la va a resolver una segunda. Propusieron calcular pass^k, la probabilidad de superar la misma tarea k veces seguidas. El mejor agente de ese momento, sobre GPT-4o, lograba menos del 50% de éxito de media, y en ocho intentos consecutivos en el escenario de comercio minorista bajaba a cerca del 25%. Los modelos de aquella medición quedaron obsoletos hace tiempo, y no conviene repetir esos porcentajes como vigentes. Lo que conviene llevarse es la construcción: un éxito único en una demo no prueba la fiabilidad.

El tercer punto de referencia lo da METR, una organización de investigación sin ánimo de lucro que se dedica a evaluar modelos. En su trabajo de 2025 mide la capacidad de un modelo por la duración de la tarea que es capaz de completar por su cuenta, y publica esa duración para dos niveles de fiabilidad a la vez: 50% de éxito y 80%. La diferencia entre ambos es grande, y de autonomía se habla tomando el nivel más alto.

En cambio, no encontramos en fuentes públicas números sobre la proporción de control manual por función: cuántas respuestas se revisan a mano en el área legal y cuántas en ventas. Circulan por artículos de resumen con referencia a grandes firmas de análisis, pero detrás de ellos no se ve un informe primario que se pueda abrir y verificar. Por eso en este texto no hay porcentajes concretos.

¿Por qué «sin correcciones» es la exigencia correcta para un agente y la equivocada para un copiloto?

Además de la proporción de sugerencias aceptadas, los autores del mismo estudio calcularon la persistence: si la sugerencia aceptada seguía sin cambios después de 30, 120, 300 y 600 segundos. Esa métrica se correlacionó peor con la productividad. A los desarrolladores no les molestaba retocar una sugerencia si les daba un punto de partida útil.

La diferencia está en para qué hay una persona en el proceso. Con un copiloto está ahí por diseño: la herramienta entrega un borrador, el autor lo termina, y la corrección es parte normal del trabajo, no una pérdida. Con un agente que envía por su cuenta el correo al cliente o modifica un registro en el CRM, la persona está en el proceso por necesidad. Cada corrección suya significa que el trabajo se hizo dos veces, y las dos las pagaste tú.

¿Cómo se puede manipular esta métrica?

Los autores del mismo estudio de GitHub dejaron una advertencia directa contra convertir la tasa de aceptación en el único criterio de calidad. Un ejemplo del trabajo: si se parte una sugerencia por la mitad y se muestran las dos mitades seguidas, una aceptación se convierte en dos, y la métrica sube sin ningún beneficio para el desarrollador.

En los procesos con agentes eso mismo es todavía más fácil de hacer. Acota el alcance del agente a las solicitudes más sencillas y la tasa de aceptación va a saltar, porque lo difícil simplemente no le llega. Quita los guardrails estrictos y desaparecen las infracciones, porque ya no hay quien las registre. Reescribe la regla de escalado para que el agente no traspase nada, y los escalados caen a cero.

Por eso el número por sí solo no vale nada sin el denominador y sin la descripción del alcance. Junto con la tasa de aceptación, anota cuántas solicitudes entraron en total al proceso y qué parte de ellas llegó siquiera al agente. Una métrica que subió mientras caía la cobertura significa estrechamiento, no madurez.

¿Existe una tasa de aceptación normal?

No hay un número bueno universal, y cualquiera que te cite un estándar del sector para la tasa de aceptación te está citando un invento. La referencia no la da el sector, sino el coste del error en el proceso concreto.

• Coste del error alto, volumen bajo: aquí la baja autonomía es normal. Supervisa y no persigas el número: no tiene por qué crecer.
• Coste del error bajo, volumen alto: la baja autonomía significa que pagas dos veces, por el agente y por la persona que lo relee.
• Coste del error alto, volumen alto: aquí es donde la métrica vale más, porque cada punto porcentual se traduce en dinero, y aquí es donde conviene invertir en un set de pruebas.

La pregunta correcta no es «cómo subir la tasa de aceptación», sino «¿corresponde al coste del error en este proceso?». A veces la respuesta es dejar todo como está.

¿Por qué esta es una métrica de dinero y no de tecnología?

Haz la cuenta con tus propios números. Supongamos que el agente procesa doscientas solicitudes al día y que cada respuesta que no se aceptó de inmediato una persona la relee durante tres minutos. Con una tasa de aceptación del 30% hay que revisar ciento cuarenta respuestas: siete horas diarias, casi un puesto a jornada completa. Con el 70% quedan sesenta respuestas y tres horas. Los escalados están contados en este cálculo como gasto de tiempo a propósito: en esencia son correctos, pero de todos modos ocupan a la persona.

En esta aritmética la factura del modelo suele ser un error de redondeo. Se nota más porque llega en un solo archivo con una cifra grande, mientras que el sueldo de quien revisa está diluido en la masa salarial y no parece un gasto en IA. Pero lo que pagas es justamente ese sueldo. Esa misma lógica está detrás del plazo de amortización de la automatización, que analizamos aparte.

¿Qué no muestra la tasa de aceptación?

La métrica tiene sus límites, y conviene conocerlos antes de ponerla en un contrato.

No muestra la calidad de lo aceptado. Una persona puede aceptar sin mirar, sobre todo en el tercer mes, cuando el agente casi no se equivoca. Una tasa de aceptación alta sin control por muestreo solo significa que nadie está mirando. Se resuelve barato: una vez por semana una persona relee el cinco por ciento de las respuestas ya aceptadas, elegidas al azar.

No muestra lo que el agente hizo pasar fuera del monitor. Una respuesta puede ser formalmente correcta pero haberse obtenido de una manera que esquiva la supervisión; la tasa de aceptación va a contar ese evento como un éxito.

Y no reemplaza el governance. El registro de agentes, un presupuesto separado y un responsable designado para cada uno siguen siendo obligatorios, sin importar lo bien que se vea el número. La métrica de aceptación se suma a ese marco; no exime de él.

El propio Intercom, que construyó su facturación sobre una métrica parecida, escribe en sus materiales de 2026 que está pasando del binario «resuelto o no resuelto» a evaluar el resultado, porque el éxito dejó de ser binario. Ahí mismo da la tasa media de solicitudes resueltas sin intervención para su agente Fin: un 76% en más de 12 000 equipos (según la página a octubre de 2026). Es un autoinforme del proveedor, no una medición independiente, y hay que leerlo exactamente así.

¿Cómo tomar la línea base de la tasa de aceptación en dos semanas?

• Elige un solo proceso, no todos a la vez. Una métrica montada sobre toda la flota de agentes da un promedio del que no se desprende ninguna decisión.
• Define la unidad de medida: una respuesta del agente es una fila en el log. Acuérdalo por escrito antes de empezar.
• Registra tres campos por fila: si la persona cambió el contenido, si hubo escalado, si se activó un guardrail. El formato y el tono cuéntalos en un contador aparte.
• No toques el prompt ni la configuración durante dos semanas. Los cambios durante la medición destruyen la línea base con la que después vas a comparar la siguiente versión.
• Calcula las tres tasas y mira la distribución por día, no solo el promedio. Una caída en días concretos suele apuntar al tipo de solicitudes, no al modelo.
• Añade una revisión por muestreo: una persona relee el cinco por ciento de las respuestas aceptadas. Sin este paso, el número te halaga.

Dos semanas es el mínimo en el que se ve el ciclo semanal de carga. Si el proceso tiene estacionalidad mensual (cierre de período, informes), la línea base hay que tomarla durante más tiempo.

¿Cómo formular el umbral de aceptación en el contrato?

«El agente funciona» no es un criterio de aceptación: funcionar, funciona siempre; la pregunta es solo cómo. Ya analizamos qué cuatro bloques conviene dejar por escrito en el contrato de desarrollo de un agente de IA; el criterio de aceptación es el que más a menudo se formula de manera que resulta imposible de verificar.

Una formulación que tiene sentido en el SOW (el documento de alcance anexo al contrato) se ve más o menos así: sobre un set acordado de N solicitudes reales, la proporción de respuestas aceptadas sin correcciones de fondo no es inferior a X por ciento, con cero infracciones de los guardrails; la medición se hace del lado del cliente y con sus datos.

El valor de X no se toma de un benchmark del sector. Se fija a partir de tu propia línea base: primero dos semanas de medición sobre el proceso actual, después un umbral que tenga sentido justamente aquí. Y aparte conviene dejar asentado que el set de solicitudes de prueba lo prepara el cliente; de lo contrario, la aceptación se convierte en una demo cuyo guion escribió la misma parte que configuró el agente.

¿Qué hace Auspex durante la implantación?

Auspex toma la línea base antes de la puesta en marcha, no después de las quejas. Antes de que el agente reciba acceso a los datos de producción, se registra el estado actual del proceso y se acuerda el set de solicitudes sobre el que después se va a verificar la aceptación.

En este esquema el escalado no se penaliza: un agente al que se castiga por pasarle un caso difícil a una persona aprende rápido a no pasarlo. Y la revisión por muestreo de lo aceptado se queda en el proceso para siempre, no solo durante la puesta en marcha: es lo único que impide que el número se convierta en autocomplacencia.

Primeros pasos hacia tu propio número

• Toma un proceso donde ya trabaje un agente y fíjate si puedes siquiera sacar de los logs tres números: correcciones, escalados, infracciones. Si no puedes, esa es la primera tarea; suele ser un día de trabajo.
• Pregúntale a quien relee las respuestas del agente cuántos minutos al día le lleva. Multiplica por su tarifa y compara con la factura del modelo.
• Si justo ahora estás recibiendo el trabajo de un contratista, no firmes la aceptación basándote en una demo. Pide una medición sobre tu set de solicitudes, preparado por tu parte.

Si ya tienes un agente trabajando pero no tienes los tres números, toma la línea base en un proceso en dos semanas: tres contadores, un umbral salido de tus datos y una revisión por muestreo de lo aceptado. La medición del agente la hace Grow2.ai, nuestra división de IA, en formato de auditoría de IA gratuita; si las preguntas son más amplias y empiezan por el proceso y el CRM que está debajo del agente, es una auditoría de CRM y automatizaciones en Auspex. Los dos enlaces están abajo.