DataTrends LATAM

Categoría: Data Governance

  • Río Negro avanza en gobernanza de datos públicos: el proyecto que divide al bloque

    Río Negro avanza en gobernanza de datos públicos: el proyecto que divide al bloque

    La provincia argentina de Río Negro está a punto de sancionar un marco normativo propio de gobernanza de datos públicos, según informó el medio legislativo Quorum. El proyecto, que ingresó a la etapa final de debate parlamentario, propone un modelo de gestión, clasificación y uso de los datos que producen los organismos estatales provinciales —y ha generado diferencias internas que todavía no están resueltas.

    La iniciativa representa uno de los primeros intentos subnacionales en Argentina de codificar, en un texto legal, los principios que deben regir el ciclo de vida del dato público: desde su producción hasta su acceso, reutilización y eventual apertura. Esto la distingue de las leyes de acceso a la información pública ya vigentes —como la Ley Nacional 27.275— que regulan el derecho de acceso pero no la arquitectura de gestión interna del dato en el Estado.

    Qué propone el proyecto rionegrino: clasificación, acceso y roles institucionales

    Según se informó, el texto establece un esquema de clasificación de los datos públicos provinciales según su sensibilidad y posibilidades de apertura, y define roles institucionales responsables de la custodia y calidad de esa información. En la nomenclatura de la industria, el proyecto intentaría instalar algo equivalente a la figura del data steward en el aparato estatal: un responsable funcional que no es el área de sistemas, sino el área productora del dato. El proyecto también contempla mecanismos de interoperabilidad entre organismos y criterios mínimos de calidad del dato.

    Las diferencias internas que menciona la cobertura legislativa habrían girado, según se informó, en torno al alcance del órgano rector propuesto —si debe ser un ente autónomo, una secretaría bajo el Ejecutivo, o una comisión mixta con participación legislativa— y al grado de obligatoriedad de los estándares de apertura para los organismos descentralizados. Esa tensión entre centralización del gobierno del dato y autonomía de los productores de datos es clásica en cualquier implementación de marcos de gobernanza, y aparece tanto en el sector privado como en el público.

    Argentina sin ley nacional de gobernanza de datos del Estado: el vacío que las provincias empiezan a llenar

    Argentina carece de un marco nacional que regule específicamente la gobernanza de datos en el sector público más allá de la apertura de datos y el acceso a la información. El Decreto 1063/2016 y el Plan de Modernización del Estado impulsaron la apertura de datos bajo un modelo de datos abiertos, pero sin definir estructuras de ownership, linaje (data lineage) ni criterios de calidad sistematizados para los datos que el Estado produce y consume internamente. En ese vacío, iniciativas subnacionales como la de Río Negro ganan relevancia como laboratorios normativos.

    A nivel federal, el Senado tiene pendientes desde hace años proyectos de interoperabilidad del Estado que nunca alcanzaron sanción. La Ciudad de Buenos Aires avanzó más que otras jurisdicciones con su ecosistema de datos abiertos (data.buenosaires.gob.ar), pero tampoco cuenta con una ley de gobernanza de datos públicos en sentido estricto. Río Negro podría convertirse, si el proyecto prospera, en la primera provincia argentina con un marco de este tipo.

    Brasil con la LGPD, Chile con la Ley 21.719 y Colombia con el CONPES 3975: el contraste regional

    En América Latina, los marcos de gobernanza de datos públicos van por carriles distintos según el país. Brasil incorporó en la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) obligaciones específicas para los organismos públicos en el tratamiento de datos personales, pero la gobernanza del dato no personal —el que producen los ministerios en su gestión cotidiana— sigue siendo un área de baja regulación. La Estratégia de Governo Digital 2024-2027 contempla lineamientos de interoperabilidad, aunque sin fuerza de ley.

    Chile sancionó en 2024 la Ley 21.719 de Protección de Datos Personales, que moderniza el régimen de privacidad e incluye disposiciones para el sector público, pero tampoco aborda la gobernanza integral del dato estatal. Colombia, en cambio, tiene el antecedente del CONPES 3975 (2019) de Política Nacional para la Transformación Digital, que sí incluye lineamientos de gestión de datos públicos con roles y responsabilidades definidos para las entidades del Estado —aunque como política, no como ley con enforcement directo. El proyecto de Río Negro, si incluye sanciones por incumplimiento, podría tener más dientes que el modelo colombiano.

    Qué monitorear: el texto final, el órgano rector y si el modelo puede replicarse en otras provincias

    Los próximos hitos a seguir son tres. Primero, el texto definitivo que salga del debate parlamentario: los artículos sobre el órgano rector y la obligatoriedad de los estándares para organismos descentralizados definirán si el marco tiene capacidad real de implementación o queda como declaración de principios. Segundo, el mecanismo de financiamiento y recursos humanos: un marco de gobernanza sin capacidad técnica instalada en los organismos productores de datos fracasa en la práctica, independientemente de su solidez jurídica. Tercero, si otras legislaturas provinciales —Neuquén, Santa Fe, Córdoba— toman el proyecto rionegrino como modelo, lo que podría acelerar una convergencia normativa subnacional que el Congreso Nacional todavía no pudo generar.

    Nuestro análisis

    El valor del proyecto de Río Negro no está en su perfección técnica —que no podemos evaluar sin acceso al texto completo— sino en la pregunta que instala: ¿quién es el dueño del dato en el Estado provincial? Esa pregunta, que en el sector privado se resuelve con marcos como DAMA-DMBOK o CDMC del EDM Council asignando data owners y data stewards por dominio, raramente tiene respuesta explícita en los gobiernos subnacionales argentinos. Los datos de salud, los registros catastrales, los datos de gestión de obras públicas: todos se producen, se usan y se pierden sin un esquema de accountability claro. Si el proyecto rionegrino logra asignar esa responsabilidad funcional —no solo tecnológica— habrá dado un paso que muchas provincias con mayor presupuesto todavía no dieron.

    El riesgo simétrico es que el debate sobre el órgano rector consuma la energía política disponible y el texto final quede como un marco declarativo sin capacidad operativa. Eso ha ocurrido con iniciativas similares en otros contextos: una ley que define qué es un dato público de calidad pero no designa quién responde si ese dato es incorrecto, incompleto o inaccesible es una ley que no cambia nada.

    Si Río Negro sanciona un marco que asigna responsabilidad funcional sobre el dato —y no solo responsabilidad tecnológica— habrá creado jurisprudencia subnacional que el nivel nacional debería mirar con atención. La pregunta que queda abierta es si el Congreso Nacional esperará a ver cuántas provincias legislan por su cuenta antes de intentar una política federal de gobernanza de datos del Estado.

  • Gobernanza de datos shift-left: el modelo que PayPal lleva a producción

    Gobernanza de datos shift-left: el modelo que PayPal lleva a producción

    Shift-left en gobernanza de datos significa mover los controles de calidad, clasificación y ownership lo más temprano posible en el ciclo de vida del dato: hacia los equipos de ingeniería, al momento del diseño del pipeline, no en la capa de consumo. Un ejecutivo de PayPal describió públicamente cómo la compañía está transitando ese camino, según se informó en TechTarget en septiembre de 2025. El enfoque tiene implicancias directas para cualquier CDO que hoy pelea contra brechas de calidad descubiertas demasiado tarde.

    El término viene del desarrollo de software —”shift-left testing” implica correr pruebas antes, en etapas tempranas del SDLC, para reducir el costo de corrección. Aplicado a datos, el principio es idéntico: si la clasificación, el etiquetado de sensibilidad y las reglas de calidad se aplican cuando el dato se crea o ingiere, el costo de remediación baja varios órdenes de magnitud. Según el marco DAMA-DMBOK, la gobernanza que opera solo en la capa analítica o de reporte llega cuando el daño ya está hecho.

    Qué implica técnicamente un modelo shift-left en un ecosistema como el de PayPal

    En la práctica, shift-left de gobernanza requiere tres capacidades simultáneas. Primero, que los data stewards —los responsables de dominio del dato, en la nomenclatura del DAMA-DMBOK— participen en el diseño de pipelines de ingestión, no solo en la validación posterior. Segundo, que las políticas de clasificación y calidad estén codificadas como reglas ejecutables en el pipeline mismo, no como documentos en un repositorio de SharePoint. Tercero, que el catálogo de datos activo reciba metadata desde el momento de la creación del asset, no como proceso de backfill retroactivo. En una plataforma de pagos con el volumen transaccional de PayPal, según se informó, esto implica orquestar esas capacidades a escala de miles de pipelines concurrentes.

    El modelo encaja con lo que el EDM Council denomina “Data Management Capability Assessment” (DCAM): la capability 8 del framework —gestión del ciclo de vida del dato— solo alcanza madurez cuando los controles están embebidos en el flujo de producción, no aplicados post-hoc. El enfoque shift-left es, en esencia, el camino operativo hacia ese nivel de madurez.

    Cuándo aplica este enfoque y cuándo no justifica el esfuerzo

    Shift-left de gobernanza aplica cuando la organización tiene pipelines de datos repetibles, equipos de ingeniería de datos con capacidad para implementar controles en código, y un modelo de ownership de dominio suficientemente maduro como para que exista un data steward identificable por cada dominio. También es el modelo correcto cuando la regulación exige trazabilidad desde el origen: por ejemplo, las entidades financieras en Brasil que reportan al Banco Central bajo las normas del open finance están obligadas a demostrar linaje desde la fuente, lo que hace de shift-left no una elección de diseño sino un requisito de cumplimiento. Lo mismo aplica para compañías de pagos operando en México bajo supervisión del CNBV, donde la LFPDPPP exige identificar con precisión qué dato personal fue procesado, cuándo y bajo qué base legal.

    El modelo no justifica el esfuerzo en organizaciones con pipelines ad hoc, baja repetibilidad de flujos de datos, o donde el ownership de dominio aún no está asignado. En esos casos, intentar embeber controles en pipelines que cambian semanalmente produce deuda técnica de gobernanza sin reducir el riesgo. Bob Seiner, autor de Non-Invasive Data Governance, señala que los controles de gobernanza deben anclarse en procesos existentes: si el proceso no existe o es inestable, el control no tiene dónde anclar.

    El gap en América Latina: ownership sin habilitación técnica

    El principal obstáculo regional para adoptar shift-left no es la falta de voluntad de los CDOs, sino una brecha estructural entre la asignación formal de roles de gobernanza y la habilitación técnica de esos roles. En la región, es común que un data steward tenga responsabilidad nominal sobre un dominio de datos pero no tenga acceso a las herramientas de catalogación, ni visibilidad sobre los pipelines que procesan ese dominio. Sin esa habilitación, shift-left es solo un nombre: los controles siguen corriendo en la capa de consumo, si es que corren. Los bancos argentinos que operan bajo la Comunicación A 8073 del BCRA ya enfrentan exigencias de trazabilidad de datos de clientes equivalentes a las capabilities de nivel 8 del DCAM, pero sin la infraestructura de catálogo activo que las soporte, el cumplimiento es manual y frágil.

    El modelo de PayPal es relevante para la región no como caso a replicar en escala, sino como referencia de diseño: el camino empieza por mapear qué pipelines tienen ownership claro y repetibilidad suficiente, y aplicar shift-left solo ahí primero. Nicola Askham, referente en implementación práctica de gobernanza, llama a esto “gobernanza por dominio piloto”: consolidar un dominio con controles embebidos antes de intentar el rollout horizontal.

    La documentación de referencia del DCAM del EDM Council y el capítulo 13 del DAMA-DMBOK sobre gestión del ciclo de vida del dato ofrecen los criterios concretos para evaluar si una organización tiene las condiciones mínimas para ejecutar este tipo de migración de controles.

  • Cuando el catálogo de datos es la brecha: por qué rotar credenciales no alcanza

    Cuando el catálogo de datos es la brecha: por qué rotar credenciales no alcanza

    Si un atacante compromete el catálogo de datos corporativo, no roba registros: roba el mapa completo de todo lo que la organización sabe sobre sus propios datos. Esa diferencia convierte a este tipo de incidente en una categoría aparte, y hace que la respuesta estándar —rotar credenciales, parchear el vector, cerrar el ticket— sea radicalmente insuficiente.

    Un catálogo de datos centraliza la metadata técnica y de negocio de una organización: qué tablas existen, qué contienen, quién las accede, cómo se relacionan entre sí, qué tan sensibles son y bajo qué política de retención operan. Herramientas como Apache Atlas, Alation, Collibra, DataHub o Amundsen acumulan esa inteligencia en un único punto. Según el marco DAMA-DMBOK, el catálogo es la columna vertebral del capability de Metadata Management, sin el cual el resto de las disciplinas de gobernanza de datos no puede operar. Eso lo convierte también en el activo de mayor valor estratégico para un adversario que quiera planificar ataques futuros o entender la arquitectura de datos de su objetivo.

    El catálogo no guarda datos: guarda el conocimiento sobre los datos

    La diferencia de impacto frente a una brecha convencional es estructural. En un incidente típico, el atacante extrae un conjunto de registros —números de tarjeta, correos, datos de salud— y el daño está acotado a esos registros. En una brecha de catálogo, el adversario obtiene el inventario completo: sabe qué base de datos contiene los datos de clientes premium, qué pipeline los mueve, quién tiene acceso privilegiado y qué controles (o ausencia de ellos) los protegen. Es, en términos prácticos, un reconocimiento total del entorno de datos. Los equipos de seguridad ofensiva llaman a esto “living off the land” aplicado a la capa de metadata.

    El data lineage —la trazabilidad de cómo un dato se mueve desde su origen hasta su destino final— amplifica el daño. Un catálogo moderno que almacena linaje completo le entrega al atacante el grafo de dependencias de toda la infraestructura de datos: desde los sistemas fuente hasta los data marts que alimentan los reportes ejecutivos. Con esa información, un atacante paciente puede planificar intrusiones quirúrgicas en sistemas downstream sin necesidad de escanear la red.

    Por qué rotar credenciales no resuelve la exposición del catálogo

    La rotación de credenciales corta el acceso activo, pero no borra el conocimiento ya adquirido. Si el catálogo estuvo expuesto durante horas o días, el atacante ya tiene una copia del inventario de metadata. Cambiar contraseñas o revocar tokens resuelve el vector de entrada, no el daño informacional. Es equivalente a cambiar la cerradura de una caja fuerte después de que alguien fotografió el contenido. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica explícitamente la protección de metadata sensible como un control de nivel 2 bajo el capability de Data Control, diferenciado del control de acceso a los datos en sí. Muchas organizaciones aplican controles de clase A a sus bases de datos productivas y dejan el catálogo con controles de clase C, sin clasificación de sensibilidad propia ni auditoría de acceso detallada.

    El problema se agrava porque los catálogos modernos tienden a integrarse con sistemas de identidad corporativa (LDAP, Azure AD), orquestadores (Airflow, Dagster), plataformas de transformación (dbt) y herramientas de observabilidad. Un catálogo comprometido puede ser el punto de pivote hacia toda esa cadena. El data steward responsable de ese dominio raramente tiene visibilidad sobre los logs de acceso al catálogo con el mismo nivel de detalle con el que el equipo de seguridad audita los sistemas productivos.

    Cuándo aplica este riesgo / cuándo NO

    Este vector de riesgo aplica a organizaciones que operan un catálogo de datos centralizado con metadata enriquecida: clasificación de sensibilidad, linaje automatizado, integración con pipelines activos y perfiles de datos. Si el catálogo es una planilla Excel o un repositorio estático sin conexión a sistemas productivos, el riesgo es considerablemente menor, aunque no nulo. No aplica —al menos no con esta criticidad— en entornos donde el catálogo está aislado de la red, opera sin autenticación federada y no contiene metadata operativa actualizada. En arquitecturas de data mesh, donde cada dominio puede operar su propio catálogo local, el riesgo se distribuye pero no desaparece: un catálogo de dominio financiero sigue siendo un activo de alto valor.

    El ángulo en América Latina: cumplimiento normativo post-brecha

    En la región, una brecha de catálogo tiene implicancias regulatorias que van más allá de lo técnico. En Brasil, la LGPD (Lei 13.709/2018) obliga a notificar a la ANPD cuando el incidente puede acarrear riesgo relevante a los titulares. Si el catálogo expuesto documenta el tratamiento de datos sensibles —salud, biometría, datos financieros— la organización debe evaluar si la exposición de esa metadata activa la obligación de notificación, incluso si los datos en sí no fueron exfiltrados. En Argentina, la Ley 25.326 y las disposiciones de la AAIP siguen una lógica similar. En México, el INAI ha comenzado a interpretar el concepto de “tratamiento” de datos de forma más amplia, lo que podría incluir la exposición de metadata que revela el alcance de ese tratamiento. Esta ambigüedad regulatoria es un riesgo legal no trivial que los equipos jurídicos de muchas organizaciones de la región aún no tienen mapeado.

    Para un CDO que quiere evaluar la exposición real de su organización, el punto de partida es concreto: auditar los logs de acceso al catálogo con la misma rigurosidad que se auditan los sistemas productivos; clasificar el catálogo como activo de datos sensible con su propio data owner y política de acceso; revisar si el data steward de cada dominio tiene visibilidad sobre quién accede a la metadata de su dominio y cuándo; y documentar el proceso de respuesta a incidentes específico para el catálogo, separado del playbook genérico de seguridad.

    Para profundizar en los controles de metadata bajo el framework CDMC del EDM Council, el punto de partida es el capability 8 (Data Control) disponible en edmcouncil.org; para el marco regulatorio de notificación en la región, la Guía de Medidas de Seguridad de la AAIP y las Resoluções de la ANPD ofrecen los criterios de evaluación más actualizados.

  • Gobernanza de datos en minería: decisiones críticas bajo datos confiables

    Gobernanza de datos en minería: decisiones críticas bajo datos confiables

    La industria minera opera con decisiones de miles de millones de dólares que dependen de datos geológicos, operativos y financieros. Sin una gobernanza de datos sólida, esos datos son ruido —y los errores se miden en pozos secos, paradas de planta o accidentes evitables.

    El concepto de gobernanza de datos en minería no se reduce a proteger información sensible: abarca definir quién es propietario de cada dato, qué versión del dato es la oficial, cómo se trazó desde su origen y con qué calidad llega a la sala de decisiones. En términos del marco DAMA-DMBOK —el estándar de referencia para la disciplina—, hablamos de las capabilities de data quality, data lineage y data ownership aplicadas a un entorno industrial de alta criticidad.

    Qué datos mueven la aguja en una operación minera

    Una mina activa genera volúmenes masivos de datos heterogéneos: telemetría de equipos pesados, modelos de bloques geológicos, registros de perforación, datos de ley del mineral, consumo energético, variables de planta y métricas de seguridad operacional. El problema no es la cantidad —es la fragmentación. Cada área suele operar con sus propias fuentes, sus propias definiciones y, con frecuencia, sus propias hojas de cálculo paralelas. Cuando la dirección consolida esa información para decidir si avanzar con una nueva fase de extracción, puede estar trabajando con versiones distintas del mismo dato sin saberlo.

    El data lineage —la trazabilidad que permite saber de dónde viene un dato, qué transformaciones sufrió y quién lo modificó— es la herramienta que permite detectar esas inconsistencias antes de que lleguen al tablero ejecutivo. Sin ese linaje documentado, la auditoría de decisiones pasadas es prácticamente imposible, y la mejora continua queda reducida a intuición.

    Ciberseguridad como extensión del gobierno del dato, no como disciplina separada

    La ciberseguridad en entornos mineros ha ganado visibilidad tras incidentes en operaciones de países productores como Chile, Perú y Australia, donde ataques a sistemas SCADA o de gestión de flota comprometieron tanto la continuidad operativa como la integridad de los datos de producción. Este punto es clave: cuando un sistema de control es comprometido, el daño no es solo operativo —los datos que ese sistema registró durante el ataque pierden confiabilidad. Si no hay controles de calidad ni mecanismos de detección de anomalías en el flujo de datos, esos registros corruptos pueden alimentar modelos de decisión sin que nadie lo advierta.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), establece que la seguridad del dato no es una capa externa sino una dimensión intrínseca del gobierno del dato. Esto implica que los equipos de data governance y los equipos de ciberseguridad deben trabajar con taxonomías compartidas: qué datos son críticos, qué nivel de sensibilidad tienen, quién puede acceder a ellos y bajo qué condiciones. En minería, eso se traduce en clasificar, por ejemplo, los modelos de recursos como activos de información de máxima criticidad —con controles equivalentes a los que se aplican a información financiera material.

    Cuándo aplica una arquitectura de gobierno del dato en minería — y cuándo no

    Una arquitectura formal de gobierno del dato tiene sentido en operaciones con múltiples fuentes de datos integradas, equipos multidisciplinarios que comparten información para decidir, y regulaciones sectoriales que exigen trazabilidad —como los reportes de recursos y reservas bajo el Código JORC o el Código NI 43-101 en América del Norte, que obligan a documentar la metodología y los datos subyacentes usados para estimar recursos minerales. En esos contextos, un catálogo de datos con data stewards asignados por dominio (geología, producción, mantenimiento, finanzas) no es un lujo: es un requisito de cumplimiento.

    Por otro lado, en operaciones pequeñas o de una sola fase, un programa formal de gobierno puede ser desproporcionado. Allí, la prioridad es establecer definiciones mínimas acordadas, identificar las fuentes únicas de verdad para las métricas críticas y documentar los procesos de transformación de datos antes de que escalen. El marco Non-Invasive Data Governance de Bob Seiner ofrece una alternativa pragmática: formalizar lo que ya existe en los procesos sin imponer burocracia nueva.

    El ángulo regulatorio en América Latina: minería, datos y obligaciones emergentes

    En la región, la gobernanza de datos en minería empieza a cruzarse con marcos regulatorios más amplios. En Chile, donde el sector representa cerca del 15% del PBI según datos del Banco Central, la Comisión para el Mercado Financiero (CMF) ya exige estándares de divulgación de información que incluyen datos operativos materiales —lo que obliga a las mineras listadas a tener trazabilidad sobre cómo se construyen esas cifras. En Perú, la Superintendencia del Mercado de Valores (SMV) avanza en línea similar. En Brasil, las empresas mineras de escala están alcanzadas por la Lei Geral de Proteção de Dados (LGPD) cuando procesan datos de empleados, contratistas y comunidades impactadas —lo que exige identificar y clasificar esos datos dentro del mismo ecosistema de gobierno que gestiona los datos operativos. Tratar ambos mundos como silos separados es uno de los errores más frecuentes en la madurez de gobierno del dato del sector.

    Para profundizar en los estándares de clasificación y trazabilidad aplicables a datos de recursos minerales, el Código JORC (Joint Ore Reserves Committee) y el marco CDMC del EDM Council son los puntos de partida obligados para cualquier equipo de gobierno del dato en el sector.

  • El debate IA abierta vs. cerrada ignora el verdadero problema empresarial

    El debate IA abierta vs. cerrada ignora el verdadero problema empresarial

    Antes de elegir entre Llama y GPT-4o, la mayoría de las organizaciones debería responder una pregunta más básica: ¿saben si sus sistemas de IA están funcionando bien? Según el análisis publicado por Monte Carlo, el debate entre modelos de pesos abiertos y modelos propietarios oculta una brecha de gobernanza mucho más profunda: la incapacidad generalizada de medir el comportamiento de cualquiera de los dos.

    El argumento más difundido en la industria divide el mercado de modelos de lenguaje de gran escala en dos campos. Por un lado, los modelos de pesos abiertos —como Llama de Meta o los de Mistral— que prometen soberanía sobre los datos, portabilidad entre infraestructuras y ausencia de dependencia de un único proveedor (vendor lock-in). Por el otro, los modelos propietarios de frontera —como Claude de Anthropic o los GPT de OpenAI— que ofrecen capacidades de razonamiento de vanguardia sin la carga operativa de administrar la infraestructura subyacente. Es una discusión legítima, pero incompleta.

    El problema real: sin observabilidad, la elección del modelo no importa

    Lo que el debate open vs. closed sistemáticamente omite es que la mayoría de las organizaciones que adoptan IA empresarial no cuenta con mecanismos confiables para evaluar el comportamiento de sus modelos en producción. Esto no es una limitación técnica menor: es un fallo de gobernanza. En términos del marco DAMA-DMBOK, implica ausencia de controles en el dominio de calidad de datos y de linaje (data lineage) de las salidas generadas por los sistemas de IA. Si no se puede medir el output, no se puede gestionar el riesgo —independientemente del modelo elegido.

    La observabilidad de modelos —la capacidad de monitorear en tiempo real si un sistema de IA produce respuestas correctas, coherentes y alineadas con los objetivos del negocio— es el eslabón que falta en la mayoría de los despliegues empresariales. Sin ella, la discusión sobre qué modelo elegir es análoga a debatir entre dos marcas de motor sin tener tacómetro en el tablero.

    Cuándo aplica el debate open vs. closed — y cuándo no

    La elección entre arquitecturas abiertas y cerradas sí es relevante cuando la organización ya opera con capacidades de evaluación maduras: pipelines de evaluación continua (evals), métricas de precisión y recall sobre casos de uso específicos, y mecanismos de retroalimentación humana en el loop. En ese escenario, el CDO puede comparar modelos con criterios objetivos y tomar una decisión informada sobre soberanía de datos, costo por token o latencia. Sin esas capacidades, la elección se convierte en una apuesta de marketing, no en una decisión de gobernanza.

    El debate tampoco aplica de la misma forma en todos los sectores. En banca, seguros o salud —industrias con alta densidad regulatoria— la preferencia por modelos de pesos abiertos suele estar impulsada por requisitos de explicabilidad y auditabilidad, no por convicción tecnológica. Pero incluso esos requisitos quedan sin satisfacer si la organización no instrumenta sus pipelines de inferencia para registrar entradas, salidas y contexto de cada llamada al modelo.

    Brasil, México y Argentina: la brecha de observabilidad en contexto regulatorio LATAM

    En América Latina, la discusión tiene una capa adicional. Las organizaciones que operan bajo la Lei Geral de Proteção de Dados (LGPD) en Brasil o la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) en México ya tienen obligaciones que dependen directamente de la capacidad de rastrear qué datos alimentan qué decisiones automatizadas. El artículo 20 de la LGPD reconoce el derecho del titular a solicitar revisión de decisiones tomadas exclusivamente por medios automatizados —un derecho que es imposible de ejercer si la organización no mantiene registros auditables de cómo opera su modelo. En Argentina, la Ley 25.326 enfrenta un proceso de actualización legislativa que, según el texto del proyecto en circulación, incorporaría disposiciones similares sobre decisiones automatizadas.

    Dicho de forma concreta: antes de que un equipo legal de una empresa brasileña o mexicana autorice el despliegue de un sistema de IA en producción, debería exigir evidencia de que existe un mecanismo de observabilidad. Si ese mecanismo no existe, el tipo de modelo —abierto o cerrado— es la menor de las preocupaciones.

    Tres capacidades que un CDO debería verificar antes de entrar al debate de modelos

    • Evaluación en producción: ¿existe un pipeline de evals automatizados que mida la calidad de las respuestas del modelo sobre casos de uso reales, no solo sobre benchmarks públicos?
    • Linaje de inferencia: ¿la organización registra qué versión del modelo, con qué prompt y con qué datos de contexto generó cada output? Sin esto, el data lineage del sistema de IA es opaco.
    • Ownership del dato de salida: ¿hay un data steward o equivalente responsable de la calidad de los outputs de IA como si fueran un activo de datos más del catálogo corporativo?

    Estas tres capacidades —evaluación continua, linaje de inferencia y ownership— son el equivalente en IA de los controles de calidad de datos que DAMA-DMBOK describe para cualquier activo de datos estructurado. El EDM Council las recoge de forma implícita en el CDMC bajo las dimensiones de gestión del ciclo de vida del dato y accountability. Organizaciones que ya operan con madurez en gobernanza de datos tradicional tienen ventaja para implementarlas: los procesos existen; solo deben extenderse al dominio de IA generativa.

    Para la mayor parte de las organizaciones latinoamericanas, la pregunta no es Llama o Claude: es si tienen los instrumentos mínimos para saber qué está haciendo su IA el día después del despliegue. Quien construya esa capacidad primero tendrá la base para cualquier elección de modelo que venga después.

  • Montevideo institucionaliza su gobernanza de datos: el modelo IMM

    Montevideo institucionaliza su gobernanza de datos: el modelo IMM

    La Intendencia de Montevideo (IMM) formalizó su modelo de gobernanza de datos, consolidando una estructura institucional para gestionar el dato como activo estratégico en el gobierno municipal. El movimiento convierte a Montevideo en uno de los pocos casos documentados de gobierno local en América Latina que institucionaliza explícitamente roles, procesos y responsabilidades sobre sus datos, según se informó.

    La decisión de la IMM no es un gesto simbólico: institucionalizar la gobernanza de datos implica que las reglas de ownership, calidad y uso de datos dejan de depender de personas clave y pasan a residir en estructuras formales que sobreviven a los cambios de administración. En la práctica, significa definir quién toma decisiones sobre los datos —y quién las ejecuta—, separando el rol de data steward del rol de custodio técnico, una distinción que el DAMA-DMBOK ubica como fundacional para cualquier programa maduro.

    Qué implica institucionalizar: estructura de roles y ownership de datos

    Un modelo de gobernanza de datos institucionalizado en el sector público requiere, como mínimo, tres componentes operativos: un consejo o comité de gobernanza con autoridad ejecutiva real, data stewards designados por dominio (ciudadanos, infraestructura, finanzas, etc.) y políticas documentadas de calidad y ciclo de vida del dato. Sin esos tres pilares funcionando en paralelo, lo que existe es un programa piloto, no un modelo. Según se informó, la IMM avanzó en esa dirección de formalización, aunque el nivel de detalle sobre cada componente no fue divulgado públicamente.

    La referencia metodológica más extendida para este tipo de iniciativas es el DAMA-DMBOK (Data Management Body of Knowledge), cuya segunda edición define la gobernanza de datos como “el ejercicio de autoridad, control y toma de decisiones compartida sobre la gestión de activos de datos”. En paralelo, el EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), ofrece un modelo de madurez de 14 capabilities que permite a organizaciones públicas y privadas medir su avance con granularidad. Una intendencia que quiera saber dónde está antes de declarar su modelo “institucionalizado” haría bien en completar ese diagnóstico.

    Uruguay y la región: un ecosistema regulatorio que empuja desde arriba

    Uruguay no opera en un vacío normativo. La Ley 18.331 de Protección de Datos Personales —y su decreto reglamentario 414/009— establece obligaciones sobre el tratamiento de datos personales que alcanzan a los organismos estatales, incluidas las intendencias departamentales. La Unidad Reguladora y de Control de Datos Personales (URCDP) tiene competencia para supervisar ese cumplimiento. Que la IMM formalice su gobernanza de datos crea una capa de control interno alineada con esas exigencias externas: cuando la URCDP pide rendir cuentas sobre un tratamiento específico, una intendencia con data stewards designados y un catálogo de datos activo puede responder con evidencia, no con búsquedas manuales.

    En el resto de la región, el panorama es dispar. Brasil cuenta con la LGPD (Lei Geral de Proteção de Dados, Ley 13.709/2018) y una ANPD con capacidad sancionatoria creciente, lo que obliga a municipios y estados a revisar su arquitectura de datos personales. Argentina avanza en la reforma de la Ley 25.326, con un proyecto que incorpora figuras como el delegado de protección de datos de forma obligatoria para organismos públicos. México opera bajo la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados (2017), que ya exige a los entes públicos federales y estatales designar un responsable de protección de datos. En ese contexto, lo que hace Montevideo tiene valor de señal: un gobierno local que no espera la presión del regulador para ordenar su casa de datos.

    Gobiernos locales en LATAM: la brecha entre política nacional y capacidad municipal

    El mayor déficit de gobernanza de datos en América Latina no está en los ministerios nacionales —que suelen tener algún nivel de estructura—, sino en los gobiernos subnacionales: municipios, intendencias, secretarías estaduales. Esos niveles acumulan datos sensibles de ciudadanos (registros civiles, expedientes de salud, catastro, tránsito) sin contar con data lineage documentado, sin ownership formal por dominio y, en muchos casos, sin inventario de los sistemas que alojan esos datos. La institucionalización que declara la IMM apunta exactamente a ese vacío.

    La comparación más cercana en la región es el Gobierno de la Ciudad de Buenos Aires, que lleva varios años desarrollando capacidades de datos abiertos y analytics, aunque sin una declaración formal de modelo de gobernanza al estilo DAMA. En Chile, algunos municipios han avanzado en portales de datos abiertos como parte de compromisos con el Open Government Partnership, pero sin formalizar estructuras de stewardship. Montevideo, al institucionalizar su modelo, establece un precedente que otros gobiernos locales de la región podrán citar —y replicar.

    Qué monitorear: los hitos que convertirán la declaración en programa real

    La institucionalización es un punto de partida, no de llegada. Para que el modelo de la IMM genere valor sostenible, hay cinco señales concretas que vale la pena monitorear en los próximos meses:

    • Publicación del organigrama formal de gobernanza de datos con roles nombrados (no solo cargos genéricos).
    • Existencia de un catálogo de datos accesible internamente, con clasificación por sensibilidad y dominio.
    • Designación explícita de data stewards por dominio de negocio con actas o resoluciones que respalden el mandato.
    • Métricas de calidad de datos publicadas o reportadas periódicamente a autoridades del gobierno municipal.
    • Articulación visible con la URCDP para alinear el modelo interno con las obligaciones de la Ley 18.331.

    Un programa que no puede mostrar avances en al menos tres de esos cinco puntos en doce meses corre el riesgo de quedar como una declaración política sin soporte operativo —un patrón que se repite en la región cada vez que el impulso inicial no se convierte en capacidad instalada.

    Nuestro análisis: por qué este caso importa más allá de Uruguay

    La decisión de la IMM tiene relevancia regional por una razón específica: los gobiernos locales son el nivel institucional con mayor contacto directo con datos personales sensibles de la ciudadanía y, al mismo tiempo, el nivel con menor presión regulatoria efectiva y menor capacidad técnica instalada. Que una intendencia latinoamericana formalice un modelo de gobernanza —incluso si los detalles de implementación son aún incipientes— desplaza el centro de gravedad de la conversación. Ya no se trata de si los gobiernos subnacionales deben gobernar sus datos, sino de cómo hacerlo con los recursos disponibles.

    El marco Non-Invasive Data Governance de Bob Seiner ofrece una perspectiva útil aquí: la gobernanza más efectiva en organizaciones con recursos limitados no es la que crea estructuras nuevas, sino la que formaliza comportamientos que ya existen. Si la IMM parte de identificar qué personas ya toman decisiones sobre datos en la práctica y les otorga reconocimiento institucional, el modelo tiene más chances de sobrevivir que uno diseñado de arriba hacia abajo con roles que nadie ocupa realmente. Esa distinción —entre gobernanza formal y gobernanza efectiva— es la que determinará si Montevideo se convierte en referencia o en caso de advertencia.

    Los gobiernos locales de la región tienen ahora un caso concreto para citar ante sus propias autoridades: ¿qué necesitaría tu municipio para replicar este modelo en doce meses?

  • Por qué la calidad de datos decide si tu IA empresarial funciona o falla

    Por qué la calidad de datos decide si tu IA empresarial funciona o falla

    Sin datos limpios, consistentes y bien gobernados, los modelos de inteligencia artificial empresarial producen resultados incorrectos, sesgados o directamente inutilizables. La calidad del dato no es un prerrequisito técnico menor: es la variable que determina si una inversión en IA genera valor o se convierte en deuda operativa.

    Cuando una organización despliega un modelo de IA sobre datos fragmentados, duplicados o sin linaje claro, el modelo no falla de forma visible: produce outputs con apariencia de precisión. Ese es el riesgo real. Un sistema de recomendación entrenado con registros de clientes mal consolidados, o un modelo de scoring crediticio alimentado con variables sin definición semántica unificada, puede operar durante meses antes de que alguien detecte que sus predicciones están sesgadas por ruido estructural en los datos de origen.

    Qué significa calidad de datos en el contexto de IA

    La calidad de datos no es sinónimo de “datos sin errores tipográficos”. En el marco del DAMA-DMBOK — el estándar de referencia de la industria para la gestión de datos — la calidad se evalúa en al menos seis dimensiones: completitud, consistencia, exactitud, oportunidad, unicidad y validez. Para IA, dos dimensiones adicionales toman protagonismo: representatividad (¿el dataset refleja la realidad que el modelo debe aprender?) y trazabilidad (¿se puede auditar de dónde viene cada variable que alimenta el modelo?). Un dataset puede pasar todos los controles de completitud y aun así producir un modelo discriminatorio si la distribución histórica de los datos replica sesgos del mundo real. La representatividad es la dimensión que más frecuentemente se omite en los proyectos de IA empresarial de la región.

    El rol del data steward en el ciclo de vida de un modelo

    La gobernanza de datos para IA no termina en la ingestión del dato: atraviesa todo el ciclo de vida del modelo. Esto implica que el data steward — el rol responsable de la calidad y el uso correcto de un dominio de datos específico — debe intervenir en tres momentos críticos: antes del entrenamiento (validación de fuentes y linaje), durante el desarrollo (monitoreo de distribución y detección de drift en variables), y después del despliegue (auditoría de outputs y retroalimentación al catálogo de datos). En la práctica, la mayoría de las organizaciones latinoamericanas involucra al área de datos solo en la primera etapa, lo que genera modelos que se degradan silenciosamente en producción sin mecanismos de alerta formales.

    Cuándo aplica este enfoque y cuándo no

    Este marco de gobernanza es crítico para modelos que toman o apoyan decisiones con impacto en personas: scoring crediticio, selección de personal, segmentación de clientes para ofertas diferenciales, modelos de riesgo regulatorio. En esos casos, la trazabilidad del dato no es solo buena práctica operativa: en jurisdicciones con regulación de IA o de datos personales vigente, puede ser un requisito legal. El AI Act de la Unión Europea, aplicable desde agosto de 2026 para sistemas de alto riesgo, exige documentación de los datasets de entrenamiento y mecanismos de gestión de calidad de datos como condición para la conformidad. Para modelos internos de baja criticidad — análisis exploratorio, dashboards descriptivos, prototipado — un nivel de gobernanza más liviano puede ser aceptable, aunque no deseable.

    El estado en América Latina: brechas concretas

    En la región, la madurez en gobernanza de datos para IA es heterogénea. Los bancos brasileños supervisados por el Banco Central do Brasil operan bajo marcos de gestión de riesgos de modelos que ya incorporan requisitos de calidad de datos alineados con las directrices del Conselho Monetário Nacional. En Argentina, la Comisión Nacional de Valores avanzó en requerimientos de trazabilidad para modelos de riesgo en el mercado de capitales. En México, el uso de IA en fintech está sujeto a las disposiciones de la CNBV, que en sus circulares más recientes incorpora criterios de gestión de modelos que implícitamente demandan gobernanza de datos. Sin embargo, fuera del sector financiero, la brecha es significativa: muchas organizaciones medianas y grandes de la región tienen proyectos de IA en producción sin un data catalog formal, sin definición de data owners por dominio, y sin procesos de Data Quality Management documentados según el estándar EDM Council DCAM.

    Tres capacidades que un CDO debe tener antes de escalar IA

    Antes de aprobar la expansión de casos de uso de IA, un Chief Data Officer debe verificar que la organización cuenta con al menos estas tres capacidades operativas:

    • Data lineage documentado para las fuentes que alimentarán los modelos, con granularidad suficiente para responder auditorías regulatorias o reclamos de usuarios afectados por decisiones automatizadas.
    • Data quality rules formalizadas en el catálogo de datos, con umbrales definidos por dominio y alertas activas en pipelines de ingestión, no solo validaciones manuales ad hoc.
    • Ownership claro por dominio de datos, con data stewards asignados que tengan autoridad real para bloquear el uso de un dataset que no cumpla estándares de calidad para un caso de uso específico.

    Sin estas tres capacidades, escalar IA no multiplica el valor: multiplica el riesgo. El modelo puede producir resultados correctos en promedio y devastadores en los casos límite — exactamente donde las regulaciones de IA y de datos personales ponen el foco.

    Para organizaciones que quieran profundizar en el marco de referencia, el DAMA-DMBOK v2 (capítulos 11 y 13) y el CDMC del EDM Council ofrecen las guías más completas disponibles para alinear calidad de datos con requisitos de IA empresarial. Ambos están disponibles en sus sitios oficiales.

  • Gobernanza de datos de salud: del control operativo al rol estratégico

    Gobernanza de datos de salud: del control operativo al rol estratégico

    La gobernanza de datos en el sector salud está dejando de ser una función de cumplimiento para convertirse en un activo estratégico dentro de las organizaciones sanitarias, según un análisis de la consultora Roland Berger. El cambio no es cosmético: implica rediseñar estructuras de ownership, ampliar el alcance del dato clínico y alinear las decisiones de datos con los objetivos de negocio y atención al paciente.

    Durante años, los hospitales, aseguradoras y sistemas de salud trataron la gobernanza de datos como una obligación regulatoria —mantener historias clínicas en orden, cumplir con auditorías, evitar multas. Ese modelo reactivo está quedando obsoleto. La presión combinada de la interoperabilidad, los sistemas de inteligencia artificial aplicados al diagnóstico y la gestión poblacional de salud obliga a repensar quién es dueño del dato, con qué calidad circula y cómo se convierte en decisión clínica o administrativa.

    De la función de soporte a la mesa de dirección

    El informe de Roland Berger identifica una transición de fase: la gobernanza de datos de salud pasa de estar bajo la órbita de TI o compliance a reportar directamente a la dirección ejecutiva. Esto significa que los roles de data steward y Chief Data Officer en organizaciones sanitarias asumen responsabilidades que antes pertenecían a los equipos médicos o financieros: definir qué datos son críticos para la operación, establecer políticas de acceso diferenciado entre clínicos y administrativos, y garantizar que los datos sean interpretables fuera del sistema donde se originaron.

    Según se informó, el cambio estratégico incluye la incorporación de marcos formales de gestión del ciclo de vida del dato clínico —desde su captura en el punto de atención hasta su uso en modelos predictivos o reportes regulatorios. Frameworks como DAMA-DMBOK y el CDMC del EDM Council, aunque diseñados para industrias financieras, están siendo adaptados por organizaciones de salud para cubrir necesidades específicas como el linaje del dato diagnóstico o la trazabilidad de consentimientos informados.

    Por qué el dato clínico es más difícil de gobernar que el dato financiero

    El dato de salud presenta desafíos de governance que no tienen equivalente directo en otros sectores. En primer lugar, es altamente sensible y está regulado por múltiples capas normativas simultáneas: confidencialidad clínica, leyes de datos personales y —en algunos países— regulaciones sectoriales específicas para registros de salud. En segundo lugar, es frecuentemente no estructurado: notas de médico, imágenes, señales de dispositivos. En tercer lugar, el ownership es difuso: ¿el dato de un paciente atendido en un hospital público pertenece a la institución, al sistema nacional de salud o al propio paciente?

    Esa ambigüedad en el ownership es precisamente donde los modelos de governance estratégica intentan intervenir. Definir data stewards por dominio clínico —no solo por sistema de información— es una de las recomendaciones que emergen de este tipo de análisis. Un steward de datos oncológicos, por ejemplo, tiene un perfil distinto al de un steward de facturación, aunque ambos operen sobre el mismo EHR (Electronic Health Record).

    Cuándo aplica este modelo estratégico / cuándo no

    El enfoque estratégico de gobernanza de datos tiene sentido en organizaciones sanitarias que ya tienen una madurez mínima en gestión de datos: algún catálogo de datos en funcionamiento, políticas de clasificación establecidas, o experiencia con proyectos de analítica clínica. Para instituciones que aún luchan con la digitalización básica de registros —realidad de buena parte del sistema de salud público en América Latina—, saltar a governance estratégica sin infraestructura de datos confiable genera estructuras de papel. El modelo no aplica como primera capa; aplica como siguiente capa.

    Tampoco aplica de forma homogénea entre subsectores: una red de clínicas privadas con sistema de EHR unificado tiene condiciones muy distintas a un hospital público con múltiples sistemas heredados y conectividad variable. La governance estratégica requiere que el dato exista, sea accesible y tenga calidad mínima antes de asignarle valor estratégico.

    El escenario regulatorio en América Latina complica y también habilita el cambio

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como datos sensibles y exige que su tratamiento cuente con bases legales específicas —consentimiento explícito o tutela de la salud, entre otras. Eso obliga a los sistemas de salud a tener trazabilidad de consentimientos, lo que es exactamente la clase de capacidad que una governance estratégica debe proveer. La LGPD, en este sentido, actúa como catalizador involuntario de madurez en gestión de datos de salud.

    En Argentina, la Ley 25.326 de Protección de los Datos Personales —actualmente en proceso de reforma legislativa— contempla protección específica para datos de salud como categoría sensible. La autoridad de control, la AAIP, ha emitido criterios sobre el tratamiento de este tipo de datos, aunque la aplicación sectorial en salud sigue siendo dispar. En México, la LFPDPPP y sus lineamientos del INAI también colocan los datos médicos en categoría de datos sensibles, con restricciones adicionales de tratamiento. Estos marcos regulatorios no eliminan la complejidad, pero establecen un piso normativo que da urgencia al salto estratégico.

    Colombia, con la Ley 1581 de 2012 y los desarrollos de la Superintendencia de Industria y Comercio (SIC), sigue una lógica similar. En todos estos casos, el riesgo regulatorio de no tener governance de datos de salud formalizada es concreto: multas, órdenes de cese de tratamiento y —en contextos de salud— consecuencias que van más allá de lo financiero.

    Para los CDO de organizaciones sanitarias en la región, la pregunta operativa no es si adoptar un modelo estratégico de gobernanza de datos, sino qué capacidades de data quality, linaje y ownership hay que construir primero para que ese modelo no sea solo un organigrama. El punto de partida más concreto es el catálogo de datos clínicos: sin inventario, no hay estrategia.

  • Meta nombra a su primer Chief Data Officer: Alex Schultz asume el cargo

    Meta nombra a su primer Chief Data Officer: Alex Schultz asume el cargo

    Meta designó a Alex Schultz, hasta ahora Chief Marketing Officer de la compañía, como su primer Chief Data Officer. El movimiento, según se informó, se hizo efectivo en febrero de 2026 y marca un punto de inflexión en cómo la empresa propietaria de Facebook, Instagram y WhatsApp decide estructurar la autoridad sobre sus datos a nivel ejecutivo.

    La creación de un rol de CDO en Meta no es un cambio cosmético. Hasta ahora, la compañía operaba sin un ejecutivo con responsabilidad formal y exclusiva sobre la estrategia de datos corporativos. Que ese rol recaiga en el CMO saliente —alguien con dos décadas de exposición a los activos de datos de Meta para publicidad y medición— sugiere que la empresa no está separando el negocio de los datos del negocio de los datos: está consolidando ambos bajo una sola firma ejecutiva.

    Por qué un CMO como primer CDO de Meta no es una elección obvia

    El perfil típico de un CDO en empresas de tecnología proviene de ingeniería de datos, analytics o, con creciente frecuencia, del área legal y de privacidad. Schultz, en cambio, llega desde el marketing. Su carrera en Meta estuvo centrada en el uso de datos para crecimiento de usuarios y rendimiento publicitario, no en la arquitectura de datos ni en el cumplimiento regulatorio como foco principal. Eso plantea una pregunta de diseño organizacional: ¿el CDO de Meta será ante todo un habilitador comercial de los datos, o asumirá también la responsabilidad de gobernanza, calidad y cumplimiento que los reguladores globales empiezan a exigir explícitamente a las empresas de su escala?

    Según el marco DAMA-DMBOK, las funciones de un CDO de madurez alta incluyen la gestión del ciclo de vida del dato, la definición de políticas de calidad, el data lineage —trazabilidad del origen y transformación de cada dato— y la interacción con autoridades de control. En Meta, esas capacidades estuvieron distribuidas históricamente entre equipos de ingeniería, legal y producto. Centralizarlas bajo un CDO con un perfil comercial puede acelerar la monetización de datos, pero también puede generar tensiones con los equipos de privacidad si la función no tiene mandato claro sobre compliance.

    El contexto regulatorio que hace urgente esta designación en 2026

    Meta opera en un entorno regulatorio que, desde 2023, no ha hecho más que complejizarse. En Europa, la compañía acumuló multas superiores a 2.000 millones de euros bajo el Reglamento General de Protección de Datos (RGPD) por transferencias internacionales y bases legales de tratamiento. En Brasil, la Autoridade Nacional de Proteção de Dados (ANPD) tiene jurisdicción sobre millones de usuarios y ha mostrado disposición a actuar contra plataformas globales. En México, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) establecen obligaciones de seguridad y aviso que aplican a cualquier empresa que trate datos de ciudadanos mexicanos, independientemente de su sede. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) supervisa el cumplimiento de la Ley 25.326, cuya reforma —en discusión desde hace años— incluiría figuras de responsabilidad ejecutiva más explícitas.

    Tener un CDO identificable y con autoridad real se convierte, en ese contexto, en algo más que una decisión de estructura interna: es una respuesta a la presión de los reguladores que exigen interlocutores ejecutivos con poder de decisión sobre datos. La pregunta que no responde la designación de Schultz es si su mandato incluirá esa dimensión regulatoria o quedará acotado a la estrategia comercial de datos.

    Cuándo aplica este modelo y cuándo no

    La decisión de Meta de promover internamente a un ejecutivo de negocio como CDO en lugar de contratar un perfil técnico o legal es replicable en organizaciones donde los datos son ante todo un activo de monetización y el equipo de ingeniería ya tiene madurez suficiente para operar sin supervisión ejecutiva directa. No es el modelo adecuado para organizaciones en etapas tempranas de gobernanza de datos, donde el CDO necesita construir capacidades básicas —catálogo, clasificación, ownership formal— antes de pensar en estrategia comercial. Tampoco es recomendable cuando la empresa enfrenta investigaciones regulatorias activas que requieren un perfil con experiencia específica en cumplimiento normativo de datos.

    Para empresas latinoamericanas de escala media que estén definiendo el perfil de su primer CDO, el caso Meta ilustra tanto las posibilidades como los riesgos del enfoque: un CDO con peso político interno puede mover la organización, pero sin mandato explícito sobre gobernanza, el rol puede convertirse en una capa adicional de gestión sin impacto real en la calidad ni en el cumplimiento de los datos.

    Lo que la designación revela sobre el momento del mercado

    Que una de las empresas con mayor volumen de datos del mundo no tuviera un CDO formal hasta 2026 dice algo sobre la velocidad a la que las presiones regulatorias y de gobernanza están alcanzando incluso a las organizaciones más grandes. Durante años, Meta pudo operar con una estructura distribuida porque la regulación era fragmentada y la presión de cumplimiento, manejable. Esa ecuación cambió. El nombramiento de Schultz es, en parte, una respuesta institucional a ese cambio: formalizar la autoridad sobre los datos cuando ya no es posible postergar esa decisión sin costos visibles.

    Para profundizar en los marcos de referencia que definen las responsabilidades del CDO moderno, el DAMA-DMBOK (Data Management Body of Knowledge) y el CDMC del EDM Council son los estándares más citados por autoridades regulatorias y equipos de gobernanza en América Latina.

  • Marco de gobernanza de datos de GEI para el transporte Ro-Ro marítimo

    Marco de gobernanza de datos de GEI para el transporte Ro-Ro marítimo

    La industria del transporte marítimo Ro-Ro —buques que cargan y descargan vehículos por rampa— acaba de estrenar un marco sectorial de gobernanza de datos de gases de efecto invernadero (GEI). La iniciativa apunta a estandarizar cómo se recopilan, validan y reportan las emisiones a lo largo de la cadena logística, en un momento en que los reguladores internacionales y regionales exigen trazabilidad creciente sobre huella de carbono.

    El marco, según se informó, fue diseñado para dar respuesta a un problema de larga data en el sector: la ausencia de definiciones comunes sobre qué datos de emisiones deben capturarse, quién es su propietario, cómo deben verificarse y bajo qué estándar deben comunicarse a clientes y autoridades. Sin esa base compartida, los reportes de GEI de distintos operadores resultan incomparables entre sí y, en muchos casos, inauditables.

    Qué resuelve el marco: ownership del dato de carbono y linaje verificable

    En términos de gobernanza de datos, el nudo central que aborda este framework es el del data ownership y el data lineage aplicados a un dato no financiero: la tonelada de CO₂ equivalente. Históricamente, en rutas Ro-Ro los datos de consumo de combustible y emisiones quedaban dispersos entre el operador del buque, el agente de carga, el armador y el embarcador de vehículos. Nadie tenía ownership formal sobre el dato agregado, y el linaje —es decir, la cadena de custodia desde el sensor de flujo de combustible hasta el reporte regulatorio— era opaco o directamente inexistente. El marco busca asignar roles claros equivalentes a los de data steward por segmento de la cadena.

    La estructura propuesta, según se informó, define capas de responsabilidad: quién genera el dato primario (el operador del buque), quién lo consolida por viaje (el armador o gestor técnico) y quién lo reporta ante la autoridad competente o el cliente final. Esta arquitectura de roles se alinea con los principios del DAMA-DMBOK en su capítulo de gestión de datos de referencia y maestros, trasladados aquí a un dominio de datos ambientales.

    El contexto regulatorio que fuerza la estandarización: IMO, UE y la presión sobre puertos latinoamericanos

    El impulso detrás de este marco no es voluntario en sentido estricto. La Organización Marítima Internacional (OMI) tiene en vigencia su estrategia revisada de reducción de GEI con metas para 2030 y 2050, y la Unión Europea incorporó al transporte marítimo en su sistema EU ETS (Emissions Trading System) a partir de 2024. Eso significa que cualquier buque que opere en puertos europeos —incluidas escalas en rutas que tocan el Atlántico sur— debe reportar emisiones verificadas bajo el Reglamento MRV (Monitoring, Reporting and Verification) de la UE.

    Para América Latina, esto tiene una implicancia concreta: los puertos de Buenos Aires, Montevideo, Santos y Valparaíso operan como eslabones en rutas que conectan con Europa. Los armadores y operadores logísticos que usan esos puertos en tráfico Ro-Ro —principalmente exportaciones de vehículos terminados desde México y Brasil y maquinaria agrícola desde Argentina— quedan expuestos al EU ETS indirectamente, porque sus clientes europeos deben acreditar la huella de carbono de su logística de importación. Sin datos de GEI estructurados y auditables desde origen, esa acreditación no es posible.

    Cuándo aplica este marco y cuándo NO

    El framework aplica directamente a operadores de buques Ro-Ro y a los embarcadores —típicamente terminales automotrices, fabricantes de maquinaria y empresas de logística especializada— que necesiten reportar emisiones Scope 3 de transporte marítimo bajo estándares como el GHG Protocol o el CDP. También es relevante para puertos que estén construyendo sus propios inventarios de emisiones por actividad portuaria. No aplica, en cambio, a empresas de transporte terrestre o multimodal que no tengan exposición a la normativa marítima internacional, ni a operadores de rutas estrictamente domésticas sin conexión a puertos sujetos al EU ETS o al sistema MRV.

    Lo que un CDO de logística marítima necesita resolver primero

    Para un Chief Data Officer o Data Lead en una empresa naviera, terminal portuaria o exportador de vehículos con operaciones en la región, el punto de partida práctico es un inventario de fuentes de datos de consumo energético: sistemas de gestión del buque (BMS), registros de bunker, AIS y los propios manifiestos de carga. El siguiente paso es mapear quién tiene hoy acceso de escritura sobre esos registros —es decir, quién puede modificarlos— y establecer controles de calidad mínimos: completitud, frecuencia de actualización y trazabilidad de cambios. Sin ese diagnóstico, cualquier adhesión formal al nuevo marco será cosmética. El EDM Council (DCAM) ofrece una capability de gestión de datos críticos que puede adaptarse a este dominio ambiental como punto de referencia para medir madurez.

    Para profundizar en los requerimientos técnicos del sistema MRV de la UE aplicado al transporte marítimo, la fuente oficial es el Reglamento (UE) 2015/757 y sus modificaciones, disponibles en el portal EUR-Lex de la Comisión Europea.