Autor: Redacción

  • Gobernanza de datos con IA en minería: qué significa construir bases confiables

    Gobernanza de datos con IA en minería: qué significa construir bases confiables

    La industria minera genera volúmenes masivos de datos operacionales, geológicos y ambientales, y la incorporación de inteligencia artificial a esos flujos no simplifica el problema de gobernanza: lo amplifica. Para que los modelos de IA sean confiables en este sector, los cimientos de datos tienen que estarlo primero.

    La minería es uno de los sectores donde la calidad del dato tiene consecuencias físicas directas: una estimación de reservas mal modelada, un sensor de tolva con datos duplicados o una lectura ambiental sin linaje verificable pueden derivar en decisiones operativas de alto riesgo. Cuando se agrega IA encima de esa infraestructura —modelos predictivos de mantenimiento, optimización de procesos, análisis de variabilidad geológica— la deuda técnica de gobernanza se convierte en deuda de confiabilidad de negocio.

    Qué entiende la industria minera por “datos confiables”

    En el marco del DAMA-DMBOK, la confiabilidad del dato se sostiene sobre al menos cuatro dimensiones: exactitud, completitud, consistencia y linaje (data lineage). En minería, el linaje es especialmente crítico porque los datos recorren un camino largo —sensores IoT en campo, sistemas SCADA, plataformas MES, ERP y finalmente capas analíticas— y cada transformación representa un punto de pérdida de trazabilidad. Un dato que llega limpio a un dashboard puede haberse degradado en tres integraciones previas sin que ningún data steward lo haya detectado.

    El problema se agudiza cuando los modelos de IA consumen esos datos sin que exista un catálogo de datos (data catalog) actualizado que describa origen, frecuencia de actualización, propietario y nivel de calidad de cada dataset. Sin ese inventario, el modelo aprende patrones sobre información cuya confiabilidad nadie puede garantizar formalmente.

    Cuándo aplica un marco de gobernanza de IA / cuándo NO

    Un marco de gobernanza de IA en minería aplica cuando los modelos toman decisiones que afectan operaciones, seguridad o reportes regulatorios —por ejemplo, sistemas de detección de fallas en equipos críticos o modelos de predicción de calidad de mineral que alimentan contratos comerciales. No aplica —o aplica con menor urgencia— cuando la IA se usa en análisis exploratorios internos sin impacto en decisiones formales, aunque incluso allí el riesgo de acostumbrarse a datos de baja calidad es real.

    Tampoco es suficiente aplicar gobernanza de datos genérica. Las normativas ambientales y de seguridad minera en América Latina —como las exigencias de reporte del Servicio Nacional de Geología y Minería (SERNAGEOMIN) en Chile o los estándares de la Agencia Nacional de Minería (ANM) en Brasil— requieren que los datos reportados sean auditables. Si esos datos son generados o transformados por modelos de IA, la cadena de custodia debe estar documentada con precisión.

    Los tres pilares operativos que fallan con más frecuencia en minería

    • Ownership sin autoridad real: Es común que las compañías mineras designen data stewards por área (geología, operaciones, medio ambiente) pero sin mandato formal para rechazar datos de baja calidad que provienen de sistemas legados. El steward documenta el problema; nadie lo resuelve.
    • Linaje roto en integraciones campo-nube: Los sensores IoT en mina raramente cuentan con metadata estructurada desde origen. Cuando esos streams llegan a una plataforma cloud para entrenar modelos, el linaje ya es incompleto. El EDM Council (DCAM) identifica el linaje automatizado como una capability de nivel intermedio que pocas organizaciones industriales han alcanzado.
    • Ausencia de controles de calidad previos al entrenamiento: No existe, en la mayoría de operaciones mineras de la región, un proceso formal de data quality gate antes de que un dataset ingrese a un pipeline de entrenamiento de modelos. El dato llega, el modelo entrena, y los sesgos o errores se heredan silenciosamente.

    Minería en LATAM: regulación ambiental como driver de gobernanza

    En América Latina, la presión regulatoria ambiental está actuando —quizás antes que cualquier marco de IA— como catalizador involuntario de gobernanza de datos. En Chile, las empresas mineras que operan bajo resoluciones de calificación ambiental (RCA) deben reportar periódicamente indicadores de consumo hídrico, emisiones y relaves. Si esos indicadores son calculados mediante modelos automatizados, la auditabilidad del cálculo depende directamente de que exista linaje de datos verificable. En Perú, el Organismo de Evaluación y Fiscalización Ambiental (OEFA) tiene facultades de fiscalización que pueden alcanzar los sistemas de monitoreo digital. En ese contexto, la gobernanza de datos no es una práctica de madurez organizacional: es un requisito implícito de cumplimiento.

    Un CDO o Data Governance Manager en una operación minera latinoamericana debería revisar esta semana si los datasets que alimentan modelos de IA están incluidos en el catálogo corporativo, si tienen un data owner formalmente asignado con nombre y área, y si existe algún registro de las transformaciones aplicadas antes del entrenamiento. Si alguna de esas tres respuestas es negativa, el modelo que corre sobre esos datos no tiene bases confiables, independientemente de su performance técnica.

    Para profundizar en el marco de capacidades de gobernanza aplicable a este sector, el DCAM Assessment del EDM Council (edmcouncil.org) ofrece un punto de partida estructurado; en la región, SERNAGEOMIN y la ANM publican sus estándares de reporte en sus sitios oficiales y pueden usarse como ancla regulatoria para definir qué datos son auditables por obligación.

  • Robo de datos vinculado a un Estado: lo que exige la gobernanza de identidades

    Robo de datos vinculado a un Estado: lo que exige la gobernanza de identidades

    Un caso de robo cibernético con presunta vinculación estatal vuelve a poner sobre la mesa una brecha estructural que persiste en universidades, laboratorios y organismos públicos: los controles de identidad y la gobernanza de datos de investigación siguen siendo puntos débiles críticos frente a amenazas avanzadas. La firma Continuum GRC advirtió, según se informó el 20 de agosto de 2025, que este tipo de incidentes eleva el nivel de exigencia para los equipos de gobierno del dato.

    El caso, referenciado por Continuum GRC —proveedor especializado en cumplimiento normativo y gestión de riesgo—, ilustra cómo actores con recursos de nivel estatal explotan debilidades en la gestión de accesos privilegiados y en la clasificación de datos sensibles de investigación. Aunque los detalles forenses del incidente específico no fueron divulgados públicamente, la firma utilizó el caso como evidencia de que los marcos de gobernanza actuales en entidades de investigación no están diseñados para enfrentar adversarios sofisticados.

    Dos fallas de gobernanza que habilitan el robo: identidades y clasificación

    El patrón de ataque en incidentes de esta naturaleza combina, según se informó, dos vectores que son responsabilidad directa del gobierno del dato: la ausencia de controles robustos sobre identidades con acceso a activos de alto valor, y la falta de clasificación formal de los datos de investigación. Sin un catálogo actualizado que distinga qué datos son sensibles, quién es el data owner y qué permisos mínimos requiere cada rol, la detección de exfiltración resulta tardía o directamente imposible. En términos del DAMA-DMBOK, las capabilities de Data Security y Data Asset Management son las que fallan primero en estos escenarios, no la ciberseguridad perimetral.

    La gestión de identidades —en inglés, Identity and Access Management (IAM)— es un componente que suele quedar fuera del scope del CDO y recaer exclusivamente en TI o ciberseguridad. Este caso refuerza el argumento contrario: si el CDO no define las políticas de acceso basadas en la sensibilidad del dato, el equipo de IAM no tiene criterios precisos para implementarlas. El ownership del dato y el ownership del acceso deben estar alineados desde el modelo de gobernanza, no gestionarse en silos.

    En LATAM, universidades y organismos públicos concentran el riesgo sin marco formal

    En América Latina, la exposición es particularmente alta en el sector de investigación científica pública. Universidades nacionales de Argentina, Brasil y México manejan datos de proyectos financiados por organismos como CONICET, FAPESP o CONACYT, pero en su mayoría operan sin un programa formal de gobernanza de datos de investigación ni roles de data steward designados. En Argentina, la Ley 25.326 de Protección de Datos Personales exige medidas de seguridad para datos sensibles, pero no establece requisitos específicos de clasificación o linaje para datos de investigación no personal. En Brasil, la LGPD aplica cuando los datos de investigación contienen información personal, aunque la implementación en el sector académico es heterogénea. Esta brecha regulatoria deja un amplio margen de exposición que los actores externos —estatales o no— pueden aprovechar.

    • Definir o revisar la política de clasificación de datos de investigación, con categorías de sensibilidad explícitas (confidencial, restringido, público).
    • Mapear qué datos de investigación tienen un data owner asignado y cuáles quedan sin custodia formal — esto es el primer insumo para el CDO el lunes.
    • Coordinar con el equipo de IAM para que los permisos de acceso reflejen la clasificación del dato, no solo el rol organizacional del usuario.
    • Incorporar data lineage básico para activos de investigación críticos: saber quién accedió, desde dónde y cuándo es el mínimo de trazabilidad exigible.
    • Revisar si el marco de gobernanza vigente cubre datos de investigación o si están fuera de scope — en la mayoría de las organizaciones de la región, lo están.

    El EDM Council, a través del CDMC (Cloud Data Management Capabilities), incluye controles de acceso basados en sensibilidad como parte de las capabilities del nivel 2. Organizaciones latinoamericanas que trabajan con datos de investigación de alto valor deberían tomar ese marco como referencia mínima, incluso antes de apuntar a una certificación formal.

    El próximo incidente de este tipo no va a esperar a que la clasificación de datos esté terminada: las organizaciones de investigación en la región tienen que definir en las próximas semanas cuáles son sus activos de mayor exposición y quién responde por ellos.

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

  • LATAM Airlines confirma intrusión y posible exposición de datos de pasajeros

    LATAM Airlines confirma intrusión y posible exposición de datos de pasajeros

    LATAM Airlines confirmó una intrusión en sus sistemas informáticos y advirtió sobre la posible exposición de datos de pasajeros, según se informó el 20 de agosto de 2026. La aerolínea, con operaciones en Argentina, Brasil, Chile, Colombia, Ecuador y Perú, es uno de los transportistas aéreos más grandes de América Latina.

    La compañía informó públicamente sobre el incidente sin precisar, hasta el momento del anuncio, el volumen exacto de registros potencialmente comprometidos ni los tipos de datos personales afectados. Tampoco se confirmó si la intrusión derivó en una exfiltración efectiva de información o si el acceso no autorizado fue contenido antes de que los datos salieran de los sistemas internos. La notificación fue divulgada por medios uruguayos y regionales, lo que sugiere que el aviso alcanzó a pasajeros de múltiples países del cono sur.

    Datos confirmados al momento del cierre

    • Actor afectado: LATAM Airlines, aerolínea con presencia en al menos seis países de América del Sur.
    • Tipo de incidente: intrusión confirmada en sistemas internos, según comunicación de la propia empresa.
    • Datos en riesgo: información de pasajeros, naturaleza específica no confirmada al momento de la publicación.
    • Fecha del anuncio público: 20 de agosto de 2026.
    • Exfiltración: no confirmada al cierre de esta edición.

    Qué se sabe y qué falta confirmar sobre la brecha

    Lo que está confirmado es la intrusión y la comunicación pública de LATAM sobre el riesgo de exposición. Lo que aún no está verificado es el alcance real del compromiso: cuántos pasajeros se vieron afectados, en qué países, qué campos de datos estuvieron expuestos —si incluyen documentos de identidad, datos de pago, historial de vuelos o datos de contacto— y si existe un actor de amenaza identificado. Tampoco trascendió si las autoridades de protección de datos de los países donde LATAM opera fueron notificadas de forma formal.

    En términos regulatorios, el incidente activa obligaciones distintas según la jurisdicción. En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que la Autoridade Nacional de Proteção de Dados (ANPD) sea notificada en un plazo razonable cuando existe riesgo relevante para los titulares. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) puede requerir reporte bajo la Ley 25.326 y la Disposición AAIP 4/2019. Chile avanza en la aplicación de su nueva Ley 21.719 de protección de datos personales, vigente desde 2024, que también contempla notificación a la autoridad ante incidentes. En Colombia, la Superintendencia de Industria y Comercio (SIC) tiene competencia sobre el tratamiento de datos de clientes de aerolíneas que operen en el país.

    El próximo hito crítico es la notificación formal a las autoridades de control en cada jurisdicción: los plazos —que van de 72 horas en marcos más estrictos a términos más amplios en legislaciones nacionales— ya están corriendo desde el momento en que LATAM tomó conocimiento de la intrusión.

  • Franquiciado líder de Applebee’s confirma robo de datos sensibles por hackers

    Franquiciado líder de Applebee’s confirma robo de datos sensibles por hackers

    Apple American Group LLC, el mayor operador de franquicias de Applebee’s en Estados Unidos, confirmó una brecha de seguridad que resultó en el robo de datos personales altamente sensibles de sus empleados y/o clientes, incluyendo números de Seguro Social, información financiera, registros de salud e información biométrica. El número total de afectados no ha sido precisado, aunque presentaciones ante autoridades estatales confirman que el incidente involucra a múltiples jurisdicciones.

    La divulgación fue reportada el 20 de agosto de 2026 por el medio especializado DataBreaches.net. Según se informó, Apple American Group —que opera cientos de restaurantes Applebee’s en todo el territorio estadounidense— presentó notificaciones ante reguladores estatales como parte del proceso obligatorio de disclosure que impone la legislación de varios estados de EE.UU. ante brechas que afectan a residentes. El vector de ataque y el grupo responsable no han sido identificados públicamente hasta el momento.

    Datos confirmados del incidente en Apple American Group

    • Empresa afectada: Apple American Group LLC, franquiciado principal de Applebee’s en EE.UU.
    • Tipos de datos comprometidos: números de Seguro Social, datos financieros, registros de salud e información biométrica.
    • Cantidad de afectados: no divulgada públicamente; presentaciones ante registros estatales confirman el alcance multi-jurisdiccional.
    • Fecha de divulgación pública: 20 de agosto de 2026.
    • Atribución del ataque: no confirmada al cierre de esta nota.

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta ahora es que la brecha implicó exfiltración real de datos —no una mera exposición accidental— y que la categoría de información comprometida es de las más críticas en términos de riesgo residual para los afectados: la biometría y los registros de salud no pueden ser cambiados como una contraseña, y los números de Seguro Social habilitan fraudes de identidad de largo alcance. Lo que permanece sin confirmar incluye el número exacto de víctimas, la fecha en que ocurrió la intrusión inicial, si el ataque involucró ransomware, y si Apple American Group tiene presencia operativa o datos de empleados fuera de EE.UU. que pudieran ampliar el alcance geográfico del incidente.

    Para los equipos de privacidad en América Latina, el caso tiene relevancia indirecta pero concreta: cadenas de comida rápida y franquicias internacionales con operaciones en la región —incluyendo México, Brasil y Argentina— suelen compartir plataformas de gestión de recursos humanos y sistemas de nómina con sus casas matrices o con otros franquiciados de la misma red. Una brecha en un nodo puede comprometer datos de empleados latinoamericanos almacenados en servidores estadounidenses, lo que activa obligaciones de notificación bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) en México, la Lei Geral de Proteção de Dados (LGPD) en Brasil, o la Ley 25.326 en Argentina, según donde residan los titulares afectados. Ninguna de esas leyes exime a las empresas por el hecho de que el incidente haya ocurrido técnicamente fuera de sus fronteras.

    El próximo hito a monitorear es la publicación de las notificaciones individuales a los afectados, cuyo plazo varía por estado en EE.UU. pero que en varios casos no supera los 30 a 45 días desde la detección confirmada del incidente.

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

  • Bibliotecas de anuncios móviles filtran ubicación sin que los desarrolladores lo sepan

    Bibliotecas de anuncios móviles filtran ubicación sin que los desarrolladores lo sepan

    Un informe de la Electronic Frontier Foundation (EFF) revela que las bibliotecas de software publicitario integradas en aplicaciones móviles recolectan y filtran datos de ubicación de los usuarios, en muchos casos sin que los propios desarrolladores de esas apps sean conscientes de ello. El negocio de datos de localización mueve miles de millones de dólares al año y el mecanismo de fuga opera de forma silenciosa, embebido en el código que los developers incorporan para monetizar sus productos.

    Las ad libraries —bibliotecas de código de terceros que los desarrolladores insertan para mostrar publicidad— son el vector central del problema documentado por la EFF. Cuando un desarrollador integra una de estas bibliotecas, no siempre recibe documentación completa sobre qué datos recopila el SDK ni a qué servidores los envía. El resultado es que la app puede estar transmitiendo coordenadas GPS, identificadores de dispositivo y patrones de movimiento del usuario hacia redes publicitarias, sin que el equipo que construyó la aplicación haya tomado esa decisión de forma explícita.

    Por qué la ubicación es el dato más sensible del ecosistema publicitario

    La dirección de un hogar, los horarios de trabajo, las visitas a clínicas o lugares de culto, las rutas habituales: todo eso puede inferirse a partir de un historial de coordenadas. La EFF señala que la ubicación no es simplemente “un punto en un mapa”, sino una fuente de información íntima sobre la vida de una persona. Esta densidad informativa es exactamente lo que convierte al sector de datos de localización en un mercado multimillonario, donde brokers de datos compran, procesan y revenden trayectorias sin que el titular del dato haya prestado un consentimiento informado real.

    El reporte de la EFF también aborda las reformas recientemente anunciadas por Flock, empresa conocida por sus sistemas de reconocimiento de patentes vehiculares, y analiza legislación en el Senado de Estados Unidos que, según la organización, introduciría riesgos adicionales de privacidad bajo la sigla KOSA (Kids Online Safety Act). Aunque el foco geográfico del informe es el mercado estadounidense, los mecanismos técnicos descriptos operan en cualquier jurisdicción donde esas apps estén disponibles, lo que hace el hallazgo directamente relevante para usuarios latinoamericanos.

    Cuándo aplica esta vulnerabilidad y cuándo no

    El problema aplica cuando una aplicación móvil —independientemente de su categoría: juegos, utilidades, comercio electrónico— incorpora SDKs publicitarios de terceros sin auditar el comportamiento de recolección de datos de esos componentes. No aplica, en cambio, cuando el desarrollador construye su propio sistema de monetización sin dependencias externas, o cuando el SDK ha sido auditado y contractualmente limitado en su alcance de recolección. La distinción importa porque desplaza la responsabilidad: no es siempre una decisión deliberada del desarrollador, sino una consecuencia de integrar código de terceros sin due diligence de privacidad.

    El marco legal en América Latina frente a la recolección encubierta por SDKs

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que el tratamiento de datos personales —incluida la ubicación— cuente con una base legal válida y que el titular haya recibido información clara sobre los fines del tratamiento. La recolección silenciosa a través de una biblioteca de anuncios sin divulgación adecuada en la política de privacidad de la app constituiría, en principio, una violación a los artículos 7 y 9 de la ley, que regulan las hipótesis de tratamiento y la transparencia. La Autoridade Nacional de Proteção de Dados (ANPD) tiene competencia para investigar tanto al desarrollador de la app como, potencialmente, al operador del SDK como agente de tratamiento.

    En Argentina, la Ley 25.326 de Protección de los Datos Personales impone obligaciones de consentimiento informado y finalidad determinada. La Agencia de Acceso a la Información Pública (AAIP) ha avanzado en los últimos años en la regulación de aplicaciones móviles, aunque la capacidad de fiscalización sobre SDKs de origen extranjero sigue siendo un desafío práctico. México, a través del INAI y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), tiene un esquema similar: el responsable del tratamiento —en este caso el desarrollador de la app— responde por los datos que su producto recopila, incluso si la recolección la ejecuta un tercero integrado en el código.

    Qué implica esto para desarrolladores y equipos de compliance

    El hallazgo de la EFF refuerza una obligación que el marco regulatorio latinoamericano ya impone pero que pocas organizaciones implementan con rigor: el inventario y la auditoría de componentes de terceros antes de publicar una aplicación. Un desarrollador que integra una ad library sin revisar su política de datos no puede escudarse en el desconocimiento como eximente; la responsabilidad por el tratamiento de datos personales de los usuarios de su app recae sobre él como responsable ante la ley. Esto aplica con especial fuerza cuando la app tiene usuarios en jurisdicciones con regulación activa, como Brasil o Colombia —que cuenta con su propia Ley 1581 de 2012 y la Superintendencia de Industria y Comercio como autoridad de control.

    El informe completo de la EFF sobre bibliotecas de anuncios móviles está disponible en eff.org/deeplinks/2026/07/developers-beware-ad-libraries-betray-your-users-location-privacy y detalla los SDKs analizados y los mecanismos técnicos de exfiltración de ubicación identificados por el equipo de investigación de la organización.

    Que el código que filtra datos de ubicación sea invisible para el propio desarrollador no es un argumento legal en ninguna regulación de la región: la cadena de responsabilidad empieza en quien publica la app, no en quien escribió el SDK.

  • Por qué el 60% de los proyectos de IA fracasan antes de escalar

    Por qué el 60% de los proyectos de IA fracasan antes de escalar

    Seis de cada diez proyectos de inteligencia artificial no llegan a producción o no generan valor medible, según cifras atribuidas a Gartner. El denominador común no es la calidad del modelo ni el presupuesto: es la gestión de los datos que lo alimentan. Para los equipos de gobierno de datos en América Latina, ese dato no es una advertencia genérica — es un diagnóstico operativo.

    La estadística circula con fuerza en el debate técnico de 2025 y 2026: la mayoría de las iniciativas de inteligencia artificial corporativa colapsan en la fase de datos, no en la de algoritmos. Los data scientists pasan entre el 60% y el 80% de su tiempo limpiando, reconciliando y buscando datos — tiempo que no se invierte en modelado ni en generación de valor. Detrás de ese cuello de botella hay déficits concretos de gobernanza: ausencia de data lineage documentado, ownership sin asignar, catálogos incompletos o inexistentes, y clasificación de datos que nunca se actualizó desde que se implementó el data lake.

    El dato sin dueño: el origen más frecuente del fracaso

    El DAMA-DMBOK identifica el data ownership como una de las capacidades fundacionales de cualquier programa de gobierno de datos. En la práctica, muchas organizaciones latinoamericanas tienen datos distribuidos entre sistemas legados, plataformas cloud y hojas de cálculo departamentales sin que ningún data steward sea formalmente responsable de su calidad o actualización. Cuando un proyecto de IA intenta consumir esos datos, el equipo técnico descubre inconsistencias que nadie puede resolver porque nadie tiene autoridad para hacerlo. El modelo termina entrenándose con datos incorrectos o el proyecto se paraliza esperando validación.

    El EDM Council, en su marco DCAM (Data Capability Assessment Model), ubica el data ownership y la definición de roles de stewardship entre las capacidades de nivel 2 — las que deben estar consolidadas antes de avanzar a casos de uso analíticos avanzados. Sin embargo, según se informa en relevamientos del sector, una proporción significativa de empresas medianas y grandes de la región inicia proyectos de IA sin haber alcanzado ese nivel de madurez.

    Data lineage y catálogos: la infraestructura invisible que los proyectos IA exigen

    Un modelo de machine learning no puede ser auditado si no se puede rastrear el origen de cada feature que lo alimenta. El data lineage — la trazabilidad documentada de cómo un dato se transforma desde su fuente hasta el output del modelo — es un requisito operativo, no un nice-to-have. Sin él, cuando el modelo arroja un resultado sesgado o erróneo, el equipo no puede determinar si el problema está en la extracción, en la transformación, en el etiquetado o en el modelo mismo. El debugging se vuelve arqueología.

    Los catálogos de datos cumplen una función complementaria: hacen que los datos correctos sean encontrables. En organizaciones donde el catálogo no existe o está desactualizado, los equipos de datos duplican esfuerzos, consumen versiones distintas del mismo dataset o directamente trabajan con datos cuya definición de negocio nadie conoce. Herramientas como Collibra, Alation o soluciones open source como OpenMetadata resuelven el problema técnico, pero solo si hay un proceso de gobernanza que las alimente con metadata real y actualizada.

    En Brasil, Argentina y México: regulación que agrega presión al problema de datos

    El contexto regulatorio latinoamericano amplifica el riesgo. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige que las organizaciones puedan demostrar el propósito del tratamiento de datos personales — incluyendo los usados para entrenar modelos de IA. Si no hay catálogo ni lineage, esa demostración es imposible, y la Autoridade Nacional de Proteção de Dados (ANPD) puede considerar el tratamiento como no conforme. En Argentina, la Ley 25.326 y las disposiciones de la AAIP imponen obligaciones similares de accountability. En México, el INAI ha comenzado a preguntar, en el marco de auditorías, qué datos se usan en sistemas automatizados de toma de decisiones. Un proyecto de IA sin gobernanza de datos no solo fracasa técnicamente: puede generar exposición regulatoria.

    Cuándo aplica este diagnóstico — y cuándo no

    Este problema es especialmente agudo en proyectos de IA que consumen datos operacionales de múltiples sistemas (ERP, CRM, fuentes externas), en modelos que toman decisiones con impacto en clientes o empleados, y en organizaciones que no tienen un Chief Data Officer o un equivalente funcional con autoridad real sobre datos. No aplica de la misma manera a proyectos de IA que trabajan sobre datos sintéticos, datasets cerrados y bien documentados, o experimentos acotados en entornos sandbox sin dependencia de datos productivos.

    Un CDO que quiera evaluar la exposición de su organización puede partir de tres preguntas concretas: ¿Cada dataset crítico para proyectos de IA tiene un data steward nombrado y operativo? ¿Existe lineage documentado desde la fuente hasta el modelo para al menos los tres proyectos de mayor impacto? ¿El catálogo de datos fue actualizado en los últimos seis meses? Si alguna respuesta es negativa, el riesgo de fracaso no es teórico — es inminente. El punto de partida práctico puede ser una evaluación de madurez contra el CDMC (Certified Data Management Professional) del EDM Council o contra los dominios del DAMA-DMBOK, priorizando ownership, calidad y arquitectura de datos antes de aprobar nuevos presupuestos de IA.

    Para profundizar en los marcos de referencia, el DAMA-DMBOK está disponible en dama.org y el DCAM del EDM Council en edmcouncil.org — ambos con versiones de evaluación de madurez descargables que permiten un diagnóstico inicial sin costo.

  • Pruebas de conocimiento cero y verificación de edad: límites reales

    Pruebas de conocimiento cero y verificación de edad: límites reales

    Las pruebas de conocimiento cero (Zero-Knowledge Proofs o ZKPs) se presentan como la solución técnica definitiva para verificar la edad de los usuarios en línea sin comprometer su privacidad. La evidencia disponible indica que esa promesa es, cuando menos, prematura: los esquemas de verificación de edad basados en ZKPs son manipulables, vulnerables a ataques y concentran poder en puntos únicos de falla que representan un riesgo estructural para los derechos digitales.

    La verificación de edad en internet se ha convertido en una tendencia regulatoria global. Aproximadamente la mitad de los estados de EE.UU. ya cuentan con alguna ley de verificación de edad en línea, según se informó. A nivel federal estadounidense avanzan propuestas como la Kids Online Safety Act (KOSA) y la KIDS Act. La Unión Europea impulsa una aplicación centralizada de verificación de edad para antes de fin de año. Australia tiene vigente una restricción especialmente amplia. En este contexto, los ZKPs emergen como el argumento técnico favorito de quienes defienden estas regulaciones.

    Qué es un ZKP y cómo se aplica a la verificación de edad

    Una prueba de conocimiento cero es un protocolo criptográfico que permite a una parte demostrar que conoce o cumple cierta condición —por ejemplo, ser mayor de 18 años— sin revelar los datos subyacentes que lo acreditan. En teoría, un usuario podría probar su mayoría de edad ante una plataforma sin que esa plataforma conozca su nombre, fecha de nacimiento ni número de documento. El atractivo regulatorio es evidente: resolver la tensión entre protección infantil y privacidad con un solo mecanismo.

    El problema empieza en la infraestructura necesaria para que ese mecanismo funcione. Para que un ZKP sea válido, debe existir una fuente autoritativa que certifique el dato de base —la edad real de la persona— y emita la credencial criptográfica que el protocolo luego verifica sin revelar. Esa fuente puede ser una identidad digital nacional, un documento de identidad digital, o un sistema centralizado de atributos. Ahí es donde la promesa de privacidad comienza a erosionarse.

    Punto único de falla: el riesgo que los ZKPs no eliminan

    Crear una infraestructura centralizada de credenciales para el acceso a internet introduce, por definición, un punto único de falla. Si el sistema que emite las credenciales ZKP es comprometido, todos los usuarios quedan expuestos simultáneamente. Si el Estado o un actor privado controla esa infraestructura, también controla —de forma efectiva— quién puede acceder a qué contenidos en línea. Esto contradice la arquitectura descentralizada que históricamente hizo posible una internet abierta.

    Según se informó, los esquemas de verificación de edad basados en ZKPs ya mostraron ser manipulables mediante redes privadas virtuales (VPN) y vulnerables a ataques técnicos. Eso significa que no cumplen su objetivo declarado —mantener a los menores fuera de ciertos espacios— mientras sí generan los riesgos de privacidad y concentración de poder que sus defensores prometían evitar. Es la combinación más desfavorable posible desde una perspectiva de política pública.

    Cuándo aplica un ZKP y cuándo no alcanza

    Los ZKPs son herramientas criptográficas legítimas y útiles en contextos donde el dato a probar proviene de una fuente confiable preexistente, el sistema de emisión de credenciales está suficientemente descentralizado o protegido, y la verificación es puntual y no crea registros de navegación ni patrones de acceso. No son adecuados cuando la infraestructura subyacente centraliza el control de acceso a internet, cuando el dato de base —la edad— requiere vincular la identidad real del usuario a un sistema estatal o privado de certificación masiva, o cuando los incentivos de evasión son altos y los métodos de bypass son accesibles, como sucede con las VPN en el contexto de la verificación de edad.

    El debate regulatorio llega a América Latina con las mismas tensiones

    En la región, la verificación de edad online no tiene aún el peso normativo que exhibe en EE.UU., Australia o la UE, pero el debate ya está instalado. Brasil debate los alcances de la regulación de plataformas para menores en el marco de su Marco Civil da Internet y la Lei Geral de Proteção de Dados (LGPD), que clasifica los datos de niños y adolescentes como datos sensibles con protecciones reforzadas. Argentina, bajo la Ley 25.326 y las resoluciones de la Agencia de Acceso a la Información Pública (AAIP), tiene obligaciones similares. México, con la LFPDPPP y la supervisión del INAI, enfrenta presiones crecientes para definir estándares de verificación de edad en servicios digitales dirigidos a menores.

    El riesgo para la región es importar un modelo regulatorio que ya está mostrando fallas técnicas en las jurisdicciones que lo implementaron primero, sin adaptar los estándares a las condiciones locales de infraestructura de identidad digital —que en varios países latinoamericanos aún es fragmentada o de cobertura desigual. Una solución de verificación de edad que depende de un sistema nacional de identidad digital robusto funciona distinto en Alemania que en un país donde esa infraestructura cubre menos del 40% de la población adulta.

    Para profundizar en el marco técnico y jurídico de los ZKPs en verificación de edad, la Electronic Frontier Foundation mantiene actualizada su sección específica sobre leyes de verificación de edad en eff.org/age, con análisis de las principales propuestas legislativas y sus implicancias para los derechos digitales.