¿Qué datos necesita un agente de IA para funcionar?

Un agente de IA no necesita un proyecto de datos de dos años antes de empezar a trabajar. Necesita tres cosas: acceso a los sistemas donde vive el caso que va a resolver, las reglas de tu operación por escrito, y un puñado de casos ya resueltos para poder medir si lo hace bien. Nada de eso exige tener el dato limpio, unificado y gobernado en toda la empresa. Exige tenerlo donde el agente lo va a usar, para la tarea concreta que le encargas.

Lo aclaro al principio porque el mito de “primero los datos” es la excusa más cara que veo en los comités. Bloquea el arranque durante trimestres, consume presupuesto en infraestructura que nadie usará todavía, y al final no responde a la pregunta que importaba: ¿puede un agente ejecutar este proceso con garantías, con los datos que ya tengo?

El mito del “primero necesito arreglar los datos”

La idea viene de proyectos anteriores. Para entrenar un modelo predictivo propio o montar un cuadro de mando corporativo, sí hacía falta consolidar años de histórico, normalizar esquemas y limpiar registros. Ese trabajo es real y a veces necesario, pero es otro trabajo.

Un agente que ejecuta un proceso operativo no aprende de tu histórico. Usa un modelo ya entrenado y aplica tus reglas sobre el caso que tiene delante. Para conciliar una factura no necesita las cien mil facturas de la última década en un lago de datos. Necesita leer esta factura, el pedido y el albarán asociados, y saber qué tolerancia de diferencia acepta tu empresa. Ese dato ya existe, en tu ERP y en la cabeza de quien concilia hoy. El trabajo no es construir un almacén nuevo, sino dar acceso al que hay y hacer explícita la regla.

Lo que un agente sí necesita

Cuando evalúo si una operación tiene datos suficientes para un agente, miro tres piezas.

Acceso a los sistemas donde vive el caso. El agente trabaja dentro de tu ERP, tu correo, tu gestor documental, tu CRM, allí donde ya está la información que una persona consultaría para resolver el caso. No hace falta moverla a ningún sitio. Hace falta que el agente pueda leerla, y escribir el resultado donde corresponda, con permisos concretos. Cómo se hace esa conexión, y qué hacer cuando el sistema es antiguo, lo cuento en integrar agentes con el ERP.

Reglas explícitas. El criterio con el que hoy se decide cada caso: qué tolerancia se acepta, qué combinaciones se aprueban solas, qué dispara una revisión. Si ese criterio solo vive en la experiencia de dos personas, el primer trabajo no es técnico, es de negocio: ponerlo por escrito. Ese paso —codificar el modelo operativo— es el que sostiene todo lo demás, y lo desarrollo en modelo operativo como código.

Casos resueltos para evaluar. Un conjunto de ejemplos con la respuesta que se considera correcta: entradas reales y el resultado que un buen operador daría. No hacen falta millones, sino suficientes para cubrir los casos frecuentes y los bordes que importan. Sirven para medir la calidad del agente antes de darle trabajo de verdad y para detectar cuándo se degrada. Sin esto no hay forma seria de afirmar que “funciona”. Sobre cómo se monta esa medición he escrito en evaluación de agentes de IA.

Lo que un agente no necesita (todavía)

Igual de importante es saber qué puedes dejar para después, porque es donde se va el tiempo y el dinero sin retorno.

No hace falta para empezar	Por qué
Un lago de datos corporativo	El agente lee el caso donde ya está, no un histórico consolidado
Calidad perfecta en toda la base	Basta la calidad del dato que toca la tarea concreta
Migrar sistemas antiguos	Se integra con lo que hay; la migración es otro proyecto
Un catálogo de datos completo	Se documenta lo que el proceso usa, no todo el mapa
Etiquetar manualmente miles de registros	El agente aplica reglas, no aprende de tu etiquetado

Nada de esta lista está mal en sí mismo. Buena parte tiene sentido a medio plazo. Pero convertirlo en prerrequisito del primer agente es lo que mantiene la IA en la presentación y fuera de la operación. He visto ese patrón de cerca y lo analizo en por qué fracasan los pilotos de IA. Casi nunca fallan por falta de datos, fallan por falta de límites claros.

Cómo se trabaja con datos imperfectos

Tus datos son imperfectos. Los de todos lo son. La cuestión no es esperar a que dejen de serlo, sino acotar el mandato del agente para que la imperfección no le haga tomar una decisión que no debería.

El mecanismo es sencillo: cuanto peor es el dato, más estrecho se hace el mandato. Imagina una distribuidora de 80 M€ cuyo maestro de proveedores tiene duplicados y nombres inconsistentes —un caso completamente habitual—. No hace falta limpiar los cien mil registros antes de arrancar. Se le dice al agente que actúe solo cuando la coincidencia sea inequívoca, y que todo lo ambiguo lo derive a una persona con el contexto ya preparado. El agente resuelve el grueso de casos limpios desde el primer día, y los casos sucios se convierten en una cola de excepciones que, además, señala exactamente qué datos conviene arreglar primero. La gestión de esa frontera la trato en excepciones y escalado a humanos.

Ese enfoque le da la vuelta al orden habitual. En lugar de “arreglo todos los datos y luego automatizo”, es “automatizo lo que el dato ya permite, y la operación me dice dónde vale la pena arreglar el resto”. El proyecto de datos deja de ser un prerrequisito ciego y se convierte en una consecuencia dirigida por el uso real.

Por dónde empezar

Si tuviera que reducirlo a una secuencia para un primer proceso: elige una tarea con volumen y reglas conocidas, escribe esas reglas y las excepciones que ya conoces, reúne veinte o treinta casos resueltos que representen lo normal y lo raro, y comprueba que el agente puede acceder a los sistemas donde vive el caso. Con eso se puede empezar a medir. Lo que falte se descubre midiendo, no planificando en abstracto.

Antes de arrancar conviene una mirada realista al estado de la casa —qué procesos están descritos, quién es dueño de cada regla, qué accesos existen—. Eso es lo que reviso en preparar tu empresa para agentes, y encaja dentro del panorama general de agentes de IA para empresas.

Preguntas frecuentes

¿Necesito un data lake para poner agentes de IA?

No para empezar. Un agente que ejecuta un proceso lee el caso donde ya vive —en el ERP, el correo, el gestor documental— y aplica tus reglas. Un almacén consolidado puede tener sentido a medio plazo para análisis, pero convertirlo en prerrequisito del primer agente es la forma más común de no arrancar nunca.

¿Cuántos datos hacen falta para entrenar un agente?

Un agente operativo no se entrena con tu histórico: usa un modelo ya entrenado y aplica tus reglas caso a caso. Lo que necesitas no son millones de registros, sino un conjunto modesto de casos ya resueltos —decenas, no millones— para evaluar si acierta y detectar cuándo se degrada.

¿Puedo usar agentes si mis datos están sucios o incompletos?

Sí, acotando el mandato. Se configura el agente para actuar solo cuando el dato es inequívoco y derivar lo ambiguo a una persona. Así resuelve los casos limpios desde el primer día, y la cola de excepciones te indica qué datos conviene limpiar primero, en lugar de limpiarlo todo a ciegas.

¿Qué es más importante, los datos o las reglas?

Las reglas, casi siempre. El dato suele existir en tus sistemas. Lo que falta es el criterio explícito con el que se decide cada caso. Si ese criterio solo vive en la experiencia de unas pocas personas, hacerlo explícito es el trabajo previo que más condiciona el resultado.