Cómo preparar los datos de tu negocio para agentes de IA: la checklist, el orden y los errores
Checklist para preparar los datos del negocio antes de entregarlos a un agente de IA: listas maestras, normalización, procesos, roles — y los errores que arruinan el proyecto.
Resumen
| Pregunta | Respuesta corta |
|---|---|
| ¿Puedo conectar mis archivos a un agente de IA y dejar que se las arregle solo? | Puedes — y producirá respuestas seguras de sí mismas construidas sobre datos contradictorios. No lo hagas |
| ¿Qué va primero? | Elige un proceso y mide su coste actual (horas, errores, dinero). Todo lo demás sirve a eso |
| ¿Qué son los datos de referencia? | Las listas sobre las que funciona el negocio: clientes, productos, precios, estados, unidades. Una copia canónica de cada una, con un responsable nombrado |
| ¿Cuánta historia entrego? | Los 3–6 meses activos. Los años anteriores son un proyecto de migración, no tarea de un agente |
| ¿Qué demuestra que el agente funciona? | Un conjunto de pruebas: 20–50 casos reales con la respuesta correcta conocida, verificados tras cada cambio |
| ¿El mayor error? | Texto libre donde debería haber una lista controlada — estados como “medio pagado”, colores como datos, una hoja por mes |
La propuesta suena irresistible: conecta Google Drive o SharePoint y un agente de IA lee tus hojas de cálculo, responde preguntas y gestiona tus operaciones. La propia página de AgentKit de OpenAI promete agentes que se “construyen e iteran visualmente” (anuncio). La demo siempre funciona. Luego llega el martes: el agente cita un precio de una lista desactualizada, “Romaschka S.L.” y “Romashka” se convierten en dos clientes distintos, y nadie puede decir qué número es el verdadero.
El problema casi nunca es el modelo. Son los datos y el proceso que hay detrás. Esta es la checklist que aplico con clientes antes de que un agente toque nada — en el orden que realmente funciona, con los errores que arruinan estos proyectos en silencio.
Por qué los archivos en bruto sabotean a un agente
Tres mecanismos, cada uno fatal por sí solo:
- Las contradicciones se vuelven respuestas seguras. Un agente no sabe que Precios-2025-FINAL-v3.xlsx sustituye a precios-viejos.xlsx. Promedia, adivina o elige uno — y afirma el resultado con total confianza. Las auditorías de hojas de cálculo de las últimas dos décadas (Ray Panko, Universidad de Hawái) encuentran de forma consistente que ~88% de las hojas de cálculo empresariales contienen errores (resumen de la investigación); un agente hereda cada uno de ellos, más los conflictos entre archivos.
- Sin claves, no hay cruces. Tu tabla de pedidos dice cliente “AK-114”, la hoja de pagos dice “Kamensky A.”, y la pestaña del CRM dice “Andrés — mayorista”. Un humano lo resuelve de memoria; un agente no. Sin identificadores compartidos, cada verificación cruzada es un lanzamiento de moneda.
- El volumen quema dinero antes que cualquier otra cosa. Un libro de 40 pestañas re-leído en cada petición significa que tus costes escalan con la longitud de la conversación, no con el valor entregado. (La matemática de costes medidos detrás de los constructores de IA está en Tu app de Replit o Lovable no está lista para producción.)
La preparación arregla las tres cosas — y es en gran parte trabajo que tendrías que hacer de todos modos para crecer más allá de las hojas de cálculo.
La checklist, en orden
1. Elige un proceso y mide su línea base
Un proceso: captación de pedidos, o aprobación de facturas, o actualización de stock. No “las operaciones”. Anota qué cuesta hoy: horas por semana, tasa de error, el precio del último error. Sin esta línea base no puedes demostrar que el agente ahorró nada — el proyecto muere en la primera pregunta de presupuesto.
2. Inventaarya todas las fuentes
Enumera cada archivo, pestaña, herramienta y persona que toca el proceso. Incluye las fuentes en la sombra: el tracker privado del jefe, el grupo de WhatsApp donde en realidad se deciden las excepciones, la pizarra. Todo lo que omitas aquí reaparecerá como punto ciego del agente.
3. Extrae los datos de referencia (los «spravochniki»)
Este es el corazón de la preparación. Para cada lista sobre la que funciona el negocio — clientes, productos, precios, unidades, estados, almacenes, centros de coste — produce exactamente una versión canónica:
- Un registro por cosa real. “Romashka S.L.”, “Romashka”, “romashka (mayorista)” se colapsan en un cliente con un ID.
- Un responsable nombrado y una regla de actualización. ¿Quién cambia la lista de precios y qué lo dispara? Los datos de referencia sin dueño se pudren en un trimestre.
- Fechas de vigencia donde la realidad cambia. Precios, tipos de cambio, aranceles: conserva la historia, pero el agente debe saber siempre qué valor es el vigente.
4. Normaliza los formatos
Reglas aburridas y decisivas:
| Regla | Roto | Corregido |
|---|---|---|
| Los estados son una lista controlada | ”¿pagado?”, “medio pagado”, “¡¡PAGADO!!” | paid / pending / overdue |
| Una fila = un evento | Tres pedidos fusionados en una fila | Una fila por pedido |
| Fechas en un formato | 03.04.26, Abr-3, 2026/4/3 | 2026-04-03 |
| Unidades explícitas | ”5” (¿cajas? ¿unidades? ¿litros?) | 5 caja |
| Sin diseño-como-dato | Celdas combinadas, rojo = vencido, una hoja por mes | Filas simples, columna de estado, columna de fecha |
Los colores y las celdas combinadas son invisibles para un agente — todo lo que codifican debe convertirse en una columna.
5. Separa hechos de referencias
Pedidos, pagos, envíos, tickets son eventos: se acumulan y nunca se editan retroactivamente. Clientes, productos, precios son referencias: cambian. Mantenerlos en tablas separadas (en vez de una mega-hoja) es lo que hace consistentes y verificables las respuestas de un agente — y es la misma separación que impone una base de datos real (por qué Sheets deja de escalar).
6. Escribe el proceso tal como funciona de verdad
No la versión del organigrama — la real. Para cada paso: quién lo hace, qué lo dispara, qué decide, cuáles son las excepciones, qué SLA aplica. Dos sesiones de medio día con las personas que tocan el proceso suelen bastar para la primera versión honesta. Cada excepción no escrita que omitas será un incidente futuro de viernes por la noche.
7. Asigna roles y permisos
Decide ya quién puede ver los costes, quién puede editar precios, quién puede aprobar reembolsos. En herramientas de chat todos lo ven todo; en un sistema real esto se convierte en acceso por roles y una pista de auditoría. Entregarle al agente un modelo de permisos (aunque sea una tabla simple) evita tanto fugas como excesos “serviciales”.
8. Define las salvaguardas y la regla de escalado
Qué puede hacer el agente solo (responder, redactar, etiquetar, enrutar) versus qué requiere siempre a un humano (enviar dinero, contactar a un cliente, cambiar datos de referencia, cualquier cosa con confianza por debajo del umbral). Define también el camino de error: ante datos ausentes o contradictorios, el agente debe parar y preguntar — no improvisar.
9. Construye el conjunto de pruebas
Toma 20–50 casos históricos reales donde conozcas el resultado correcto, incluidos los difíciles. Ese conjunto es tu definición de “funciona”. Tras cualquier cambio de prompt o de datos, el agente debe superarlo. Sin conjunto de pruebas, “mejor” es indistinguible de “distinto” — el modo de fallo detrás de la mayoría de las hogueras de tokens.
10. Empaqueta la entrega
Lo que recibe el agente (o el ingeniero que construye a su alrededor): los archivos de referencia canónicos, el documento de proceso, la tabla de permisos, las reglas de salvaguarda, el conjunto de pruebas y la línea base de KPI. Ese paquete — no el prompt — es el proyecto real.
Los errores que matan estos proyectos
| Error | Qué pasa | La solución |
|---|---|---|
| Entregar la carpeta en bruto | El agente responde desde la versión equivocada | Pasos 3–5 primero, un proceso a la vez |
| Datos de referencia sin dueño | Las listas divergen de nuevo en silencio | Responsable nombrado + regla de actualización, por escrito |
| Estados en texto libre | El agente no puede contar, filtrar ni escalar con fiabilidad | Vocabulario controlado |
| Colores/celdas combinadas como datos | El agente es ciego a la mitad del significado | Columnas, filas simples |
| Migrar toda la historia el primer día | Meses de trabajo antes de cualquier resultado | 3–6 meses activos, archivar el resto |
| Excepciones no escritas en una sola cabeza | El agente “falla aleatoriamente” | Documento de proceso + inventario de fuentes ocultas |
| Sin conjunto de pruebas | Prompts infinitos, sin prueba de progreso | 20–50 casos con respuestas conocidas |
| Sin línea base de KPI | ROI indemostrable; presupuesto cortado a mitad | Mide antes de construir |
Qué cambia cuando los datos están preparados
El mismo agente, sobre el mismo modelo, empieza a comportarse como un sistema distinto: cruza clientes con pagos sin lanzar monedas, sus costes dejan de escalar con el tamaño de los archivos, sus respuestas se vuelven verificables contra el conjunto de pruebas — y los errores restantes se corrigen en un solo lugar en vez de perseguirse por cuarenta pestañas. Esta es también exactamente la preparación que abarata una migración posterior a una plataforma real: la demo de Sheets a SQL muestra cómo se ve con números en vivo.
La preparación es la mayor parte de la batalla — pero no toda. El artículo siguiente cubre lo que la preparación de datos no puede arreglar: por qué los equipos queman cientos de prompts tras hacerlo todo bien, y por qué la pieza que falta es una persona.
Fuentes y lecturas adicionales
- Introducing AgentKit — OpenAI — qué envían realmente los proveedores (y quiénes son sus «builders»)
- Raymond Panko, What We Know About Spreadsheet Errors — las auditorías con ~88% de tasa de error
- When Google Sheets Stops Scaling — el techo de volumen detrás del mecanismo 3
- Google Sheets to SQL in One Transaction — a dónde lleva esta checklist: 1.686 registros, 12 defectos encontrados, demo en vivo