DataTrends LATAM

Categoría: Data Governance

  • DLH obtiene contrato piloto de gobernanza de datos del NIH por USD 2 millones

    DLH obtiene contrato piloto de gobernanza de datos del NIH por USD 2 millones

    DLH Holdings aseguró una orden de tarea piloto valuada en USD 2 millones otorgada por los Institutos Nacionales de Salud de Estados Unidos (NIH) para implementar un programa de gobernanza de datos en el ámbito federal de salud, según se informó el 5 de octubre de 2025.

    El contrato, encuadrado como proyecto piloto, posiciona a DLH como proveedor de servicios de data governance para una de las agencias científicas con mayor volumen de datos clínicos y de investigación del gobierno estadounidense. La adjudicación fue reportada por TradingView y no incluyó detalles sobre el alcance técnico específico ni los plazos de entrega intermedios. Se desconoce por ahora qué dominios de datos del NIH abarca el piloto ni qué marcos de referencia fueron exigidos en el pliego.

    Datos confirmados del contrato NIH–DLH

    • Valor del contrato: USD 2 millones
    • Tipo de instrumento: task order de fase piloto
    • Agencia contratante: Institutos Nacionales de Salud (NIH), dependencia del Departamento de Salud de EE.UU.
    • Empresa adjudicataria: DLH Holdings Corp.
    • Fecha de divulgación: 5 de octubre de 2025

    Qué se sabe y qué falta confirmar

    Lo confirmado es el valor, la parte contratante y el carácter piloto del encargo. Lo que no está verificado incluye: el framework de gobernanza exigido (si se utilizará DAMA-DMBOK, CDMC del EDM Council u otro estándar), los dominios de datos involucrados (ensayos clínicos, datos genómicos, registros administrativos), y si el piloto tiene cláusula de extensión a un contrato mayor. Tampoco se informó si existe un Data Steward designado dentro del NIH como contraparte del programa, un rol crítico para que este tipo de iniciativas supere la etapa piloto en organismos públicos de gran escala.

    El sector salud del gobierno federal estadounidense acumula uno de los repositorios de datos más complejos del mundo: ensayos clínicos, datos genómicos, estadísticas epidemiológicas y registros de beneficiarios operan en silos con distintos niveles de sensibilidad y marcos regulatorios (HIPAA, entre otros). Un piloto de gobernanza en ese entorno implica, como mínimo, definir ownership por dominio, construir un catálogo de datos con linaje, y establecer políticas de calidad y acceso. Que esté estructurado como piloto sugiere que el NIH aún no tiene una arquitectura de gobernanza consolidada y busca validar un modelo antes de escalarlo.

    En América Latina, iniciativas equivalentes en el sector público de salud son escasas pero crecientes. Brasil avanza con el Rnds (Rede Nacional de Dados em Saúde) bajo supervisión del Ministerio de Salud, con obligaciones de interoperabilidad que implican, de facto, capacidades de data lineage y control de calidad. En Argentina, el Sistema Nacional de Información Sanitaria opera sin un marco formal de gobernanza de datos publicado, aunque entidades como el Ministerio de Salud y el PAMI manejan volúmenes de datos clínicos que justificarían un ejercicio similar al que el NIH está piloteando. El caso DLH–NIH ofrece un modelo de contratación pública acotada —piloto antes que transformación total— que organismos de salud latinoamericanos podrían replicar para iniciar programas de gobernanza sin comprometer presupuestos de largo plazo antes de validar el enfoque.

    El próximo hito a seguir es la divulgación del informe de resultados del piloto, cuya fecha no fue informada; hasta entonces, el contrato no permite evaluar si DLH escalará el programa al resto de la infraestructura de datos del NIH.

  • PwC: las brechas en gobernanza de datos frenan la seguridad en IA

    PwC: las brechas en gobernanza de datos frenan la seguridad en IA

    Una encuesta global de PwC revela que las organizaciones avanzan en adopción de inteligencia artificial mientras sus fundamentos de gobernanza de datos permanecen sin resolver. La brecha no es técnica: es de ownership, clasificación y control del dato antes de que llegue a los modelos.

    El hallazgo central del relevamiento de PwC es que la seguridad en sistemas de IA no puede desacoplarse de la madurez en gobernanza de datos corporativa. Las compañías que despliegan modelos sobre datos sin clasificar, sin linaje documentado y sin un data steward identificable están, en la práctica, introduciendo riesgo sistémico en cada inferencia. No es un problema de firewall ni de modelo: es un problema de quién es responsable del dato que alimenta ese modelo.

    Qué mide PwC y qué encontró en las organizaciones relevadas

    Según se informó a partir del relevamiento, una proporción significativa de empresas encuestadas reconoce no tener controles formales sobre los datos que utilizan para entrenar o alimentar sus sistemas de IA. Esto incluye ausencia de catálogos de datos activos, falta de políticas de retención aplicadas a datasets de entrenamiento, y procesos de data quality que no escalan al ritmo de los proyectos de IA. El reporte identifica tres brechas recurrentes: ausencia de roles de gobernanza formalizados para IA, políticas de acceso a datos inconsistentes entre áreas de negocio, y ausencia de trazabilidad (data lineage) desde la fuente hasta el output del modelo.

    Por qué el data lineage es el punto de quiebre en entornos de IA

    El data lineage —la documentación de cómo un dato es capturado, transformado y consumido a lo largo de su ciclo de vida— no es un requisito nuevo. El DAMA-DMBOK lo ubica como una capability central dentro del área de conocimiento de Data Architecture. Lo que cambia con la IA generativa es la velocidad a la que un dato mal catalogado o sin owner asignado puede propagarse a un output visible, auditable y potencialmente regulado. Si el modelo responde con información personal no depurada o con datos de clientes de una jurisdicción con restricciones de transferencia, el problema de compliance ya ocurrió. El lineage es el único mecanismo que permite reconstruir ese camino y demostrar control ante un regulador.

    El EDM Council y el umbral mínimo de madurez para operar IA de forma segura

    El EDM Council, a través de su framework CDMC (Cloud Data Management Capabilities), establece que las organizaciones necesitan al menos las capabilities de clasificación de datos, gestión de consentimiento y control de acceso granular antes de mover datos sensibles a entornos de IA en la nube. Según el esquema de madurez del CDMC, muchas organizaciones de la región operan entre los niveles 4 y 6 de 12, suficiente para reporting operativo pero insuficiente para soportar un programa de IA con datos regulados. La distancia no es menor: entre el nivel 6 y el 9 —donde el control sobre datos en IA empieza a ser robusto— hay decisiones de presupuesto, de talento y de arquitectura que no se resuelven en un trimestre.

    En América Latina: LGPD, Ley 25.326 y el riesgo de entrenar modelos con datos personales sin base legal

    En Brasil, la LGPD (Lei Geral de Proteção de Dados, Lei nº 13.709/2018) exige que cualquier tratamiento de datos personales, incluyendo el uso para entrenamiento de modelos de IA, cuente con una base legal habilitante. La Autoridade Nacional de Proteção de Dados (ANPD) ya emitió orientaciones sobre tratamiento automatizado que las organizaciones con operaciones en el país deben considerar al diseñar sus pipelines de entrenamiento. En Argentina, la Ley 25.326 de Protección de Datos Personales aplica lógica similar, aunque la Agencia de Acceso a la Información Pública (AAIP) aún no cuenta con una guía específica para IA. En México, el INAI opera bajo la LFPDPPP y ha emitido recomendaciones sobre decisiones automatizadas. El punto común: ninguno de estos marcos habilita el uso de datos personales en IA por defecto. La gobernanza de datos no es preparación para una auditoría futura; es el requisito previo para operar hoy.

    Cuándo aplica este análisis y cuándo no

    Las brechas identificadas por PwC son directamente relevantes para organizaciones que: (a) usan datos de clientes o empleados para alimentar modelos de IA propios o de terceros; (b) operan en industrias reguladas —banca, salud, seguros— con requisitos específicos de control de datos; o (c) tienen proveedores de IA que acceden a datos propios para fine-tuning o RAG (Retrieval-Augmented Generation). No aplica de la misma forma a organizaciones que usan modelos de IA exclusivamente con datos públicos o sintéticos sin trazabilidad a personas identificables. En ese segmento, el riesgo de gobernanza es menor, aunque el riesgo de calidad de output persiste.

    Para un CDO o Data Governance Manager con proyectos de IA activos, el paso inmediato es auditar qué datasets están siendo utilizados por esos proyectos, quién figura como data owner en el catálogo corporativo, y si existe una base legal documentada para ese uso bajo la ley aplicable en cada jurisdicción donde operan. Si alguna de esas tres preguntas no tiene respuesta clara, el riesgo ya existe.

    El reporte completo de PwC está disponible en pwc.com; para el marco regulatorio aplicable en Brasil, la ANPD publica sus resoluciones y guías técnicas en gov.br/anpd.

  • Gobernanza de datos en la era de la IA: qué está cambiando y por qué importa

    Gobernanza de datos en la era de la IA: qué está cambiando y por qué importa

    La irrupción de la inteligencia artificial generativa está forzando a las organizaciones a revisar desde cero sus marcos de gobernanza de datos: los modelos consumen información a una velocidad y escala que los controles tradicionales no estaban diseñados para gestionar. El debate ya no es si gobernar los datos de la IA, sino cómo hacerlo antes de que el costo de no haberlo hecho se vuelva irreversible.

    Durante años, la gobernanza de datos fue tratada como una función de soporte —importante, pero no urgente. Esa lógica se quebró cuando los equipos de datos empezaron a alimentar modelos de lenguaje con activos de información cuya calidad, linaje y ownership nadie había trazado formalmente. El resultado es predecible: outputs incorrectos, riesgos legales no anticipados y una incapacidad estructural para auditar decisiones automatizadas. Lo que antes era un problema de reporting interno se convirtió en un problema de responsabilidad corporativa.

    Por qué los marcos de gobernanza pre-IA se quedan cortos

    Los frameworks de gobernanza diseñados en la era del data warehouse —incluyendo las primeras versiones del DAMA-DMBOK— partían de un supuesto razonable en su momento: los datos tienen ciclos de vida relativamente predecibles, los consumidores son analistas internos y los controles pueden aplicarse por dominio. Los modelos de IA generativa rompen ese supuesto en tres puntos críticos. Primero, consumen datos de múltiples dominios simultáneamente, sin respetar fronteras de ownership. Segundo, producen outputs que son en sí mismos nuevos datos —con linaje opaco, difícil de rastrear hasta la fuente. Tercero, operan a una velocidad que hace inviable la revisión manual caso a caso.

    El EDM Council, a través de su framework CDMC (Cloud Data Management Capabilities), ya incorporó controles específicos para entornos de IA en su versión más reciente, incluyendo requisitos de trazabilidad del dato de entrenamiento y mecanismos de auditoría de outputs. Sin embargo, la adopción formal de estos controles en América Latina sigue siendo marginal, concentrada en grandes bancos y telcos con presencia multinacional.

    Tres tensiones concretas que los CDO están enfrentando hoy

    La conversación sobre gobernanza de datos en la era de la IA se concentra en un conjunto acotado de tensiones operativas que los Chief Data Officers deben resolver sin manual de instrucciones consolidado:

    • Calidad del dato de entrenamiento: los modelos amplifican sesgos presentes en los datos de origen. Si el catálogo de datos no tiene perfiles de calidad actualizados, el equipo de IA entrena sobre activos que nadie certificó. El data steward del dominio correspondiente debe ser parte del proceso de aprobación de datasets para entrenamiento, no una consulta posterior.
    • Ownership de los outputs generados por IA: cuando un modelo produce un informe, una clasificación o una predicción, ¿quién es el data owner de ese output? La mayoría de los marcos actuales no lo especifican. Sin ownership claro, no hay responsabilidad sobre errores ni mecanismo de corrección.
    • Linaje end-to-end: la capacidad de rastrear un output de IA hasta los datos que lo produjeron —data lineage completo— se está convirtiendo en un requisito regulatorio implícito en múltiples jurisdicciones, incluso donde no existe una norma específica de IA. En la práctica, pocos equipos tienen herramientas de linaje que crucen la frontera entre el pipeline de datos y el pipeline de ML.

    Cuándo aplica una revisión de governance para IA / cuándo NO

    Una revisión del marco de gobernanza orientada a IA aplica cuando la organización está desplegando modelos que consumen datos de producción, cuando los outputs del modelo alimentan decisiones con consecuencias sobre terceros —clientes, empleados, proveedores—, o cuando existe una obligación regulatoria de explicabilidad o auditoría. No aplica —o no es urgente— cuando el uso de IA está restringido a entornos sandbox con datos sintéticos o anonimizados, sin conexión a sistemas de producción ni impacto en decisiones reales.

    En América Latina, este umbral de urgencia está siendo acelerado por marcos regulatorios que, aunque no son leyes de IA específicas, ya exigen trazabilidad y explicabilidad en contextos sectoriales. El Banco Central de Brasil, a través de sus resoluciones sobre modelos de crédito, requiere que las instituciones financieras documenten los datos utilizados en decisiones automatizadas. En Argentina, la Comunicación A 7724 del BCRA establece requisitos de gestión de riesgos de modelos que de facto obligan a un nivel de linaje y calidad que muchos equipos de datos aún no tienen instrumentado. En México, la CNBV tiene lineamientos similares para modelos de scoring en entidades supervisadas.

    Lo que un CDO puede hacer esta semana sin esperar la estrategia perfecta

    La discusión sobre gobernanza de datos e IA suele quedar atrapada en el nivel de política y framework, cuando hay acciones concretas de bajo costo y alto impacto que pueden iniciarse de inmediato. El primer paso es mapear qué datasets de producción están siendo consumidos por modelos en uso —no en desarrollo, en uso real— y verificar si esos datasets tienen un data steward asignado, un perfil de calidad vigente y un contrato de datos documentado. En la mayoría de las organizaciones de la región, ese mapeo revelará entre tres y cinco dominios críticos sin ownership formal. Eso es el punto de partida, no un problema irresoluble.

    El segundo paso es revisar si el proceso de aprobación de nuevos proyectos de IA incluye una etapa de revisión de governance del dato —no solo una revisión técnica o de negocio. El modelo de Non-Invasive Data Governance de Bob Seiner ofrece una guía práctica para integrar estos controles sin crear burocracia adicional: el principio central es que las personas que ya trabajan con los datos asuman formalmente el rol de steward, en lugar de crear una capa de gobierno paralela.

    Para profundizar en los requisitos de trazabilidad aplicables a modelos en producción, el CDMC del EDM Council y la resolución BCB 4.557 de Brasil son los dos documentos de referencia más directamente aplicables al contexto latinoamericano hoy.

  • 11 cámaras Flock sin dueño en Florida revelan fallas de ownership en vigilancia pública

    11 cámaras Flock sin dueño en Florida revelan fallas de ownership en vigilancia pública

    Once cámaras de reconocimiento de matrículas de la empresa Flock Safety operaban en Florida sin un responsable institucional identificable, según se informó el 4 de octubre de 2025. El hallazgo expone una brecha concreta de ownership de datos en redes de vigilancia pública: dispositivos activos, datos capturados, y ningún organismo formalmente asignado como custodio.

    La situación fue reportada por ecosistemastartup.com a partir de registros públicos que revelaron once nodos de la red Flock —tecnología de captura automática de placas vehiculares (ALPR, por sus siglas en inglés) ampliamente desplegada por cuerpos policiales y municipios en Estados Unidos— funcionando en territorio del estado de Florida sin que ninguna agencia o entidad gubernamental hubiera asumido formalmente la titularidad del sistema. Flock Safety es una empresa privada que provee hardware, software y acceso a una red federada de datos de tráfico vehicular a clientes institucionales. Que once nodos carezcan de dueño registrado no es un problema técnico: es un problema de gobernanza.

    Sin data owner: qué falló en la cadena de custodia

    En términos de gestión de datos, cada dispositivo de captura en una red ALPR es un punto de generación de datos personales —ubicación, hora, imagen de vehículo y placa, potencialmente vinculable a una persona identificable. La ausencia de un data owner asignado implica que no existe un responsable de definir la política de retención, los niveles de acceso, el propósito del tratamiento ni los procedimientos de respuesta ante solicitudes de derechos. Es exactamente el escenario que los marcos de gobernanza como DAMA-DMBOK o el CDMC del EDM Council buscan prevenir con la asignación obligatoria de data stewards por dominio de dato.

    El caso de Florida no es un accidente aislado: refleja un patrón frecuente en despliegues de tecnología de vigilancia pública donde la adquisición del hardware precede —a veces por años— a la definición del marco de gobernanza. El contrato con el proveedor existe; el esquema de ownership interno, no.

    LATAM: el mismo riesgo en ciudades con CCTV y ALPR sin marco formal

    Varias ciudades latinoamericanas han expandido redes de cámaras de reconocimiento de placas y circuitos cerrados integrados con bases de datos policiales en los últimos años. En Argentina, el tratamiento de imágenes vinculadas a personas identificables queda comprendido bajo la Ley 25.326 de Protección de los Datos Personales, que exige que el responsable del tratamiento esté formalmente identificado y registrado ante la Agencia de Acceso a la Información Pública (AAIP). En México, la LFPDPPP y, para el sector público, la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados establecen obligaciones equivalentes sobre el responsable del tratamiento. En Brasil, la LGPD (Lei 13.709/2018) impone requisitos similares de identificación del controlador de datos. En ninguno de estos marcos es admisible que un sistema capture datos personales sin un responsable formalmente designado —pero la fiscalización efectiva de redes municipales de vigilancia sigue siendo escasa en la región.

    El caso de Florida es útil como señal de alerta para equipos de gobernanza en organismos públicos latinoamericanos que operen o estén evaluando contratos con proveedores de tecnología ALPR o CCTV inteligente: el contrato de servicio no reemplaza la designación interna de un data steward ni la inscripción del tratamiento ante la autoridad de control correspondiente.

    El próximo hito a monitorear es si las autoridades de Florida identifican formalmente a los responsables de esos once nodos o si el hallazgo deriva en una auditoría más amplia de la red Flock en el estado.

  • República Dominicana en el Diálogo de Gobernanza de Datos: avances y brechas

    República Dominicana en el Diálogo de Gobernanza de Datos: avances y brechas

    República Dominicana participó en un Diálogo de Gobernanza de Datos donde presentó sus avances institucionales e identificó oportunidades de mejora en la gestión pública del dato. El ejercicio, según se informó, sirvió como diagnóstico comparativo entre pares regionales y marca un punto de inflexión para el país en su trayectoria hacia un marco formal de gobernanza.

    La gobernanza de datos en el sector público no es un concepto abstracto: se trata de definir quién es responsable de cada dato, bajo qué reglas se recopila y comparte, y qué mecanismos garantizan su calidad e integridad a lo largo del tiempo. En el marco de los diálogos regionales —espacios promovidos por organismos multilaterales para que los Estados intercambien experiencias y se evalúen contra estándares comunes—, República Dominicana expuso tanto lo que ya tiene construido como lo que aún le falta consolidar.

    Qué presentó República Dominicana y qué reveló el diagnóstico

    Según se informó, la delegación dominicana expuso avances en la articulación de instancias de coordinación interinstitucional para el manejo de datos gubernamentales. Entre los logros destacados figuran iniciativas de digitalización de registros y esfuerzos por estandarizar formatos de datos entre organismos del Estado. Sin embargo, el propio ejercicio de diálogo dejó en evidencia brechas persistentes: ausencia de un catálogo de datos oficial, falta de roles formalizados de data stewardship en las entidades públicas, y marcos de calidad del dato que aún operan de manera ad hoc.

    Este tipo de diagnóstico se alinea con la metodología del DAMA-DMBOK, que estructura la gobernanza de datos en once áreas de conocimiento —desde la arquitectura hasta la seguridad y la calidad— y permite a los países o instituciones identificar en qué nivel de madurez se encuentran en cada dimensión. El reconocimiento explícito de oportunidades, más que de déficits, sugiere que República Dominicana adoptó en el diálogo un enfoque de madurez progresiva antes que de cumplimiento estricto.

    Por qué los diálogos regionales importan más allá del protocolo diplomático

    Los espacios de diálogo de gobernanza de datos entre Estados tienen una función técnica concreta: fuerzan a los gobiernos a traducir sus capacidades reales en indicadores comparables. En América Latina, donde la mayoría de los países carece de una ley específica de gobernanza de datos del sector público, estos foros funcionan como sustitutos parciales de los marcos regulatorios. Colombia avanza con su Política Nacional de Explotación de Datos (CONPES 3920), Chile opera bajo el impulso de su Agenda de Transformación Digital, y Brasil consolida su ecosistema alrededor de la Lei Geral de Proteção de Dados (LGPD) con creciente presión sobre el sector público para que gestione datos con trazabilidad y accountability.

    República Dominicana, que cuenta con la Ley 172-13 de Protección de Datos Personales —una de las más antiguas de la región, aunque con actualización pendiente—, enfrenta el desafío de articular esa normativa de privacidad con una capa superior de gobernanza que regule cómo el Estado clasifica, comparte e interopera datos entre sus propias instituciones. El diálogo expuso justamente esa tensión: tener legislación de privacidad no equivale a tener gobernanza de datos.

    Cuándo aplica este modelo de diálogo — y cuándo no

    Los diálogos de gobernanza de datos son útiles cuando un país se encuentra en las fases iniciales o intermedias de madurez institucional y necesita benchmarking externo para priorizar inversiones. Son menos eficaces cuando no existe un mandato político claro detrás de los compromisos que se asumen en esos foros: sin autoridad central con poder de coordinación —un Chief Data Officer nacional o una agencia equivalente—, los diagnósticos quedan en papel. El modelo funciona mejor cuando los resultados del diálogo alimentan planes de acción con responsables nominados, presupuesto asignado y plazos concretos.

    En el contexto caribeño y centroamericano, República Dominicana tiene la oportunidad de posicionarse como referente subregional si convierte las oportunidades identificadas en este diálogo en una hoja de ruta pública. Eso requiere, como mínimo, formalizar la figura del data steward en al menos los ministerios con mayor volumen de datos ciudadanos —salud, hacienda, registros civiles— y establecer un inventario de activos de datos con nivel de clasificación y propietario asignado.

    El eslabón que conecta el diálogo con la acción: ownership y catálogo

    La brecha más frecuente que revelan estos ejercicios comparativos no es tecnológica sino organizacional: los datos existen, pero nadie es formalmente responsable de su calidad. Sin un marco de data ownership —siguiendo el enfoque Non-Invasive Data Governance de Bob Seiner, que asigna responsabilidades a quienes ya usan los datos en lugar de crear estructuras paralelas—, los avances técnicos quedan desconectados de la rendición de cuentas. Un catálogo de datos gubernamental, aunque sea básico, es el primer artefacto que transforma el diálogo en gestión.

    Los países que convierten sus brechas en hojas de ruta con nombres y fechas avanzan; los que las dejan como “oportunidades identificadas” vuelven al próximo diálogo con el mismo diagnóstico. El texto completo de los compromisos asumidos por República Dominicana en este diálogo —incluyendo plazos y responsables— debería ser de acceso público para que el ejercicio tenga valor real de accountability.

  • Progress adquiere Domo: qué implica para la gobernanza de datos en LATAM

    Progress adquiere Domo: qué implica para la gobernanza de datos en LATAM

    Progress Software anunció la adquisición de Domo, la plataforma de business intelligence y analítica en la nube, en un movimiento que reordena el mercado de gobernanza de datos e inteligencia artificial para empresas en América Latina. La operación consolida capacidades de integración de datos, catálogo y analítica bajo un mismo stack, con consecuencias directas para los equipos de gobierno de datos que ya operan con alguna de las dos plataformas.

    Progress Software es conocida en la región por sus herramientas de integración y gestión de datos —entre ellas DataDirect y Telerik—, mientras que Domo construyó su posicionamiento sobre la promesa de llevar datos operacionales a ejecutivos sin intermediación técnica. La combinación apunta a cerrar la brecha que habitualmente existe entre la capa de gobierno de datos (ownership, calidad, linaje) y la capa de consumo (dashboards, alertas, decisiones). Para un Chief Data Officer, eso es tanto una oportunidad como un riesgo de consolidación de proveedor.

    Qué cambia en el stack de gobierno de datos

    Desde la perspectiva del DAMA-DMBOK, la gobernanza de datos abarca once áreas de conocimiento que van desde la arquitectura hasta la calidad y la seguridad. Históricamente, Domo ocupaba el extremo de consumo —visualización y distribución de métricas—, mientras que Progress cubría la integración y el movimiento de datos. La adquisición sugiere una estrategia para construir un pipeline end-to-end: ingestión, transformación, catálogo semántico y presentación, todo bajo un contrato de licenciamiento único. Para los equipos que trabajan con frameworks del EDM Council (DCAM o CDMC), esto implica revisar las capabilities de data integration (nivel 3 del CDMC) y data publication (nivel 5), que ahora podrían cubrirse con un solo proveedor en lugar de dos.

    El componente de inteligencia artificial también es relevante. Domo ha desarrollado funcionalidades de IA generativa para análisis conversacional —el usuario pregunta en lenguaje natural y el sistema devuelve gráficos o cifras—, una tendencia que Progress quiere amplificar dentro de su ecosistema. El desafío de gobernanza aquí es concreto: cuando un modelo de lenguaje genera una respuesta basada en datos operacionales, ¿quién es el data steward responsable de validar que el output sea correcto y no derive de datos mal clasificados o desactualizados?

    Cuándo aplica este cambio — y cuándo no

    La adquisición es directamente relevante para organizaciones que ya usan Domo como plataforma de BI corporativa y tienen contrato activo con Progress para integración. En ese escenario, los equipos de gobierno de datos deben anticipar cambios en los Service Level Agreements, en los esquemas de licenciamiento y en la hoja de ruta de producto —decisiones que suelen tomarse sin consultar al área de datos. Para empresas que no usan ninguna de las dos plataformas, el impacto inmediato es menor, aunque el movimiento señala una tendencia de consolidación que también está ocurriendo con Salesforce-Tableau, Microsoft-Fabric y Google-Looker: el mercado de BI independiente se contrae. Las organizaciones con estrategia multi-vendor deberán revisar si ese modelo sigue siendo sostenible en un ecosistema cada vez más integrado verticalmente.

    El ángulo regulatorio en Argentina, Brasil y México

    Para las empresas de la región, la consolidación de plataformas de datos en manos de un único proveedor estadounidense tiene implicancias que van más allá de la tecnología. En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) exige que las organizaciones mantengan registros de las operaciones de tratamiento y puedan identificar qué datos personales residen en qué sistema. Si Domo almacena o procesa datos de clientes o empleados brasileños, la migración o integración de plataformas post-adquisición activa obligaciones de actualización del Registro de Operações de Tratamento y, potencialmente, nuevas cláusulas contractuales con el operador. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) supervisa el cumplimiento de la Ley 25.326; los responsables de datos deben notificar cambios en los encargados de tratamiento cuando estos involucran transferencia internacional. En México, la LFPDPPP impone obligaciones similares de aviso de privacidad actualizado ante cambios en subencargados. El CDO no puede tratar esta adquisición como un tema puramente de IT.

    Cuatro decisiones concretas que no pueden esperar

    • Auditar el inventario de datos que reside en Domo: qué datasets contienen datos personales, bajo qué base legal y con qué controles de acceso activos.
    • Revisar los contratos de Data Processing Agreement (DPA) vigentes con Domo y verificar si la adquisición por Progress activa cláusulas de cambio de control que requieran consentimiento del cliente.
    • Identificar al data steward responsable de cada dominio de datos expuesto en Domo y confirmar que el linaje (data lineage) hacia las fuentes originales esté documentado en el catálogo corporativo, independientemente del proveedor.
    • Evaluar la estrategia de IA conversacional de la plataforma combinada: si el nuevo stack va a permitir que usuarios de negocio interroguen datos en lenguaje natural, se necesitan políticas de uso aceptable y controles de calidad de output antes del despliegue.

    El marco Non-Invasive Data Governance de Bob Seiner es útil aquí: la gobernanza efectiva no depende de qué herramienta usa el negocio, sino de que los roles, responsabilidades y políticas estén definidos por encima del stack tecnológico. Una adquisición cambia el proveedor; no cambia la necesidad de ownership claro sobre cada dato crítico.

    Las consolidaciones de plataformas BI aceleran una pregunta que muchos CDOs de la región todavía no respondieron: ¿qué datos críticos del negocio existen únicamente dentro de un SaaS de tercero, sin linaje documentado ni ownership formal? Esa respuesta no puede depender de que llegue un comunicado de adquisición para buscarse.

  • Ciberataques potenciados por IA: identidad y gobernanza de datos como primera línea

    Ciberataques potenciados por IA: identidad y gobernanza de datos como primera línea

    Cuando los atacantes usan inteligencia artificial para automatizar y escalar sus ofensivas, la gobernanza de datos deja de ser un asunto de cumplimiento y se convierte en infraestructura defensiva. Así lo plantea Microsoft en su análisis más reciente sobre el panorama de amenazas: sin saber qué datos existen, dónde están y quién puede acceder a ellos, cualquier control de seguridad queda ciego.

    La premisa es operativa antes que filosófica. Los modelos de lenguaje y las herramientas de automatización ofensiva permiten a los atacantes enumerar superficies de ataque, generar credenciales falsas y moverse lateralmente a una velocidad que supera la capacidad de respuesta humana. En ese escenario, la identidad —quién es quién en el ecosistema digital de una organización— y el gobierno del dato —qué activos existen y bajo qué reglas se accede a ellos— se convierten en los dos vectores que determinan si una intrusión escala o se contiene.

    Por qué la gobernanza de datos es el problema de seguridad que nadie nombra

    Un ataque potenciado por IA no inventa vulnerabilidades nuevas: las explota más rápido. Si una organización no tiene un catálogo de datos actualizado —es decir, no sabe qué información sensible existe ni quién tiene permisos sobre ella—, un atacante que compromete una cuenta privilegiada puede exfiltrar activos críticos antes de que se active cualquier alerta. La gobernanza de datos, en términos de DAMA-DMBOK, es exactamente lo que evita ese punto ciego: clasificación de activos, definición de ownership, control de acceso basado en el nivel de sensibilidad del dato y data lineage que permita rastrear qué se movió y hacia dónde.

    El data steward —el rol responsable de definir reglas de uso y calidad sobre dominios específicos de datos— cobra aquí una función que trasciende el compliance. En un entorno donde la IA ofensiva puede identificar en segundos qué tablas de una base de datos contienen registros de alto valor, tener un steward que mantenga actualizada la clasificación de sensibilidad es una decisión de gestión de riesgo, no una formalidad de auditoría.

    Identidad: el vector que amplifica o neutraliza el daño

    El control de identidad es el complemento necesario. Sin una arquitectura robusta de gestión de identidades y accesos —incluyendo privilegios mínimos, revisiones periódicas de permisos y detección de anomalías de comportamiento—, la mejor clasificación de datos no impide que una cuenta comprometida acceda a activos que no debería tocar. La IA ofensiva es especialmente efectiva en el abuso de identidades: puede generar campañas de phishing hiperpersonalizadas, explotar tokens de sesión y escalar privilegios de formas que los sistemas de detección convencionales no anticipan.

    El vínculo entre identidad y gobierno del dato no es metafórico. En términos del marco DCAM del EDM Council, la capability de seguridad y privacidad del dato requiere que los controles de acceso estén alineados con la clasificación del activo: un dato catalogado como “restringido” debería activar automáticamente políticas de acceso más estrictas en el directorio de identidades. Cuando esa alineación no existe, la brecha entre lo que dice el catálogo y lo que permite el sistema de permisos es exactamente el espacio que un atacante con IA puede explotar.

    Cuándo aplica / cuándo NO este enfoque

    Este marco de defensa es relevante para organizaciones que ya tienen una superficie de datos significativa —múltiples fuentes, entornos híbridos, usuarios con distintos niveles de privilegio— y que enfrentan adversarios con capacidad de automatizar reconocimiento y movimiento lateral. No es la solución prioritaria para una pequeña empresa con un único sistema central y accesos controlados manualmente: en ese caso, los controles de identidad básicos y el backup seguro siguen siendo la inversión más eficiente. La gobernanza de datos como vector defensivo escala en importancia directamente con la complejidad del ecosistema de datos y el valor de los activos expuestos.

    El estado del arte en América Latina: regulación que empuja en la misma dirección

    En la región, varios marcos regulatorios están generando presión convergente. La Lei Geral de Proteção de Dados (LGPD) de Brasil exige que las organizaciones implementen medidas técnicas y administrativas para proteger datos personales, lo que incluye controles de acceso y clasificación. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) ha actualizado sus lineamientos de seguridad exigiendo que los responsables de tratamiento documenten las medidas adoptadas para proteger los datos que tratan. En México, la LFPDPPP —y su reglamento— requieren que los encargados del tratamiento mantengan un inventario de los datos que procesan. Ninguna de estas normas menciona explícitamente “catálogo de datos” o “data steward”, pero todas presuponen capacidades de gobierno del dato para poder cumplirse. Las organizaciones que construyen esas capacidades para defenderse de ataques de IA también están, en paralelo, avanzando en su madurez regulatoria.

    Para un Chief Data Officer o Data Governance Manager en la región, la conversación sobre ciberataques potenciados por IA es una oportunidad concreta: inventariar qué activos de datos de alto valor existen y si su clasificación está actualizada en el catálogo corporativo; revisar si los permisos de acceso en el directorio de identidades son consistentes con esa clasificación; y validar si los data stewards de cada dominio tienen visibilidad sobre quién accede a los datos bajo su ownership. Esas tres acciones son el punto de partida mínimo recomendado por frameworks como CDMC del EDM Council para organizaciones que operan en entornos de amenaza elevada.

    Para profundizar en los principios de clasificación y control de acceso a datos, el DAMA-DMBOK 2 (capítulos de Data Security y Data Governance) y el marco CDMC del EDM Council ofrecen las guías de referencia más completas disponibles para equipos de gobierno de datos en entornos corporativos.

  • Data lineage en reportes financieros: el problema que nadie ve hasta que es tarde

    Data lineage en reportes financieros: el problema que nadie ve hasta que es tarde

    Los reportes financieros de las organizaciones son tan confiables como el linaje de los datos que los alimentan. Cuando ese linaje está roto o es invisible, los equipos de finanzas y auditoría firman cifras que nadie puede rastrear hasta su origen, y las consecuencias —regulatorias y reputacionales— son predecibles.

    El data lineage, o linaje de datos, es el registro completo de cómo un dato nació, qué transformaciones sufrió y adónde fue a parar. En el contexto de reportes financieros, eso significa poder responder con precisión: este número que aparece en el balance, ¿vino de qué sistema fuente?, ¿pasó por qué reglas de transformación?, ¿quién lo aprobó y cuándo? Sin esa trazabilidad, el proceso de cierre contable y los informes regulatorios descansan sobre suposiciones.

    Por qué los reportes financieros son el caso de prueba más exigente del linaje

    Las áreas de finanzas suelen operar con datos que atraviesan docenas de sistemas: ERPs, plataformas de consolidación, hojas de cálculo intermedias, herramientas de BI y, cada vez más, pipelines de datos en la nube. Cada salto entre sistemas es un punto donde el linaje puede romperse. El problema no es solo técnico: cuando un analista no puede explicar de dónde viene un número, el auditor externo tampoco puede validarlo, y el regulador —si pide explicaciones— encontrará un vacío.

    Según el marco DAMA-DMBOK, el linaje es una de las capacidades nucleares de la gestión de metadatos. Sin embargo, en la práctica, muchas organizaciones documentan el linaje de sus datos maestros o de sus dimensiones analíticas, pero descuidan el linaje de los datos financieros que alimentan reportes de cierre, informes a reguladores bancarios o estados contables auditados. La brecha entre ambos mundos —data governance y finanzas— es el punto ciego más frecuente.

    El riesgo concreto: restatements, multas y pérdida de control del CDO

    Cuando una compañía debe corregir un reporte financiero ya publicado —lo que en el mercado de capitales se conoce como restatement— una causa frecuente es la incapacidad de rastrear errores de transformación en los datos. Sin linaje documentado, encontrar el origen del error puede tomar semanas. Con linaje automatizado, puede tomar horas. La diferencia entre ambos escenarios, en términos de exposición regulatoria y costo operativo, es sustancial.

    En el ecosistema de data governance, el EDM Council —a través de su marco CDMC (Cloud Data Management Capabilities)— incluye explícitamente la trazabilidad de datos financieros como parte de las capacidades de nivel avanzado. Las organizaciones que operan sin esa trazabilidad pueden cumplir con los primeros niveles del framework pero quedarán expuestas en auditorías de madurez más exigentes.

    Cuándo aplica y cuándo no: alcance real del linaje en finanzas

    El linaje de datos financieros es crítico cuando: (a) la organización reporta a reguladores que exigen explicabilidad de las cifras —bancos centrales, comisiones de valores, superintendencias—; (b) los estados contables son auditados externamente y los auditores solicitan evidencia de los procesos de transformación; (c) la compañía opera en jurisdicciones con regímenes de reporte obligatorio de datos financieros, como los bancos sujetos a normas de Basilea III/IV. No aplica de la misma manera —aunque sí importa— en organizaciones pequeñas con sistemas únicos donde la transformación es mínima y la trazabilidad es evidente por diseño.

    • Reportes regulatorios ante bancos centrales o superintendencias
    • Consolidaciones contables que atraviesan múltiples entidades jurídicas
    • Auditorías externas que requieren evidencia de la cadena de transformación
    • Procesos de cierre mensual o trimestral con datos de múltiples fuentes

    El estado del linaje financiero en América Latina: brechas regulatorias concretas

    En la región, los reguladores financieros han avanzado en exigir calidad de datos pero rara vez prescriben lineaje como tal. El Banco Central de Brasil (BCB) ha incorporado en sus circulares de reporte requisitos de trazabilidad para datos de crédito e información prudencial, lo que obliga a los bancos a documentar el origen de sus cifras. En Argentina, la Comunicación A 8073 del BCRA establece controles sobre la integridad de la información financiera reportada, aunque sin un marco explícito de linaje. En México, la CNBV exige consistencia entre los estados financieros enviados y los datos internos, pero la responsabilidad de demostrar esa consistencia recae en las instituciones sin una metodología estándar definida.

    El resultado es una brecha común en la región: las instituciones financieras cumplen con los requerimientos de reporte, pero sin la infraestructura de linaje que permitiría responder a una pregunta de auditoría profunda en tiempo razonable. Muchos equipos de datos en bancos latinoamericanos documentan el linaje en herramientas como Collibra, Alation o Apache Atlas solo para los dominios de datos maestros, dejando fuera los pipelines de transformación financiera.

    Tres pasos concretos para cerrar la brecha

    El primer paso es mapear los dominios de datos que alimentan cada reporte regulatorio o estado contable, identificando los sistemas fuente, las reglas de transformación y los data stewards responsables de cada etapa. El segundo es extender el catálogo de datos existente —si lo hay— para incluir los pipelines financieros, no solo los dominios analíticos. El tercero, y frecuentemente el más difícil, es establecer acuerdos de ownership entre las áreas de datos y las de finanzas: el linaje financiero no puede ser responsabilidad exclusiva de IT ni de contabilidad; requiere un modelo de stewardship compartido, alineado con lo que Bob Seiner describe como Non-Invasive Data Governance: institucionalizar la responsabilidad sin crear una burocracia paralela.

    Los marcos DAMA-DMBOK y CDMC del EDM Council ofrecen guías detalladas sobre implementación de linaje en contextos regulados; las circulares del BCB y las comunicaciones del BCRA son el punto de partida para entender qué nivel de trazabilidad exige cada regulador en la región.

  • Primero los datos, después la IA: la apuesta de Brookfield Residential

    Primero los datos, después la IA: la apuesta de Brookfield Residential

    Brookfield Residential decidió invertir en gobernanza de datos antes de escalar cualquier iniciativa de inteligencia artificial. La lógica detrás de esa decisión es simple pero poco frecuente en el sector: sin datos confiables, los modelos de IA reproducen el caos a mayor velocidad.

    La industria inmobiliaria no suele ser la primera en aparecer en conversaciones sobre madurez de datos. Sin embargo, la desarrolladora canadiense Brookfield Residential —con operaciones en Estados Unidos y Canadá— se convirtió en un caso de referencia al anteponer la construcción de una base de gobernanza sólida a la adopción de herramientas de inteligencia artificial. La decisión, según se informó, surgió de reconocer que sus datos operativos —precios, inventarios, ciclos de construcción, perfiles de compradores— estaban fragmentados entre sistemas que no hablaban entre sí.

    Qué significa “poner la gobernanza primero” en la práctica

    En términos operativos, anteponer la gobernanza implica resolver tres problemas antes de entrenar o desplegar cualquier modelo: definir quién es el propietario del dato (data ownership), establecer definiciones compartidas entre áreas (data definitions o business glossary), y mapear el recorrido del dato desde su origen hasta su uso analítico (data lineage). Estos tres pilares son la base del marco DAMA-DMBOK, que organiza las capacidades de gestión de datos en once áreas de conocimiento. Sin ellos, una organización que alimenta un modelo de IA con datos de baja calidad no obtiene predicciones mejores: obtiene predicciones incorrectas con mayor velocidad y apariencia de precisión.

    En el caso de Brookfield Residential, según se informó, el trabajo incluyó la designación de data stewards por área de negocio —roles responsables de asegurar la calidad y el uso apropiado del dato dentro de su dominio— y la implementación de un catálogo de datos que permitiera a los equipos encontrar, entender y confiar en los activos de información disponibles. Este tipo de arquitectura de gobierno es lo que el EDM Council denomina una capability central dentro del CDMC (Cloud Data Management Capabilities), específicamente en el dominio de Data Governance and Accountability.

    Cuándo aplica este enfoque —y cuándo no

    La secuencia “gobernanza antes que IA” aplica con mayor fuerza cuando los datos están dispersos en silos operacionales heterogéneos, cuando los equipos de negocio tienen definiciones distintas para los mismos conceptos (¿qué es una “unidad vendida”? ¿en qué momento del proceso?), o cuando existe una brecha significativa entre los datos históricos disponibles y los que realmente se necesitan para entrenar un modelo útil. No aplica de la misma forma en organizaciones que ya tienen un data warehouse consolidado, pipelines de calidad implementados y ownership claro: en esos casos, la gobernanza puede avanzar en paralelo con los primeros pilotos de IA sin riesgo sistémico.

    El error más frecuente no es desplegar IA prematuramente, sino subestimar cuánto trabajo previo de gobernanza se necesita. Muchas organizaciones descubren ese déficit recién cuando el modelo falla —o peor, cuando falla silenciosamente y nadie lo detecta a tiempo.

    América Latina: el mismo desafío, menor tiempo para resolverlo

    En la región, el caso de Brookfield Residential resuena especialmente en sectores como real estate, banca y retail, donde la adopción de herramientas de IA generativa avanza más rápido que la madurez de los datos subyacentes. En Brasil, las instituciones financieras supervisadas por el Banco Central operan bajo la Resolução CMN 4.893/2021, que exige políticas de gestión de datos como parte del marco de gestión de riesgos —lo que obliga, al menos formalmente, a tener ownership y calidad de datos definidos antes de automatizar decisiones crediticias con modelos. En Argentina, la Comunicación A 8073 del BCRA establece requisitos similares para el gobierno de datos en entidades financieras, aunque la certificación formal bajo marcos como CDMC sigue siendo prácticamente inexistente en la industria local.

    En México, Colombia y Chile, las normativas sectoriales de finanzas y salud empujan en la misma dirección, pero fuera de esos sectores regulados la presión para formalizar la gobernanza antes de escalar IA es todavía baja. El riesgo real es que las organizaciones latinoamericanas lleguen tarde no al tren de la IA, sino a la infraestructura de datos que la hace funcionar.

    Lo que un CDO puede hacer esta semana con este caso

    El caso de Brookfield Residential ofrece una palanca concreta para quienes lideran datos en organizaciones que ya tienen proyectos de IA en agenda. Primero, auditar el estado de los datos que alimentarán esos modelos: ¿tienen un propietario identificado? ¿hay una definición acordada entre negocio y tecnología? ¿el lineage está documentado? Segundo, usar ese diagnóstico como argumento ante el comité ejecutivo para priorizar inversión en gobernanza —no como obstáculo a la IA, sino como condición de su éxito. Tercero, si la organización ya tiene un catálogo de datos, verificar que los datasets candidatos para IA estén efectivamente catalogados y con metadata de calidad actualizada. La secuencia de Brookfield no es conservadora: es la que minimiza el costo de retrabajo cuando el modelo ya está en producción.

    Para profundizar en los fundamentos de este enfoque, el DAMA-DMBOK (segunda edición) y el framework CDMC del EDM Council son los puntos de partida más citados por equipos de gobierno de datos a nivel global.

  • Cloudflare lanza su plataforma de datos Basin: sin egress fees, datos en el borde

    Cloudflare lanza su plataforma de datos Basin: sin egress fees, datos en el borde

    Cloudflare presentó Basin, una plataforma serverless de gestión de datos que promete eliminar —o al menos reducir significativamente— los cargos por egress de datos. La propuesta apunta directamente a uno de los costos ocultos más debatidos en arquitecturas cloud modernas: el precio de mover datos entre capas y proveedores.

    Basin se posiciona como una solución de gestión de datos sin servidor construida sobre la infraestructura de red de Cloudflare. La idea central es que los datos vivan cerca del borde de la red —donde se procesan las solicitudes— en lugar de residir en regiones centralizadas de cómputo. Esto, según la compañía, permite reducir la latencia y, sobre todo, evitar los cargos por transferencia de datos salientes que los grandes proveedores de nube —AWS, Azure, Google Cloud— aplican como parte estándar de su modelo de negocio.

    Egress fees: el costo que no aparece en el presupuesto inicial

    Los cargos por egress —la tarifa que cobra un proveedor de nube cada vez que los datos salen de su infraestructura— son uno de los mecanismos de lock-in más efectivos del mercado. Una organización puede ingresar datos a AWS o Google Cloud prácticamente sin costo, pero moverlos hacia otro entorno, hacia un sistema on-premise o hacia un socio externo puede generar facturas inesperadamente elevadas. En América Latina, donde muchas organizaciones operan con infraestructura híbrida y proveedores múltiples, este costo tiene un impacto desproporcionado respecto a los presupuestos de TI disponibles.

    Cloudflare no es el primero en atacar este modelo: su propia oferta de almacenamiento R2 ya eliminó los egress fees para datos almacenados en esa capa. Basin extiende esa lógica al plano de la gestión de datos como plataforma integrada, aunque la promesa de “sin egress fees” viene acompañada de un “sort of” —es decir, con matices que dependerán del caso de uso concreto y de los límites del plan contratado.

    Qué incluye Basin y qué significa “serverless” en este contexto

    Una plataforma serverless de datos no significa que no existan servidores —significa que el cliente no los administra. La organización define su lógica de procesamiento y almacenamiento; la infraestructura escala automáticamente según demanda. Para equipos de datos sin una práctica robusta de infraestructura, esto reduce la carga operativa. Para equipos maduros, el interrogante habitual es si el nivel de control y observabilidad está a la altura de lo que ofrecen plataformas más establecidas. Según se informó, Basin integra capacidades de gestión de datos distribuidos sobre la red global de Cloudflare, aunque los detalles técnicos completos sobre soporte de motores SQL, integración con pipelines existentes y SLAs aún no estaban disponibles en el lanzamiento.

    Cuándo aplica Basin — y cuándo no

    Basin tiene sentido para organizaciones que ya operan sobre Workers, Pages u otros productos de Cloudflare, y que buscan una capa de datos cohesionada dentro del mismo ecosistema. También es relevante para casos de uso con distribución geográfica intensiva —CDN-first, APIs con usuarios en múltiples países, aplicaciones edge-native— donde el egress entre regiones es un factor de costo real. No aplica como reemplazo directo de un data warehouse analítico pesado (Snowflake, BigQuery, Redshift), ni para organizaciones con necesidades de procesamiento masivo OLAP o con modelos de gobernanza que requieren residencia estricta de datos en jurisdicciones específicas. En este último punto, los equipos legales y de cumplimiento en América Latina deberán verificar en qué nodos de la red de Cloudflare residirán efectivamente los datos, especialmente frente a requisitos de la LGPD brasileña (artículos 33 y 34 sobre transferencia internacional), la Ley 25.326 argentina o la Ley Estatutaria 1581 de Colombia.

    Residencia de datos y cumplimiento en América Latina

    La propuesta de Cloudflare de distribuir datos en el borde global plantea una tensión directa con los marcos regulatorios de protección de datos personales en la región. La LGPD de Brasil establece condiciones específicas para la transferencia internacional de datos personales; la Ley 25.326 de Argentina y su reglamentación exigen garantías equivalentes cuando los datos salen del país; Chile avanza con su nueva ley de protección de datos personales (Ley 21.719), que también contempla restricciones de transferencia. Para cualquier organización latinoamericana que evalúe Basin como plataforma de datos operativos —no solo estáticos— la pregunta de “¿en qué país físicamente residen mis datos?” no es opcional. Cloudflare ofrece controles de jurisdicción en algunos de sus productos, pero la verificación caso por caso es responsabilidad del responsable de tratamiento.

    Antes de migrar cargas de trabajo a Basin, un equipo de datos responsable debería mapear qué tipos de datos procesará la plataforma, identificar si incluye datos personales según la ley aplicable, y confirmar con Cloudflare qué garantías de residencia y transferencia ofrece para cada región de América Latina donde opera la organización. La referencia normativa de partida está en la documentación oficial de cada autoridad de control: ANPD (Brasil), AAIP (Argentina), SIC (Colombia) e INAI (México).