Qué mide de verdad esta capa
Mide disponibilidad de contexto, no volumen de datos.
Es una distinción que cuesta aceptar porque la industria lleva quince años midiendo lo contrario. Una empresa mediana puede tener veinte años de histórico en un ERP y no tener nada aprovechable para el caso que quiere resolver, porque lo que ese caso necesita no son transacciones: son las razones por las que se tomaron. El «por qué» rara vez está en la base de datos.
Lo que no mide: la sofisticación de tu arquitectura. Hemos visto casos funcionar sobre una carpeta bien organizada de doscientos documentos, y casos morir sobre plataformas de datos de siete cifras.
Por qué la empresa mediana la hace mal
Por sobrecorrección. La empresa oye «la IA necesita datos», concluye que necesita un proyecto de datos, y arranca una iniciativa transversal que se come el presupuesto y la paciencia antes de que ningún caso llegue a producción.
Es el error espejo del de la capa de ingeniería. Allí se compra herramienta sin problema; aquí se prepara terreno sin destino.
Los números del mercado apuntan aquí con una insistencia que no tiene ninguna otra capa. Gartner estima que el 60% de los proyectos de IA se abandonarán hasta 2026 por una base de datos inadecuada, y que el 63% de las organizaciones no dispone —o no sabe si dispone— de las prácticas de gestión de datos que la IA requiere. Ese segundo dato es el más revelador: no sabe. El problema no es solo la carencia; es que no está diagnosticada.
Pero de ahí no se sigue que haya que arreglar los datos de la empresa. Se sigue que hay que arreglar los datos que un caso concreto necesita.
La pregunta que ordena esta capa
Si mañana quisieras que un sistema respondiera con el criterio de tu empresa —no con el criterio genérico de internet—, ¿de dónde saldría ese criterio?
Las respuestas que damos por buenas:
- De un histórico de documentos donde ese criterio se aplicó y quedó por escrito.
- De un conjunto de reglas que alguien mantiene y que refleja cómo se decide de verdad.
- De ejemplos anteriores verificados por quien sabe si estaban bien.
Las respuestas que son un aviso:
- «De la gente.» Entonces el criterio no es un dato: es conocimiento tácito, y hay que externalizarlo antes de automatizar nada.
- «Del ERP.» El ERP tiene el qué, casi nunca el porqué.
- «Lo sabe el proveedor.» Entonces el resultado será el criterio del sector, no el tuyo, y no habrá diferencial ninguno.
Diagnóstico: dónde estás
Estadio 1 · Conocimiento tácito. Lo que hace bien a tu empresa está en las personas. Funciona mientras esas personas estén. Señal observable: cuando alguien se va, se pierde forma de trabajar, no solo capacidad.
Estadio 2 · Corpus acotado. Existe un conjunto de material —propuestas, informes, expedientes, tickets resueltos— ordenado y suficiente para un caso concreto. No está todo; está lo de ese caso. Señal observable: alguien puede señalar una carpeta y decir «aquí está cómo lo hacemos, y está al día».
Estadio 3 · Contexto mantenido. El corpus tiene dueño, se actualiza como parte del trabajo normal y se sabe qué está desactualizado. Señal observable: existe una fecha de última revisión y alguien responde por ella.
Casi ninguna empresa mediana está en el 3, y no pasa nada. El salto que cambia las cosas es del 1 al 2, y es mucho más barato de lo que la industria sugiere.
Los primeros 90 días
Semanas 1-3 · Inventario dirigido. No un inventario de datos corporativos: el inventario de lo que necesita el caso elegido en la capa de valor. Qué documentos, dónde están, quién los mantiene, cuál es la versión buena.
Semanas 4-6 · Prueba de suficiencia. Coger diez casos reales del pasado y comprobar si con el material inventariado se habría podido resolver. Es la prueba más barata y más informativa de toda la capa, y casi nadie la hace. Si con diez ejemplos históricos no sale, con mil tampoco.
Semanas 7-10 · Saneamiento mínimo. Solo lo que la prueba haya señalado: duplicados que confunden, versiones obsoletas que contradicen, lagunas que obligan a inventar. Nada más.
Semanas 11-12 · Dueño y cadencia. Quién mantiene esto y cada cuánto. Sin esta decisión el corpus se degrada en seis meses y el sistema empieza a responder con criterios que ya no son los de la casa.
Qué NO hacer todavía
- No arranques un data lake. Ni un data mesh, ni una plataforma de gobierno del dato. Son buenas decisiones cuando hay cartera; son formas de aplazar cuando hay un caso.
- No etiquetes a mano miles de ejemplos. Antes comprueba con diez si el planteamiento se sostiene.
- No mezcles calidad de dato con calidad de criterio. Un dato impecable sobre un criterio equivocado produce errores impecables.
- No externalices el corpus. El material que codifica cómo trabaja tu empresa es el activo; si vive en el proveedor, el diferencial es del proveedor.
Lo que cuesta saltársela
Cuesta un tipo de fracaso especialmente desmoralizante: el sistema funciona técnicamente y responde mal. Contesta con seguridad cosas que en tu empresa no se harían así. El equipo pierde la confianza en dos semanas, y recuperarla cuesta más que haberlo hecho bien.
Ese es, en nuestra experiencia, el verdadero significado de la cifra del 60% de Gartner. No son proyectos que se estrellan contra un error técnico: son proyectos que producen resultados plausibles y ajenos, y que nadie quiere usar.
Esta es la segunda capa de la serie sobre las siete capas de madurez en IA. La anterior es la capa de valor, que es la que decide qué caso hay que alimentar.
Preguntas frecuentes
¿Qué datos necesita una empresa para empezar con IA?
Los del caso concreto que quiere resolver, no los de la empresa entera. Normalmente un corpus acotado de documentos donde su criterio quedó aplicado por escrito: propuestas, informes, expedientes o tickets resueltos. Diez ejemplos históricos bastan para saber si el planteamiento se sostiene.
¿Hay que montar un data lake antes de usar IA?
No para el primer caso. Un data lake es una buena decisión cuando existe cartera de casos y volumen que justifique la plataforma. Antes de eso es una forma cara de aplazar: Gartner atribuye a bases de datos inadecuadas el 60% de los abandonos, pero el remedio es preparación dirigida, no preparación total.
¿Qué pasa si nuestro conocimiento está solo en las personas?
Que hay un paso previo a automatizar: externalizarlo. Mientras el criterio viva únicamente en cabezas, cualquier sistema responderá con criterio ajeno. Ese paso no es tecnológico y suele ser el más rentable de todo el proyecto, porque además reduce la dependencia de personas concretas.
¿Cuánta calidad de datos hace falta realmente?
La suficiente para que diez casos históricos se resuelvan bien. Es un umbral verificable en semanas, frente al objetivo inalcanzable de «datos limpios». La calidad perfecta no es requisito de la IA: es una excusa habitual para no empezar.

Jordi García es Tech Lead en onext. Trabaja en llevar la IA a producción gobernada en equipos de desarrollo y de producto —con Spec-Driven Development, ingeniería de contexto y verificación humana en cada paso— y firma los insights técnicos de onext sobre método, calidad y coste de la IA aplicada.
LinkedIn →