· 8 min de lectura

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

PreguntaRespuesta 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:

  1. 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.
  2. 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.
  3. 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:

ReglaRotoCorregido
Los estados son una lista controlada”¿pagado?”, “medio pagado”, “¡¡PAGADO!!”paid / pending / overdue
Una fila = un eventoTres pedidos fusionados en una filaUna fila por pedido
Fechas en un formato03.04.26, Abr-3, 2026/4/32026-04-03
Unidades explícitas”5” (¿cajas? ¿unidades? ¿litros?)5 caja
Sin diseño-como-datoCeldas combinadas, rojo = vencido, una hoja por mesFilas 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

ErrorQué pasaLa solución
Entregar la carpeta en brutoEl agente responde desde la versión equivocadaPasos 3–5 primero, un proceso a la vez
Datos de referencia sin dueñoLas listas divergen de nuevo en silencioResponsable nombrado + regla de actualización, por escrito
Estados en texto libreEl agente no puede contar, filtrar ni escalar con fiabilidadVocabulario controlado
Colores/celdas combinadas como datosEl agente es ciego a la mitad del significadoColumnas, filas simples
Migrar toda la historia el primer díaMeses de trabajo antes de cualquier resultado3–6 meses activos, archivar el resto
Excepciones no escritas en una sola cabezaEl agente “falla aleatoriamente”Documento de proceso + inventario de fuentes ocultas
Sin conjunto de pruebasPrompts infinitos, sin prueba de progreso20–50 casos con respuestas conocidas
Sin línea base de KPIROI indemostrable; presupuesto cortado a mitadMide 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