Hay un patrón que se repite en muchas organizaciones en este momento. Un equipo de operaciones identifica un problema concreto que parece perfecto para un agente de IA: triaje de incidencias, escalado automático, resolución de alertas recurrentes. El equipo tiene experiencia real en el dominio, motivación, y acceso a herramientas modernas. Empieza a construir. Y a las pocas semanas aparece el mismo obstáculo, siempre el mismo: los datos no están donde deberían, no significan lo que parecen, o no se puede confiar en ellos lo suficiente como para dejar que una IA tome decisiones basadas en ellos.
No es un problema de tecnología. Es un problema de fundamentos.
Este artículo no va sobre cómo construir agentes de IA. Va sobre lo que tiene que estar resuelto antes de empezar, para que cuando el agente llegue a producción no se convierta en una fuente de decisiones incorrectas difíciles de rastrear.
El perfil que más está adoptando agentes ahora mismo
Los equipos de operaciones son, probablemente, el colectivo que más valor puede extraer de los agentes de IA en el corto plazo. Conocen los procesos en profundidad, tienen una lista interminable de tareas repetitivas que consumen tiempo, y son capaces de definir con precisión qué significa una buena decisión frente a una mala.
Pero precisamente por eso son también los más expuestos al riesgo: construyen sobre datos operacionales que nunca fueron diseñados para ser consumidos por sistemas automatizados. Logs de sistemas legacy, registros en formatos inconsistentes, estados que solo tienen sentido si conoces el contexto histórico del proceso. Datos que un operador experimentado interpreta correctamente porque lleva años haciéndolo. Datos que un agente interpretará de forma literal, sin ese contexto.
El resultado más habitual no es un fallo catastrófico visible. Es algo más sutil y más peligroso: un agente que funciona bien el 80% de las veces y falla de forma silenciosa en el 20% restante. Y sin los mecanismos adecuados, nadie lo sabe hasta que el problema ya ha escalado.
Qué significa “tener los datos listos” para un agente
Cuando hablamos de preparar los datos para un agente de IA, no hablamos de tener un data lake ordenado ni de haber completado una estrategia de datos a tres años. Hablamos de responder cuatro preguntas concretas antes de escribir la primera línea de código del agente:
¿De dónde vienen los datos que el agente va a usar?
Parece obvio, pero en la práctica muchos equipos empiezan a construir sobre fuentes de datos que no controlan completamente: APIs de sistemas de terceros, exportaciones manuales, bases de datos operacionales sin SLA de disponibilidad. Si el agente depende de una fuente que puede no estar disponible o puede cambiar de formato sin previo aviso, el agente heredará esa fragilidad.
¿Qué significa cada campo, y quién lo decide?
Los datos operacionales están llenos de convenciones implícitas. Un campo llamado estado puede tener doce valores posibles, de los cuales tres son técnicamente equivalentes pero se usan en sistemas distintos por razones históricas. Sin un diccionario de datos mínimo, el agente aprenderá esas inconsistencias y las reproducirá en sus decisiones.
¿Quién puede acceder a qué, y bajo qué condiciones?
Los agentes de IA no son usuarios humanos, pero acceden a datos con las mismas implicaciones de privacidad y cumplimiento. En sectores regulados como aerolíneas, banca, seguros o sanidad, esto no es opcional. Un agente que accede a información de pasajeros para resolver incidencias operacionales necesita exactamente el mismo nivel de control de acceso que cualquier sistema de producción. Si esto no está definido desde el principio, se convierte en una deuda técnica y regulatoria que frena el despliegue.
¿Cómo sabremos si el agente está tomando decisiones basadas en datos incorrectos?
Esta es la pregunta que menos equipos se hacen antes de empezar, y la más importante. La observabilidad de un agente no es solo monitorizar si responde o no. Es poder trazar, para cualquier decisión que tome, qué datos consultó, en qué momento, y con qué valores. Sin eso, depurar un comportamiento incorrecto es casi imposible.
El gobierno del dato no es burocracia: es la condición de escalabilidad
Hay una percepción extendida en los equipos de negocio de que el gobierno del dato es un proyecto de IT que ralentiza las cosas. En el contexto de los agentes de IA, esa percepción es especialmente costosa.
Un agente en producción toma decisiones de forma continua y autónoma. Cada decisión incorrecta tiene un coste: operacional, económico, o de confianza del usuario. A diferencia de un proceso manual en el que un operador puede corregir sobre la marcha, un agente escala el error tan rápido como escala el acierto.
Esto no significa que haya que completar un programa de gobierno del dato de dos años antes de lanzar el primer agente. Significa que hay que identificar, para el caso de uso concreto, cuáles son los datos críticos, quién es su propietario, y qué nivel de calidad es aceptable. Es un ejercicio que puede hacerse en días si el alcance está bien acotado.
La diferencia entre los proyectos de IA que llegan a producción y los que se quedan en piloto eterno raramente está en el modelo o en la plataforma. Está en si el equipo hizo ese trabajo previo sobre los datos o no.
Qué debería hacer un CIO o CDO antes de autorizar el desarrollo
Si estás en posición de decisión sobre si lanzar un proyecto de agentes de IA en tu organización, hay tres acciones concretas que marcan la diferencia entre un piloto que escala y uno que no:
- Identifica al propietario de cada fuente de datos que el agente va a consumir. No el propietario técnico del sistema, sino el responsable de negocio que puede responder si los datos son correctos y completos. Si no existe esa figura, créala antes de empezar.
- Define el contrato de datos mínimo. Para el caso de uso concreto: qué campos son imprescindibles, qué valores son válidos, qué latencia es aceptable. No hace falta un catálogo de datos completo, hace falta saber exactamente qué necesita el agente para funcionar correctamente.
- Establece un mecanismo de revisión humana para las decisiones de alto impacto. Los agentes no tienen que ser totalmente autónomos desde el primer día. Un diseño que mantiene al operador en el bucle para las excepciones es más robusto, más fácil de auditar, y genera más confianza organizacional. La autonomía se amplía a medida que el sistema demuestra fiabilidad, no al revés.
Construir bien desde el principio
La adopción de agentes de IA en operaciones es una oportunidad real para las organizaciones que tienen equipos con conocimiento de dominio profundo y problemas bien definidos. Pero esa oportunidad solo se materializa si los fundamentos de datos están en su sitio.
No se trata de perfección. Se trata de no construir sobre arena. Un agente que opera sobre datos bien gobernados, con trazabilidad y control de acceso definidos, no solo funciona mejor: es un agente del que la organización puede fiarse. Y en operaciones críticas, la confianza en el sistema es tan importante como su precisión.
Los equipos que empiezan bien este camino, con los datos en orden, con los propietarios identificados y con la observabilidad diseñada desde el principio, son los que en seis meses tienen agentes en producción haciendo un trabajo real. Los que no, tienen pilotos que siguen siendo pilotos.
Sergio Cambelo
Cloud Architect at Keepler. "Knowledge is the foundation of what we do everyday to help our customers to achieve their goals. I like to design complex cloud architectures but what I enjoy the most is learning and sharing the knowledge with others to bring value to Keepler and their customers."
0 comentarios