Blog

  • Cultura de gobernanza de datos: la ventaja competitiva que pocas empresas explotan

    Cultura de gobernanza de datos: la ventaja competitiva que pocas empresas explotan

    Instalar una cultura de gobernanza de datos no es un proyecto de TI: es una decisión estratégica que separa a las organizaciones que aprovechan sus activos de información de las que los desperdician. Según se informó desde el sector de tecnología tributaria, las empresas que internalizan esta cultura como parte de su ADN operativo obtienen ventajas competitivas mensurables frente a sus pares.

    La gobernanza de datos —entendida como el conjunto de políticas, roles, procesos y estándares que determinan quién puede hacer qué con qué datos, y cuándo— sigue siendo uno de los conceptos más citados y menos implementados en el mundo corporativo latinoamericano. La brecha entre el discurso y la práctica no es técnica: es cultural. Las organizaciones que logran cerrarla no lo hacen comprando una herramienta de catálogo de datos o contratando un Chief Data Officer (CDO); lo hacen cuando cada área de negocio asume que los datos que genera y consume son un activo bajo su responsabilidad.

    Qué significa cultura de gobernanza, más allá del framework

    Marcos como el DAMA-DMBOK o el Data Management Capability Assessment Model (DCAM) del EDM Council describen con precisión qué capacidades debe tener una organización madura en gobernanza de datos. Pero ningún framework se implementa solo: requiere que los equipos de negocio entiendan por qué importa la calidad del dato, que los data stewards tengan autoridad real para rechazar datos mal clasificados, y que la alta dirección vincule las métricas de datos con los resultados de negocio. Sin ese sustrato cultural, un catálogo de datos es una herramienta vacía y un data lineage es un diagrama que nadie consulta.

    El sector de tecnología tributaria —donde la precisión del dato tiene consecuencias directas en cumplimiento fiscal y exposición regulatoria— ilustra bien este punto. Cuando los datos de transacciones, clientes o declaraciones son inconsistentes, el costo no es abstracto: es una multa, una auditoría o una pérdida de confianza del regulador. Esa presión concreta obliga a que la gobernanza deje de ser un proyecto del área de datos y se convierta en una prioridad compartida.

    El ownership del dato: la pieza que más falla en América Latina

    En la mayoría de las organizaciones de la región, el concepto de data ownership —la responsabilidad explícita de un área o persona sobre la calidad, clasificación y ciclo de vida de un conjunto de datos específico— sigue siendo difuso. El equipo de TI cree que es responsabilidad del negocio; el negocio cree que es responsabilidad de TI. Ese limbo produce datos duplicados, definiciones inconsistentes de KPIs entre áreas, y reportes que diferentes equipos no pueden reconciliar. Bob Seiner, referente del enfoque Non-Invasive Data Governance, sostiene que el ownership del dato ya existe en toda organización —alguien siempre toma decisiones sobre los datos—; el trabajo de gobernanza es hacerlo explícito y formal, no inventarlo.

    En Brasil, las empresas sujetas a la Lei Geral de Proteção de Dados (LGPD) enfrentan una presión adicional: la Autoridade Nacional de Proteção de Dados (ANPD) puede requerir evidencia de que los datos personales tienen un responsable identificado, una base legal documentada y controles de acceso verificables. Eso no es posible sin un programa mínimo de gobernanza. En Argentina, la Ley 25.326 y las disposiciones de la Agencia de Acceso a la Información Pública (AAIP) imponen obligaciones similares sobre los responsables de bases de datos. En México, la LFPDPPP obliga a los responsables a establecer y mantener medidas de seguridad administrativas que, en la práctica, requieren saber qué datos existen, dónde están y quién los maneja.

    Cuándo aplica / cuándo NO

    Una cultura de gobernanza de datos aplica en cualquier organización que tome decisiones basadas en datos propios o de terceros, que opere en sectores regulados, o que aspire a escalar operaciones sin perder control sobre la calidad de su información. No aplica como solución inmediata para empresas en etapas muy tempranas sin datos sistematizados, ni como sustituto de controles de ciberseguridad: gobernanza y seguridad son complementarios, no intercambiables. Tampoco reemplaza una estrategia de datos clara: sin saber qué preguntas de negocio se quieren responder, gobernar datos es un ejercicio burocrático sin retorno.

    Tres palancas concretas para instalar la cultura

    Las organizaciones que avanzan en madurez de gobernanza suelen compartir tres características operativas. Primero, vinculan métricas de calidad de datos —completitud, consistencia, oportunidad— con objetivos de negocio medibles, no con indicadores internos de TI. Segundo, establecen un consejo o comité de datos con representación de las áreas de negocio principales, no solo del área técnica; ese espacio es donde se resuelven conflictos de definición y se priorizan iniciativas. Tercero, capacitan a los data stewards no solo en herramientas, sino en el razonamiento detrás de cada política: un steward que entiende por qué existe una regla de clasificación la aplica y la defiende; uno que solo la ejecuta la evita cuando hay presión de tiempo.

    Para los CDOs y Data Governance Managers de la región, el punto de entrada más eficiente no es el framework más sofisticado sino la pregunta más simple: ¿quién en esta organización es responsable de que este dato esté correcto mañana a las 8 AM? Si nadie tiene una respuesta clara, el programa de gobernanza empieza ahí.

  • ICO amonesta a la oficina de antecedentes penales del Reino Unido por brecha de datos

    ICO amonesta a la oficina de antecedentes penales del Reino Unido por brecha de datos

    La Oficina del Comisionado de Información del Reino Unido (ICO) emitió una amonestación formal contra ACRO Criminal Records Office, unidad policial nacional encargada de emitir certificados de antecedentes penales y certificados de protección internacional de menores, tras confirmar infracciones a los artículos 32(1), 32(1)(b) y 32(1)(d) del UK GDPR.

    ACRO es una unidad policial de alcance nacional que, entre otras funciones, procesa solicitudes de acceso de titulares (Subject Access Requests) y gestiona documentación sensible vinculada a antecedentes penales y protección infantil. La ICO determinó que la entidad no implementó medidas técnicas y organizativas adecuadas para garantizar un nivel de seguridad apropiado al riesgo de los datos que trata, una exigencia explícita del artículo 32 del UK GDPR. La amonestación fue publicada el 15 de agosto de 2026, según se informó en DataBreaches.net.

    Artículo 32 UK GDPR: los tres puntos de infracción confirmados

    • Artículo 32(1): ausencia de medidas técnicas y organizativas apropiadas para el nivel de riesgo del tratamiento.
    • Artículo 32(1)(b): falta de capacidad para garantizar la confidencialidad, integridad, disponibilidad y resiliencia continuas de los sistemas de tratamiento.
    • Artículo 32(1)(d): inexistencia de un proceso regular de verificación, evaluación y valoración de la eficacia de las medidas de seguridad aplicadas.

    Qué se sabe y qué falta confirmar

    La información disponible confirma la amonestación formal de la ICO y los artículos infringidos del UK GDPR. No se han divulgado públicamente detalles sobre el volumen de registros afectados, la naturaleza técnica del incidente —si fue una exfiltración externa, un error de configuración o una exposición interna—, ni el número de personas cuyos datos podrían haberse visto comprometidos. Tampoco se ha informado si ACRO notificó el incidente a los titulares afectados ni en qué plazo. La ICO optó por una amonestación y no por una sanción económica, decisión que en el marco del UK GDPR post-Brexit es una herramienta regulatoria diferenciada de la multa administrativa, aunque igualmente vinculante en cuanto a las medidas correctivas exigidas.

    El caso tiene relevancia directa para organismos públicos en América Latina que procesan datos de categorías especiales —como antecedentes penales o datos de menores— sin controles equivalentes al artículo 32. En Argentina, la Ley 25.326 y las disposiciones de la AAIP exigen medidas de seguridad adecuadas al nivel de sensibilidad del dato; en Brasil, el artículo 46 de la LGPD impone obligaciones similares con un estándar de proporcionalidad al riesgo. Entidades públicas que gestionan registros criminales o certificados de conducta en la región operan frecuentemente sin evaluaciones periódicas de la eficacia de sus controles —exactamente el punto que motivó la infracción al artículo 32(1)(d) en este caso.

    El próximo hito a seguir es la respuesta formal de ACRO al plan de acción correctivo que la ICO tiene facultad de exigir tras la amonestación, cuyo plazo no fue publicado al cierre de esta nota.

  • NHS admite brecha de datos: enviaba información de trasplantes por pagers sin cifrar

    NHS admite brecha de datos: enviaba información de trasplantes por pagers sin cifrar

    El Servicio Nacional de Salud del Reino Unido (NHS) reconoció una brecha de datos tras confirmarse que enviaba información médica sensible de pacientes en lista de trasplante a través de una red de pagers sin cifrado. El hallazgo, producto de una investigación de la BBC, expuso nombres, fechas de nacimiento y tipos de órganos ofrecidos o necesitados circulando en texto plano.

    Según se informó, los datos se transmitían de forma rutinaria mediante dispositivos pager —tecnología de radiofrecuencia de los años ochenta— cuya señal puede interceptarse con equipos de bajo costo disponibles en el mercado. La investigación periodística detectó que el sistema afectaba específicamente a pacientes del programa de trasplantes, uno de los perfiles clínicos de mayor sensibilidad, dado que los datos expuestos incluyen información de salud que en la mayoría de los marcos regulatorios modernos recibe protección reforzada.

    Datos confirmados al 14 de agosto de 2026

    • El NHS reconoció públicamente la existencia de la brecha tras la publicación de la investigación de la BBC.
    • Los datos transmitidos incluían: nombre completo del paciente, fecha de nacimiento y tipo de órgano involucrado (ofrecido o requerido).
    • La red de pagers utilizada no contaba con cifrado en la transmisión de datos.
    • El uso de pagers para comunicaciones clínicas era, según se informó, una práctica rutinaria y no un evento aislado.
    • No se ha confirmado públicamente si hubo acceso no autorizado efectivo a los datos interceptados.

    Qué se sabe y qué falta confirmar sobre el alcance

    Lo confirmado hasta ahora es que el NHS reconoció el incidente y que la práctica era sistemática, no accidental. Lo que permanece sin verificar es el número total de pacientes afectados, el período durante el cual se realizaron estas transmisiones y si la Oficina del Comisionado de Información del Reino Unido (ICO) —autoridad de control bajo el UK GDPR— ya recibió la notificación formal de la brecha. Bajo el régimen de protección de datos vigente en el Reino Unido, las organizaciones tienen 72 horas para notificar a la autoridad cuando el riesgo para los titulares es probable. Tampoco se ha informado si el NHS activó algún protocolo de notificación individual hacia los pacientes afectados.

    El incidente tiene repercusión directa para la región. En Argentina, la Ley 25.326 de Protección de los Datos Personales clasifica los datos de salud como datos sensibles y exige medidas de seguridad adecuadas para su tratamiento; la AAIP puede ordenar el cese del tratamiento y aplicar sanciones ante incumplimientos. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece la misma categoría de dato sensible para información de salud y fija la obligación de notificación a la ANPD en plazos que la propia autoridad ha ido precisando mediante resoluciones. En México, la LFPDPPP y su reglamento obligan a los responsables a implementar medidas de seguridad físicas, técnicas y administrativas; el uso de canales no cifrados para datos de salud difícilmente superaría un escrutinio del INAI. El caso NHS es, en ese sentido, un espejo incómodo: los sistemas de salud pública de la región también operan con infraestructura heredada que no fue diseñada con privacidad en mente.

    El próximo hito a seguir es la confirmación de si la ICO recibió la notificación formal dentro del plazo de 72 horas exigido por el UK GDPR y si iniciará una investigación sobre el alcance total del incidente.

  • Gobernanza de datos indígena: soberanía digital y economía tribal

    Gobernanza de datos indígena: soberanía digital y economía tribal

    Las naciones indígenas de Estados Unidos están usando la gobernanza de datos como instrumento de soberanía: controlar quién accede a la información sobre sus comunidades equivale, según sus propios marcos conceptuales, a defender territorio digital. El enfoque, documentado por el Banco de la Reserva Federal de Minneapolis, tiene implicancias directas para comunidades originarias de América Latina que hoy carecen de mecanismos formales de control sobre sus propios datos.

    La premisa es simple pero políticamente densa: los datos generados por una comunidad indígena —censos, registros de salud, patrones de uso de la tierra, información cultural— son recursos propios. Si esos datos fluyen sin restricciones hacia agencias gubernamentales, empresas farmacéuticas o plataformas de investigación académica, la comunidad pierde control sobre narrativas que la afectan directamente y, con frecuencia, sobre decisiones económicas que dependen de esa información. La gobernanza de datos, en este marco, no es un ejercicio de cumplimiento normativo sino un acto de autodeterminación.

    El concepto de “tierra digital” y qué significa en la práctica

    La metáfora de la “tierra digital” no es retórica. Las naciones tribales en Estados Unidos tienen reconocimiento jurídico de soberanía sobre su territorio físico; extender ese principio al espacio de los datos implica reclamar derechos equivalentes: decidir qué se recopila, quién puede acceder, bajo qué condiciones y con qué fines. Algunas tribus han formalizado esto a través de políticas propias de gobernanza de datos que incluyen comités de revisión de datos, protocolos de consentimiento comunitario y acuerdos de uso que van más allá de lo que exige la legislación federal estadounidense. En términos de frameworks reconocidos, la estructura se aproxima a lo que el DAMA-DMBOK identifica como data ownership y data stewardship, pero aplicado a un nivel de soberanía colectiva que los marcos corporativos no contemplaron originalmente.

    El componente económico es igualmente concreto. Según se informó en el análisis del Banco de la Reserva Federal de Minneapolis, algunas comunidades han utilizado el control de sus datos para negociar mejores condiciones con proveedores de salud, orientar inversiones en infraestructura comunitaria y atraer financiamiento que de otro modo se basaría en estadísticas externas —frecuentemente desactualizadas o metodológicamente cuestionables— sobre sus poblaciones.

    Cuándo aplica este modelo / cuándo NO

    Este enfoque aplica cuando una comunidad tiene algún grado de reconocimiento jurídico o capacidad organizativa para establecer reglas propias sobre sus datos, y cuando existe una asimetría identificable entre los datos que produce y el beneficio que recibe a cambio de compartirlos. No aplica —o aplica con fricciones significativas— en contextos donde la comunidad depende enteramente de infraestructura de datos administrada por terceros sin cláusulas de acceso negociables, o donde la dispersión poblacional impide constituir un cuerpo de gobierno cohesionado. Tampoco reemplaza la necesidad de marcos legales externos: sin un reconocimiento normativo mínimo, las políticas internas de gobernanza de datos tienen fuerza moral pero no poder de negociación frente a actores estatales o corporativos.

    América Latina: pueblos originarios y un vacío normativo que persiste en 2025

    En la región, el panorama es fragmentado. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018), que reconoce datos sensibles de origen racial o étnico como categoría especial, pero no establece mecanismos de gobernanza colectiva para comunidades indígenas. La Autoridade Nacional de Proteção de Dados (ANPD) tiene competencia sobre el tratamiento de esos datos, pero la participación comunitaria en las decisiones de gobernanza no está contemplada en la norma. México, con la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), y Argentina, con la Ley 25.326 actualmente en proceso de reforma, presentan vacíos similares. Chile, cuya nueva Ley 21.719 de protección de datos personales entra en vigencia plena en 2026, tampoco incorpora un régimen diferenciado para datos de pueblos originarios, a pesar de que el país reconoce constitucionalmente la existencia de pueblos indígenas.

    El principio de soberanía de datos indígenas tiene un antecedente conceptual sólido en el movimiento CARE (Collective Benefit, Authority to Control, Responsibility, Ethics), desarrollado como complemento indígena a los principios FAIR de gestión de datos de investigación. Varias universidades latinoamericanas han comenzado a adoptar estos principios en sus protocolos de investigación con comunidades originarias, aunque su penetración en marcos regulatorios nacionales es todavía marginal.

    Un modelo replicable con adaptaciones institucionales

    La experiencia de las naciones tribales estadounidenses sugiere que la gobernanza de datos puede ser un instrumento de desarrollo económico comunitario cuando se articula con capacidad institucional propia. Para que eso ocurra en América Latina, se requieren al menos tres condiciones: reconocimiento normativo del derecho colectivo sobre los datos generados por la comunidad, infraestructura técnica mínima para administrar ese control, y marcos de negociación con el Estado y actores privados que hagan ejecutable la política de datos. Ninguna de esas condiciones está completamente satisfecha hoy en ningún país de la región, aunque organizaciones como la COIAB en Brasil o la CONAIE en Ecuador han comenzado a plantear demandas en esta dirección sin usar todavía el lenguaje formal de la gobernanza de datos.

    Los principios CARE y los marcos de soberanía de datos indígenas están documentados en el Global Indigenous Data Alliance (www.gida-global.org), punto de partida obligado para cualquier organización que trabaje con datos de comunidades originarias en la región.

  • Gobernanza de datos clínica: por qué el expediente del paciente no puede esperar

    Gobernanza de datos clínica: por qué el expediente del paciente no puede esperar

    La atención centrada en el paciente fracasa cuando el dato clínico no es confiable, no está disponible a tiempo o no tiene un dueño claro dentro de la organización de salud. Expertos del sector coinciden en que la gobernanza de datos no es un proyecto de IT: es infraestructura estratégica para cualquier sistema sanitario que pretenda operar con estándares modernos de calidad asistencial.

    El punto de partida es una definición operativa que muchos hospitales y redes de salud todavía eluden: datos clínicos de calidad significa que el dato es exacto, completo, oportuno, consistente entre sistemas y trazable hasta su origen. Ninguna de esas dimensiones se sostiene sola. Un expediente electrónico con campos vacíos, diagnósticos duplicados o fechas inconsistentes no solo es un problema de reporting: puede derivar en errores de prescripción, subdiagnóstico o demoras en tratamientos críticos. El DAMA-DMBOK, marco de referencia global para la gestión de datos, identifica la calidad del dato como una de las once áreas de conocimiento fundamentales, y en el sector salud esa área no admite deuda técnica diferida.

    El data steward clínico: un rol que el sector salud aún no nombra

    En la industria financiera o en retail, la figura del data steward —responsable de definir, supervisar y defender la calidad del dato en un dominio específico— lleva años institucionalizada. En salud, la misma función existe de facto en médicos jefes, enfermeras coordinadoras o directores de registros médicos, pero sin el reconocimiento formal ni las herramientas de gobernanza que el rol requiere. La consecuencia es predecible: cuando un dato clínico es incorrecto, nadie tiene accountability explícita. El modelo Non-Invasive Data Governance de Bob Seiner propone exactamente lo contrario: formalizar responsabilidades sobre el dato sin crear burocracia adicional, asignando ownership a quienes ya trabajan con ese dato en su operación diaria. Aplicado a salud, significa que el médico tratante es el data steward natural del diagnóstico, y que el sistema debe registrar esa responsabilidad de forma auditable.

    Interoperabilidad: el problema técnico con raíz en governance, no en IT

    La fragmentación del expediente clínico entre múltiples sistemas —HIS, LIS, RIS, EMR de distintos proveedores— no se resuelve únicamente con integración técnica. Detrás de cada silo de datos hay una decisión de governance no tomada: qué sistema es la fuente de verdad para cada tipo de dato, qué entidad define el catálogo de terminología clínica autorizada (ICD-10, SNOMED CT, LOINC), y quién valida que el dato que sale de un sistema sea el mismo que entra en el siguiente. Sin esas definiciones, el data lineage —la trazabilidad del dato desde su captura hasta su uso en decisión clínica o reporte regulatorio— es imposible de construir. Y sin data lineage, auditar la calidad asistencial o responder a una inspección regulatoria se convierte en una operación manual de días o semanas.

    Cuándo aplica la gobernanza de datos en salud y cuándo no es suficiente

    La gobernanza de datos clínica aplica en toda organización que genere, procese o comparta datos de pacientes con fines asistenciales, de investigación o de reporte a autoridades sanitarias. Esto incluye hospitales públicos y privados, redes de atención primaria, laboratorios, aseguradoras de salud y plataformas de telemedicina. Lo que la gobernanza de datos no reemplaza es la ciberseguridad: un programa robusto de ownership, calidad y linaje no protege por sí solo contra ransomware o acceso no autorizado. Tampoco suple la protección de datos personales en sentido estricto. Son capas complementarias, no sustitutos.

    El marco regulatorio en América Latina: LGPD, Ley 25.326 y resoluciones sectoriales de salud

    En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) dedica tratamiento específico a los datos de salud, clasificándolos como datos sensibles en su artículo 11, con restricciones más estrictas para su tratamiento y requisitos de consentimiento diferenciado. La Autoridade Nacional de Proteção de Dados (ANPD) ya ha publicado orientaciones sobre tratamiento en contextos de salud pública. En Argentina, la Ley 25.326 de Protección de Datos Personales clasifica los datos de salud como datos sensibles bajo su artículo 2, y la Agencia de Acceso a la Información Pública (AAIP) es la autoridad de aplicación. A eso se suman las resoluciones del Ministerio de Salud sobre historia clínica electrónica (Resolución 84/2016 y sus modificatorias), que establecen requisitos de integridad, autenticidad y conservación que, en la práctica, demandan capacidades de gobernanza de datos que muchos prestadores todavía no tienen documentadas. En México, la NOM-024-SSA3-2010 regula los sistemas de información en salud y la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares) aplica al sector privado. Un CDO o Chief Data Officer de una red hospitalaria regional debe mapear cuáles de esas obligaciones generan requerimientos concretos de calidad, linaje y ownership en su arquitectura de datos, porque la auditoría regulatoria no pregunta por intenciones: pregunta por registros.

    Tres capacidades que un CDO de salud debe tener operativas antes de fin de año

    Independientemente del tamaño de la organización, hay un piso mínimo de gobernanza de datos clínicos que el contexto regulatorio latinoamericano ya exige implícitamente. En primer lugar, un catálogo de datos activo que identifique los dominios clínicos críticos —diagnóstico, medicación, identificación del paciente— y el data steward responsable de cada uno. En segundo lugar, un proceso documentado de gestión de calidad del dato que registre reglas de validación, frecuencia de revisión y responsable de resolución de discrepancias. En tercer lugar, trazabilidad básica del dato entre sistemas: al menos poder responder, ante una auditoría, de dónde viene el dato que aparece en el reporte regulatorio y qué transformaciones recibió. Estas tres capacidades equivalen aproximadamente a los niveles 4, 5 y 6 del CDMC (Cloud Data Management Capabilities) del EDM Council, adaptados al contexto clínico.

    Para profundizar en los requisitos específicos, el marco DAMA-DMBOK 2 dedica el capítulo 13 a la gestión de datos en contextos regulados, y la ANPD brasileña publicó en 2023 una guía orientativa sobre tratamiento de datos de salud que sirve como referencia para toda la región.

  • Gobernanza de datos clínica: el requisito que los hospitales ya no pueden ignorar

    Gobernanza de datos clínica: el requisito que los hospitales ya no pueden ignorar

    Sin gobernanza de datos robusta, los sistemas de salud no pueden construir una atención centrada en el paciente: los datos clínicos dispersos, sin ownership claro ni calidad verificada, producen decisiones médicas deficientes y exponen a las instituciones a riesgos regulatorios crecientes. El sector salud en América Latina opera con esa deuda técnica acumulada, y el margen para ignorarla se estrecha.

    La gobernanza de datos en salud no es un proyecto de TI. Es el conjunto de políticas, roles, procesos y estándares que determinan quién puede acceder a qué datos clínicos, cómo se definen, con qué calidad se capturan y cómo se integran entre sistemas —historias clínicas electrónicas (HCE), laboratorio, farmacia, facturación— para que el médico que atiende al paciente tenga información completa, confiable y oportuna. Sin esa estructura, la atención centrada en el paciente es un objetivo declarado, no operativo.

    Por qué los datos clínicos fallan sin un marco de gobierno

    El problema más frecuente en hospitales y redes de atención de la región es la fragmentación: cada sistema genera su propio registro, con sus propias definiciones de campo, sin un modelo de datos unificado ni un data steward —responsable de dominio de datos— que arbitre las discrepancias. Un mismo paciente puede tener tres identificadores distintos en tres sistemas, ninguno de los cuales dialoga con los otros. El resultado clínico es medicación duplicada, alergias no registradas o resultados de laboratorio que nunca llegan al médico tratante. El resultado institucional es incapacidad de analizar poblaciones, de cumplir con reportes regulatorios o de alimentar modelos de inteligencia artificial con datos confiables.

    El DAMA-DMBOK, referencia estándar en la industria, identifica la calidad del dato como una de las once áreas de conocimiento de la gobernanza. En salud, esa área adquiere carácter crítico: un dato de presión arterial con timestamp incorrecto o una dosis registrada con unidad de medida ambigua no es un error de reporting —es un riesgo clínico directo. Las instituciones que implementan marcos de calidad de datos con reglas de validación en el punto de captura reducen esa categoría de error de forma medible.

    Roles críticos: CDO, data steward y el médico como productor de datos

    La gobernanza de datos clínicos requiere una estructura de roles que la mayoría de los hospitales latinoamericanos todavía no ha formalizado. El Chief Data Officer (CDO) —o su equivalente funcional— es responsable de la estrategia de datos de la institución. Los data stewards de dominio clínico son los profesionales, frecuentemente médicos o enfermeras con perfil analítico, que definen y custodian los estándares de cada conjunto de datos: qué es un diagnóstico principal, cómo se codifica con CIE-10, cuándo un campo es obligatorio. Sin ese rol, las reglas de negocio quedan implícitas en la cabeza de cada operador y se vuelven ingoberables a escala.

    El marco Non-Invasive Data Governance de Bob Seiner ofrece una perspectiva útil para el sector salud: en lugar de imponer capas burocráticas, formaliza las responsabilidades que los profesionales ya ejercen informalmente. Un médico que corrige un diagnóstico ya está haciendo stewardship; la gobernanza lo hace visible, trazable y replicable. Esa lógica es especialmente relevante en hospitales públicos de la región, donde los recursos para estructuras formales son limitados.

    Cuándo aplica la gobernanza de datos en salud — y cuándo no es suficiente

    La gobernanza de datos clínicos aplica en cualquier institución que centralice registros de pacientes, opere con múltiples sistemas integrados o deba reportar indicadores de calidad asistencial a autoridades regulatorias. En Argentina, los hospitales que reportan al Ministerio de Salud de la Nación bajo el sistema SNVS 2.0 (enfermedades de notificación obligatoria) ya operan en un esquema que exige calidad y completitud del dato; ese requerimiento es, en la práctica, gobernanza de datos aplicada al dominio epidemiológico. En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como datos sensibles y exige tratamiento diferenciado, lo que obliga a las instituciones a mapear sus flujos de datos clínicos con un nivel de detalle que sólo es posible con un programa de gobernanza activo.

    La gobernanza de datos, sin embargo, no reemplaza la seguridad de la información ni la ciberseguridad clínica. Un hospital puede tener políticas de acceso bien definidas y aun así ser vulnerable a un ataque si no cuenta con controles técnicos complementarios. Tampoco resuelve por sí sola la interoperabilidad: sin estándares como HL7 FHIR implementados correctamente, la gobernanza documenta silos sin eliminarlos.

    El marco regulatorio en LATAM presiona hacia la acción

    Más allá de Brasil, otros países de la región están generando presión normativa sobre el manejo de datos clínicos. En Colombia, la Resolución 866 de 2021 del Ministerio de Salud establece lineamientos para la interoperabilidad de datos de salud, lo que implica implícitamente requisitos de calidad y estandarización. En México, la NOM-004-SSA3-2012 regula el expediente clínico electrónico y define qué datos son obligatorios y cómo deben estructurarse —una base normativa para un programa de calidad de datos clínicos. En Chile, la Ley 21.541 de 2023 sobre protección de datos, que moderniza la legislación y clasifica los datos de salud como sensibles, añade otra capa de exigencia para las instituciones del sector.

    Para los equipos de datos que trabajan en organizaciones de salud en la región, el punto de partida operativo es concreto: realizar un inventario de los dominios de datos clínicos críticos (paciente, diagnóstico, medicación, resultado de examen), asignar un data steward responsable por dominio, definir las reglas de calidad mínimas para cada campo, y establecer un dashboard de métricas de completitud y consistencia visible para la dirección médica y el área de TI. Sin ese inventario, cualquier iniciativa de analítica clínica o de inteligencia artificial aplicada a salud construye sobre una base que no conoce su propia fragilidad.

    Para profundizar en los marcos de referencia, el DAMA-DMBOK 2.0 (disponible en español) y la guía de implementación de HL7 FHIR para América Latina, publicada por la OPS, son los puntos de partida técnicos más sólidos para equipos que inician o maduran un programa de gobernanza de datos en salud.

  • AI Act: las obligaciones de transparencia del artículo 50 ya rigen en la UE

    AI Act: las obligaciones de transparencia del artículo 50 ya rigen en la UE

    Desde el 2 de agosto de 2026, las principales obligaciones de transparencia del artículo 50 del Reglamento de Inteligencia Artificial de la Unión Europea son de aplicación obligatoria para proveedores y desplegadores de sistemas de IA de propósito general. El hito convierte a la UE en la primera jurisdicción del mundo con reglas vinculantes sobre divulgación de IA en vigor, y su efecto extraterritorial alcanza a cualquier empresa que comercialice o despliegue sistemas en el mercado europeo, incluyendo a las de base latinoamericana con operaciones en la región.

    El EU AI Act —Reglamento (UE) 2024/1689, publicado en el Diario Oficial el 12 de julio de 2024— establece un calendario de implementación por fases. Las prohibiciones absolutas (artículo 5) entraron en vigor en febrero de 2026; las obligaciones para sistemas de alto riesgo tienen plazos que se extienden hasta 2027. El artículo 50, sin embargo, opera en una categoría propia: se aplica a prácticamente cualquier sistema de IA con el que un usuario pueda interactuar, con independencia de su nivel de riesgo clasificado.

    Qué exige el artículo 50 a proveedores y desplegadores de IA

    El artículo 50 impone cuatro obligaciones centrales. Primero, los proveedores de sistemas de IA diseñados para interactuar con personas deben asegurarse de que los usuarios sean informados de que están interactuando con una máquina, salvo que resulte evidente por el contexto. Segundo, los operadores de sistemas de IA generativa que produzcan contenido sintético —imágenes, audio, video o texto— deben etiquetar ese contenido como generado artificialmente mediante mecanismos legibles por máquina. Tercero, quienes desplieguen sistemas de reconocimiento de emociones o categorización biométrica deben notificar a los usuarios expuestos. Cuarto, los proveedores de modelos de IA de propósito general con capacidad generativa deben asegurarse de que los outputs puedan ser detectados como sintéticos mediante estándares técnicos interoperables, en línea con lo que desarrolle la Oficina de IA de la Comisión Europea.

    Las sanciones por incumplimiento del artículo 50 pueden alcanzar los 15 millones de euros o el 3% de la facturación global anual, el monto que resulte mayor. Ese umbral es inferior al del artículo 5 (35 millones o 7%) pero suficientemente significativo para organizaciones medianas con operaciones en Europa.

    Alcance extraterritorial: qué empresas latinoamericanas quedan expuestas

    El AI Act sigue el modelo regulatorio del GDPR en materia de aplicación territorial: no importa dónde esté establecido el proveedor, sino dónde se despliega el sistema o dónde están los usuarios afectados. Una fintech brasileña que ofrezca un chatbot de atención al cliente a usuarios en España o Alemania, una startup mexicana de síntesis de voz con clientes en Francia, o un proveedor argentino de soluciones de reconocimiento facial con contratos en Portugal quedan sujetos a las obligaciones del artículo 50 desde el 2 de agosto. El criterio de “puesta en el mercado” de la UE es amplio y no requiere presencia física en territorio europeo.

    Según el informe LAVCA 2025 sobre ecosistemas tecnológicos latinoamericanos, más de 340 startups de IA de la región identificaron Europa como mercado de expansión prioritario. Para todas ellas, el artículo 50 no es una regulación futura: es un requisito operativo vigente hoy.

    Brasil, Colombia y Chile: marcos de IA locales en distintos estadios de avance

    El contraste con América Latina es marcado. Brasil avanza con el Projeto de Lei 2.338/2023, que sigue la lógica de riesgo del AI Act europeo e incluye obligaciones de transparencia para sistemas de IA con impacto en personas, pero a agosto de 2026 aún no ha sido promulgado. La Autoridade Nacional de Proteção de Dados (ANPD) publicó en 2025 una guía orientadora sobre IA y tratamiento de datos personales, pero sin fuerza normativa vinculante en materia de transparencia de sistemas. Colombia cuenta con el documento CONPES 3975 de política nacional de IA y avanza en un proyecto de ley sectorial, aunque sin cronograma legislativo firme. Chile promulgó en 2024 su nueva Ley de Protección de Datos Personales (Ley 21.719), que incluye disposiciones sobre decisiones automatizadas, pero no aborda la transparencia de contenido sintético de forma explícita.

    En ninguna de estas jurisdicciones existe hoy una obligación análoga a la del artículo 50 del AI Act. Eso genera una asimetría regulatoria relevante: las empresas latinoamericanas que quieran operar en Europa deben adoptar estándares más exigentes que los requeridos en sus propios mercados domésticos, mientras que sus competidores europeos operan ya bajo ese estándar como condición de base.

    Impacto operativo: qué cambia para un equipo de producto o legal en la región

    El cumplimiento del artículo 50 no es solo un ejercicio jurídico: requiere decisiones técnicas de producto. Los equipos de ingeniería deben implementar mecanismos de etiquetado de contenido sintético compatibles con los estándares que emita la Oficina de IA de la UE, incluyendo potencialmente metadatos C2PA (Coalition for Content Provenance and Authenticity), que ya adoptaron plataformas como Adobe, Microsoft y Google. Los equipos legales deben revisar contratos con clientes europeos para incluir cláusulas de cumplimiento del AI Act y distribuir responsabilidades entre proveedor y desplegador, distinción que el reglamento hace explícita. Los equipos de producto deben auditar los flujos de interacción con usuarios para identificar dónde aplican las obligaciones de divulgación de interacción con IA.

    Un aspecto que genera dudas operativas frecuentes es la excepción de “contexto evidente”: el artículo 50 no exige notificación cuando resulte manifiestamente obvio que el usuario interactúa con una IA. Pero la carga de probar esa obviedad recae sobre el desplegador, y la Oficina de IA aún no ha publicado criterios orientadores sobre cómo interpretar ese umbral.

    Próximos hitos del AI Act que las empresas con exposición europea deben monitorear

    El calendario regulatorio del AI Act no termina con el artículo 50. Las obligaciones para sistemas de alto riesgo del Anexo III —incluyendo IA en crédito, empleo, educación y administración de justicia— son exigibles a partir de agosto de 2027. Los Códigos de Práctica para modelos de propósito general, desarrollados bajo la Oficina de IA con participación de la industria, debían estar finalizados en mayo de 2025 y son de relevancia directa para cualquier empresa que opere modelos fundacionales o construya sobre APIs de terceros. El sistema de notificación de incidentes graves para sistemas de alto riesgo también entra en vigor de forma escalonada. Monitorear la producción normativa de la Oficina de IA —que publica actos delegados y guías técnicas de forma continua— es hoy una tarea de inteligencia regulatoria que no puede quedar solo en manos del equipo legal.

    Nuestro análisis

    El artículo 50 es, en términos prácticos, la primera norma global de transparencia de IA con enforcement real. Que sea europea no la hace irrelevante para la región: la convierte en el estándar de facto para cualquier empresa latinoamericana con ambiciones de internacionalización. La asimetría actual —donde operar en Europa exige más que operar en casa— podría invertirse si Brasil promulga el PL 2.338 con obligaciones análogas, algo que el ANPD ha impulsado técnicamente pero que depende de voluntad legislativa. Mientras eso no ocurra, las empresas de la región que decidan ignorar el AI Act por considerar que “solo aplica en Europa” subestiman tanto el alcance territorial del reglamento como el impacto reputacional de un incumplimiento documentado por una autoridad de control europea. La Oficina de IA tiene competencia sancionatoria directa sobre modelos de propósito general y ha señalado que priorizará casos de alto impacto en su primer año de operación.

    Para las empresas latinoamericanas con operaciones o clientes en Europa, la pregunta ya no es si el AI Act aplica: es si sus procesos internos de producto, legal e ingeniería están alineados antes de que llegue la primera inspección.

  • IA reactiva el interés en data mesh y data fabric: qué cambia para los equipos de datos

    IA reactiva el interés en data mesh y data fabric: qué cambia para los equipos de datos

    La adopción acelerada de inteligencia artificial en las organizaciones está reviviendo dos arquitecturas de datos que muchos equipos habían postergado: data mesh y data fabric. La razón es operativa, no teórica: los sistemas de IA necesitan datos confiables, bien catalogados y accesibles a escala, exactamente lo que estas arquitecturas prometen resolver.

    Data mesh y data fabric no son conceptos nuevos. El primero fue popularizado por Zhamak Dehghani hacia 2019 como una respuesta a los cuellos de botella de los equipos centralizados de datos: en lugar de un lago de datos monolítico, propone distribuir la responsabilidad del dato a los dominios de negocio que lo generan y consumen. El data fabric, por su parte, es una capa de integración semántica y automatizada que conecta fuentes heterogéneas sin moverlas físicamente, usando metadatos activos para que los datos sean descubribles y reutilizables. Ambos enfoques comparten un objetivo: que el dato correcto llegue a quien lo necesita, cuando lo necesita, con la calidad adecuada.

    Por qué la IA fuerza a resolver lo que se había pospuesto

    Durante años, muchas organizaciones operaron con arquitecturas de datos fragmentadas sin consecuencias inmediatas visibles. Los analistas sabían dónde estaban los datos, los pipelines funcionaban con fricciones tolerables y los reportes salían aunque tarde. La IA generativa rompió ese equilibrio: un modelo de lenguaje que consume datos de múltiples dominios no puede operar con silos manuales, metadatos inconsistentes o linaje opaco. Cuando un agente de IA toma una decisión basada en datos incorrectos o desactualizados, el error escala a velocidad y volumen que los procesos manuales de calidad no pueden contener. El resultado es que proyectos de IA que fracasan en producción están forzando conversaciones de arquitectura que los equipos evitaban desde hace años.

    Según el marco DAMA-DMBOK, la gestión de metadatos y el data lineage —la trazabilidad del origen, transformación y movimiento de un dato— son capabilities centrales de cualquier programa de gobernanza maduro. En la práctica, son también los dos requisitos no negociables para que un sistema de IA opere de forma auditable. Sin saber de dónde viene un dato ni cómo fue transformado, no es posible validar los outputs de un modelo ni cumplir con los requisitos de explicabilidad que exigen marcos regulatorios como el AI Act europeo o los lineamientos en desarrollo de la ANPD en Brasil.

    Data mesh: ownership de dominio como condición de escala

    El principio central de data mesh es que cada dominio de negocio actúa como productor y responsable de sus propios data products —conjuntos de datos con calidad garantizada, documentados y expuestos con una interfaz estándar. En la terminología de Dehghani, esto se conoce como “data product thinking”: el dato deja de ser un subproducto de los procesos operativos y se gestiona con la misma rigurosidad que un producto de software. Para la IA, esto importa porque los modelos de machine learning y los agentes de IA requieren datos con contratos explícitos: esquema estable, SLA de calidad, propietario identificable. Un data product bien definido cumple esos requisitos por diseño.

    La implementación de data mesh, sin embargo, no es trivial. Requiere asignar data stewards —responsables operativos del dato dentro de cada dominio— con tiempo, herramientas y autoridad real para mantener la calidad. La experiencia en la región muestra que este es el punto de fractura más común: las organizaciones adoptan la retórica del data mesh sin redistribuir la responsabilidad efectiva ni asignar los recursos que esa responsabilidad requiere. El resultado es un catálogo poblado a medias y data products que nadie actualiza.

    Data fabric y metadatos activos: el rol del catálogo inteligente en Argentina, Brasil y México

    El data fabric se apoya en metadatos activos —metadatos que no solo describen los datos sino que se usan para automatizar su descubrimiento, integración y gobierno. Herramientas como catálogos de datos con capacidades de IA incorporada pueden inferir relaciones entre datasets, proponer clasificaciones de sensibilidad y alertar cuando el linaje de un dato cambia. Esta automatización es especialmente relevante para organizaciones en América Latina que operan con equipos pequeños de datos pero con entornos multicloud y fuentes heterogéneas.

    En el contexto regulatorio de la región, la capa de metadatos activos tiene implicancias directas. La Ley 25.326 de Argentina y la LGPD de Brasil exigen poder identificar qué datos personales se procesan, con qué base legal y durante cuánto tiempo. Un data fabric con linaje automatizado puede responder esas preguntas de forma reproducible. En México, la LFPDPPP impone obligaciones similares para el sector privado. Las organizaciones que ya invirtieron en data fabric para soportar sus proyectos de IA tienen, como subproducto, una infraestructura de trazabilidad que simplifica el cumplimiento de estas leyes. Las que no lo hicieron enfrentarán el mismo problema dos veces: una para la IA y otra para el regulador.

    Cuándo aplica data mesh y cuándo data fabric — y cuándo ninguno de los dos

    Data mesh aplica cuando la organización tiene múltiples dominios de negocio con datos propios, equipos técnicos distribuidos y un problema de ownership —nadie sabe quién es responsable de qué dato. No aplica en organizaciones pequeñas con un solo equipo de datos centralizado: el overhead de coordinación supera los beneficios. Data fabric aplica cuando el problema es de integración heterogénea —muchas fuentes, muchos formatos, baja reutilización— y el equipo no puede o no quiere mover los datos a un repositorio central. No es la solución correcta cuando el problema de fondo es calidad en origen: una capa de integración sobre datos sucios produce datos sucios integrados más rápido. Ambas arquitecturas son complementarias y muchas organizaciones grandes las implementan en capas, pero el orden importa: primero ownership y calidad, después integración y escala.

    El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), ubica el data lineage y la gestión de metadatos en las capabilities de nivel 6 a 8 de madurez —las más avanzadas. Eso significa que una organización que aún no tiene ownership claro de sus datos ni catálogo operativo no está lista para implementar data mesh o data fabric de forma efectiva. El camino correcto es secuencial: establecer stewardship, catalogar, medir calidad, y recién entonces escalar con arquitecturas distribuidas.

    La especificación completa del modelo de data product de Zhamak Dehghani está disponible en datamesh-architecture.com; el marco CDMC del EDM Council, en edmcouncil.org. Ambos son puntos de partida más útiles que cualquier vendor deck.

  • Gobernanza de datos clínica: por qué el sector salud no puede improvisar

    Gobernanza de datos clínica: por qué el sector salud no puede improvisar

    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.

  • Gobernanza de datos e IA: la ventaja competitiva que los CDO no pueden ignorar

    Gobernanza de datos e IA: la ventaja competitiva que los CDO no pueden ignorar

    Las organizaciones que tratan la gobernanza de datos como un requisito de cumplimiento —y no como palanca estratégica— están perdiendo terreno frente a competidores que ya usan sus datos con trazabilidad, calidad y confianza verificables. Con la inteligencia artificial como acelerador, el costo de una mala gobernanza dejó de ser abstracto: se mide en modelos sesgados, decisiones auditadas judicialmente y multas regulatorias.

    La gobernanza de datos, en términos operativos, es el conjunto de políticas, roles, procesos y controles que determinan quién puede hacer qué con qué dato, cuándo y con qué nivel de calidad garantizado. No es un proyecto de TI: es una disciplina organizacional que cruza finanzas, legal, operaciones y ahora —de manera inseparable— los sistemas de inteligencia artificial. Sin gobernanza, un modelo de IA es una caja negra alimentada con datos de origen incierto; con gobernanza, ese mismo modelo puede auditarse, explicarse y defenderse ante un regulador.

    Por qué la IA convierte la gobernanza de datos en urgencia de negocio

    Los sistemas de IA generativa y los modelos predictivos dependen de los datos que los alimentan. Si esos datos tienen problemas de calidad, linaje incompleto o clasificación errónea, el output del modelo hereda —y amplifica— esos defectos. El marco DAMA-DMBOK v2 identifica once áreas de conocimiento en la gestión de datos; las más críticas para implementaciones de IA son precisamente las que menos madurez tienen en la mayoría de las empresas de la región: calidad de datos, linaje (data lineage) y seguridad de datos con clasificación formal. El EDM Council, a través del modelo CDMC (Cloud Data Management Capabilities), añade una capa adicional: la trazabilidad del dato en entornos cloud, que es donde la mayoría de los modelos de IA se entrenan y despliegan hoy.

    El data lineage —la capacidad de rastrear un dato desde su origen hasta su uso final, incluyendo cada transformación intermedia— es el componente que los reguladores de IA están comenzando a exigir explícitamente. El AI Act de la Unión Europea, vigente desde agosto de 2024, obliga a los proveedores de sistemas de IA de alto riesgo a documentar la procedencia y características de los datasets de entrenamiento. Esa exigencia no es opcional para empresas latinoamericanas que exporten servicios de IA a Europa o que operen filiales allí.

    Transparencia algorítmica y los marcos regulatorios en Brasil, México y Argentina

    En América Latina, la presión regulatoria sobre la IA todavía no alcanza la especificidad del AI Act europeo, pero los marcos de protección de datos ya imponen obligaciones indirectas que requieren gobernanza sólida. La Lei Geral de Proteção de Dados (LGPD) de Brasil, en su artículo 20, establece el derecho del titular a solicitar revisión de decisiones tomadas exclusivamente por medios automatizados. Ejercer ese derecho —y responderlo— exige que la organización tenga linaje documentado y pueda reconstruir la lógica del modelo. Sin gobernanza de datos, ese artículo es inejercitable en la práctica. En México, la LFPDPPP y los Lineamientos del INAI sobre tratamientos especiales apuntan en la misma dirección. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) publicó en 2023 recomendaciones sobre el uso de IA en el sector público que enfatizan la necesidad de auditoría de datos de entrada.

    El dato que sintetiza el problema regional: según el informe State of Data Management de DAMA International (edición 2023), menos del 30% de las organizaciones encuestadas en mercados emergentes tienen un programa formal de calidad de datos con métricas publicadas internamente. Es decir, la mayoría de las empresas que hoy despliegan IA en LATAM lo hacen sin saber, con precisión documentada, qué tan confiables son los datos que alimentan sus modelos.

    Cuándo aplica la gobernanza de datos como ventaja competitiva — y cuándo no

    La gobernanza de datos genera ventaja competitiva verificable en escenarios concretos: sectores regulados con auditorías externas (banca, salud, seguros), organizaciones que monetizan datos como producto o insumo para terceros, y empresas que despliegan IA en decisiones que afectan a personas (crédito, contratación, scoring de riesgo). En esos contextos, la capacidad de demostrar la calidad, el origen y el tratamiento ético de los datos es diferencial. Donde la gobernanza no es ventaja competitiva inmediata —aunque sí sigue siendo necesaria— es en operaciones internas sin regulación sectorial y sin modelos de IA en producción: allí el foco inicial debería ser construir el inventario de datos (data catalog) antes de crear estructuras de gobierno complejas. Bob Seiner, referente del enfoque Non-Invasive Data Governance, subraya que los programas que empiezan por la burocracia antes que por el inventario suelen morir en el comité de aprobación.

    Tres capacidades concretas para construir gobernanza que soporte IA

    Un programa de gobernanza de datos orientado a soportar sistemas de IA debe priorizar, en este orden:

    • Clasificación formal de datos: definir qué datos son sensibles, críticos o regulados, y asignar un data steward responsable por cada dominio. Sin clasificación, no hay control de acceso diferenciado ni linaje aplicable.
    • Linaje end-to-end en los pipelines que alimentan modelos: documentar las transformaciones, joins y filtros que aplican sobre los datos antes de que lleguen al entrenamiento o a la inferencia. Herramientas como Apache Atlas, OpenMetadata o las capacidades nativas de plataformas cloud (AWS Glue DataBrew, Azure Purview) permiten automatizar buena parte de esta captura.
    • Métricas de calidad de datos publicadas y revisadas en ciclos definidos: dimensiones mínimas según DAMA-DMBOK: completitud, exactitud, consistencia y oportunidad. Sin métricas, la “calidad de datos” es una aspiración, no un estado gestionable.

    Para los CDO que operan en la región, el punto de entrada más realista en 2025 no es implementar CDMC completo —son 14 capacidades con más de 500 sub-controles— sino mapear cuáles de esas capacidades ya tienen equivalentes funcionales en la organización. Los bancos argentinos que reportan al BCRA bajo Comunicación A 7724 (gestión de riesgos tecnológicos) ya operan con controles de calidad y trazabilidad que cubren parcialmente las capabilities 6 y 8 del CDMC, aunque sin la certificación formal. El ejercicio de mapear eso toma menos tiempo del que parece y produce el argumento de negocio para financiar los gaps.

    Para profundizar en los requisitos de documentación de datasets bajo el AI Act europeo, el texto oficial está disponible en el Diario Oficial de la UE (Reglamento 2024/1689); para el contexto LATAM, las recomendaciones de la AAIP sobre IA en el sector público ofrecen el punto de partida más concreto disponible en la región a la fecha.