Categoría: Data Governance

Sin una gobernanza de datos robusta, los sistemas de salud no pueden garantizar ni la continuidad del cuidado del paciente ni el cumplimiento regulatorio. La discusión ya no es si implementarla, sino cómo construirla con los controles correctos en un sector donde un dato erróneo puede costar una vida.

Los datos clínicos son, por naturaleza, fragmentados: provienen de historias clínicas electrónicas, dispositivos de monitoreo, laboratorios, farmacias y registros de seguros. Sin una capa de gobernanza que unifique definiciones, asigne ownership y garantice calidad, esa fragmentación se traduce directamente en diagnósticos incompletos, duplicación de estudios y errores de medicación. La atención centrada en el paciente —principio que hoy organiza los modelos de salud más avanzados— depende de que el dato correcto esté disponible, sea confiable y llegue en el momento oportuno.

Qué falla cuando el dato clínico no tiene dueño

El problema central en la mayoría de los sistemas hospitalarios no es la ausencia de datos, sino la ausencia de accountability sobre esos datos. En el marco DAMA-DMBOK, el concepto de data stewardship —la responsabilidad formal sobre un dominio de datos— es el núcleo operativo de cualquier programa de gobernanza. En salud, esa responsabilidad suele estar implícita en el médico tratante o en el área de sistemas, pero rara vez está formalizada: no hay un data steward clínico con criterios documentados, no hay un glosario de negocio que defina qué es “episodio de atención” o “diagnóstico principal”, y no hay un proceso de resolución de conflictos cuando dos fuentes dicen cosas distintas sobre el mismo paciente.

El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), identifica la gestión del ciclo de vida del dato como una de las capabilities críticas en entornos regulados. En salud, eso implica saber cuándo un dato nace, quién lo modifica, cuándo expira y bajo qué condiciones puede ser compartido con terceros. Sin data lineage trazable —es decir, sin poder seguir el recorrido completo de un dato desde su origen hasta su uso— cualquier auditoría clínica o regulatoria se convierte en un ejercicio de arqueología forense.

Los marcos regulatorios en LATAM que presionan hacia la formalización

América Latina no tiene un equivalente directo al HIPAA estadounidense, pero la presión regulatoria sobre datos de salud crece en toda la región. En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) clasifica los datos de salud como datos sensibles con requisitos de tratamiento más estrictos, incluyendo base legal explícita y medidas técnicas y organizativas específicas. La Autoridade Nacional de Proteção de Dados (ANPD) ya emitió orientaciones sobre cómo aplica la ley en contextos de salud pública. En Argentina, la Ley 25.326 de Protección de Datos Personales contempla categorías especiales para datos de salud, y la AAIP (Agencia de Acceso a la Información Pública) ha señalado reiteradamente que el sector salud es de atención prioritaria en sus planes de fiscalización. En México, la LFPDPPP y su reglamento establecen obligaciones específicas para quienes tratan datos de salud en el sector privado, con requerimientos de consentimiento expreso y medidas de seguridad reforzadas.

Lo que estas regulaciones tienen en común es que no se satisfacen con declaraciones de política interna: exigen evidencia de controles operativos, lo que implica —en la práctica— un programa de gobernanza de datos funcionando. Una organización de salud que no puede demostrar quién autorizó el acceso a un expediente, qué datos comparte con qué terceros y bajo qué base legal, está expuesta a sanciones independientemente de si hubo o no una brecha.

Cuándo aplica la gobernanza clínica / cuándo NO alcanza con política de privacidad

La gobernanza de datos en salud aplica en cualquier contexto donde se tomen decisiones clínicas, operativas o estratégicas basadas en datos de pacientes: hospitales, clínicas, aseguradoras de salud, laboratorios, plataformas de telemedicina y proveedores de sistemas de información hospitalaria (HIS/EMR). No aplica solo al área de IT: la gobernanza es un programa de negocio con responsabilidades distribuidas entre clínicos, administradores y equipos de datos. Una política de privacidad publicada en el sitio web no reemplaza ni sustituye un programa de gobernanza: la política declara intenciones, la gobernanza implementa controles verificables. Tampoco alcanza con tener un DPO (Delegado de Protección de Datos) designado si ese rol no cuenta con las estructuras de datos bien definidas para ejercer sus funciones.

Tres capabilities que un CDO de salud debe priorizar este trimestre

• Catálogo de datos clínicos activo: un inventario de los dominios de datos críticos (paciente, episodio, diagnóstico, medicamento, resultado) con ownership asignado y definiciones acordadas entre clínicos y equipos de datos. Sin catálogo, no hay punto de partida para ninguna iniciativa de calidad o interoperabilidad.
• Data lineage en flujos de alto riesgo: trazabilidad documentada de los datos que alimentan decisiones clínicas automatizadas o semiautomatizadas —alertas de medicación, scores de riesgo, derivaciones— para que cualquier error sea rastreable hasta su origen.
• Marco de clasificación de datos sensibles: una taxonomía que diferencie datos de salud por nivel de sensibilidad y defina controles de acceso diferenciados, alineada con los requisitos de la LGPD, Ley 25.326 o LFPDPPP según la jurisdicción operativa de la organización.

El modelo Non-Invasive Data Governance de Bob Seiner ofrece un punto de entrada pragmático para hospitales que no quieren crear una burocracia paralela: en lugar de nombrar nuevos roles, formaliza responsabilidades que los profesionales de salud ya ejercen informalmente, lo que reduce la resistencia al cambio en culturas clínicas muy estructuradas.

Para profundizar en los requisitos regulatorios aplicables, el texto consolidado de la LGPD está disponible en el portal de la ANPD (gov.br/anpd), y las orientaciones de la AAIP sobre datos sensibles en salud pueden consultarse en argentina.gob.ar/aaip. Ambas son lectura obligatoria para cualquier equipo que diseñe o actualice su programa de gobernanza en la región.

El dato clínico es el activo más sensible que gestiona una organización de salud: identifica, predice y, si se pierde el control, discrimina. Expertos del sector coinciden en que sin una gobernanza de datos robusta no hay atención centrada en el paciente, sino solo tecnología costosa sin dirección.

Hablar de gobernanza de datos en salud no es hablar de burocracia interna. Es hablar de quién tiene autoridad sobre un expediente clínico, cómo se classifica un diagnóstico antes de que llegue a un sistema de análisis, y qué ocurre con ese dato cuando el paciente cruza de un prestador a otro. La definición operativa que maneja la industria, alineada con el DAMA-DMBOK, es clara: gobernanza de datos clínicos es el conjunto de políticas, roles y procesos que determinan quién puede usar un dato, para qué y con qué controles. Sin esa estructura, los proyectos de IA clínica, interoperabilidad y medicina personalizada colapsan antes de llegar a producción.

El dato clínico tiene propiedades que complican su gobierno

A diferencia del dato transaccional de un e-commerce, el dato clínico es longitudinal —acompaña al paciente décadas—, multifuente —laboratorio, imagen, farmacia, wearable— y jurídicamente sensible desde el momento de su creación. Esto impone exigencias específicas sobre el data lineage: no alcanza con saber dónde vive el dato, hay que poder reconstruir cada transformación que sufrió desde la consulta médica hasta el modelo predictivo. En sistemas hospitalarios que operan con múltiples EHR (electronic health records) y proveedores de nube, esa trazabilidad suele romperse en la primera integración. El rol del data steward clínico —distinto al steward financiero— debe incluir competencias en terminología médica estandarizada (HL7 FHIR, SNOMED CT, ICD-10) además de las capacidades habituales de governance.

Cuándo aplica / cuándo NO una arquitectura de gobernanza estándar en salud

Una arquitectura de gobernanza corporativa estándar aplica en salud cuando el objetivo es gestionar datos administrativos: facturación, RRHH, proveedores. No aplica —o aplica con modificaciones profundas— cuando el dato es parte del acto médico. En ese caso, los frameworks deben incorporar dimensiones de consentimiento informado, finalidad de tratamiento y minimización de datos que en otros sectores son opcionales. El EDM Council (CDMC) tiene controles específicos para datos regulados que pueden adaptarse, pero ningún marco genérico reemplaza la política de datos clínicos diseñada para el contexto sanitario específico de cada país. Un hospital que aplica DCAM capability 8 (data risk and compliance) sin adaptarlo a la normativa de salud local opera con un control de papel.

En América Latina, la regulación sectorial presiona antes que los marcos voluntarios

En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) clasifica los datos de salud como datos sensibles en su artículo 11, lo que impone requisitos de consentimiento específico y restringe el uso secundario —incluyendo el entrenamiento de modelos de IA— sin base legal explícita. La Autoridade Nacional de Proteção de Dados (ANPD) ha señalado el sector salud como área de atención prioritaria. En Argentina, la Ley 25.326 de Protección de Datos Personales también categoriza los datos de salud como sensibles, y las clínicas y hospitales que operan bases de datos están obligados a inscribirse ante la AAIP. En México, la LFPDPPP y su reglamento aplican a los prestadores privados, mientras que el sector público enfrenta un régimen mixto que genera fricciones operativas cuando se intenta compartir datos entre IMSS, ISSSTE y prestadores privados en proyectos de interoperabilidad. En Colombia, la Ley 1581/2012 sigue la misma lógica de datos sensibles con requisitos de autorización expresa. Ninguno de estos marcos jurídicos resuelve por sí solo el problema operativo: la gobernanza de datos es la capa que traduce la obligación legal en control técnico.

Tres fricciones que aparecen siempre en proyectos de datos clínicos

• Ownership difuso: el expediente clínico tiene múltiples custodios (médico, institución, paciente) y la política de datos raramente define quién tiene autoridad de decisión sobre cambios en el dato maestro del paciente.
• Calidad en origen: los datos que ingresan al sistema de análisis provienen de digitación manual, formularios no estandarizados y sistemas legados con codificaciones propias. Sin data quality rules en el punto de captura, el modelo downstream hereda el error.
• Consentimiento no granular: el formulario de consentimiento del paciente raramente distingue entre uso para atención directa, investigación anónima, entrenamiento de IA o compartición con aseguradoras. Esa falta de granularidad expone a la institución ante la autoridad de control cuando llega una solicitud de ejercicio de derechos.

Resolver estas tres fricciones no es un proyecto de tecnología: es un proyecto de gobernanza con entregables concretos —política de ownership, diccionario de datos clínicos, registro de consentimientos con versionado— antes de que entre en escena cualquier plataforma.

Para profundizar en los requisitos de tratamiento de datos sensibles en salud, el texto completo de la LGPD (artículo 11) y la Resolución CD/ANPD Nº 15/2024 sobre seguridad de la información son punto de partida obligado para cualquier equipo que opere en Brasil o aspire a interoperar con prestadores brasileños.

En salud, un dato sin dueño claro es un dato que tarde o temprano daña a alguien. La gobernanza de datos robusta —con data stewards definidos, catálogos activos y linaje trazable desde el origen clínico— es la precondición técnica y organizacional para que el modelo de atención centrada en el paciente deje de ser un objetivo declarativo y se convierta en práctica operativa.

El concepto de atención centrada en el paciente exige que la información clínica esté disponible, sea confiable y pueda integrarse a lo largo de todo el ciclo de cuidado: desde el primer contacto en atención primaria hasta el alta hospitalaria o el seguimiento ambulatorio. Ese flujo no es posible si los datos de salud están fragmentados en silos departamentales, si no existe un responsable formal del dato —el data steward clínico— y si los sistemas de registro no comparten un esquema semántico común. La gobernanza de datos no es, en este contexto, un problema de IT: es una decisión institucional con consecuencias clínicas directas.

El dato clínico tiene cuatro problemas de ownership que ningún EHR resuelve solo

Un sistema de historia clínica electrónica (EHR, por sus siglas en inglés) captura el dato, pero no garantiza su calidad ni su coherencia longitudinal. Los cuatro problemas más frecuentes en entornos hospitalarios son la duplicidad de registros de paciente (un mismo individuo con múltiples identificadores), la ausencia de definiciones maestras para términos clínicos críticos (como “diagnóstico principal” o “fecha de egreso”), la falta de linaje que permita rastrear de dónde proviene un valor y quién lo modificó, y la inexistencia de un proceso formal de certificación de calidad antes de que el dato alimente tableros de gestión o modelos predictivos. Según el marco DAMA-DMBOK, estos problemas corresponden a brechas en las áreas de conocimiento de Gestión de la Calidad del Dato y Gestión de Metadatos, y ninguna herramienta tecnológica los soluciona si no hay una estructura organizacional que asigne accountability.

Cuándo aplica la gobernanza clínica de datos — y cuándo NO

La gobernanza de datos en salud aplica siempre que una organización tome decisiones clínicas, operativas o regulatorias basadas en datos de pacientes: hospitales, clínicas, aseguradoras de salud, laboratorios y sistemas nacionales de información sanitaria. Aplica también cuando se alimentan modelos de inteligencia artificial con datos de historia clínica, porque un modelo entrenado sobre datos sin gobierno reproducirá los sesgos y errores del registro original. Lo que la gobernanza clínica de datos NO reemplaza es la seguridad informática (controles de acceso, cifrado, gestión de incidentes) ni la privacidad en sentido estricto (consentimiento informado, derechos de acceso y rectificación del paciente): estos son dominios complementarios que requieren sus propios programas. La confusión entre los tres dominios —gobernanza, seguridad y privacidad— es uno de los errores más comunes en los proyectos de transformación digital hospitalaria en la región.

LATAM: tres marcos regulatorios que exigen capacidades de gobernanza sin nombrarlas así

En América Latina, varios marcos regulatorios del sector salud implican requisitos de facto de gobernanza de datos, aunque no los llamen por ese nombre. En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) clasifica los datos de salud como datos sensibles y exige que el operador demuestre exactitud y actualización del dato —lo que requiere procesos de calidad y linaje—. En Argentina, la Ley 25.326 de Protección de Datos Personales establece el principio de exactitud de los datos (art. 4°), que en un hospital se traduce en la necesidad de un proceso de validación y corrección del registro clínico. En México, la LFPDPPP y las Normas Oficiales Mexicanas del sector salud —en particular la NOM-004-SSA3-2012 sobre el expediente clínico— establecen estándares de integridad y conservación que son, en esencia, requisitos de governance sin el vocabulario técnico correspondiente. Las instituciones que aún tratan estos marcos como obligaciones de IT y no como programas de gobierno del dato enfrentan el doble riesgo del incumplimiento regulatorio y de la degradación silenciosa de la calidad de su información clínica.

Tres capacidades mínimas para un CDO de salud que opera en la región

Cualquier programa de gobernanza de datos clínicos funcional en LATAM necesita al menos tres capacidades instaladas. Primero, un Master Data Management (MDM) de paciente: un identificador único, validado y mantenido, que permita vincular registros a lo largo del tiempo y entre sistemas. Segundo, un catálogo de datos con definiciones acordadas entre las áreas clínicas, financieras y de IT, donde cada elemento crítico —diagnóstico, medicamento, evento adverso— tenga un steward asignado con nombre y apellido. Tercero, un proceso de medición periódica de calidad del dato con indicadores formales (completitud, exactitud, consistencia) publicados internamente y vinculados a decisiones de mejora. El EDM Council (CDMC) ofrece un marco de certificación que varios sistemas de salud en Europa y Norteamérica ya están adoptando; en la región, la adopción es aún marginal, pero los requisitos regulatorios mencionados arriba convergen hacia las mismas capacidades.

Los marcos regulatorios de salud en Brasil, Argentina y México ya exigen —con distinto vocabulario— lo mismo que un programa de gobernanza de datos clínica: exactitud, trazabilidad y accountability del dato del paciente. La brecha no es de regulación; es de implementación.

El Comité Legal y de Política de CRASA —la asociación de reguladores de telecomunicaciones del sur y este de África— abrió formalmente una sesión de trabajo dedicada a inteligencia artificial, gobernanza de datos y regulación regional de las TIC. El encuentro señala un punto de inflexión: los reguladores de una de las regiones con mayor crecimiento de infraestructura digital del mundo reconocen que sus marcos normativos no están diseñados para los ecosistemas de datos actuales. Para América Latina, que enfrenta el mismo desfasaje entre velocidad tecnológica y capacidad regulatoria, el movimiento africano ofrece una referencia metodológica concreta.

CRASA y los 16 reguladores que coordinan el sur de África

CRASA (Communications Regulators’ Association of Southern Africa) agrupa a las autoridades regulatorias de telecomunicaciones de 16 países del sur y este del continente africano. Su Comité Legal y de Política actúa como espacio de armonización normativa: cuando ese comité abre una sesión específica sobre IA y gobernanza de datos, no está explorando tendencias académicas sino evaluando si los instrumentos regulatorios existentes —licencias, obligaciones de reporte, regímenes de acceso a infraestructura— son suficientes para gobernar flujos de datos transfronterizos, sistemas automatizados de decisión y modelos de IA desplegados por operadores con presencia regional. Según se informó, la agenda incluyó el análisis del estado de avance de los marcos nacionales frente a los requerimientos de la economía digital.

Por qué un comité de telcos discute gobernanza de datos en 2025

La convergencia entre regulación de telecomunicaciones y gobernanza de datos no es una anomalía: es la consecuencia lógica de que los operadores de redes son, simultáneamente, los mayores recolectores de datos de comportamiento, geolocalización y comunicaciones de sus países. Cuando un regulador TIC fija condiciones para una licencia de operación, está —aunque no lo nombre explícitamente— estableciendo quién tiene acceso a qué datos, bajo qué condiciones y con qué obligaciones de retención. El Comité de CRASA está haciendo explícito algo que en muchas jurisdicciones permanece implícito: la regulación de infraestructura digital es, en el fondo, una forma de gobernanza de datos.

Desde la perspectiva del DAMA-DMBOK, esto equivale a reconocer que el “data ownership” no puede resolverse solo dentro de las organizaciones —requiere un marco externo que defina derechos, responsabilidades y mecanismos de control a nivel sectorial y regional. Los reguladores africanos están intentando construir ese marco colectivamente, algo que en América Latina todavía se hace de manera fragmentada y fundamentalmente reactiva.

Brasil, México y Colombia: tres velocidades en el mismo problema

América Latina no parte de cero. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) y con la ANPD como autoridad de aplicación, que en 2024 emitió regulaciones sobre agentes de tratamiento y bases legales. Sin embargo, la ANPD no tiene mandato explícito sobre gobernanza corporativa de datos más allá de lo que impone la LGPD: no puede exigir que una empresa implemente un catálogo de datos, defina data stewards o mantenga linaje documentado, a menos que esa ausencia derive en una violación de los principios de seguridad o minimización de la ley.

México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, 2010) y el INAI como regulador, con un marco centrado en derechos ARCO que tiene escasa incidencia en cómo las empresas organizan internamente sus arquitecturas de datos. Colombia, por su parte, cuenta con la Ley 1581 de 2012 y la Superintendencia de Industria y Comercio (SIC), que ha avanzado en orientaciones sobre transferencias internacionales, pero aún no emitió guías técnicas sobre gestión del ciclo de vida del dato equivalentes a las que se esperan de un marco CDMC. El resultado es que las tres jurisdicciones más grandes de la región tienen marcos de privacidad razonablemente maduros pero marcos de gobernanza de datos corporativa virtualmente inexistentes desde el ángulo regulatorio.

Lo que los CDOs de la región pueden tomar del modelo CRASA

El valor del enfoque de CRASA no está en sus resoluciones —que todavía no se conocen públicamente— sino en su método: un comité sectorial que evalúa sistemáticamente si los instrumentos regulatorios existentes son adecuados para los activos de datos que los operadores manejan. Ese ejercicio de mapeo —”¿tenemos cobertura normativa para este tipo de dato, este tipo de sistema, este tipo de flujo transfronterizo?”— es exactamente lo que los marcos de gobernanza maduros como DCAM (Data Capability Assessment Model del EDM Council) proponen hacer a nivel organizacional.

Un CDO en Argentina, Brasil o Colombia puede tomar ese modelo y aplicarlo internamente: mapear las capacidades de gobernanza existentes contra los requerimientos que la regulación sectorial ya impone —comunicaciones al BCRA bajo la Comunicación A 8073 para bancos argentinos, reportes de incidentes a la ANPD bajo el artículo 48 de la LGPD, o notificaciones a la SIC en Colombia— e identificar las brechas reales. Ese mapeo es el punto de partida para un roadmap de gobernanza que no sea aspiracional sino jurisdiccionalmente anclado. La semana que viene es una buena fecha para abrir ese inventario: quién es el data steward de cada dominio regulado, qué linaje está documentado, qué no.

Qué monitorear: la agenda regulatoria TIC en LATAM durante el segundo semestre de 2025

El movimiento de CRASA coincide con una ventana activa en la región. En Chile, la Ley 21.719 de Protección de Datos Personales —promulgada en diciembre de 2024 y con entrada en vigor escalonada— incluye obligaciones de seguridad y gobernanza que van más allá de los marcos anteriores. En Perú, la Ley 29733 está bajo revisión legislativa. En Brasil, la ANPD tiene en su agenda la regulación de decisiones automatizadas. Ninguno de estos procesos cuenta aún con un comité equivalente al de CRASA —un espacio de armonización técnica entre reguladores— lo que hace que el intercambio de experiencias entre países siga dependiendo de foros informales o de la intermediación de organismos como la CEPAL o la OEA.

Nuestro análisis

La sesión de CRASA importa menos por lo que resuelva que por lo que institucionaliza: la gobernanza de datos como agenda regulatoria sectorial, no solo como obligación de privacidad individual. Esa distinción es crucial. Mientras los marcos latinoamericanos siguen atando gobernanza de datos a derechos de titulares —un enfoque necesario pero insuficiente—, otros bloques regionales están construyendo la capa de gobernanza corporativa e interoperabilidad que permite que esos derechos sean ejercibles en la práctica. Una empresa que no sabe qué datos tiene, dónde están y quién es responsible de cada dominio no puede responder un DSAR en 30 días ni notificar una brecha en 72 horas. El orden lógico es: gobernanza primero, cumplimiento como resultado. Eso es lo que CRASA, al menos en el papel, está intentando formalizar.

La pregunta concreta para los equipos de datos en la región: ¿puede su organización responder hoy, sin buscar en carpetas, quién es el data steward de cada sistema que toca datos regulados? Si la respuesta es no, ese es el primer gap que documentar.

Desplegar inteligencia artificial sobre datos sin gobierno es repetir, a mayor escala y velocidad, el mismo error que organizaciones latinoamericanas han cometido con cada ola tecnológica anterior: integrar primero, ordenar después. El resultado predecible es un sistema que amplifica el caos en lugar de reducirlo.

Cuando una organización conecta un modelo de lenguaje o un sistema de analítica predictiva a sus repositorios internos sin haber definido quién es responsable de cada dato, qué calidad tiene y bajo qué reglas circula, no está adoptando inteligencia artificial — está construyendo un conducto de alta velocidad hacia sus problemas de datos más viejos. La IA no genera orden: consume el que existe. Si el orden no existe, el modelo lo hace visible de la peor manera posible: en producción, frente al cliente, o frente al regulador.

Por qué la IA expone brechas de gobernanza que los sistemas legacy ocultaban

Los sistemas transaccionales tradicionales toleran datos duplicados, inconsistentes o sin propietario definido porque operan con reglas fijas y flujos predecibles. Un ERP con mala calidad de datos sigue funcionando dentro de sus parámetros. Un modelo de IA entrenado o alimentado con esos mismos datos, en cambio, generaliza las inconsistencias: las aprende, las replica y las escala a toda decisión que toque. Lo que antes era un problema de datos silenciado por la rigidez del sistema, ahora se convierte en un comportamiento del modelo difícil de depurar y más difícil aún de explicar ante una auditoría.

El marco DAMA-DMBOK identifica diez áreas de conocimiento en gobernanza de datos. Las más frecuentemente ausentes en proyectos de IA corporativa en la región son precisamente las más críticas para su funcionamiento: calidad de datos (Data Quality), gestión de metadatos (Metadata Management) y lineaje (Data Lineage). Sin saber de dónde viene un dato, qué transformaciones sufrió y quién lo validó, es imposible auditar por qué un modelo tomó una decisión determinada — requisito que ya no es opcional en ninguna jurisdicción con regulación de IA o de datos personales activa.

El rol del data steward antes del primer prompt

En organizaciones con gobernanza madura, el data steward — responsable operativo de un dominio de datos específico — es quien certifica que un conjunto de datos es apto para un uso determinado antes de que ese uso ocurra. En proyectos de IA, esa certificación debería preceder al entrenamiento o a la conexión del modelo a fuentes internas. Sin embargo, según el EDM Council, menos del 30% de las organizaciones globales que han iniciado proyectos de IA generativa en entornos productivos contaban con ownership formal de datos en los dominios involucrados al momento del despliegue, según se informó en su evaluación CDMC de 2024.

El patrón es conocido en la región: el equipo de datos construye el pipeline, el equipo de negocio aprueba el caso de uso, y la función de gobernanza — cuando existe — es informada después. Bob Seiner, referente de la metodología Non-Invasive Data Governance, describe este modelo como “gobernanza reactiva”: se activa cuando algo sale mal, no cuando se define qué puede salir mal. En proyectos de IA, el costo de esa reactividad es estructuralmente más alto porque los errores se propagan a velocidades que los procesos manuales de remediación no pueden seguir.

México y el costo regulatorio de no gobernar antes de desplegar

México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y su autoridad de control, el INAI, ha emitido lineamientos sobre el uso de datos personales en sistemas automatizados. Si un modelo de IA toma decisiones que afectan a personas físicas — scoring crediticio, selección de candidatos, segmentación de pacientes — y fue alimentado con datos personales sin el consentimiento adecuado o sin una base legal documentada, la organización enfrenta responsabilidad bajo la ley vigente, independientemente de si el modelo “funciona bien” en términos técnicos. La ausencia de linaje documental hace imposible demostrar cumplimiento en una auditoría del INAI.

El escenario no es exclusivo de México. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige base legal para cada tratamiento de datos personales, incluidos los automatizados, y la ANPD ha señalado explícitamente el uso de IA como área de supervisión prioritaria para 2025-2026. En Argentina, la Ley 25.326 y la AAIP enfrentan un escenario similar con menor capacidad sancionatoria formal, pero con presión creciente desde la esfera judicial. En todos estos casos, un catálogo de datos con clasificación de sensibilidad y linaje documentado es la primera línea de defensa — no el cifrado, no el pentesting, sino saber qué datos tiene la organización y quién responde por ellos.

Cuándo aplica la gobernanza previa — y cuándo ya es tarde

La gobernanza de datos como prerrequisito de IA aplica en cualquier proyecto que involucre datos internos de la organización, datos de clientes, o datos sujetos a regulación sectorial — es decir, prácticamente todos los casos de uso empresarial relevantes. No aplica, o aplica en menor medida, a modelos completamente aislados que operan sobre datos sintéticos o sobre conjuntos públicos sin datos personales, que representan una fracción marginal de los proyectos reales. La pregunta que un CDO debe hacer antes de aprobar el presupuesto de cualquier iniciativa de IA no es “¿tenemos los datos?” sino “¿sabemos qué son esos datos, quién los posee y bajo qué condiciones pueden usarse?”. Si la respuesta a alguna de esas tres preguntas es incierta, el proyecto tiene un problema de gobernanza disfrazado de problema de ingeniería.

Un CDO que enfrenta esta situación en su organización puede tomar tres pasos concretos antes de que el siguiente proyecto de IA entre a producción: primero, mapear los dominios de datos que alimentarán el sistema e identificar si tienen un data steward asignado con accountability formal; segundo, ejecutar un perfil de calidad de datos sobre esas fuentes con métricas de completitud, consistencia y unicidad — herramientas como Great Expectations, Monte Carlo o incluso dbt tests permiten hacerlo sin infraestructura adicional; tercero, documentar el linaje desde la fuente hasta el modelo en el catálogo de datos corporativo, de modo que cualquier auditor interno o externo pueda reconstruir el recorrido del dato sin depender de quien lo construyó. Estos tres pasos no garantizan un modelo perfecto, pero sí una organización que puede defender sus decisiones.

La gobernanza de datos no es el freno de la adopción de IA: es la condición para que esa adopción sea sostenible. Las organizaciones que lo descubran después del primer incidente regulatorio habrán pagado un precio innecesario por una lección que ya estaba disponible.