Etiqueta: Normativa

  • 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.

  • IA que diseña fármacos: quién se lleva el crédito (y la responsabilidad)

    IA que diseña fármacos: quién se lleva el crédito (y la responsabilidad)

    Cuando Insilico Medicine anunció que su plataforma de inteligencia artificial había “descubierto” una molécula candidata para tratar la fibrosis pulmonar, abrió sin quererlo un debate jurídico que va mucho más allá del marketing farmacéutico: si una IA diseña un fármaco, ¿a quién pertenece ese hallazgo y quién responde si falla?

    La atribución de autoría en ciencia siempre fue complicada. Pero la irrupción de sistemas de inteligencia artificial generativa en el descubrimiento de fármacos agrega una capa de ambigüedad que los marcos legales vigentes —pensados para inventores humanos— no resuelven con claridad. El caso de Insilico Medicine, que usó sus modelos computacionales para proponer una molécula prometedora contra la fibrosis pulmonar, ilustra exactamente esa tensión: la empresa no dudó en atribuirle a su IA el rol de descubridora, una afirmación con consecuencias directas sobre patentes, responsabilidad civil y regulación sanitaria.

    Patentes sin inventor humano: el límite que ya se está probando en tribunales

    El sistema de patentes fue diseñado bajo un supuesto que hoy tambalea: que detrás de cada invención hay una persona física. En Estados Unidos, la Corte de Apelaciones del Circuito Federal resolvió en 2022 que el sistema DABUS —desarrollado por Stephen Thaler— no podía figurar como inventor en una solicitud de patente porque la ley exige que el inventor sea humano. El Reino Unido llegó a la misma conclusión por la vía del Supremo en 2023. La pregunta que queda abierta es cuánto cambia la ecuación cuando la IA no figura como inventora pero es la que, en los hechos, genera la hipótesis central del compuesto.

    Insilico y otras empresas del sector —Exscientia, Recursion, Absci— posicionan a sus plataformas como co-diseñadoras o aceleradoras del proceso de descubrimiento. Desde el punto de vista de la estrategia de propiedad intelectual, esa distinción importa: si la IA “descubre” y el humano solo valida, la solidez jurídica de la patente puede cuestionarse por insuficiencia inventiva humana. Si el humano es quien dirige y la IA es una herramienta sofisticada —equivalente a un espectrómetro de masas muy avanzado—, la patente se sostiene. El lenguaje del press release, entonces, no es inocente.

    Responsabilidad downstream: quién responde cuando el fármaco falla en fase clínica

    La atribución de crédito no es solo una cuestión de ego corporativo o relaciones públicas. Tiene un correlato directo en la cadena de responsabilidad. Si un compuesto propuesto por IA llega a ensayos clínicos y genera efectos adversos imprevistos, los marcos de responsabilidad vigentes necesitan identificar un responsable: ¿el desarrollador del modelo, la empresa farmacéutica que lo adoptó, el equipo científico que validó la hipótesis, o el organismo regulador que habilitó el ensayo? La respuesta depende en parte de cómo se documentó la participación de la IA en cada etapa del proceso.

    Este problema no es teórico. La FDA de Estados Unidos ya publicó lineamientos preliminares sobre el uso de inteligencia artificial y machine learning en el desarrollo de dispositivos médicos, y está trabajando en marcos similares para el proceso de aprobación de nuevos fármacos. La EMA europea sigue una trayectoria paralela. La pregunta es si la atribución narrativa —lo que una empresa dice en un comunicado— puede tener efectos jurídicos en un litigio posterior sobre daños.

    El AI Act europeo y la clasificación de riesgo en aplicaciones biomédicas

    El Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, Reglamento UE 2024/1689) clasifica como sistemas de alto riesgo a aquellos usados en el ámbito de la salud cuando toman o influyen decisiones relevantes. Un sistema de IA que propone moléculas para uso terapéutico humano califica, en principio, dentro de esa categoría: exige documentación técnica exhaustiva, supervisión humana verificable y trazabilidad de las decisiones del modelo. Eso significa que “la IA lo descubrió” no puede ser el final del relato regulatorio —tiene que haber un humano que pueda explicar, auditar y asumir la decisión.

    Cuándo aplica este debate / cuándo NO

    El conflicto de atribución se vuelve jurídicamente relevante cuando el output de la IA es la hipótesis central de una solicitud de patente, cuando el compuesto avanza hacia ensayos en humanos, o cuando la empresa hace afirmaciones públicas sobre la autoría del sistema. No aplica con la misma intensidad cuando la IA funciona como herramienta de cribado masivo (virtual screening) dentro de un proceso en el que el equipo científico genera y selecciona hipótesis de forma sustantiva. La distinción operativa —IA como autor versus IA como instrumento— es la que definirá los casos que lleguen a litigio en los próximos años.

    América Latina: marcos de IA en construcción, sector farmacéutico ya activo

    En la región, el debate llega antes que los marcos regulatorios. Brasil avanza con el Projeto de Lei 2.338/2023 sobre regulación de IA, que incluye disposiciones sobre sistemas de alto riesgo en salud pero no aborda específicamente la atribución de autoría inventiva a sistemas automatizados. Argentina no tiene legislación de IA aprobada al cierre de esta nota, aunque el INPI —Instituto Nacional de la Propiedad Industrial— ya enfrenta solicitudes que implican procesos asistidos por IA. México, por su parte, tiene una industria farmacéutica de escala regional y un IMPI que todavía opera bajo los criterios tradicionales de inventiva humana contemplados en la Ley Federal de Protección a la Propiedad Industrial. Ninguno de los tres países tiene hoy una respuesta clara para la pregunta que Insilico planteó en su press release.

    La presión llegará desde afuera hacia adentro: cuando una empresa extranjera intente patentar en México, Brasil o Argentina un compuesto cuyo origen sea un sistema de IA, las oficinas de propiedad industrial deberán decidir sin doctrina previa. Ese vacío no es neutral —favorece a quien primero defina el marco.

    Para profundizar en el marco regulatorio europeo, el texto completo del AI Act está disponible en el Diario Oficial de la Unión Europea (DO L, 12 de julio de 2024); el Proyecto de Lei 2.338/2023 de Brasil puede consultarse en el sitio del Senado Federal.

  • 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.

  • Meta nombra a su primer Chief Data Officer: qué implica el rol

    Meta nombra a su primer Chief Data Officer: qué implica el rol

    Meta designó a Alex Schultz como su primer Chief Data Officer, según se informó en agosto de 2025. La creación formal del rol en una compañía de esa escala no es un movimiento cosmético: indica que la función de gobernanza de datos dejó de ser absorbible por el liderazgo de ingeniería o privacidad y exige representación propia en el C-suite.

    El cargo de CDO —Chief Data Officer— existe formalmente en el sector financiero y regulado desde principios de los 2010, impulsado en parte por la exigencia de marcos como Basel III y, más tarde, por las disposiciones del BCBS 239 para bancos sistémicamente importantes. Que una empresa de tecnología de consumo masivo como Meta lo cree recién ahora revela una brecha estructural: durante años, la gobernanza de datos fue disuelta entre equipos de producto, ingeniería y legal, sin un propietario ejecutivo único con mandato transversal.

    Qué hace un CDO que no hace un CTO ni un DPO

    La confusión entre roles es frecuente. El Chief Technology Officer (CTO) gobierna la arquitectura y la infraestructura; el Data Protection Officer (DPO) —exigido por el RGPD europeo y sus equivalentes latinoamericanos— responde específicamente por el tratamiento de datos personales y actúa como interlocutor ante las autoridades de control. El CDO, en cambio, tiene mandato sobre el dato como activo corporativo: su calidad, su ciclo de vida, su linaje (data lineage), los dominios y los data stewards que los gestionan, y la capacidad de la organización de monetizarlos o utilizarlos para decisiones confiables. Según el marco DAMA-DMBOK, estas funciones se agrupan en once áreas de conocimiento —desde arquitectura de datos hasta gestión de documentos y contenido— que raramente tienen un responsable único a nivel ejecutivo.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), describe doce capabilities que una organización madura debe demostrar. La ausencia de un CDO formal suele correlacionar con brechas en las capabilities 4 (Data Ownership) y 7 (Data Quality), precisamente porque sin un ejecutivo con mandato explícito, la asignación de ownership recae en acuerdos informales entre equipos.

    Por qué 2025 y no 2015: presión regulatoria como catalizador

    El timing no es casual. Meta opera bajo el escrutinio de la Comisión Europea tras las multas históricas impuestas por la Autoridad de Protección de Datos de Irlanda (DPC) en aplicación del RGPD —incluyendo la sanción de 1.200 millones de euros de mayo de 2023 por transferencias de datos a Estados Unidos—. A eso se suma la presión del AI Act europeo, vigente desde agosto de 2024, que para los sistemas de IA de alto riesgo exige trazabilidad de los datos de entrenamiento y mecanismos de gobernanza documentados. Un CDO con mandato formal es, en ese contexto, también una respuesta de arquitectura organizacional ante reguladores que preguntan quién responde por el dato.

    En América Latina, el mismo patrón se reproduce con menor visibilidad pública. La Lei Geral de Proteção de Dados de Brasil (LGPD, Lei 13.709/2018) exige la figura del Encarregado —equivalente funcional al DPO— pero no menciona al CDO. Sin embargo, la Autoridade Nacional de Proteção de Dados (ANPD) ha comenzado a fiscalizar la existencia de programas de gobernanza de datos como parte de la evaluación de accountability. En Argentina, la AAIP (Agencia de Acceso a la Información Pública) y el proyecto de modernización de la Ley 25.326 apuntan en la misma dirección: las empresas que procesan datos a escala ya no pueden invocar “responsabilidad difusa” ante un incidente.

    Cuándo aplica el rol de CDO / cuándo NO

    El CDO tiene sentido operativo cuando la organización supera ciertos umbrales de complejidad: múltiples dominios de datos con owners distintos, pipelines de analítica que cruzan unidades de negocio, o exigencias regulatorias que requieren demostrar linaje y calidad ante un auditor externo. No es una figura necesaria en organizaciones pequeñas con un único dominio de datos o en empresas donde el CTO puede absorber esa responsabilidad sin conflicto de mandatos. Bob Seiner, referente de Non-Invasive Data Governance, argumenta que el rol ejecutivo sólo funciona si hay data stewards operativos debajo: sin esa red, el CDO se convierte en un cargo de nombre sin palancas reales de cambio.

    En el sector financiero latinoamericano, bancos que reportan al Banco Central de Brasil o al BCRA bajo marcos de riesgo operacional ya operan con capabilities equivalentes a las del CDMC, aunque en muchos casos sin la certificación formal ni el título ejecutivo. La designación de Meta puede funcionar como señal de mercado que acelere la formalización de esos roles en empresas de tecnología y retail de la región.

    Lo que hace un CDO en las primeras semanas del mandato

    Más allá del anuncio, la efectividad del rol depende de decisiones tempranas. Schultz —quien, según se informó, ya ocupaba el cargo de Chief Marketing Officer en Meta— deberá establecer en qué dominios de datos no existe ownership formal asignado, cuál es el estado del catálogo de datos corporativo y si hay una definición acordada de calidad mínima aceptable por dominio. La primera entrega concreta suele ser un mapa de dominios con stewards nombrados, un inventario de activos críticos y una propuesta de estructura de gobierno que separe las decisiones que toma el CDO de las que delega. Sin esos productos en las primeras doce semanas, el cargo pierde tracción ejecutiva rápidamente.

    Para organizaciones de la región que aún debaten si crear el rol, el marco DAMA-DMBOK (segunda edición, disponible en dama.org) y el CDMC del EDM Council ofrecen los criterios más precisos para evaluar si la complejidad de su portafolio de datos justifica —o exige— un CDO con mandato propio.

  • Contratos de datos: el acuerdo que la IA obliga a formalizar

    Contratos de datos: el acuerdo que la IA obliga a formalizar

    Los data contracts —acuerdos formales sobre cómo se produce, entrega y consume un dato entre equipos— dejaron de ser una práctica de vanguardia para convertirse en un requisito operativo. La presión llega desde la capa de inteligencia artificial: cuando un modelo falla, la causa más frecuente no es el algoritmo sino el dato que lo alimenta, y sin un contrato que defina responsabilidades, nadie sabe a quién corresponde resolver el problema.

    Un data contract es, en su definición operativa, un acuerdo explícito y versionado entre el equipo productor de un dato y los equipos que lo consumen. Especifica el esquema, la frecuencia de actualización, los SLAs de calidad, el propietario (data owner) y las condiciones bajo las cuales el contrato puede modificarse. La analogía con los contratos de API es útil: así como una API define qué esperar de un servicio, el data contract define qué esperar de un dataset. La diferencia es que los contratos de datos incluyen semántica de negocio, no solo estructura técnica.

    Por qué la IA accelera la adopción de data contracts en 2025

    Los pipelines de machine learning e inteligencia artificial generativa son especialmente frágiles frente a cambios silenciosos en los datos de entrada: un campo que pasa de texto libre a codificado, una frecuencia que se reduce de diario a semanal, un valor nulo que antes era cero. Sin data contracts, estos cambios se propagan sin aviso hasta el modelo, que comienza a producir outputs degradados o directamente incorrectos. El costo de detectar esa degradación aguas abajo —en producción, en una decisión de negocio— es ordenes de magnitud mayor que haberlo detectado en la fuente. Los equipos de datos que operan sin data contracts en un entorno de IA están, en la práctica, gestionando riesgo operativo sin instrumentos formales.

    El marco DAMA-DMBOK v2 no usa el término “data contract” de forma explícita, pero el concepto es la instancia operativa de lo que el estándar llama Data Architecture y Data Quality agreements: acuerdos documentados sobre expectativas y responsabilidades entre productores y consumidores. El EDM Council, en su CDMC (Cloud Data Management Capabilities), lo incorpora en las capabilities de control de acceso y linaje (data lineage) como prerequisito para auditar el flujo de datos sensibles. Autores como Andrew Jones —quien popularizó el término en su forma moderna— argumentan que el data contract es la unidad mínima de gobernanza en arquitecturas orientadas a datos.

    Qué contiene un data contract útil: cinco elementos que no pueden faltar

    • Esquema versionado: nombre, tipo y descripción de cada campo, con historial de cambios.
    • SLA de calidad: completitud mínima, tasa de nulos aceptable, latencia máxima de entrega.
    • Data owner identificable: persona o equipo con nombre, no un área genérica.
    • Política de cambios: notificación mínima ante modificaciones de esquema o frecuencia (generalmente 5 a 15 días hábiles).
    • Clasificación del dato: etiqueta de sensibilidad (público, interno, confidencial, restringido) alineada con la política de data governance corporativa.

    Cuándo aplica / cuándo NO

    Los data contracts son pertinentes cuando hay al menos dos equipos distintos que producen y consumen el mismo dato, cuando ese dato alimenta un modelo de IA, un reporte regulatorio o una decisión de negocio crítica, y cuando los cambios en el dato pueden propagarse sin visibilidad hacia consumidores. No aplican —o no es prioritario formalizarlos— en datasets experimentales de uso único, en exploraciones de ciencia de datos sin destino productivo, o en equipos de menos de cinco personas donde la coordinación informal todavía funciona. El error más común es intentar contratar todos los datos al mismo tiempo: la recomendación práctica es comenzar por los datasets que alimentan modelos en producción o que son fuente de reportes regulatorios.

    En LATAM: bancos, telcos y el reporte regulatorio como driver de adopción

    En América Latina, el driver de adopción más concreto no es la IA sino el reporte regulatorio. Los bancos que reportan al Banco Central de Brasil (BACEN) bajo las exigencias de Open Finance, o los que reportan al BCRA argentino bajo la Comunicación A 7724 y sus actualizaciones, ya operan con acuerdos tácitos de calidad de datos entre áreas. La diferencia es que esos acuerdos raramente están documentados como data contracts formales: viven en correos electrónicos, en reuniones de comité de datos, o en la memoria de un data steward que lleva cinco años en la organización. Cuando esa persona se va, el conocimiento se va con ella. Las telcos en México y Colombia enfrentan el mismo problema con los datos que alimentan sus modelos de churn prediction y scoring crediticio alternativo: la informalidad del acuerdo se vuelve riesgo operativo en cuanto el modelo entra en producción.

    Un CDO que quiera dar el primer paso concreto puede empezar auditando los cinco datasets más críticos de su organización —los que alimentan modelos productivos o reportes regulatorios— y verificar si existe documentación explícita del esquema, el owner y el SLA de calidad. Si la respuesta es no para dos o más de esos cinco, la formalización de data contracts es la prioridad de gobernanza del trimestre, antes que cualquier inversión en catálogo o linaje. Un catálogo sin contracts es un inventario sin compromisos: describe lo que existe, pero no garantiza lo que se puede usar.

    La especificación abierta de data contracts impulsada por la comunidad está disponible en datacontract.com, con plantillas en YAML compatibles con las principales plataformas de datos; es el punto de partida más directo para equipos que quieren adoptar el estándar sin construir desde cero.

  • Bailment e inteligencia artificial: una doctrina del siglo XIX ante las brechas de datos de IA

    Bailment e inteligencia artificial: una doctrina del siglo XIX ante las brechas de datos de IA

    Cuando dos ingenieros de OpenAI presentaron en Black Hat los detalles del incidente de Hugging Face, no esperaban que la respuesta más resonante viniera de una doctrina jurídica que precede a la computadora por más de un siglo: el bailment, o depósito legal anglosajón. La tesis, desarrollada por Jake L. Ramsey del estudio Offit Kurman, propone que la responsabilidad por brechas de datos en sistemas de inteligencia artificial puede —y debería— analizarse bajo la misma lógica con que el derecho común regula la entrega de bienes en custodia.

    El bailment es una figura del common law que describe la relación jurídica que surge cuando una persona entrega un bien a otra para un fin específico, con obligación de devolución o uso conforme a lo pactado. El depositario —quien recibe el bien— asume deberes de cuidado proporcionales al beneficio que obtiene de esa custodia. Si el bien resulta dañado o perdido, la carga de la prueba se invierte: es el depositario quien debe demostrar que actuó diligentemente. Aplicado a datos: quien recibe información de terceros para entrenar o ejecutar un modelo de inteligencia artificial puede quedar, bajo esta lógica, en la posición del depositario.

    El incidente de Hugging Face como caso de prueba para la doctrina

    La presentación en Black Hat que sirvió de detonante fue protagonizada por dos ingenieros de OpenAI, quienes describieron el incidente de Hugging Face —plataforma central en el ecosistema de modelos abiertos— como un escenario con implicancias que van más allá del análisis técnico de vulnerabilidades. Según se informó, sus declaraciones subrayaron tanto la naturaleza del acceso no autorizado como la exposición de datos de terceros almacenados o procesados en la infraestructura de la plataforma. El artículo de Ramsey toma esas afirmaciones como punto de partida para argumentar que la relación entre quienes suben datasets o modelos a plataformas como Hugging Face y la propia plataforma encaja con los elementos constitutivos del bailment: entrega voluntaria, custodia ajena, finalidad determinada y deber de restitución o uso conforme.

    El argumento tiene relevancia práctica inmediata: si un tribunal acepta el encuadre del bailment, la víctima de una brecha de datos no necesita probar negligencia específica. Basta con acreditar que entregó datos al custodio y que esos datos fueron comprometidos. La carga probatoria pasa entonces al proveedor de la plataforma, que debe demostrar haber ejercido el nivel de cuidado exigido por la relación de depósito.

    Por qué la figura del depósito legal presiona a los proveedores de IA más que los marcos actuales

    Los marcos regulatorios vigentes —desde el Reglamento General de Protección de Datos europeo hasta el AI Act— operan sobre la distinción entre responsable y encargado del tratamiento, con obligaciones contractuales y técnicas relativamente bien delimitadas. El bailment, en cambio, no requiere que los datos sean “personales” en sentido legal: aplica sobre cualquier bien entregado en custodia. Eso amplía potencialmente el universo de activos protegidos: modelos propietarios, conjuntos de datos no personales, embeddings, pesos de modelos finetuneados por terceros. Para los proveedores de infraestructura de IA —plataformas de hosting de modelos, entornos de entrenamiento en nube, repositorios colaborativos— la implicancia es que su exposición legal podría ser mayor que la derivada exclusivamente de la normativa de privacidad.

    El debate también tiene consecuencias contractuales directas. Si los términos de servicio de una plataforma no contemplan explícitamente el estándar de cuidado aplicable a los datos y modelos depositados, un tribunal de tradición anglosajona podría inferirlo desde la doctrina del bailment, sin necesidad de que las partes lo hayan pactado. Eso convierte la redacción de cláusulas de responsabilidad en los contratos de servicios de IA en un ejercicio jurídico más complejo de lo que muchos equipos legales anticipan.

    Cuándo aplica la doctrina del bailment sobre datos — y cuándo no

    La doctrina, tal como existe en jurisdicciones de common law (Estados Unidos, Reino Unido, Australia, Canadá), no tiene equivalente directo en los sistemas de derecho civil continental que predominan en América Latina. En Argentina, Brasil, México, Colombia y Chile, la figura más próxima es el contrato de depósito o custodia regulado en los códigos civiles y comerciales, aunque sin la inversión automática de la carga probatoria que caracteriza al bailment. La analogía, sin embargo, no es irrelevante: los principios subyacentes —responsabilidad proporcional al control efectivo sobre el bien ajeno— informan el análisis de responsabilidad civil en cualquier sistema jurídico.

    La doctrina no aplica cuando el proveedor de IA no actúa como custodio sino como mero procesador técnico sin acceso real a los datos, o cuando los datos nunca abandonan el entorno del propio titular. Tampoco aplica, en principio, sobre outputs del modelo —las respuestas generadas— sino sobre los inputs y parámetros entregados al sistema. Esa distinción es importante porque delimita qué tipo de activos quedan potencialmente bajo el estándar de cuidado del depositario.

    La perspectiva desde América Latina: depósito civil, responsabilidad por riesgo y regulación de IA

    En la región, el encuadre jurídico más cercano combina tres fuentes: el contrato de depósito del derecho civil, la responsabilidad objetiva por actividad riesgosa —reconocida en los códigos civiles de Argentina, Brasil y México— y, de forma incipiente, los marcos de gobernanza de inteligencia artificial que varios países están desarrollando. Brasil avanza con el Projeto de Lei 2.338/2023 de regulación de IA, que contempla responsabilidad diferenciada para sistemas de alto riesgo. Colombia publicó en 2023 su marco de ética e IA con lineamientos sobre gestión de riesgos para proveedores. Argentina, por su parte, trabaja en una propuesta de regulación de IA cuya discusión aún no tiene fecha de resolución legislativa confirmada.

    Para los equipos legales y de gobernanza de datos en empresas latinoamericanas que utilizan plataformas internacionales de IA —ya sea para alojar modelos propios o para acceder a modelos de terceros— el argumento del bailment ofrece una señal de alerta concreta: los contratos con proveedores de infraestructura de IA deberían explicitar quién responde, con qué estándar de cuidado y bajo qué ley aplicable, antes de que un incidente lo defina un juez. La brecha entre lo que dicen los términos de servicio estándar y lo que una corte podría imponer bajo doctrinas como el bailment o la responsabilidad por actividad riesgosa es, hoy, sustancial.

    El análisis completo de Jake L. Ramsey está disponible en el blog de Offit Kurman; la presentación de Black Hat sobre el incidente de Hugging Face constituye el punto de partida técnico para quienes quieran evaluar la cadena de hechos que motivó la discusión legal.

  • Marco de gobernanza de datos GEI para la industria Ro-Ro: qué implica el estándar

    Marco de gobernanza de datos GEI para la industria Ro-Ro: qué implica el estándar

    La industria Ro-Ro —transporte marítimo de vehículos y carga rodante— acaba de recibir su primer marco sectorial de gobernanza de datos de emisiones de gases de efecto invernadero (GEI). El estándar, lanzado según se informó en agosto de 2025, llega en un momento en que la presión regulatoria sobre el reporte de emisiones del sector marítimo escala tanto en Europa como en América Latina, y pone sobre la mesa una pregunta que los operadores portuarios de la región no pueden ignorar por más tiempo: ¿tienen sus datos de GEI bajo un ownership claro y auditabe?

    El sector Ro-Ro opera con una particularidad estructural que lo hace especialmente vulnerable a la fragmentación de datos: una sola travesía involucra múltiples actores —armadores, operadores de terminal, agentes de carga y fabricantes de vehículos— cada uno con sus propios sistemas de registro. Hasta ahora, no existía un lenguaje común para consolidar los datos de emisiones a lo largo de esa cadena. El nuevo marco apunta precisamente a resolver ese vacío, estableciendo definiciones, métricas y responsabilidades compartidas para el reporte de GEI en este subsegmento del shipping.

    Qué establece el marco y qué actores quedan obligados

    Según se informó, el marco define estándares para la recopilación, validación y reporte de datos de emisiones a lo largo del ciclo operativo de los buques Ro-Ro. Esto incluye consumo de combustible por viaje, factor de carga, rutas y tonelaje transportado —variables que, combinadas, permiten calcular la intensidad de carbono por unidad de transporte. El estándar busca alinearse con los requisitos del sistema de monitoreo, reporte y verificación (MRV) de la Organización Marítima Internacional (OMI) y con el reglamento MRV de la Unión Europea, que desde 2024 obliga a los buques que hacen escala en puertos europeos a reportar sus emisiones de CO₂.

    La distinción relevante para los profesionales de gobernanza de datos es que el marco no se limita a definir qué datos recopilar, sino que establece quién es responsable de cada dato en cada etapa —lo que en la terminología DAMA-DMBOK se conoce como data stewardship distribuido. En una cadena Ro-Ro típica, eso significa asignar roles de data steward tanto en el armador como en el operador de terminal y, potencialmente, en el fabricante automotriz embarcador.

    Argentina, Brasil y Chile ante el reporte de emisiones marítimas en 2025

    América Latina concentra algunos de los puertos Ro-Ro más activos del Atlántico Sur y el Pacífico: Zárate y Buenos Aires en Argentina, Santos y Itajaí en Brasil, y San Antonio en Chile son puntos de entrada y salida críticos para la exportación automotriz regional. Sin embargo, ninguno de los tres países cuenta aún con un régimen de reporte de emisiones marítimas equivalente al MRV europeo. Brasil avanza en la implementación de su Sistema de Estimativas de Emissões e Remoções de Gases de Efeito Estufa (SEEG), pero su alcance sobre el transporte marítimo internacional sigue siendo limitado. Argentina, bajo la Ley 27.520 de Presupuestos Mínimos de Adaptación y Mitigación al Cambio Climático Global, habilita marcos de reporte pero no establece obligaciones específicas para el sector naviero. Chile es quien más ha avanzado, con su Ley Marco de Cambio Climático (Ley 21.455 de 2022), que incorpora mecanismos de monitoreo sectorial, aunque la reglamentación marítima específica aún está pendiente.

    Este vacío regulatorio local tiene una consecuencia práctica inmediata: los operadores portuarios latinoamericanos que prestan servicios a líneas navieras con destino a Europa ya están sujetos al MRV europeo de facto, porque sus contrapartes armadoras deben reportar las emisiones de toda la travesía, incluidos los segmentos en aguas latinoamericanas. Dicho de otro modo, la demanda de datos de GEI con calidad certificable ya llegó a la región, aunque la obligación legal local todavía no.

    Data lineage de emisiones: el desafío técnico que el marco expone

    Implementar este tipo de estándar exige algo que muchos operadores portuarios latinoamericanos aún no tienen resuelto: un data lineage —trazabilidad de datos desde su origen hasta el reporte final— que permita auditar de dónde viene cada dato de consumo de combustible, quién lo validó y con qué metodología se convirtió en una cifra de CO₂. Sin ese linaje documentado, cualquier reporte de GEI es potencialmente impugnable ante una auditoría de la OMI o de un cliente europeo.

    El marco sectorial Ro-Ro, al definir responsabilidades por actor y por etapa, sienta las bases para construir ese linaje. Pero la implementación real requiere que los operadores mapeen sus fuentes de datos actuales —sensores de flujo de combustible, registros de despacho, sistemas ERP portuarios— y determinen qué gaps existen entre lo que hoy capturan y lo que el estándar exige. Los equipos de gobernanza de datos que ya operan bajo CDMC del EDM Council tienen una ventaja: las capabilities de data quality y data lineage del modelo son directamente transferibles a este caso de uso.

    Qué monitorear: OMI 2027 y la ventana de preparación para puertos latinoamericanos

    El próximo hito regulatorio relevante es la entrada en vigor de la estrategia revisada de reducción de emisiones de la OMI, con metas intermedias hacia 2030 que requerirán reportes verificados por terceros. Los puertos latinoamericanos que hoy no tienen estructurada su gobernanza de datos de GEI enfrentarán esa exigencia sin infraestructura de datos adecuada. Los pasos concretos para los equipos de gobernanza incluyen: inventariar las fuentes de datos de consumo energético en operaciones portuarias, identificar al data steward responsable de cada fuente, evaluar si los sistemas actuales permiten exportar datos en formatos compatibles con el estándar MRV, y revisar los contratos con armadores para entender qué datos se les está proveyendo hoy y bajo qué formato.

    Nuestro análisis

    El lanzamiento de este marco sectorial es, ante todo, una señal de madurez industrial: el sector Ro-Ro reconoce que la fragmentación de datos de emisiones es un riesgo reputacional y regulatorio, no solo un problema técnico. Lo relevante para la región es que este estándar llegará a los puertos latinoamericanos no por mandato de sus propios gobiernos, sino por presión de las cadenas de valor globales. Eso es, en términos de gobernanza de datos, una demanda de capabilities que ya existe aunque la regulación local no la haya formalizado todavía.

    La experiencia de otros sectores —banca bajo Basilea III, automotriz bajo WLTP— muestra que los operadores que esperan al mandato local para construir sus capacidades de datos llegan tarde y con costos más altos. Los CDOs de puertos y navieras en la región tienen hoy una oportunidad concreta: adoptar el marco sectorial Ro-Ro como caso piloto para desarrollar una práctica de gobernanza de datos de sostenibilidad que después podrá escalarse a otras obligaciones de reporte ESG.

    La gobernanza de datos de emisiones no es un problema ambiental que espera solución técnica: es un problema de ownership, linaje y calidad de datos que los equipos de gobernanza de la región ya saben resolver. La pregunta es si lo harán antes o después de que el regulador los obligue.

  • Gobernanza de datos de emisiones GHG: el sector naviero crea un organismo internacional

    Gobernanza de datos de emisiones GHG: el sector naviero crea un organismo internacional

    La industria de transporte marítimo ro-ro lanzó un organismo internacional de gobernanza y un nuevo marco para gestionar datos de emisiones de gases de efecto invernadero (GHG), con la participación de ClassNK, una de las principales sociedades de clasificación naval del mundo. La iniciativa apunta a estandarizar la recolección, calidad y uso de datos de emisiones en una industria que enfrenta presión regulatoria creciente a nivel global.

    El transporte ro-ro (roll-on/roll-off), especializado en vehículos, maquinaria y carga rodante, representa una porción significativa del comercio marítimo internacional. Durante años, la falta de un estándar común para reportar emisiones de carbono dentro del sector generó inconsistencias que complicaban tanto la toma de decisiones operativas como el cumplimiento regulatorio ante organismos como la Organización Marítima Internacional (OMI). El nuevo marco de gobernanza de datos GHG busca resolver exactamente esa brecha.

    Qué hace el nuevo organismo y por qué ClassNK es clave

    El organismo recién establecido tiene como función central definir reglas comunes para la captura, validación, almacenamiento y uso de datos de emisiones de GHG dentro del sector ro-ro. ClassNK —sociedad de clasificación con sede en Japón que certifica embarcaciones de todo el mundo— participa activamente en la iniciativa, según se informó. Su rol es especialmente relevante porque las sociedades de clasificación ya operan como intermediarios de confianza en la verificación técnica de buques, lo que las posiciona como actores naturales en esquemas de gobernanza de datos sectoriales. Sin una entidad de este tipo, cada operador podía calcular y reportar emisiones con metodologías distintas, haciendo imposible la comparación entre flotas o rutas.

    El marco GHG: qué estandariza y qué mecanismos define

    El framework de gobernanza de datos GHG establece, según se informó, lineamientos sobre cómo deben recolectarse los datos de emisiones a bordo, qué métricas son válidas para el cálculo de intensidad de carbono, y cómo debe documentarse el linaje de esos datos —es decir, su origen, transformaciones y responsables— a lo largo de la cadena de reporte. En términos de DAMA-DMBOK, el sector estaba operando sin definición formal de data stewardship ni de data quality rules aplicadas a métricas ambientales. Este organismo introduce, en la práctica, una capa de gobierno que asigna roles y responsabilidades sobre los datos antes de que lleguen a los reportes regulatorios.

    Cuándo aplica este marco y cuándo NO

    El marco aplica específicamente al segmento ro-ro dentro de la industria naviera: buques diseñados para el transporte de vehículos y carga rodante. No cubre, al menos en esta etapa según se informó, otros tipos de embarcaciones como portacontenedores, graneleros o buques tanque, aunque la arquitectura del sistema podría ser replicable en esos segmentos. Tampoco reemplaza los esquemas de reporte obligatorio existentes ante la OMI o bajo regulaciones regionales como el sistema EU ETS (mercado de carbono europeo), al que el transporte marítimo fue incorporado en 2024; más bien, busca mejorar la calidad de los datos que alimentan esos reportes.

    Relevancia para puertos y operadores en América Latina

    Para la región, la iniciativa tiene implicancias concretas. Los puertos latinoamericanos con operaciones ro-ro relevantes —como Buenos Aires, Santos, Callao y Veracruz— reciben y despachan flotas que operan bajo banderas sujetas a regulación de la OMI. Los operadores navieros que toquen puertos de la Unión Europea ya están obligados a reportar emisiones bajo el EU ETS y el sistema MRV (Monitoreo, Reporte y Verificación) marítimo europeo. Un marco sectorial que estandarice los datos de origen mejora la trazabilidad de esas declaraciones y reduce el riesgo de discrepancias que pueden derivar en sanciones o en la pérdida de acceso a ciertos mercados. Además, países como Brasil y Chile avanzan en regulaciones de carbono propias: Brasil trabaja en su sistema de comercio de emisiones (SBCE) y Chile ya tiene impuesto al carbono vigente, lo que anticipa que la calidad de datos de emisiones marítimas tendrá consecuencias directas también en el ámbito local.

    El dato de gobernanza que más importa aquí

    Lo que distingue a este organismo de una iniciativa de reporte ambiental convencional es su enfoque explícito en gobernanza del dato —no en la política ambiental en sí. Crear un cuerpo que defina quién es el data owner de un registro de emisión a bordo, qué transformaciones son válidas, y cómo se audita el linaje de ese dato antes de que llegue al regulador, es exactamente lo que marcos como el CDMC del EDM Council o el estándar ISO/IEC 38505 proponen para cualquier dominio crítico de datos. El sector naviero ro-ro está aplicando, en contexto ambiental, principios que la industria financiera y la farmacéutica llevan más de una década desarrollando.

    Para referencia sobre los estándares de reporte de emisiones marítimas vigentes, el marco MRV de la Unión Europea y las directrices de la OMI sobre intensidad de carbono están disponibles en sus respectivos sitios oficiales. El texto del framework GHG sectorial no había sido publicado en forma completa al momento de esta nota.

  • OpenAI promete retención cero de datos para empresas: ¿qué garantiza realmente?

    OpenAI promete retención cero de datos para empresas: ¿qué garantiza realmente?

    OpenAI anunció una política de retención cero de datos para clientes corporativos, en un movimiento que apunta directamente a reducir la ventaja competitiva de Anthropic en el segmento enterprise. La promesa central: los prompts y las respuestas no se almacenan una vez que la sesión termina. Pero el anuncio viene con una capa que merece atención: la compañía también presentó “Private Safety Processing”, un mecanismo de vigilancia automatizada de los inputs que, según informó la empresa, operaría de forma discreta.

    La retención cero de datos —conocida en contratos de servicios cloud como zero data retention o ZDR— es una condición que los equipos legales y de privacidad de grandes organizaciones vienen exigiendo cada vez con más frecuencia al contratar modelos de lenguaje como servicio. Bajo este esquema, el proveedor se compromete a no guardar ningún dato transmitido durante la inferencia: ni el prompt del usuario, ni la respuesta del modelo, ni metadatos asociados a la consulta. Para sectores como salud, banca o servicios jurídicos, donde los prompts pueden contener datos sensibles de clientes o información protegida por secreto profesional, esta condición suele ser el umbral mínimo de negociación.

    Qué significa “retención cero” y qué no cubre

    Una política ZDR no equivale a ausencia total de procesamiento. Los datos aún transitan por la infraestructura del proveedor, son procesados por el modelo y pueden quedar expuestos a mecanismos intermedios de seguridad. Precisamente ahí entra en escena Private Safety Processing: según se informó, OpenAI incorpora un sistema automatizado que analiza los prompts con fines de moderación y seguridad, incluso bajo el esquema de retención cero. La empresa describe este procesamiento como discreto, lo que plantea una pregunta técnica y jurídica inmediata: ¿qué datos se procesan, por cuánto tiempo, con qué base legal y quién los controla?

    Esta distinción importa porque en la mayoría de los marcos de protección de datos vigentes, el procesamiento sin almacenamiento permanente sigue siendo tratamiento de datos personales. La LGPD de Brasil, la Ley 25.326 de Argentina y la LFPDPPP de México exigen que cualquier operación sobre datos personales —incluyendo la simple lectura en memoria— cuente con una base legal habilitante, un propósito declarado y, en muchos casos, un contrato de encargado de tratamiento debidamente suscrito. Que los datos no se “guarden” en un disco no los saca del ámbito regulatorio.

    Cuándo aplica la política ZDR y cuándo no

    La retención cero es relevante cuando los prompts contienen datos personales de terceros, información confidencial protegida por ley o datos sujetos a regulación sectorial —expedientes médicos, datos financieros, información de menores. No aplica, o aplica con matices, cuando el modelo se usa para tareas internas sin datos sensibles, cuando el proveedor opera bajo un acuerdo de procesamiento de datos (DPA) que ya regula la retención, o cuando la organización despliega el modelo en infraestructura propia. En esos casos, la política ZDR es un plus comercial, no una salvaguarda regulatoria crítica.

    También conviene distinguir entre retención cero en inferencia y retención cero en fine-tuning o entrenamiento. Los modelos personalizados con datos del cliente abren una categoría diferente de riesgos: los pesos del modelo podrían codificar, de forma difusa pero real, información presente en los datos de entrenamiento. Una política ZDR sobre inferencia no cubre ese vector.

    El contexto competitivo: Anthropic lleva ventaja en el segmento legal y de salud

    Anthropic construyó parte de su posicionamiento enterprise precisamente sobre compromisos de privacidad más estrictos que los de OpenAI, al menos en la percepción del mercado. Sectores como el legal, el financiero y el sanitario en Estados Unidos —y sus equivalentes en América Latina— eligieron Claude en parte por ese diferencial. El movimiento de OpenAI busca cerrar esa brecha, pero la credibilidad de un compromiso de privacidad no se establece solo con un anuncio: requiere cláusulas contractuales auditables, mecanismos de verificación independiente y, en jurisdicciones con autoridades de control activas, la posibilidad de que esas autoridades revisen el cumplimiento efectivo.

    En América Latina, ese último punto es relevante. La Autoridad Nacional de Protección de Datos de Brasil (ANPD) ha avanzado en lineamientos sobre uso de inteligencia artificial con datos personales, y la Agencia de Acceso a la Información Pública de Argentina (AAIP) ha publicado criterios sobre tratamiento de datos en entornos de IA. Cualquier empresa de la región que evalúe adoptar OpenAI bajo política ZDR debería revisar si el DPA ofrecido por el proveedor es compatible con las exigencias locales de subencargados de tratamiento y transferencias internacionales.

    El problema específico del “safety processing” discreto

    El punto más delicado del anuncio no es la retención cero sino el procesamiento de seguridad que coexiste con ella. Si Private Safety Processing implica que un sistema automatizado analiza el contenido de los prompts —aunque sea para detectar usos prohibidos— esa operación debe estar declarada en la política de privacidad, en el DPA y, si los datos son personales, debe contar con base legal. “Seguridad del servicio” puede constituir un interés legítimo bajo GDPR o LGPD, pero no es automático: requiere un test de proporcionalidad y, en algunos casos, una evaluación de impacto (DPIA). Las empresas que asumen que retención cero equivale a privacidad total asumen demasiado.

    Para los equipos jurídicos y de privacidad en LATAM que evalúan proveedores de IA, la pregunta correcta no es “¿ofrecen retención cero?” sino “¿qué datos procesan, durante cuánto tiempo, bajo qué base legal, y pueden acreditarlo ante una autoridad de control?”. Los documentos contractuales —no los anuncios de producto— son donde esa respuesta debe aparecer.

  • Montevideo formaliza su modelo de gobernanza de datos a nivel institucional

    Montevideo formaliza su modelo de gobernanza de datos a nivel institucional

    La Intendencia de Montevideo oficializó un modelo de gobernanza de datos que convierte a la capital uruguaya en uno de los pocos gobiernos municipales de América Latina con un marco institucional explícito para la gestión de sus activos de datos. El movimiento no es cosmético: implica roles definidos, políticas internas y una arquitectura de decisión sobre los datos públicos que la ciudad produce y consume.

    Que un gobierno subnacional latinoamericano formalice su gobernanza de datos sigue siendo la excepción, no la regla. La mayoría de las intendencias, municipios y alcaldías de la región operan con datos fragmentados entre sistemas sectoriales —salud, movilidad, tributos, catastro— sin un marco transversal que defina quién es responsable de cada dominio, cómo se garantiza la calidad y bajo qué criterios se habilita el intercambio. Montevideo acaba de dar un paso que pocas administraciones de su tamaño han dado de manera formal.

    Qué significa institucionalizar en el marco DAMA-DMBOK

    En el lenguaje de la industria, “institucionalizar” un modelo de gobernanza implica que las prácticas dejan de depender de voluntades individuales y se anclan en estructuras formales: políticas aprobadas, roles con mandato explícito (data stewards, data owners, un equivalente a CDO), y procesos repetibles de control de calidad y ciclo de vida del dato. Según el DAMA-DMBOK —el framework de referencia global para la gestión de datos—, la gobernanza es la función paraguas que habilita todas las demás áreas de conocimiento: calidad, arquitectura, seguridad, metadata. Sin ese paraguas formal, cada área opera en silos. La Intendencia de Montevideo, según se informó, habría avanzado precisamente en ese nivel estructural.

    El modelo institucionalizado supone también que existe alguna forma de data catalog o inventario de activos de datos, un mecanismo de data lineage para rastrear el origen y transformación de los datos entre sistemas municipales, y —lo más difícil en el sector público— un proceso de resolución de conflictos entre dominios cuando distintas áreas reclaman ownership sobre el mismo dato. Sin estos tres elementos operativos, la gobernanza se queda en el papel.

    Uruguay lidera en LATAM, pero el estándar regional sigue siendo bajo

    Uruguay viene construyendo capacidades de datos públicos desde hace más de una década. La Agencia de Gobierno Electrónico y Sociedad de la Información y el Conocimiento (AGESIC) —hoy reorganizada como parte de la Agencia de Transformación Digital y Ciberseguridad (ATDC)— desarrolló marcos de interoperabilidad y datos abiertos que posicionaron al país como referente regional en e-government. El movimiento de la Intendencia de Montevideo es coherente con ese ecosistema nacional, pero ocurre a nivel subnacional, donde el avance suele ser mucho más lento.

    En contraste, en Argentina los municipios carecen de un marco federal que los oriente en gobernanza de datos, y el Poder Ejecutivo Nacional aún no consolidó un modelo equivalente al nivel del Estado central. Brasil avanzó con la Estratégia de Governo Digital 2024-2027 y la actuación de la Controladoria-Geral da União (CGU) en datos abiertos, pero la gobernanza subnacional es heterogénea: São Paulo tiene capacidades muy distintas a las de un municipio del interior de Mato Grosso. México, por su parte, tiene a nivel federal la Plataforma Nacional de Transparencia, pero la gobernanza de datos como disciplina de gestión interna —con data owners, stewards y políticas de calidad— es prácticamente inexistente en los gobiernos locales.

    El riesgo de la gobernanza declarativa: qué distingue el papel de la práctica

    La historia reciente de la región tiene varios ejemplos de marcos de gobernanza que se aprueban por decreto y nunca se operacionalizan. La diferencia entre una gobernanza real y una gobernanza decorativa se mide en tres indicadores concretos: si existe un comité de datos con reuniones regulares y actas documentadas, si los data stewards tienen tiempo formal asignado a sus responsabilidades de gobernanza (no solo como función adicional a su rol técnico), y si hay métricas de calidad de datos que se reportan periódicamente a la dirección. Sin estos tres elementos, el modelo más sofisticado sobre papel no produce ningún cambio operativo.

    El EDM Council, a través de su framework CDMC (Cloud Data Management Capabilities), identifica 14 capabilities organizadas en capas que van desde la definición de políticas hasta la implementación técnica de controles. La mayoría de los gobiernos latinoamericanos —incluso los más avanzados— operan con capabilities equivalentes a los niveles 1 y 2 del CDMC, sin certificación formal y sin benchmarking externo. Montevideo, si el modelo institucionalizado incluye mecanismos de medición, podría convertirse en el primer gobierno municipal de la región en mapear sus capacidades contra un estándar internacional.

    Qué monitorear en los próximos meses: los hitos que confirmarán la solidez del modelo

    El anuncio de institucionalización es el punto de partida, no el destino. Los hitos que confirmarán si el modelo de Montevideo tiene tracción real son los siguientes:

    • Publicación del marco normativo interno (resolución, decreto departamental o política aprobada) con los roles formales de gobernanza y sus atribuciones.
    • Designación pública de los data owners por dominio temático (movilidad, tributos, salud, catastro) y del responsable central de gobernanza.
    • Integración del modelo con el portal de datos abiertos de la Intendencia, que existe desde hace años pero sin una capa de gobernanza explícita sobre la calidad y actualización de los datasets publicados.
    • Primer reporte de métricas de calidad de datos o inventario de activos accesible públicamente.

    Si en seis meses ninguno de estos elementos es visible, el riesgo de que el modelo quede como declaración de intenciones es alto. Si alguno de ellos aparece, Montevideo habrá construido un caso de referencia replicable para otras capitales de la región.

    Nuestro análisis

    La iniciativa de Montevideo importa por lo que representa, no solo por lo que hace: un gobierno municipal en América Latina que trata los datos como activos que requieren gestión estructurada, roles formales y políticas explícitas es todavía una rareza. El timing también es relevante. La presión regulatoria sobre el sector público en materia de datos —desde la Ley 19.670 de Uruguay hasta los reglamentos de la ATDC sobre ciberseguridad y datos— hace que la gobernanza deje de ser optativa para convertirse en una condición de cumplimiento. Las intendencias que no tengan un modelo operativo cuando lleguen los primeros requerimientos de auditoría o los primeros incidentes de datos enfrentarán costos institucionales y reputacionales que podrían haberse evitado.

    Para los equipos de datos de otras administraciones públicas de la región, la experiencia de Montevideo ofrece algo valioso: un caso concreto, en escala municipal, de cómo iniciar la formalización sin esperar a tener presupuestos de gobierno federal ni plataformas tecnológicas de última generación. La gobernanza de datos no requiere primero comprar herramientas; requiere primero definir quién decide qué sobre los datos, y documentarlo.

    La pregunta que Montevideo deja abierta para el resto de la región es si este tipo de decisiones llegará por convicción institucional o habrá que esperar a que un incidente de datos públicos obligue a los gobiernos a actuar.