Por qué las automatizaciones IA colapsan a los 90 días (y casi nunca es culpa del modelo)

El patrón que nadie quiere reconocer

Hay un ciclo que se repite constantemente en el mundo de las agencias de automatización IA. La agencia construye un demo impecable. El cliente lo aprueba entusiasmado. Se firma el contrato. Se entrega el desarrollo. Y tres meses después, silenciosamente, deja de funcionar.

Nadie abre un ticket. Nadie llama. El equipo simplemente empieza a trabajar alrededor del problema, añadiendo pasos manuales aquí y allá hasta que la automatización que iba a ahorrarte horas se convierte en una capa adicional de complejidad. Para cuando alguien en dirección se da cuenta, el daño ya está hecho.

Lo llamativo es que el modelo de IA casi nunca es el culpable. El problema estaba ahí desde el principio, enterrado en los datos.

El demo funciona con datos limpios. La producción no está limpia

Cuando una agencia construye un agente IA en fase de demo, trabaja con datos preparados: estructurados, consistentes, sin duplicados. El agente responde como se espera porque los inputs son predecibles.

La realidad de una pyme es otra cosa. El CRM tiene cinco registros distintos del mismo cliente con nombres escritos de formas diferentes. Las hojas de cálculo mezclan estados como pendiente, PENDIENTE, en espera y pdte para referirse exactamente a lo mismo. Los campos de fecha tienen formatos distintos según quién los rellenó. Hay columnas que ya nadie sabe para qué sirven.

El agente llega a producción, encuentra ese caos y empieza a degradar. No lanza un error. No manda una alerta. Simplemente va dando respuestas cada vez menos precisas, tomando decisiones sobre datos incorrectos, hasta que alguien percibe que algo no va bien sin saber exactamente qué.

Este es el fallo silencioso: el más peligroso porque es invisible hasta que ya ha causado daño real.

Por qué el fallo silencioso es peor que el fallo ruidoso

Los sistemas de automatización más tradicionales tienen una ventaja que a menudo se infravalora: cuando algo no encaja, fallan en voz alta. Una validación de esquema que no encuentra el formato esperado lanza un error inmediatamente, en la semana uno, cuando arreglarlo cuesta poco.

Un agente IA no funciona así. Si recibe datos con un formato inesperado, no se rompe: intenta interpretarlos. A veces lo hace bien. A veces no. Y como no hay error visible, nadie investiga. El problema se acumula durante semanas hasta que la degradación es tan evidente que ya no hay forma de ignorarla.

El patrón que se observa en equipos con experiencia real en producción es consistente: las automatizaciones que sobreviven meses sin intervención tienen dos características comunes. La primera es validación de entrada que rechaza activamente cualquier desviación del formato esperado, en lugar de intentar procesarla. La segunda es un punto de revalidación periódica contra datos reales, no contra el dataset de prueba original.

Dicho de otra manera: el sistema tiene que quejarse cuando algo está mal, y tiene que verificar regularmente que el mundo real sigue pareciéndose a lo que se construyó.

La limpieza de datos no es parte del desarrollo. Es una fase previa

Aquí está la conclusión incómoda que las agencias serias ya han asumido: gran parte de lo que se vende como automatización IA es en realidad un proyecto de limpieza de datos con un chatbot encima. El chatbot es la parte fácil. Los datos son el problema.

Las agencias que absorben la limpieza de datos dentro del presupuesto de desarrollo están, básicamente, subvencionando el caos del cliente con sus propios márgenes. Y cuando los márgenes desaparecen, desaparece también la calidad del trabajo.

La alternativa —que es la que funciona— es tratar la auditoría y limpieza de datos como una fase contractual explícita, con su propio alcance y su propia línea en el presupuesto. Hay un efecto secundario útil: mostrarle al cliente cómo lucen sus datos en bruto, antes de cualquier automatización, cambia completamente la conversación. Deja de ser una promesa técnica y se convierte en un diagnóstico real de dónde está parado su negocio.

Otro efecto, más directo todavía: hacer una auditoría de datos seria al inicio filtra a los clientes que no están preparados. Eso puede parecer perder oportunidades. En realidad es evitar proyectos condenados desde el primer día.

Quién realmente sabe cuándo se rompe una automatización

Hay un detalle que los desarrolladores con experiencia en ERP y sistemas empresariales conocen bien: cuando una automatización falla, la dirección es la última en enterarse. Y a menudo nunca llega a enterarse, porque el equipo operativo ya ha construido un proceso alternativo alrededor del problema.

La persona que sabe que algo cambió es quien usa el sistema cada día. Es quien nota que desde que se actualizó una configuración el fin de semana, su proceso ya no cuadra. Es quien lleva semanas haciendo ajustes manuales para compensar algo que antes funcionaba solo.

Esto tiene una implicación directa para cualquier proyecto de automatización: el acceso a usuarios finales no es opcional. No es suficiente con hablar con el responsable de área en la reunión de kickoff. Hay que tener un canal activo con quienes usan el sistema en el día a día, porque ellos detectan las roturas antes que cualquier monitor técnico.

Cómo estructurar un contrato que no te deje tirado a los tres meses

Si estás evaluando contratar automatización IA, la estructura del contrato importa tanto como la calidad técnica del desarrollo. Estas son las tres fases que debe incluir cualquier propuesta seria:

• Auditoría y limpieza de datos: fase previa al desarrollo, con alcance propio. Aquí se mapean las fuentes de datos, se identifican inconsistencias, se define el modelo de datos limpio sobre el que correrá el agente. Sin esta fase, cualquier presupuesto de desarrollo es especulativo.
• Desarrollo e implementación: el proyecto en sí, construido sobre datos ya estructurados. Con validación de entrada definida desde el inicio, no como añadido posterior.
• Mantenimiento recurrente con SLA: no un soporte reactivo cuando algo explota, sino un servicio con revisiones periódicas, revalidación contra datos reales y reportes sobre anomalías detectadas. Esto es un coste mensual o trimestral, no un extra opcional.

Una agencia que no menciona mantenimiento recurrente en su propuesta inicial no está planteando un servicio: está planteando una entrega puntual. La diferencia es crítica.

Qué métricas pedir para detectar degradación antes de que sea un problema

La degradación silenciosa se puede anticipar si sabes qué mirar. En un contrato de automatización IA bien planteado, deberías poder exigir acceso periódico a información como:

• Validaciones de entrada rechazadas: cuántos registros llegaron al agente con un formato o estructura que no coincidía con lo esperado. Un aumento sostenido en este número es señal de que algo cambió en los datos de origen.
• Tasa de ejecuciones completadas frente a ejecuciones revisadas manualmente: si el equipo empieza a corregir outputs del agente con frecuencia creciente, hay degradación aunque no haya errores técnicos.
• Anomalías en datos de entrada: valores fuera de rango, campos vacíos donde no debería haberlos, nuevos valores que el agente no había visto durante el entrenamiento.

Estos indicadores no requieren expertise técnico para interpretarlos. Un informe mensual con estas tres métricas, bien presentado, es suficiente para que cualquier responsable de operaciones detecte a tiempo si algo está empezando a torcerse.

El ángulo que pocas agencias mencionan: RGPD y datos incorrectos

Hay una dimensión del problema de datos sucios que raramente aparece en las propuestas de automatización IA: si el agente trabaja con datos de clientes, la calidad de esos datos no es solo una cuestión de rendimiento técnico. Es también una cuestión de cumplimiento.

El RGPD establece el principio de exactitud: los datos personales deben ser precisos y, cuando sea necesario, actualizados. Un agente que opera sobre datos duplicados, desactualizados o incorrectos —y que toma decisiones o genera comunicaciones a partir de ellos— puede estar vulnerando derechos sin que nadie se dé cuenta, precisamente porque el fallo es silencioso.

Esto añade otro argumento para tratar la auditoría de datos como una inversión, no como un coste. No limpiar los datos antes de automatizar no es solo un riesgo operativo. Puede ser un riesgo legal.

La pregunta que vale hacerse antes de firmar

Antes de comprometerte con cualquier propuesta de automatización IA, hay una pregunta concreta que puedes hacer a la agencia: ¿qué pasa con vuestros desarrollos seis meses después de la entrega, sin que los toquéis?

La respuesta que quieres escuchar no es nuestros agentes son muy robustos. Es tenemos un proceso de revalidación periódica y aquí están los indicadores que monitorizamos. Si la respuesta es vaga, ya tienes información útil.

Una pyme que automatiza un proceso crítico —facturación, atención a clientes, gestión de pedidos— no puede permitirse descubrir que lleva tres meses trabajando con una automatización que degrada en silencio. El coste de arreglarlo siempre es mayor que el coste de haberlo planteado bien desde el principio.

Vale la pena dedicar un momento a revisar qué datos alimentan los procesos que quieres automatizar, antes de pensar en qué agente los va a gestionar. Ese orden importa más de lo que parece.