Por qué fallan la mayoría de las implementaciones de IA: omiten la capa de datos
La versión corta: la IA falla una capa más abajo. Una verdad dispersa entre sistemas no le da al modelo nada sobre lo que sostenerse. Construya primero la capa de datos; la parte de IA es el trabajo menor.
El patrón es lo bastante consistente como para predecirlo. Una empresa decide que llegó la hora de la IA. Alguien corre un piloto: un copiloto, un chatbot, un agente cableado a los datos que fueran más fáciles de alcanzar. El demo impresiona. El despliegue decepciona. Las respuestas vuelven equivocadas de maneras difíciles de detectar y más difíciles de explicar. En un trimestre el piloto se archiva sin ruido, y la conclusión aterriza en la siguiente presentación a la junta: probamos la IA, y no está lista.
El modelo nunca fue el problema. Los insumos sí.
La IA no falla en inteligencia. Falla en los insumos.
La parte que nadie presupuesta
Todo sistema de IA, por capaz que sea, opera sobre lo que puede leer. En la mayoría de las empresas medianas, lo que puede leer es un desorden: un ERP envejecido que exporta a CSV en un buen día, cuatro hojas de cálculo que discrepan entre sí en silencio, una bandeja de entrada donde viven las decisiones reales y dos empleados cuya memoria es el verdadero sistema de registro.
Apunte un modelo hacia eso y hará lo que haría un empleado nuevo y brillante en su primer día sin inducción: adivinar, con confianza.
Un modelo apuntado al caos devuelve caos con confianza.
El trabajo que determina si la IA entrega resultados no es la selección del modelo, ni la ingeniería de prompts, ni la elección del proveedor. Es el trabajo sin glamour de construir una capa de datos: un lugar organizado, con permisos definidos y al día donde realmente viven los hechos del negocio. Esa capa falta en la mayoría de los presupuestos de IA porque no es emocionante de comprar. También es el mayor predictor individual de si el proyecto sobrevive al contacto con la realidad.
Una falla, con la forma de siempre
Esta es la forma que seguimos viendo, anonimizada y comprimida.
Un operador de distribución quiere un asistente de IA que responda preguntas sobre pedidos, inventario e historial de clientes. El proveedor conecta el asistente a las exportaciones de reportes del ERP y a un drive compartido de hojas de cálculo. En el demo, resume documentos de maravilla.
En producción, alguien hace una pregunta que cruza sistemas: qué clientes pidieron el producto X en los últimos noventa días y todavía tienen saldo pendiente. El historial de pedidos está en el ERP. Los saldos están en una hoja de cálculo que el contralor actualiza cada semana, a veces. Dos clientes existen bajo tres nombres ligeramente distintos. El asistente hilvana una respuesta que se lee perfecta y está equivocada en dos lugares.
Nadie puede saber cuáles dos lugares sin rehacer el trabajo a mano. Así que la gente rehace el trabajo a mano, cada vez, y la confianza se erosiona hasta que nadie le pregunta al asistente nada que importe. El proyecto no falló con estruendo. Falló como fallan la mayoría: se volvió decoración.
Note lo que nunca salió a relucir: el modelo. El mismo asistente, apuntado a datos conciliados, habría respondido correctamente. Se le pidió ser inteligente sobre información que ningún humano en el edificio habría podido desenredar tampoco.
Si sus datos no pueden responder una pregunta, su IA tampoco.
Qué es realmente una capa de datos
Tres propiedades, ninguna opcional.
Organizada. Cada registro tiene un hogar. Las relaciones entre las cosas (clientes con pedidos, proyectos con facturas, personal con turnos) son vínculos explícitos, no convenciones de nombres que alguien tiene que recordar. Cuando dos sistemas discrepan, uno de ellos queda designado como la verdad.
Con permisos definidos. Quién puede ver qué se aplica por estructura, no con la esperanza de que nadie baje demasiado en la pantalla. Esto importa más de lo que los equipos esperan, y es donde la IA amplifica el descuido existente: un asistente con acceso a todo tarde o temprano le mostrará algo a alguien que no debía verlo.
Al día. Los hechos llevan fecha. Actualizar los datos es parte de hacer el trabajo, no una tarea administrativa que se hace después. Una capa de datos 95 por ciento precisa pero con tres semanas de atraso es un pasivo disfrazado de activo.
Esto no requiere un data warehouse ni un programa de TI de dos años. Para operaciones medianas, nuestra opción por defecto es Airtable: relacional, totalmente legible y escribible por otro software, y mantenible por el propio equipo del cliente después de que nos vamos. Encima de esa capa se sienta Claude, la inteligencia que la lee, actúa sobre ella y redacta contra ella. Pero las herramientas son la decisión menor. Las propiedades son el punto.
Un éxito, con la forma de siempre
Una firma de logística de viajes llevaba su operación en hojas de cálculo, bandejas de entrada y memoria institucional. El instinto era comprar IA primero. El trabajo fue en la dirección contraria.
Primero, la capa de datos: viajes, proveedores, viajeros, pagos, cada uno con un hogar y relaciones explícitas, migrados con cuidado desde las hojas de cálculo con las discrepancias resueltas en el camino de entrada, no arrastradas. Luego, la plomería aburrida: la recepción de solicitudes que antes era correo electrónico se volvió estructurada, y actualizar un registro se volvió la manera de hacer el trabajo y no un reporte sobre el trabajo.
Solo entonces, la inteligencia: redactar comunicaciones a proveedores desde datos de viaje en vivo, marcar reservas cuyos hechos no conciliaban, responder las preguntas transversales que antes tomaban una tarde de saltar entre pestañas. La porción de IA de la construcción fue la menor parte del trabajo. Funcionó al primer intento serio, porque por primera vez había algo confiable sobre lo que sostenerse.
Ese orden es el método completo. El puente se construye desde la capa de datos hacia afuera, no desde el modelo hacia atrás.
Por qué verificamos todo en vivo
Una capa de datos es tan confiable como los hechos de plataforma que tiene debajo, y los hechos de plataforma se desvían. La documentación se desvía todavía más.
Un ejemplo de nuestro propio sistema de referencia, con fecha para que pueda tomarnos la palabra. La documentación de Airtable establecía un límite de 10 registros por solicitud al API. En julio de 2026 probamos el API en vivo y aceptó 25. Construimos contra 25, con la fecha adjunta, y una rutina automática vuelve a verificar hechos como este cada mes, porque lo que era cierto en julio puede no serlo en octubre.
La misma disciplina aplica a la seguridad. Antes de publicar la experticia de Airtable que construimos dentro de Claude, corrimos una revisión adversarial en su contra: construir deliberadamente escenarios de falla en lugar de leer buscando errores. Esa revisión detectó tres maneras distintas en que un portal de clientes podía filtrar los datos de un cliente a otro, en una guía donde cada oración individual era cierta. La publicación quedó bloqueada hasta que las tres quedaron corregidas.
No lo mencionamos como anécdota sino porque es el estándar de trabajo. "Cada afirmación con fecha o probada" es lo que separa una capa de datos que se le puede entregar a una IA de una pila de supuestos con un esquema.
Los supuestos sin probar son solo caídas que todavía no ocurren.
Preguntas frecuentes
¿No es el modelo la parte difícil?
No. Los modelos de frontera ya son, para la mayoría de las tareas operativas de negocio, más capaces que los datos que se les entregan. La brecha entre un resultado de IA mediocre y uno excelente suele ser 20 por ciento modelo y 80 por ciento lo que el modelo puede leer.
¿Puede la IA limpiar el desorden por sí sola?
Puede ayudar, bajo supervisión, y así la usamos durante las migraciones. Pero decidir cuál de dos registros en conflicto es el verdadero, quién puede ver qué y cuál sistema es la fuente de registro son juicios sobre su negocio. Delegarlos a un modelo es la manera de conseguir una capa de apariencia ordenada con respuestas equivocadas horneadas adentro.
¿Cuánto toma esto?
De semanas a meses, según cuántos sistemas haya y cuánta discrepancia entre ellos. Es trabajo deliberado, y es la razón por la que tomamos pocos proyectos a la vez. Si el cronograma que tiene en mente es un fin de semana, una tienda de plantillas le servirá mejor que nosotros.
¿Por dónde deberíamos empezar?
No con una herramienta. Empiece con un mapa honesto de dónde viven realmente sus hechos hoy y qué podría hacer la IA con ellos tal como están. Esa evaluación es un entregable fijo que usted conserva sin importar quién construya después, y es donde comienza cada uno de nuestros proyectos.
El resumen incómodo
La mayoría de las implementaciones de IA fallan antes de que la IA participe, porque omiten la capa sobre la que la IA debía sostenerse. Las empresas que obtienen resultados reales no son las que tienen acceso secreto a modelos. Son las que hicieron primero el trabajo aburrido.
La capa de datos es aburrida. Lo aburrido es la virtud.
Si sus sistemas son más viejos que sus ambiciones de IA, el argumento largo está en la página del método, y la primera conversación es sobre si el trabajo es el correcto, no una llamada de ventas. Iníciela aquí.