Primero los datos, luego los agentes

Un agente puede leer información, proponer una respuesta y ejecutar una acción. Cada paso aumenta el costo de trabajar con un dato equivocado. Por eso, antes de elegir un agente, conviene decidir qué fuente puede usar, qué significa cada dato, qué permisos tendrá y cuándo debe pedir ayuda a una persona.

La diferencia me resulta familiar desde el trabajo con datos y operaciones en LATAM. Una demo puede unir tablas preparadas a mano y producir una respuesta convincente. En operación, las fuentes cambian, los equipos usan definiciones distintas y hay casos que no encajan en la regla. El trabajo de datos determina si el sistema puede responder por ellos.

McKinsey plantea en su análisis de preparación de datos para IA que escalar exige información confiable, trazable y gobernada, tanto estructurada como no estructurada. Su matiz es importante: no se trata de esperar datos perfectos, sino de definir qué calidad es suficiente para cada uso y su riesgo. Esta es mi forma de llevar esa idea a un piloto concreto.

Primero define la acción que quieres permitir

«Necesitamos agentes para ventas» deja demasiadas preguntas abiertas. «Queremos preparar una lista semanal de cuentas que requieren seguimiento, para que una persona la revise antes de contactar» delimita el resultado, la frecuencia y el control humano.

Separa el trabajo en tres niveles:

1. Leer y resumir. El sistema reúne antecedentes y muestra de dónde vienen. Si se equivoca, la persona todavía puede contrastar la fuente.
2. Recomendar. Prioriza o redacta una propuesta. Hace falta registrar qué criterios usó y cómo se corrige una recomendación mala.
3. Ejecutar. Envía un mensaje, cambia un precio o actualiza un registro. Aquí un error puede afectar a alguien fuera del equipo; los permisos y las condiciones de parada deben ser explícitos.

No todos los casos tienen que llegar al tercer nivel. Si la preparación de información resuelve la espera principal, esa puede ser la mejor primera versión. En mi guía para pasar un piloto de IA a la operación explico cómo elegir la decisión y medir si cambió el trabajo.

Cinco preguntas para revisar los datos antes del piloto

No hace falta rehacer toda la arquitectura. Toma un caso real y comprueba lo siguiente con la persona dueña del proceso:

• ¿Cuál es la fuente válida? Identifica el sistema, documento o tabla que manda cuando aparecen dos cifras distintas.
• ¿Qué significa cada campo? Acuerda una definición de fecha, estado, moneda, cliente o indicador entre los equipos que lo usarán.
• ¿Cuándo se actualiza? Fija una frecuencia y muestra una señal visible cuando la información está incompleta o vencida.
• ¿Quién puede verla o modificarla? Da al agente permisos concretos y asigna a una persona la aprobación de cambios con efecto externo.
• ¿Cómo se reconstruye una respuesta? Guarda la fuente y versión utilizadas, el resultado producido y la corrección aplicada si hubo un error.

Si una respuesta falta, no concluyas automáticamente que «la empresa no está lista para IA». Reduce el alcance: usa una fuente controlada, limita el agente a lectura y registra las excepciones. La calidad requerida para resumir una reunión no es la misma que para modificar una cotización.

Un ejemplo de la capa que suele pasar desapercibida

El dashboard WBR que construí reúne ventas, operación y metas para que una revisión semanal parta de una vista compartida de los desvíos. No es un agente. Sí muestra una condición previa importante: antes de pedir a un sistema que explique o actúe sobre un indicador, el equipo necesita acordar su definición y trabajar con una base consistente.

Imagina, como ejemplo hipotético, que dos países registran «ventas de la semana» con cortes horarios o monedas distintos. Un agente podría calcular una variación impecablemente sobre una comparación equivocada. La respuesta no se arregla solo con un prompt mejor; hay que definir el corte, la conversión y quién valida la cifra antes de usarla para decidir.

Con documentos pasa algo parecido. Si una política cambió, el sistema debe distinguir la versión vigente de la anterior y poder señalar cuál consultó. Hacer que un archivo sea buscable no garantiza que su contenido sea el correcto para actuar.

Una secuencia prudente para dar permisos

En un piloto, empezaría con un lote pequeño de casos reales y una persona que conozca el proceso:

1. Reúne una línea base. ¿Cuánto tarda hoy la decisión y cuántas correcciones necesita?
2. Ejecuta en modo lectura. Muestra fuentes, respuesta propuesta y datos faltantes, sin escribir en sistemas operativos.
3. Revisa los desacuerdos. Clasifica si el problema vino de la fuente, la definición, la recuperación del dato o la propuesta del modelo.
4. Autoriza una acción acotada. Solo cuando la persona pueda revisar resultados repetidos, define qué puede hacer el sistema y qué requiere aprobación.
5. Mide uso y errores. Compara casos elegibles, tiempo hasta la decisión, correcciones y excepciones con la línea base.

El criterio de salida no debería ser que la demo «funcionó». Debería ser que el flujo produce un resultado útil en casos reales, deja revisar por qué lo produjo y tiene a alguien que responde cuando falla. Entonces tiene sentido ampliar el alcance. Si no, el trabajo pendiente está en el dato o en el proceso, no necesariamente en un agente más sofisticado.