El data readiness es el estado medible en que los datos de una empresa pueden alimentar un sistema de IA en producción: accesibles, con esquema estable, con permisos resueltos y con calidad conocida. Cuando falta, el agente funciona en la demo y falla en producción, porque el modelo no compensa lo que el dato no trae.
Tres pilotos en staging y ninguno cruzando a producción. Es la conversación que más he repetido este año.
Y casi siempre empieza en el mismo sitio, que es preguntando si el problema está en el modelo. Nosotros también empezamos ahí: cambiamos de proveedor, subimos la ventana de contexto, reescribimos el prompt tres veces. El piloto seguía funcionando en la demo. Lo que descubrimos semanas más tarde fue que la consulta que el agente necesitaba hacer cada mañana pasaba por una tabla que un equipo distinto regeneraba de madrugada, sin avisar a nadie cuando le cambiaba las columnas. Nadie lo había ocultado. Simplemente esa dependencia no tenía dueño, y una dependencia sin dueño no aparece en ninguna revisión hasta el día en que rompe algo que sí lo tiene.
TL;DR. El data readiness no es limpieza de datos, es una propiedad evaluable de la infraestructura que hay debajo: acceso, estabilidad del esquema, permisos y calidad medida. Todo el mercado recomienda prepararlos y entrega una checklist, pero ninguna de esas listas dice quién los prepara ni con qué skill concreta, y ese silencio es exactamente donde se decide si el proyecto avanza o se queda en staging. Según el análisis de mercado de Shakers, de cada 100 ofertas españolas que exigen construir agentes, 37 piden alguna skill de datos y ninguna pide una herramienta de gobierno o calidad del dato. El piloto no cruza porque nadie está contratando la mitad de abajo.
Data readiness es una propiedad del dato, no del modelo
Un modelo no arregla un permiso que no existe. Tampoco adivina qué significa una columna que cambió de nombre el martes, ni sabe que la tabla que está leyendo lleva nueve días sin actualizarse y que por eso responde con confianza absoluta sobre un inventario que dejó de ser cierto la semana pasada. No lo detecta. No tiene con qué.
Esa es la línea que separa las dos conversaciones. Elegir modelo, ajustar el prompt y medir la calidad de la respuesta es trabajo sobre el sistema de IA; garantizar que el dato llega, que llega con la misma forma que ayer y que quien lo consulta tiene derecho a verlo es trabajo sobre la infraestructura. La primera se paga en tokens y en semanas de iteración. La segunda se paga en perfiles.
El data readiness es la segunda. Se puede evaluar entera antes de escribir la primera línea de código del agente, que es justo el orden inverso al que sigue casi todo el mundo cuando arranca un piloto con prisa y con una fecha de demo ya comunicada al comité.
Las cuatro dimensiones que se pueden evaluar
Una checklist genérica de veinte puntos no sirve para decidir. Estas cuatro sí, porque cada una se responde con una pregunta cerrada y tiene un dueño identificable:
| Dimensión | La pregunta que la resuelve | Señal de que no está |
|---|---|---|
| Acceso | ¿Puede el agente leer el dato en el momento en que lo necesita, sin intervención manual? | Alguien exporta un CSV para que el piloto funcione |
| Estabilidad del esquema | ¿Cambia la forma del dato sin que nadie avise aguas abajo? | El agente se rompe los lunes y nadie sabe por qué |
| Permisos y trazabilidad | ¿Está resuelto quién puede ver qué, y queda registro de lo que consultó el agente? | El piloto corre con credenciales de administrador |
| Calidad conocida | ¿Está medida la calidad, con umbrales y alertas, o solo se supone? | La respuesta es "los datos están bien" sin cifra detrás |
La cuarta es la que más se malinterpreta. Calidad conocida no significa datos perfectos: significa saber el porcentaje de nulos de un campo crítico, tener un umbral y que alguien reciba un aviso cuando se cruza. Un dato mediocre y medido es operable. Un dato bueno y no medido es una apuesta.
La segunda dimensión tiene un mecanismo formal para resolverse, que es el de los contratos de datos entre equipos. Aquí basta con saber si existe o no.
Quién monta cada dimensión
Este es el paso que falta en todas las checklists del mercado. Una dimensión sin perfil asignado es una intención, y las cuatro se sostienen sobre skills concretas y verificables:
| Dimensión | Perfil que la sostiene | Skills observables |
|---|---|---|
| Acceso | Data Engineer | Airflow, SQL, el almacén en uso (Snowflake, Databricks) |
| Estabilidad del esquema | Analytics Engineer con criterio de contrato | dbt, versionado de esquema, CI/CD aplicado a datos |
| Permisos y trazabilidad | Data Platform Engineer | Catálogo (Collibra, Purview, Unity Catalog), IAM, linaje |
| Calidad conocida | Analytics Engineer o Data Quality Engineer | Tests sobre datos, observabilidad, definición de umbrales |
Ninguno de estos cuatro es el perfil que se contrata para construir el agente. Al agente lo monta un ingeniero de aplicación, con otro stack y otra trayectoria, y esa diferencia, que parece un detalle de organigrama sin consecuencias operativas, es la que explica por qué el proyecto se queda parado meses sin que nadie sepa señalar la causa.
El marco que ordena todo esto por encima de las cuatro dimensiones es la gobernanza de datos. El readiness es su estado medible en un momento dado.
Lo que dice el mercado: 37 de cada 100 ofertas de agentes piden datos
Aquí es donde el argumento deja de ser opinión. Según el análisis de mercado de Shakers sobre 15.618 ofertas tech españolas con skills etiquetadas, de un total de 18.341 recogidas entre el 14 de junio y el 3 de agosto de 2026, hay 535 ofertas que exigen LangChain. Analizamos 100 de ellas y contamos qué skills aparecían al lado:
- Python 87, AWS 60, Azure 54, Docker 38, CI/CD 38, OpenAI 37, LlamaIndex 33, Kubernetes 21.
- SQL 18, Airflow 11, Kafka 7, Databricks 6, Snowflake 5, Spark 3, dbt 1.
- Con alguna skill de pipeline de datos: 37 de 100.
- Con alguna herramienta de gobierno o calidad del dato: 0 de 100.
El stack que acompaña a los agentes es Python, cloud, contenedores e integración continua. Es el perfil de una aplicación. No el de una plataforma de datos.
El contraste en el mercado completo va en la misma dirección, comparando herramienta contra herramienta. Collibra aparece en 2 ofertas. Purview, Atlan y Unity Catalog aparecen en cero. Enfrente: Kafka 949, Spark 738, Databricks 720, Airflow 591, Snowflake 443, dbt 409. Hay demanda amplia de mover el dato y demanda casi nula de gobernarlo.
Tres salvedades, porque el dato propio se publica con sus límites o no se publica:
- La muestra son las 100 primeras de 535, no una muestra aleatoria. Es el 18,7% del universo y el orden lo fija la API, no un muestreo estadístico.
- Que no aparezcan esas herramientas no prueba que no haya práctica de gobierno. Una empresa puede gobernar sus datos sin Collibra. Lo defendible es la señal de demanda por skill, no la madurez real de las empresas.
- La taxonomía etiqueta herramientas, no conceptos. Por eso el contraste se hace entre herramientas comparables y nunca entre un concepto y una herramienta, que daría cero por cómo funciona la etiqueta y no por lo que pide el mercado.
Con esos límites puestos, la lectura aguanta: el mercado español está contratando a quien construye el agente y no a quien sostiene el dato que lo alimenta. Es la cara concreta del implementation gap que midió BCG en enero de 2025, cuando encontró que el 75% de las empresas había probado IA y solo el 25% había visto resultados. McKinsey publicó en junio de 2026 un artículo dedicado al data readiness para IA, señal de que el asunto ya subió del equipo técnico al comité.
Por qué el piloto funciona y producción no
Un piloto se construye sobre condiciones que producción no reproduce. El dataset se curó a mano, el esquema estuvo congelado esas semanas, el volumen cabía en memoria y los permisos se resolvieron dando acceso amplio a una cuenta de servicio para no bloquear la demo.
Producción rompe las cuatro a la vez. Entran fuentes que nadie inventarió, el esquema vuelve a moverse al ritmo de los equipos que lo publican, el volumen obliga a decidir qué se consulta en caliente y qué se calcula por adelantado, y el acceso amplio deja de ser aceptable en el momento exacto en que el agente toca un dato con nombre y apellidos y alguien de legal pregunta quién autorizó esa consulta.
Por eso el diagnóstico "el modelo no es lo bastante bueno" suele ser falso. El modelo hace lo mismo que hacía en la demo. Ha cambiado el resto.
El orden correcto: evaluar antes de desplegar
La evaluación de readiness cuesta menos que el piloto que se va a estancar. Y se hace antes. Cuatro preguntas, un dueño por dimensión y una decisión honesta sobre cuáles de las cuatro están cubiertas hoy, cuáles se pueden cubrir en unas semanas y cuáles exigen sentarse a contratar.
Lo que cambiaríamos si volviéramos atrás es sencillo de decir y cuesta de aplicar: mirar el organigrama antes que el modelo. Si ninguna de las cuatro dimensiones tiene un nombre detrás, el proyecto no tiene un problema de IA. Tiene un hueco de capacidad en el equipo de datos, y cerrarlo con talento certificado en skills verificadas, en plantilla o en equipos blended, es una decisión de infraestructura de contratación.
Habla con un experto Shakers si necesitas cubrir esas dimensiones con perfiles verificados.
Preguntas frecuentes sobre data readiness para agentes
- ¿Data readiness y gobernanza de datos son lo mismo?
-
No. La gobernanza es el marco de reglas, roles y responsabilidades sobre el dato. El data readiness es el estado medible que ese marco produce en un momento concreto, evaluable con cuatro preguntas: acceso, estabilidad del esquema, permisos y calidad conocida. Una empresa puede tener gobernanza documentada y no estar lista.
- ¿Hace falta un contrato de datos para estar listo?
-
No es obligatorio, pero resuelve la dimensión más frágil. El contrato de datos formaliza qué forma tiene el dato que un equipo publica y qué pasa cuando cambia. Sin él la estabilidad del esquema depende de que alguien avise por su cuenta, y eso falla en cuanto crece el número de equipos implicados.
- ¿Qué perfil evalúa el data readiness?
-
Un Data Platform Engineer o un Data Engineer senior con visión de plataforma, no el ingeniero que construye el agente. Son dos conjuntos de skills distintos: uno trabaja sobre el dato y sus permisos, el otro sobre el modelo y la aplicación. Confundirlos es el error más común al arrancar.
- ¿Cuánto tarda una evaluación de data readiness?
-
Depende de cuántas fuentes entran y de si ya existe un catálogo. El inventario de fuentes y la revisión del esquema son rápidos. Lo que alarga la evaluación es casi siempre resolver los permisos, porque exige encontrar al dueño de cada dato y no todos están documentados.
El agente que no cruza a producción rara vez tiene un problema de modelo. Tiene un problema de propiedad, y esa pregunta no se responde comprando herramienta ni ampliando la ventana de contexto: se responde señalando a alguien concreto en el organigrama y comprobando, una por una, que las skills que esa posición necesita están de verdad ahí. Casi nunca lo están. Y ese es el trabajo.