| Llega un mail a soporte. Ramón Ramírez, un cliente reclamando una factura que no es suya. Es el aviso que pone en marcha a un agente de IA que busca en el CRM y encuentra dos clientes con ese mismo nombre. En el ERP aparece un tercero, mismos apellidos, otro correo. Encadena media docena de pasos de razonamiento sin hacer ni una pregunta. Al final decide, responde con una amabilidad impecable y deja la reclamación anotada (y cerrada) en la ficha del Ramón equivocado. La respuesta errónea tiene arreglo barato, el cliente contesta indignado, alguien pide perdón y a otra cosa. Lo que puede salir caro es un detallito. Esa anotación del agente acaba de nacer como un hecho en tu fuente de verdad. El siguiente proceso que pase por esa ficha la leerá como cierta. Estos ingredientes los tienes en tu empresa: homónimos, dos sistemas que no se hablan, un campo de escritura y agentes con instrucciones que cumplir. La información para saber cuál de los Ramones era el bueno no estaba en el dato. Estaba en la empresa. El dato cotidiano de tu actividad se ha escrito durante décadas para una persona que levanta el teléfono cuando tiene dudas. Las notas del CRM, los campos libres, la hoja de precios descansan sobre ese margen de seguridad. Caro en tiempo, pero eficaz. El agente de IA abarata este tipo de gestiones y las hace mejor que las automatizaciones básicas que le precedieron. Pero este nuevo lector hace algo que ninguno de los bots anteriores podía hacer a esta escala. Escribe lo que razona. En tu negocio esta situación se puede dar en los campos del CRM y del ERP; en un banco, en el expediente del cliente; en una aseguradora, en la anotación del siniestro. Un agente escribe su resultado y el siguiente lector, cada vez más a menudo otro agente, lo tomará como su fuente de verdad. Porque son sus instrucciones. El objetivo bien cumplido de un agente puede ser la entrada errónea del siguiente. |
Hasta ahora medíamos el riesgo en la calidad del dato: campo sucio, duplicado, Excel fantasma... El riesgo ahora también vive en anotaciones frescas, sin verificar, camino del siguiente proceso. ¿Y hasta dónde llega una anotación así? Un estudio reciente liderado desde la Universidad de Illinois grabó 200 tareas fallidas de agentes en entornos de prueba y las revisó paso a paso para localizar en cada una el error raíz (root-cause error), es decir, el paso más temprano que, corregido, habría evitado el fallo final. Ese fallo raíz arrastra las decisiones siguientes hasta tumbar la tarea entera. Es la factura de los Ramones encadenándose: la anotación da la factura por buena, la factura dispara el recordatorio de pago, el recordatorio lleva a la marca de moroso, la marca al bloqueo de pedidos... Y, además, la factura impagada original, la del Ramón Ramírez que aún no pagó, sigue sin cobrarse porque nadie lo ha identificado. Ya oigo al ingeniero de IT pidiendo umbral de confianza y un human in the loop. Donde hay señal de duda funcionaría, sí, pero la ambigüedad plausible no da señal de alerta per se. Los tres Ramones son entradas perfectamente válidas, sin probabilidad a la que ponerle umbral. El reto no es cuando el modelo está inseguro, sino cuando está seguro de lo incorrecto. |
Entonces, ¿cuánto se le puede delegar a un agente? Quien lo mide, lo mide en tiempo. El METR, un laboratorio que evalúa agentes, reunió 170 tareas técnicas (programación, ciberseguridad, razonamiento...), cronometró lo que tardaba una persona en resolver cada una y, con esa base, evaluó agentes. Toby Ord, filósofo de Oxford que trabaja en seguridad de la IA, observa que cada minuto de tarea (minuto humano, el que tardaría una persona) trae para el agente el mismo riesgo de fallar, sea el primero o el cuadragésimo. De ahí sale la «vida media» de un agente, que está definida como cuánto tiempo puede estar con una tarea antes de que sus opciones de éxito caigan por debajo del 50%. 
Esa es la parte que nos importa, porque para tratar la reclamación de una factura no nos vale acertar la mitad de las veces. Necesitamos algo cercano a 99 de cada 100. Según Ord, el tramo que se puede delegar con ese nivel de acierto es unas setenta veces más corto que la vida media. Es decir, un agente que resuelve el 50% de las tareas de una hora, si le exigimos el 99%, podríamos confiarle menos de un minuto. Es un promedio observado sobre ese determinado tipo de tareas, no una regla que se cumpla caso a caso, pero la curva dice mucho. Según METR, los mejores modelos de 2026 aguantan tareas de unas diez a dieciséis horas con la mitad de acierto. Exigiendo el 99%, con la cuenta de Ord, eso son unos ocho a trece minutos. La tarea de los Ramones cabe en ese margen, pero solo con modelos de frontera, que no son los que se suelen poner en este tipo de automatizaciones. Por eso debemos poner nuestros propios medios. 
La propagación de errores entre agentes vía campos compartidos no se ha medido todavía. Lo más cercano que tenemos es un estudio de Berkeley sobre equipos de agentes que podían hablarse entre sí, con más opciones de entenderse que dos que solo comparten los campos de una ficha. Aun así, un tercio de sus fallos eran de coordinación o alineamiento entre ellos. Si eso pasa cuando pueden preguntarse, mi conjetura es que un campo compartido no lo va a hacer mejor. La gran limpieza del dato heredado es el pozo donde llevan décadas muriendo los proyectos de datos por su coste, envergadura y ramificaciones. Ahora toca gobernar el punto de escritura, que es más barato, acotado y podemos arrancar el lunes que viene. Primero, el inventario: qué agentes tienen permiso de escribir en qué campos. El mapa completo, porque los agentes también escriben a través de accesos técnicos sin persona detrás, cuentas de servicio e integraciones que, quizás, nadie documentó. Después separa lo que cada agente lee de lo que escribe en los campos de los que dependa otro proceso, y pon al lado de cada permiso de escritura el nombre de quien lo autoriza. Empieza por los campos que mueven dinero, obligación o instrucciones sensibles. Y dale a cada campo escribible un contrato mínimo: qué formato y valores admite, quién es su dueño y un guardarraíl que rechace lo inválido y obligue a preguntar en lo dudoso, pero también ante determinadas circunstancias identificadas aunque el agente no dude. Y aun con todo registrado, falta un control real, una firma. Alguien que responda por cada escritura y un filtro que pueda rechazar las más sensibles. La firma se pone una vez, al autorizar el permiso, y cubre todo lo que se escriba con él: la persona solo entra cuando el filtro salta. Es el human in the loop que pedía el ingeniero de IT, con una condición. Un filtro que nunca rechaza, más que un control, es un registro con pretensiones. La métrica que importa de ese filtro es su tasa de rechazo. Cero rechazos durante meses significa que es como si no mirase nadie, por mucho que el reporte mensual lo celebre como eficiencia. Al homónimo no lo detecta el filtro; ve la misma ficha convincente que vio el agente. La señal de duda se construye fuera del modelo, con reglas sencillas. Dos candidatos válidos a la vez, o dos sistemas que se contradicen, y la escritura se para hasta que alguien pregunte. El agente da con los tres Ramones y se queda quieto. Ahora es el guardarraíl quien levanta el teléfono y la factura acaba en el Ramón que realmente la debe. A la confianza del modelo no se le pide nada, ya vimos de lo que es capaz. Te propongo un test que no te exige nada nuevo. Cuando compliance pregunta por un dato personal, tu equipo tiene que poder reconstruir quién accedió y para qué. Ese proceso ya existía antes de los agentes. Ahora añádele una casilla: ¿qué leyó y qué escribió el agente para resolver esto? Mide cuánto tiempo tardas en obtener una respuesta. Si te cuesta una tarde, tienes un sistema. Si te cuesta una semana, tienes un problema. Nadie tiene que releer cada ficha si alguien firmó cada escritura. Nos leemos. P.D. De Los Ramones, el bueno era Johnny.
Sergio Serrano Director de Marketing en EBIS Business Techschool | 
