Después de más de dos décadas en sectores donde una hora de caída puede costar cientos de miles de euros sin mencionar temas reputacionales, he aprendido que cuando, como CIO, subes a presentar, justificar y defender una inversión ante un comité, hay un lenguaje que funciona y otro que no. “Hemos ahorrado horas de trabajo” no funciona. “Hemos reducido un 35% la probabilidad de que este proceso crítico nos cueste dinero” sí funciona. La diferencia es la que hay entre un proyecto que sobrevive y uno que se cancela en la siguiente revisión de presupuesto.
El único número que importa: cuánto cuesta el impacto de fallos
La forma más directa de justificar agentes en términos financieros es algo que cualquier director financiero entiende sin traducción técnica: cuánto dinero pierdes cuando algo se rompe o sufres un problema grave. Probabilidad de que ocurra un problema grave, multiplicada por lo que cuesta cada hora que ese problema está activo — dinero que pierdes, multas que pagas, clientes que se van —, multiplicada por cuánto tardan en arreglarlo.
La mayoría de inversiones en agentes justificadas solo con productividad se ciñen a una parte menor del problema: el tiempo que dedicamos a tareas repetitivas. Lo que mueve la aguja es un agente que acorta cuánto dura un incidente porque lo detecta antes —hay datos contrastados de reducciones del 25 al 40% en tiempos de detección y resolución—. Lo que mueve la aguja es un agente que reduce la probabilidad de que un problema llegue a producirse. Y lo que mueve la aguja es un agente que limita el daño: corta el problema antes de que se extienda, activa protecciones automáticas, reduce hasta dónde llega el impacto.
No prometo cero incidentes. Lo que defiendo es medir y reducir lo que cuesta cada problema de forma sistemática, trimestre a trimestre. Eso ayuda a modelar la inteligencia artificial hacia un programa de mejora continua con resultados que se acumulan y se van midiendo.
Ejemplo:
Una entidad financiera europea con 500.000 clientes sufría caídas en su sistema de pagos una vez al trimestre.
- Coste medio: 150.000 euros por hora (negocio parado + penalizaciones regulatorias).
- Tiempo de detección: 45 minutos. Tiempo de resolución: 3,5 horas.
- Coste por incidente: 600.000 euros.
- Coste anual: 2,4 millones de euros.
La entidad implementó un agente de detección de anomalías enfocado exclusivamente en métricas de latencia y tasas de error.
- Inversión inicial: 180.000 euros.
- Coste operativo anual: 60.000 euros.
Resultado tras 12 meses:
- Detección de 45 min a 8 min
- Resolución de 3,5h a 1,8h
- Coste medio por incidente: de 600.000 a 280.000 euros.
- Reducción anual: 1,28 millones de euros.
- ROI del primer año: 433%.
Creo que es importante medir primero los incidentes actuales que sufres ahora, cuánto tardas en detectarlos, cuánto tardas en resolverlos y qué te cuesta cada hora. Calcular la mejora que esperas con el agente. Sumar el coste real de hacerlo funcionar: servidores, guardar los registros el tiempo que exige regulación, usuarios y permisos, y el equipo que lo controla y supervisa. Si los números no cuadran antes de empezar, el caso no se sostiene y es menos defendible.
La paradoja de la productividad que nadie mide
Hay un coste oculto que casi ningún piloto o POC (prueba de concepto) mide: la intensificación del trabajo. Un estudio reciente de ocho meses en una empresa tecnológica estadounidense documentó que los empleados que adoptaron IA generativa no trabajaron menos: trabajaron más. Las tareas se extendieron (“si puedo hacerlo con IA, ¿por qué no lo intento?”), las fronteras entre trabajo y descanso se difuminaron (un prompt rápido durante el almuerzo), y el multitasking se multiplicó (varios agentes corriendo en paralelo).
El resultado: mayor volumen de trabajo sin tiempo recuperado. Como resumió un ingeniero del estudio: “Pensabas que con IA trabajarías menos. Pero realmente no trabajas menos. Trabajas lo mismo o incluso más”.
Para un comité de dirección, esto importa porque invalida el argumento clásico de “ahorras X horas al mes por empleado”. Si esas horas se reinvierten inmediatamente en más tareas —sin descanso, sin reflexión, sin margen—, no estás ganando productividad sostenible. Estás acumulando deuda cognitiva que se paga con errores, burnout y decisiones apresuradas justo cuando más necesitas que la gente piense con claridad.
Por qué son más efectivos los agentes especializados
Voy a defender una idea que igual no es compartida: los agentes diseñados para hacer una tarea especializada y hacerla bien tienen tasas de éxito muy superiores a los generalistas. Al menos hoy en día.
“Especializado” no significa simple. Significa que el agente tiene un trabajo definido, unas reglas claras, unos controles reales y una forma objetiva de saber si lo está haciendo bien o mal. Gartner predice que más del 40% de los proyectos con agentes se cancelarán antes de 2027 por costes que se disparan o por falta de controles adecuados. Sin hablar de los datos… y la calidad de los mismos. La diferencia entre los que sobreviven y los que no casi nunca lo hacen es tecnológica y creo más asociable la disciplina operativa y sobre todo ESTRATÉGICA.
Los agentes especializados pueden validar con situaciones acotadas antes de escribir código. Se pueden revisar y auditar porque cada acción queda registrada. Pueden contener el impacto y pasear porque el daño máximo que pueden causar está limitado por diseño. Se puede gobernar porque hay reglas claras. Y se pueden mejorar porque trabajan contra objetivos estables con KPI claros y bien definidos.
Los agentes de propósito siguen un patrón predecible: alguien pide “una cosa más”, la definición de éxito se vuelve borrosa, el agente necesita acceder a más datos, y el coste crece más deprisa que el valor. Estudios recientes recientes indican que los sistemas que hacen uso de agentes pueden consumir hasta cinco veces más capacidad de cálculo por tarea que una implementación estándar. No es un dato teórico, es una factura real a final de mes.
Red Flag: si no puedes definir y delimitar qué datos lee el agente, qué puede hacer, cómo saber si lo hizo bien y cómo deshacerlo si falla, no es candidato para producción.
Dónde se esfuman los presupuestos
Cuando se cancela un proyecto de agentes, casi nunca es porque la tecnología no haya funcionado. Es porque se han dejado cinco partidas de gastos sin predecir:
- Calidad de los datos. Si la información es incompleta o contradictoria, el agente no se para. Produce resultados que parecen correctos pero no lo son. En procesos críticos, una respuesta convincente pero equivocada no es un fallo técnico: es un riesgo de negocio. En 2024, un tribunal de Columbia Británica dictaminó que una importante aerolínea internacional era responsable por información incorrecta proporcionada por su chatbot. Solo un tercio de las organizaciones tiene mecanismos para prevenir este tipo de errores. La adopción es cada vez mayor pero también este tipo de acciones lo será.
- Identidad y permisos. Cada agente necesita de una identidad propia, permisos mínimos y registro completo. Solo el 10% de las organizaciones gestiona bien la identidad de sus sistemas automatizados.
- Registro y trazabilidad. Qué hizo el agente, con qué autorización, a partir de qué información. Esto ocupa espacio, hay que guardarlo durante años y necesita control de acceso.
- Aislamiento. Si un agente toca sistemas críticos, necesita funcionar en un entorno controlado. Investigadores han documentado vulnerabilidades que permiten robar información sin que nadie se entere.
- Operación del día a día. Investigaciones recientes muestran que en organizaciones que escalan IA, una parte importante del equipo técnico acaba dedicado a tareas relacionadas con el propio mantenimiento de la IA. La operación no tiene un coste menor. Es el principal coste.
La mayoría de directivos en estudios recientes reconoce que los costes de poner agentes a funcionar superan con mucho lo esperado. El coste existe de todas formas. La decisión es si lo metes en el presupuesto desde el principio, con visibilidad, o si lo pagas después como deuda acumulada.
Cinco días para saber si un piloto merece vivir o morir en el intento
He desarrollado una prueba que usó antes de meter recursos reales. No sirve para demostrar que un agente “es capaz”. Sirve para saber si el caso de uso se puede operar en el mundo real.
- Día 1.- Definir OKR claros. Problema concreto y verificable. Qué datos puede usar. Qué acciones puede realizar. Y cuándo se para si algo va mal. Si no puedes definir cuándo parar, no estás listo para empezar.
- Día 2.- Comprobar el entorno. Calidad real de los datos (no la teórica, sino la que hay un lunes por la mañana). Accesos con permisos mínimos. Requisitos de registro definidos.
- Día 3.- Modelo MVP. Pocas fuentes, pocas acciones, mucho control. Si para funcionar hace falta “una fuente más” o “un permiso adicional”, eso se apunta como gasto extra.
- Día 4.- Medir sin compasión. Cuántas veces interviene una persona. Cuántas veces falla. Cuánto tarda. Si se salta reglas. Si no se puede medir…
- Día 5.- Decisión. Valor conservador. Coste real incluyendo datos, controles y operación. Decisión limpia: adelante, fuera o reducir alcance. Sin zonas grises.
Para finalizar
La productividad personal es un beneficio posible. Pero no aguanta un caso de inversión cuando metes los controles que exige una empresa seria. La inversión que sí aguanta es la que reduce lo que te cuesta cuando algo falla y mejora tu capacidad de respuesta y, sobre todo, las posibilidades de anticiparse a problemas o predecirlos. Con pruebas, con límites claros y con capacidad real de recuperación.
La pregunta que hemos de hacernos no es si nuestra empresa está usando agentes de inteligencia artificial. A estas alturas, prácticamente todas dicen que sí. La pregunta es si los que están funcionando podrían aguantar una auditoría seria mañana por la mañana. Si la respuesta no es un sí rotundo, la organización no tiene un programa de agentes. Tiene una colección de pilotos esperando a convertirse en algo incuestionable y, lo peor, nada controlable.
En la entrega final cerraremos el círculo con el papel del CIO: cómo diseñar supervisión que funcione a escala, con métricas, gobierno y arquitectura operativa para tener más agentes sin perder el control. Porque escalar no es desplegar más agentes. Escalar es gobernar bien los que ya tienes antes de añadir el siguiente.
Read More from This Article: Por qué la resiliencia es el único ROI defendible (y por qué los agentes especializados superan a los generalistas)
Source: News

