Data Practice: cómo convertir los datos en una capacidad real de negocio

Una organización puede tener un Data Lake, pipelines, dashboards, infraestructura cloud y varios proyectos de inteligencia artificial en marcha y, aun así, seguir teniendo dificultades para responder preguntas aparentemente simples: ¿cuál es el dato correcto?, ¿de dónde viene?, ¿quién responde por él?, ¿cuánto cuesta procesarlo?, ¿qué ocurre si falla un pipeline? o ¿está realmente preparado para alimentar un modelo de IA?

El problema, entonces, no siempre es la falta de tecnología.

Con frecuencia, aparece cuando arquitectura, ingeniería, operación, gobierno y analítica evolucionan como iniciativas independientes. Se incorporan nuevas plataformas, se integran fuentes y se desarrollan casos de uso, pero las capacidades necesarias para operar los datos de manera confiable no avanzan al mismo ritmo.

La expansión de la inteligencia artificial está haciendo esa brecha todavía más visible. El estudio The Data Reality Check: 2025 Data and AI Adoption, de DataArt encontró que 82% de las organizaciones analizadas carecía de la madurez de datos necesaria para desplegar IA a escala de producción. El mismo análisis identificó la gobernanza y la calidad como uno de los principales cuellos de botella para avanzar desde la experimentación hacia escenarios reales de uso.

El desafío, por tanto, consiste en desarrollar una Data Practice capaz de conectar esas capacidades y convertir los datos en una plataforma confiable, escalable y medible para operación, analítica e inteligencia artificial.

¿Qué es una Data Practice?

Una Data Practice puede entenderse como una capacidad integrada para diseñar, construir, gobernar, operar y evolucionar el ecosistema de datos de una organización. No es una metodología universal ni una tecnología específica, pero tampoco es simplemente tener un equipo de Data Engineering o implementar un Data Lake.

Su función es conectar disciplinas que con frecuencia se administran por separado:

Data Architecture + Data Engineering + DataOps + Data Governance + Data Quality + observability + FinOps + analytics + AI Readiness.

El valor aparece cuando estas capacidades dejan de resolver problemas aislados y comienzan a responder a una estrategia común.

Por ejemplo, una decisión de arquitectura no debería evaluarse únicamente por su capacidad técnica. También debería considerar cuánto costará operarla, cómo se monitorearán sus pipelines, qué controles de acceso requerirá, quién será responsable de los datos, qué nivel de trazabilidad tendrá y qué casos de analítica o IA deberá soportar posteriormente.

Desde esa perspectiva, una Data Practice cambia la pregunta.

Ya no se trata solo de “¿qué plataforma deberíamos implementar?”, sino de “¿qué capacidades necesitamos para que nuestros datos puedan utilizarse con confianza y evolucionar con el negocio?”.

El problema de gestionar los datos como iniciativas separadas

Muchas organizaciones han desarrollado su ecosistema de datos de manera incremental.

Primero aparece una necesidad de reporting. Luego una integración. Después un Data Lake. Más tarde una plataforma cloud. Se agregan pipelines, herramientas de Business Intelligence, modelos analíticos y, finalmente, iniciativas de machine learning o GenAI.

Cada proyecto puede resolver un problema específico y seguir siendo técnicamente correcto. La dificultad aparece cuando nadie observa el sistema completo.

Entonces empiezan a acumularse síntomas conocidos:

Distintas fuentes representan de manera diferente una misma entidad;
Los equipos no saben cuál es el dato confiable;
Existen pipelines críticos con poca observabilidad;
Los costos de infraestructura crecen sin suficiente trazabilidad;
Data Engineers y Data Analysts dedican tiempo a limpiar o reconciliar información;
Catálogo, linaje y ownership están incompletos;
La arquitectura dificulta incorporar nuevos casos de uso;
Los proyectos de IA consumen información cuya calidad o procedencia no siempre puede demostrarse.

Este tipo de problemas también está en el centro de la propuesta actual de ACL Data Practice, que identifica fragmentación de datos, baja observabilidad, costos difíciles de controlar, gobierno insuficiente, limitaciones arquitectónicas y preparación para IA como desafíos que deben abordarse de forma coordinada.

El resultado es una organización que tiene infraestructura de datos, pero todavía no necesariamente una capacidad de datos.

La diferencia es importante.

Una plataforma puede almacenar y procesar información. Una Data Practice incorpora además las reglas, responsabilidades, procesos operativos y mecanismos de control necesarios para que esa plataforma siga funcionando cuando aumentan los datos, los usuarios, las exigencias regulatorias y los casos de uso.

¿Qué capacidades debe conectar una Data Practice?

No todas las organizaciones necesitan exactamente la misma arquitectura ni las mismas herramientas. Sin embargo, existen cuatro dimensiones que conviene analizar de forma coordinada.

1. Arquitectura y plataforma que puedan evolucionar

La arquitectura define mucho más que dónde se almacenan los datos. Determina cómo se integran las fuentes, cómo circula la información, qué dependencias existen, cómo aumenta la capacidad y qué tan complejo será incorporar nuevos consumidores y casos de uso.

Aquí pueden aparecer modelos como Data Lake, Lakehouse o arquitecturas Medallion, además de diferentes combinaciones de servicios cloud y plataformas especializadas, pero ninguna de esas alternativas debería convertirse automáticamente en la respuesta.

Una arquitectura adecuada depende del contexto: volumen y variedad de datos, latencia requerida, sistemas existentes, exigencias regulatorias, capacidades internas, costos, cargas analíticas y objetivos futuros.

Esto implica mantener una mirada suficientemente agnóstica de la tecnología.

La pregunta correcta no es si todas las empresas deberían migrar hacia una plataforma determinada. Es si la arquitectura actual permite integrar, gobernar, observar y escalar los datos necesarios para las prioridades del negocio.

Una Data Practice debe poder evaluar esa situación, detectar deuda arquitectónica y decidir dónde conviene modernizar, integrar, migrar o conservar componentes existentes.

2. Ingeniería y operación que hagan confiable la plataforma

Construir un pipeline es solamente una parte del trabajo, después comienza la operación.

¿Qué ocurre si una fuente deja de entregar información? ¿Cuánto demora el equipo en detectar el problema? ¿Puede identificarse qué procesos downstream quedaron afectados? ¿Existen mecanismos de recuperación? ¿Cuánto cuesta ejecutar cada workload? ¿Se están utilizando recursos sobredimensionados?

Aquí convergen Data Engineering, DataOps, CI/CD, observability, monitoring y FinOps.

La observabilidad permite pasar de descubrir un problema cuando un usuario encuentra un dashboard incorrecto a detectar señales sobre disponibilidad, latencia, volumen, rendimiento o calidad antes de que el impacto se propague.

FinOps incorpora otra dimensión: la eficiencia económica de la plataforma.

En entornos cloud, incrementar capacidad técnica también puede aumentar rápidamente el consumo. Por eso no basta con preguntar si una arquitectura funciona; también importa saber cuánto cuesta operar cada componente y cuánto valor produce ese gasto.

Una Data Practice madura convierte estas variables en parte permanente de la operación, en lugar de abordarlas únicamente cuando aparece una falla o una factura inesperada.

3. Gobierno que convierta datos disponibles en datos confiables

Tener acceso a un dato no significa necesariamente poder confiar en él.

Para utilizarlo en una decisión relevante, una organización debería ser capaz de establecer, entre otras cosas:

Qué significa;
De dónde proviene;
Qué transformaciones ha experimentado;
Qué nivel de calidad tiene;
Quién responde por él;
Quién está autorizado para utilizarlo.

Ahí convergen Data Quality, Data Catalog, Data Lineage, ownership y controles de acceso.

Como plantea Alejandro Contreras, Head of Data Practice de ACL powered by DataArt:

“Gobernar datos no es crear documentación. Es saber qué información existe, quién es responsable de ella, de dónde proviene, quién puede acceder y qué reglas de calidad debe cumplir.”

Esto también requiere distribuir responsabilidades.

El gobierno de datos difícilmente escala si queda confinado a un equipo central. Data Owners, Data Stewards y responsables técnicos necesitan derechos de decisión claros y mecanismos concretos para validar definiciones, calidad y uso.

En Roles del gobierno de datos: quién decide, quién valida y quién opera profundizamos precisamente en esa distribución de responsabilidades.

La confianza, además, necesita evidencia.

Un catálogo permite entender qué datos existen y qué significan; la calidad permite determinar si cumplen las condiciones necesarias para utilizarlos; y el linaje ayuda a reconstruir su recorrido desde la fuente hasta los procesos que los consumen.

Estas capacidades se complementan y pueden revisarse con mayor detalle en Calidad, catálogo y linaje de datos: las bases para construir información confiable.

Gobernar datos, por tanto, no equivale simplemente a documentarlos. Significa incorporar decisiones y controles dentro de su ciclo de vida.

Para organizaciones que están comenzando a estructurar esta disciplina, la Guía completa para implementar un gobierno de datos eficaz desarrolla con mayor profundidad cómo llevar estos principios hacia un modelo operativo.

4. AI Readiness: preparar los datos antes de escalar IA

La presión por implementar inteligencia artificial está haciendo más visibles problemas de datos que antes podían permanecer ocultos.

Un dashboard construido sobre información inconsistente ya era un problema. Un modelo o agente de IA que utiliza esa misma información puede ampliar el impacto porque incorpora el dato dentro de decisiones, recomendaciones y procesos automatizados.

La brecha también aparece cuando se consulta directamente a los responsables empresariales de los datos.

El 2025 Chief Data Officer Study del IBM Institute for Business Value, basado en una encuesta global a 1.700 Chief Data Officers, encontró que solo 26% considera que sus capacidades de datos pueden sostener nuevas fuentes de ingresos habilitadas por IA. El estudio también muestra que 83% identifica los silos de datos como un obstáculo para innovar, realizar analítica en tiempo real y tomar decisiones.

Estas cifras no significan que una empresa deba reconstruir toda su plataforma antes de implementar inteligencia artificial.

El concepto de AI Readiness debe entenderse de una forma más práctica: determinar si los datos, controles y procesos que necesita un caso de uso específico son adecuados para llevarlo a producción.

Eso puede involucrar:

Calidad y representatividad de los datos;
Disponibilidad y actualización;
Metadata y contexto;
Fuentes autorizadas;
Permisos y controles de acceso;
Información sensible;
Trazabilidad;
Observabilidad;
Mecanismos de validación y supervisión.

Como resume Alejandro Contreras:

“Puedes tener una gran capa de IA, pero si debajo tienes malos datos, solo estás sofisticando el problema.”

La frase resume una tensión relevante: incorporar un modelo más avanzado no resuelve automáticamente problemas existentes en las fuentes que lo alimentan.

En escenarios de GenAI, RAG o AI Agents, estas dependencias aumentan porque los modelos pueden consumir múltiples repositorios y participar directamente en nuevas cadenas de decisión.

Por eso, la gobernanza para IA no debería diseñarse como una capa posterior.

En Gobierno de datos para IA: cómo escalar modelos y agentes sin perder control profundizamos en cómo calidad, linaje, permisos, fuentes autorizadas y trazabilidad cambian cuando la información comienza a alimentar sistemas de inteligencia artificial.

De proyectos de datos a una capacidad continua

Otro cambio importante consiste en dejar de pensar la estrategia de datos exclusivamente como una secuencia de proyectos.

Una migración puede terminar. La operación de la plataforma, no.

Lo mismo ocurre con un catálogo, un modelo de calidad o una arquitectura de datos: pueden implementarse en un momento determinado, pero después necesitan mantenerse, monitorearse y adaptarse.

Una forma práctica de estructurar esa evolución es trabajar en tres etapas:

Diagnóstico → Implementación → Operación continua.

Esta misma lógica estructura el modelo de trabajo de ACL Data Practice: identificar primero una brecha concreta, implementar una solución priorizada y luego acompañar su operación y evolución.

Diagnóstico: entender la brecha antes de elegir la solución

El primer paso debería ser determinar dónde está realmente el problema.

Una organización puede creer que necesita modernizar su arquitectura cuando su mayor brecha está en observabilidad. Puede estar evaluando una nueva plataforma cuando el problema principal está en la forma en que utiliza su capacidad actual. O puede querer desplegar IA cuando todavía no existen suficientes mecanismos de calidad, catálogo u ownership sobre los datos críticos.

Un diagnóstico puede revisar arquitectura, integraciones, pipelines, gobierno, calidad, costos y AI Readiness para definir prioridades basadas en riesgo, impacto y factibilidad.

El objetivo no es producir un assessment que termine en una presentación, sino identificar decisiones concretas.

Implementación: resolver una prioridad verificable

Una vez identificada la brecha, la organización puede intervenir donde exista mayor impacto.

Eso puede significar modernizar una arquitectura, migrar información, construir o rediseñar pipelines, incorporar observabilidad, implementar Data Quality, desarrollar catálogo y linaje o habilitar una arquitectura para nuevos escenarios analíticos.

El alcance debería asociarse a resultados verificables.

Por ejemplo:

Disminuir incidentes sobre pipelines críticos;
Aumentar la cobertura de linaje en determinados dominios;
Reducir el tiempo necesario para detectar fallas;
Mejorar la trazabilidad del gasto cloud;
Aumentar el porcentaje de datos críticos con reglas de calidad;
Asignar ownership sobre activos prioritarios;
Evaluar qué datasets cumplen las condiciones necesarias para un caso de IA.

Cuando no existe un benchmark válido para una organización, resulta más útil establecer una línea base propia y medir la evolución que utilizar porcentajes de mejora genéricos.

Operación: mantener el valor después del proyecto

Esta etapa suele recibir menos atención, pero es donde una Data Practice demuestra si realmente existe.

Las plataformas cambian.
Los costos cambian.
Aparecen nuevas fuentes.
Los modelos evolucionan.
Las reglas de negocio se modifican y surgen nuevos requerimientos.

Por eso, observability, FinOps, DataOps, soporte, gobierno y mejora continua no deberían ser elementos accesorios, forman parte del producto operativo.

¿Todas estas capacidades tienen que existir internamente?

No necesariamente. Una organización debería mantener internamente las decisiones que forman parte de su estrategia y accountability: prioridades, ownership, políticas, niveles de riesgo aceptables y decisiones críticas sobre el uso de los datos. Pero eso no significa que todas las capacidades especializadas deban estar disponibles permanentemente dentro de la estructura.

Arquitectos de datos, especialistas en Data Governance, expertos en optimización, Data Engineers o perfiles de AI pueden requerirse con distinta intensidad dependiendo de la etapa, por eso existen modelos como especialistas fraccionados o Centers of Excellence (CoE), capaces de concentrar conocimiento especializado y ponerlo a disposición de diferentes equipos.

La decisión no debería plantearse simplemente como “interno versus externo”.

La pregunta más útil es:

¿Qué capacidades constituyen una responsabilidad permanente del negocio y cuáles necesitamos consumir con flexibilidad para ejecutar bien?

Ese equilibrio permite mantener ownership interno sin obligar a construir estructuras sobredimensionadas para capacidades cuya demanda cambia según los proyectos y prioridades.

Cómo saber por dónde empezar una Data Practice

Antes de lanzar otro proyecto o incorporar una nueva herramienta, una organización puede evaluar su situación a partir de algunas preguntas.

¿Confiamos en nuestros datos críticos para tomar decisiones?
¿Podemos rastrear su origen y las transformaciones que experimentaron?
¿Sabemos quién responde por cada dominio de información importante?
¿Tenemos suficiente visibilidad sobre el costo de nuestra plataforma de datos?
¿Podemos detectar rápidamente cuando un pipeline falla o comienza a degradarse?
¿Nuestra arquitectura permite incorporar nuevos casos de uso sin generar una nueva capa de complejidad?
¿Sabemos qué datos están realmente preparados para los casos de IA que queremos llevar a producción?

No todas las respuestas tienen que ser afirmativas.

Precisamente ahí está el valor del diagnóstico: identificar qué brechas limitan hoy al negocio, cuáles representan un riesgo y cuáles pueden esperar.

Una Data Practice debe generar capacidad, no solamente proyectos

La madurez de una organización no debería medirse únicamente por cuántas plataformas tiene, cuánto dato almacena ni cuántas iniciativas de IA consigue iniciar. Una señal más relevante es cuánto puede hacer con sus datos de manera confiable, eficiente, trazable y repetible.

Eso requiere arquitectura, pero también operación.
Ingeniería, pero también gobierno.
IA, pero también calidad, contexto y accountability.
Y, sobre todo, requiere conectar esas disciplinas alrededor de resultados concretos de negocio.

Como plantea Alejandro Contreras:

“Una práctica de datos madura debería liberar a los equipos de buscar, corregir y preparar información para que puedan concentrarse en generar insights y valor para el negocio.”

En ACL Data Pratice abordamos ese recorrido de punta a punta: desde evaluar arquitectura, plataformas, gobierno, calidad, costos y preparación para IA hasta implementar las capacidades priorizadas y acompañarlas durante su operación.

No todas las organizaciones necesitan comenzar en el mismo lugar.

Si hoy el desafío está en la arquitectura, los costos, la trazabilidad, la calidad o la preparación para nuevos casos de IA, el primer paso es identificar qué brecha está limitando realmente el valor de los datos y definir una prioridad concreta para resolverla.

¿Necesitas revisar arquitectura, gobierno, costos o preparación para IA? Conversemos sobre tu escenario de datos con ACL Data Practice.

Preguntas frecuentes sobre Data Practice

¿Qué es una Data Practice?

Una Data Practice es una capacidad organizacional y tecnológica que integra arquitectura, Data Engineering, operación, gobierno, calidad, analítica y preparación para IA para gestionar los datos de manera confiable, escalable y alineada con necesidades de negocio. No corresponde a una herramienta o metodología universal específica.

¿Cuál es la diferencia entre una Data Practice y una plataforma de datos?

Una plataforma de datos entrega infraestructura y capacidades tecnológicas para almacenar, procesar o consultar información. Una Data Practice incorpora además personas, procesos, ownership, gobierno, calidad, observabilidad, costos y mecanismos de operación continua necesarios para administrar esa plataforma como una capacidad empresarial.

¿Es necesario utilizar un Data Lake o Lakehouse para construir una Data Practice?

No. La arquitectura debe definirse según las necesidades, restricciones y sistemas de cada organización. Data Lake y Lakehouse son alternativas posibles, pero una Data Practice debería mantener una mirada agnóstica y seleccionar las capacidades tecnológicas según el problema que necesita resolver.

¿Qué relación existe entre Data Governance y Data Practice?

Data Governance es una de las capacidades que forman una Data Practice. Define responsabilidades, políticas, estándares y controles relacionados con el uso de los datos. Una Data Practice conecta ese gobierno con arquitectura, Data Engineering, DataOps, calidad y operación para que las reglas puedan aplicarse efectivamente sobre la plataforma.

¿Qué significa que los datos estén AI-ready?

Significa que los datos utilizados por un caso de inteligencia artificial cumplen las condiciones necesarias para ese uso: calidad, representatividad, disponibilidad, contexto, seguridad, metadata y gobierno, entre otras. AI Readiness debe evaluarse respecto de cada caso de uso y no simplemente como una propiedad general de toda la plataforma.

¿Cómo debería comenzar una empresa a desarrollar su Data Practice?

Conviene comenzar identificando la brecha que genera mayor impacto: arquitectura, estabilidad de pipelines, costos, gobierno, calidad, trazabilidad o preparación para IA. A partir de ese diagnóstico puede priorizarse una intervención concreta, definir métricas de éxito y posteriormente incorporar las capacidades necesarias para operarla y escalarla.

‍