Data Readiness: Las cuatro condiciones que ninguna empresa cumple por completo.

Accesibilidad, calidad, integración y gobierno. Una guía operativa para CDOs y arquitectos de datos para que dejemos de hablar del problema y empezar a medirlo. 

Data Readiness es uno de los términos más usados y menos definidos del mercado tecnológico actual. Aparece en presentaciones de consultoras, en RFPs corporativos y en pitches de proveedores con la misma frecuencia con la que se usa, ~ironía incluida~, el término “estamos trabajando en eso”. 

El problema con los términos vacíos es que vuelven invisibles los problemas reales. Una organización puede afirmar que está “avanzando en data readiness” durante tres años consecutivos sin que nadie pueda responder con precisión: ¿qué significa eso?, ¿cuánto se ha avanzado?, o ¿qué falta?.  

Mientras tanto, los proyectos de IA siguen fracasando: solo el 11% de las organizaciones ha logrado escalar implementaciones de IA generativa más allá de pilotos exploratorios, según Cloud Reality Check 2025 de NTT Data con MIT Technology Review Insights. 

Con este artículo, proponemos recuperar la utilidad operativa del término data readiness. Una organización está data ready cuando cumple simultáneamente cuatro condiciones medibles: accesibilidad, calidad, integración y gobierno.  

Las cuatro condiciones son simultáneas, no son secuenciales ni son aspiracionales, son prerrequisitos. Fallar en una, invalida las otras tres. 

1. Accesibilidad: la prueba del día hábil 

La primera condición es la más obvia y la más violada: los datos deben ser consultables sin fricción burocrática por quienes los necesitan. Si un científico de datos o un analista de negocio requiere días o semanas para obtener acceso a una fuente, el ciclo completo de iteración de un modelo se vuelve inviable. 

Se propone un criterio práctico, observable y discutible en cualquier comité técnico. No importa cuán sofisticada sea la plataforma instalada, ni cuántos diagramas de arquitectura describan flujos elegantes, si obtener acceso de lectura a una tabla del dominio crítico tarda más de un día hábil, lo cual se considera un tiempo operativo razonable, la condición falla.  

Cuatro escenarios que se repiten 

En nuestra experiencia, hay cuatro escenarios que aparecen una y otra vez en organizaciones que afirman tener accesibilidad resuelta. No son fallas técnicas: son patrones organizacionales.  

• El data warehouse cerrado, donde cada consulta nueva requiere un ticket que un equipo central prioriza según criterios opacos.  

• Los permisos por correo, donde el acceso depende de quién conozca a quién dentro de TI.  

• Los formatos propietarios que obligan a exportaciones manuales para cualquier análisis fuera del sistema fuente.  

• Las extracciones programadas que entregan datos con días de retraso, cuando el caso de uso requiere minutos. 

El indicador más simple para medir accesibilidad real es contar, durante un trimestre, cuántas solicitudes de acceso a datos del equipo de analítica se resolvieron en menos de 24 horas. Si la respuesta es menos del 70%, la organización tiene un problema de accesibilidad, independientemente de lo que diga su roadmap de datos. 

2. Calidad: el costo silencioso 

La segunda condición es la que más se subestima en los presupuestos y la que más cuesta en la operación. Los datos deben ser completos, actualizados y consistentes. Gartner estima que las empresas pierden, en promedio, USD 12,9 millones al año por mala calidad de datos¹. Pero el costo visible, el que aparece en una auditoría, es solo una fracción del costo real. 

El costo invisible es mayor. Aparece, por ejemplo, en data scientists que pierden entre el 60% y el 80% de su tiempo en tareas de preparación de datos; en modelos que producen recomendaciones erróneas porque sus datos de entrada tenían sesgos no detectados, y/o en decisiones comerciales basadas en dashboards que nadie volvió a validar después del último cambio en el sistema fuente. Cada uno de estos costos es difícil de atribuir individualmente, pero suman cifras estructurales. 

Cómo se construye sin frenar el negocio 

Un programa de calidad de datos no funciona como un proyecto único de limpieza masiva. Funciona como una disciplina continua con tres componentes: validación en origen (reglas que rechazan datos malformados antes de que entren al sistema), monitoreo automatizado (alertas cuando una métrica de calidad cae bajo un umbral) y responsabilidad atribuida (cada dominio tiene un dueño de la calidad, no un equipo central que limpia lo que otros ensuciaron). 

El error frecuente es intentar lograr “100% de calidad en todos los datos”. Es una ambición que paraliza. La práctica madura es definir niveles de calidad diferenciados por dominio: los datos que alimentan el reporte regulatorio mensual, requieren calidad máxima; los datos que alimentan un experimento de marketing, pueden tolerar mayor ruido. Sin esa diferenciación, los recursos se diluyen. 

3. Integración: el cuello de botella estructural 

La tercera condición es la más difícil técnicamente y la que más distingue a las organizaciones maduras: los datos deben ser cruzables entre dominios sin trabajo manual significativo. Solo el 12% de las empresas considera que sus datos están al nivel necesario para escalar IA, según Cloud Reality Check 2025². La integración es donde se rompen los proyectos que parecían viables en el papel. 

El problema no es nuevo, pero la IA lo amplificó. Un dashboard ejecutivo puede tolerar que el cruce entre ventas y servicio al cliente requiera una conciliación manual mensual. Un modelo de IA que personaliza recomendaciones en tiempo real, no. La diferencia entre ambos casos no es de complejidad analítica: es de arquitectura de integración. 

APIs abiertas y event-driven architecture 

Las organizaciones que resuelven la integración estructuralmente lo hacen sobre dos pilares arquitectónicos. Primero, APIs abiertas sobre los sistemas críticos: el ERP, el CRM, el core transaccional, el sistema de inventario, exponen sus datos y operaciones a través de interfaces estandarizadas, autenticadas y documentadas. No archivos planos nocturnos. No conexiones directas a bases de datos productivas. APIs. 

Segundo, arquitecturas orientadas a eventos: los cambios relevantes, una venta, un ticket, una actualización de cliente, se publican como eventos que cualquier sistema autorizado puede consumir en tiempo real. Esto desacopla a los productores de datos de sus consumidores y permite que la organización agregue nuevos casos de uso sin reabrir integraciones existentes. 

Cerca del 74% de las empresas tiene dificultad para escalar valor con IA, principalmente por arquitecturas legacy, según McKinsey³. No es casualidad. Las aplicaciones monolíticas que dominaron las décadas anteriores fueron diseñadas para optimizar transacciones, no para exponer información. Resolver eso no es opcional. Es la inversión estructural sobre la cual descansa todo lo demás. 

4. Gobierno: La brecha del 95% 

La cuarta condición es la menos técnica y la más subestimada. El 95% de las organizaciones reporta brechas significativas en gobernanza de IA, según el último World Quality Report⁴. La cifra es casi idéntica a la del fracaso de proyectos de IA (y no por coincidencia). 

Gobierno de datos no significa un comité que se reúne cada dos meses para revisar políticas, significa responsabilidades operativas claras: para cada dominio de datos relevante, debe existir un responsable identificable que responda por su calidad, su acceso, su evolución y su cumplimiento regulatorio. Sin esa atribución, las decisiones críticas se diluyen en la organización. 

Por dominio, no por sistema 

El error frecuente es organizar el gobierno alrededor de los sistemas instalados: un responsable del SAP, un responsable del Salesforce, un responsable del data warehouse. Esa organización refleja la historia de las compras de software, no la lógica del negocio. Un cliente no vive en el CRM: vive como concepto transversal que aparece en facturación, servicio, marketing, logística y finanzas. El gobierno tiene que organizarse por dominio de negocio, no por aplicación. 

El 68% de los CEOs afirma que la gobernanza de IA debe integrarse desde el diseño, no agregarse después, según IBM Institute for Business Value⁵. La afirmación es correcta y, paradójicamente, casi siempre incumplida en la práctica. La razón es organizacional: definir un dueño de dominio implica redistribuir poder dentro de la empresa, y eso es más difícil que comprar otra plataforma. 

Las cuatro son simultáneas 

La tentación natural frente a este marco es secuenciarlo: “primero arreglemos la accesibilidad, luego trabajemos la calidad, después abordamos la integración, y al final formalizamos el gobierno”. El razonamiento es comprensible pero erróneo. Las cuatro condiciones son simultáneas porque se sostienen mutuamente. 

Sin gobierno claro, no hay quien responda por la calidad. Sin calidad, la integración propaga errores en lugar de información. Sin integración, la accesibilidad solo da acceso a fragmentos parciales. Sin accesibilidad, el gobierno se vuelve un ejercicio teórico desconectado de la operación. Fallar en una condición invalida las otras tres. 

Esto no significa que haya que resolverlas todas en paralelo a escala empresarial. Significa que el avance debe ser por dominio: tomar un dominio crítico (cliente, producto, financiero) y llevarlo a data readiness completa antes de pasar al siguiente. La organización que logra eso en su primer dominio aprende un patrón replicable. La que intenta resolver las cuatro condiciones a escala global sin priorizar dominios, no llega a finalizar ninguna. 

La organización data ready no es la que tiene la mejor plataforma instalada. Es la que puede responder con claridad las cuatro preguntas, dominio por dominio. 

El criterio operativo 

Una organización está realmente lista para IA cuando puede responder afirmativamente cuatro preguntas sobre cada uno de sus dominios críticos: 

Accesibilidad: ¿Un analista autorizado puede consultar los datos de este dominio en menos de un día hábil? 

Calidad: ¿Existe un nivel de calidad definido, monitoreado y atribuido a un responsable? 

Integración: ¿Este dominio expone datos vía APIs modernas, cruzables en tiempo real con otros dominios? 

Gobierno: ¿Hay un dueño de dominio identificado, con autoridad y responsabilidad explícita? 

Las organizaciones que pueden responder “sí” a las cuatro preguntas para sus dominios críticos son las que están capturando valor real con IA. Los líderes en IA capturan 2,5 veces más valor que los rezagados de la misma industria, según Boston Consulting Group.  

La brecha no se cierra contratando talento ni suscribiendo modelos. Se cierra haciendo, dominio por dominio, el trabajo invisible del data readiness real. 

---

Este artículo es parte de la serie Cloud con Criterio.

Este artículo es parte de Cloud con Criterio, la serie editorial de ARKHO para líderes que toman decisiones sobre transformación digital. Cinco ebooks que abordan, con honestidad periodística y profundidad técnica, los cinco temas que definen una migración exitosa a la nube: IA, migración, modernización, business case y stakeholder management.

Porque en la nube, las buenas decisiones no se toman por moda. Se toman con criterio.

---

Fuentes: 

1.- Gartner, Magic Quadrant for Data Quality Solutions (July 2020): Survey of 154 enterprise customers on estimated cost of poor data quality. gartner.com/en/data-analytics/topics/data-quality 

2.- NTT Data, en colaboración con MIT Technology Review Insights. Cloud Reality Check 2025. Estudio global sobre madurez cloud y adopción de IA. Publicado en 2025. 

3.- McKinsey & Company. The State of AI, encuesta global 2024. Análisis sobre madurez de capacidades de IA. 

4.- OpenText / Capgemini / Sogeti. World Quality Report 2024-2025. Estudio anual sobre calidad de software y gobernanza de TI. Sección de gobernanza de IA. 

5.- IBM Institute for Business Value. CEO Decision-Making in the Age of AI, 2024. Encuesta global a CEOs sobre prioridades de IA.