DataTrends LATAM

Etiqueta: Normativa

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

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

  • Gartner: la mala gestión de datos amenaza 6 de cada 10 proyectos de IA

    Gartner: la mala gestión de datos amenaza 6 de cada 10 proyectos de IA

    Seis de cada diez proyectos de inteligencia artificial fracasan o no alcanzan sus objetivos no por fallas en los modelos, sino por problemas en la gestión de los datos que los alimentan, según advirtió Gartner. La cifra pone en el centro del debate una capacidad que muchas organizaciones latinoamericanas todavía tratan como tarea pendiente: la gobernanza de datos.

    El diagnóstico de Gartner no es nuevo en su dirección, pero sí en su magnitud. Cuando una empresa decide implementar un modelo de lenguaje, un sistema de recomendación o cualquier herramienta de analítica avanzada, el supuesto implícito es que los datos de entrenamiento y operación son confiables, están bien catalogados y tienen un propietario claro. En la mayoría de las organizaciones de la región, ese supuesto es falso. Los datos llegan de silos desconectados, sin linaje trazable, con definiciones inconsistentes entre áreas y sin un data steward —responsable temático del dato— que garantice su calidad antes de que el modelo los consuma.

    Por qué el dato roto destruye al modelo, no al revés

    Un modelo de inteligencia artificial es, en términos operativos, una función matemática que generaliza patrones a partir de datos históricos. Si esos datos contienen duplicados, valores ausentes sin criterio de imputación, o categorías definidas de forma distinta en cada sistema de origen, el modelo aprende esos errores y los amplifica. El fenómeno tiene nombre en la industria: garbage in, garbage out. Lo que Gartner señala es que ese “garbage” no es un accidente técnico: es el resultado predecible de organizaciones que invierten en infraestructura de IA antes de haber resuelto su arquitectura de gobierno del dato.

    El marco DAMA-DMBOK identifica once áreas de conocimiento en gobernanza de datos —desde la arquitectura y el modelado hasta la calidad, la seguridad y el ciclo de vida del dato—. Las organizaciones que lanzan proyectos de IA sin haber madurado al menos las áreas de calidad de datos, catálogo y linaje están operando sin los cimientos mínimos. El EDM Council, a través de su certificación CDMC (Cloud Data Management Capabilities), también establece que la trazabilidad del dato —saber de dónde viene, cómo fue transformado y quién lo aprobó para uso analítico— es una capacidad de nivel básico, no avanzado.

    Cuándo aplica esta advertencia / cuándo NO

    La advertencia de Gartner aplica directamente a proyectos de IA que operan sobre datos internos de la organización: modelos predictivos de riesgo crediticio, sistemas de detección de fraude, motores de recomendación, analítica de clientes o automatización de procesos con datos históricos. El riesgo es más alto cuando los datos provienen de múltiples sistemas legados con escasa integración. En cambio, el problema es menos crítico —aunque no inexistente— en implementaciones que usan modelos fundacionales pre-entrenados con datos propietarios externos, donde el riesgo de dato roto se desplaza al proveedor del modelo. Tampoco aplica de la misma forma a proyectos de IA que operan sobre datos sintéticos o en entornos de laboratorio sin implicancias operativas.

    El estado de la gobernanza de datos en América Latina

    En la región, la brecha es estructural. Muchos bancos colombianos y mexicanos que reportan ante la Superintendencia Financiera de Colombia o la CNBV operan con modelos de scoring crediticio cuya trazabilidad de datos es, en el mejor caso, parcial. En Brasil, la LGPD (Lei Geral de Proteção de Dados, Ley 13.709/2018) obliga a las empresas a documentar el tratamiento de datos personales, lo que ha empujado a algunas organizaciones a construir catálogos de datos reactivamente —para cumplir con la ley— sin integrarlos a una estrategia de gobernanza más amplia. En Argentina, la Ley 25.326 de Protección de Datos Personales está en proceso de modernización, y el debate sobre su reforma incluye requisitos de documentación de tratamientos que, si se aprueban, tendrán el mismo efecto de forzar estructuras mínimas de gobierno del dato.

    La paradoja regional es que la presión regulatoria de privacidad está creando, como efecto secundario, las condiciones para una gobernanza de datos más sólida. Las organizaciones que construyen sus registros de actividades de tratamiento (RAT) para cumplir con LGPD o con la normativa de la AAIP argentina están, sin saberlo, construyendo un inventario de datos que puede convertirse en el punto de partida de un catálogo de datos institucional.

    Tres capacidades que un CDO debe tener antes de aprobar un proyecto de IA

    Si el número de Gartner tiene alguna utilidad práctica, es como criterio de evaluación previa. Antes de aprobar el presupuesto de un proyecto de IA, un Chief Data Officer debería poder responder afirmativamente a tres preguntas concretas: primero, si los datos de entrenamiento tienen un data steward identificado que pueda certificar su calidad y origen; segundo, si existe linaje documentado que permita rastrear cada campo crítico desde su fuente hasta el modelo; y tercero, si hay un proceso de monitoreo de calidad de datos en producción, no solo en el momento del entrenamiento inicial. Si alguna de esas tres respuestas es negativa, el proyecto tiene una probabilidad estadísticamente documentada —según Gartner— de estar entre el 60% que no cumplirá sus objetivos. La decisión de avanzar de todas formas es legítima, pero debe tomarse con esa información sobre la mesa.

    Para profundizar en los marcos de madurez aplicables, el DAMA-DMBOK2 y el framework CDMC del EDM Council son los estándares de referencia que cualquier equipo de gobernanza puede usar como línea de base antes de comprometer recursos en IA.

  • GRC crea consejo para fortalecer la gobernanza de datos de emisiones

    GRC crea consejo para fortalecer la gobernanza de datos de emisiones

    El Global Regulatory Council (GRC) anunció la creación de un consejo dedicado a la gobernanza de datos de emisiones en el sector marítimo, con el objetivo de estandarizar la recolección, calidad y reporte de información climática a escala global. La iniciativa responde a una brecha estructural que los reguladores y operadores del sector ya no pueden ignorar: los datos sobre emisiones que circulan entre armadores, puertos y autoridades nacionales son, con frecuencia, inconsistentes, incompletos o incomparables.

    La gobernanza de datos de emisiones es el conjunto de políticas, roles, procesos y controles que determinan cómo se captura, valida, almacena y reporta la información sobre gases de efecto invernadero generados por operaciones —en este caso, principalmente por buques y flotas comerciales. Sin una capa de gobierno clara sobre esos datos, las declaraciones de descarbonización se vuelven inauditables: una empresa puede reportar reducciones que ningún tercero puede verificar de forma independiente.

    Por qué el sector marítimo necesita un consejo específico para datos de emisiones

    El transporte marítimo mueve aproximadamente el 80% del comercio mundial y representa, según estimaciones de la Organización Marítima Internacional (OMI), cerca del 2,9% de las emisiones globales de CO₂. La fragmentación regulatoria es intensa: conviven el sistema EU MRV (Monitoring, Reporting and Verification) de la Unión Europea, el sistema IMO DCS (Data Collection System) y marcos nacionales que en muchos casos no son interoperables. El resultado es que un mismo buque puede reportar datos de consumo de combustible bajo tres esquemas distintos con metodologías incompatibles, generando inconsistencias que distorsionan los inventarios de emisiones sectoriales. El nuevo consejo del GRC apunta, según se informó, a crear criterios comunes de definición, recolección y auditoría de datos que puedan funcionar como capa transversal sobre esos regímenes existentes.

    Mecanismo: qué hace concretamente un consejo de gobernanza de datos en este contexto

    Un órgano de este tipo opera, en la práctica, como un comité de data stewardship sectorial. Sus funciones típicas incluyen la definición de un glosario común (¿qué se entiende exactamente por “emisión verificada” versus “emisión estimada”?), el establecimiento de reglas de ownership sobre los datos a lo largo de la cadena —quién es responsable del dato desde el sensor en sala de máquinas hasta el registro en la plataforma de reporte—, y la validación de metodologías de cálculo. Bajo el marco DAMA-DMBOK, esto equivale a activar las disciplinas de Calidad de Datos y Gestión de Metadatos con alcance interorganizacional, lo que es considerablemente más complejo que hacerlo dentro de una sola empresa porque implica acordar estándares entre actores con incentivos distintos: armadores, navieras, clasificadoras y reguladores.

    Cuándo aplica este modelo de gobernanza / cuándo NO

    Este enfoque de consejo sectorial es pertinente cuando el problema de calidad de datos no puede resolverse dentro de una sola organización porque los datos cruzan fronteras organizacionales antes de ser usados para decisiones regulatorias o comerciales. Aplica en sectores con múltiples actores interdependientes: marítimo, energía, cadenas de suministro, salud pública. No aplica —o aplica de forma muy limitada— cuando el problema es interno: si los datos de emisiones son capturados y reportados por una sola empresa bajo un único marco regulatorio, la solución es un programa interno de calidad de datos con un data steward designado, no un consejo interinstitucional. La distinción importa porque los consejos sectoriales tienen costos de coordinación altos y tienden a avanzar lentamente; usarlos para problemas que pueden resolverse internamente es un error de diseño frecuente.

    La perspectiva de América Latina: puertos y flotas bajo marcos de reporte disímiles

    Para los países latinoamericanos con actividad portuaria significativa —Brasil, México, Chile, Panamá, Argentina— la iniciativa del GRC tiene implicancias directas. Las flotas que hacen escala en puertos europeos ya están sujetas al EU MRV; las que operan exclusivamente en rutas regionales quedan bajo el IMO DCS y las normativas nacionales, que en la mayoría de los casos carecen de requisitos de verificación independiente de los datos. En Brasil, la ANTAQ (Agência Nacional de Transportes Aquaviários) regula el sector pero no ha establecido aún un esquema de data governance para emisiones equiparable al EU MRV. En Argentina, la Subsecretaría de Puertos y Vías Navegables tampoco cuenta con un marco estandarizado de recolección de datos de emisiones para la flota fluvial y de cabotaje. Eso significa que operadores latinoamericanos que quieran acceder a mercados o financiamiento verde en los próximos años tendrán que adaptar sus sistemas de datos a estándares que se están definiendo hoy en foros como el que impulsa el GRC, sin haber participado activamente en su diseño.

    Para quienes administran datos en organizaciones del sector marítimo o de logística regional, el movimiento del GRC es una señal de que los estándares de reporte de emisiones van a converger —y que el costo de no tener una arquitectura de datos de emisiones auditables hoy será, en pocos años, el costo de rehacerla bajo presión regulatoria. La referencia para profundizar es el marco de reporte del IMO DCS y la regulación EU MRV (Reglamento UE 2015/757), ambos disponibles en los sitios oficiales de la OMI y la Comisión Europea.

  • Automejora recursiva de IA: por qué el salto explosivo podría llegar más tarde

    Automejora recursiva de IA: por qué el salto explosivo podría llegar más tarde

    La promesa de que la inteligencia artificial se mejorará a sí misma con mínima supervisión humana —lo que la literatura técnica llama automejora recursiva— enfrenta obstáculos concretos que los pronósticos más optimistas tienden a subestimar. Según un análisis publicado por MIT Technology Review, ese salto explosivo podría no llegar tan pronto como sugieren las proyecciones más difundidas del sector.

    La automejora recursiva describe un proceso en el que un sistema de inteligencia artificial es capaz de reescribir su propio código, generar datos sintéticos para su propio entrenamiento y optimizar el hardware sobre el que opera, todo ello sin intervención humana relevante. Los modelos de lenguaje de gran escala (LLMs) ya realizan algunas de estas tareas de forma parcial: escriben código funcional, producen datos sintéticos y participan en la optimización de arquitecturas de chips. El debate no es si estas capacidades existen, sino si pueden encadenarse de forma autónoma y acumulativa hasta producir un ciclo de mejora sostenida.

    Qué requiere realmente el ciclo de automejora

    Para que la automejora recursiva funcione como la describen sus defensores, no basta con que un modelo genere código: ese código debe mejorar al propio modelo de forma medible, y esa mejora debe poder retroalimentarse en ciclos sucesivos sin degradación ni pérdida de alineación. Cada uno de esos pasos introduce fricciones que los benchmarks actuales no logran capturar con precisión. Los sistemas de evaluación que los modelos usan para medir su propio progreso son, en muchos casos, construidos por los mismos modelos, lo que introduce sesgos de autovalidación difíciles de detectar desde afuera.

    A esto se suma el problema del compute: cada iteración de mejora exige más capacidad de cómputo, más datos de calidad y más tiempo de ingeniería humana para verificar que el resultado es efectivamente mejor y no solo diferente. La curva de rendimientos puede volverse decreciente mucho antes del punto de inflexión que los optimistas anticipan.

    Cuándo aplica el concepto y cuándo no

    La automejora recursiva aplica, en sentido estricto, cuando un sistema modifica sus propios parámetros o arquitectura de forma autónoma y verifica que el cambio produce ganancias reales en tareas relevantes. No aplica cuando un modelo simplemente genera código que un ingeniero luego revisa, integra y evalúa: ese proceso sigue siendo asistido por humanos, no autónomo. Tampoco aplica cuando los “avances” son mejoras en benchmarks diseñados por el mismo equipo que entrena el modelo, sin validación independiente. La distinción importa porque buena parte de las afirmaciones actuales del sector cae en esta segunda categoría.

    El marco regulatorio de la UE ya anticipa este escenario

    El AI Act de la Unión Europea, vigente desde agosto de 2024 en sus disposiciones generales, contempla explícitamente los sistemas de IA con capacidad de auto-modificación como una categoría que requiere evaluaciones de conformidad reforzadas. El artículo 9 del AI Act exige que los sistemas de alto riesgo cuenten con sistemas de gestión de riesgos capaces de actualizarse ante comportamientos nuevos o no anticipados. Si un modelo puede reescribirse a sí mismo, ese requisito se vuelve técnicamente complejo de cumplir: ¿quién certifica la versión modificada?

    En América Latina, ningún marco regulatorio vigente aborda todavía la automejora recursiva de forma explícita. El proyecto de ley de inteligencia artificial en Brasil, en discusión en el Congreso durante 2025 y 2026, establece obligaciones de transparencia y evaluación de impacto para sistemas de IA de alto riesgo, pero no define umbrales técnicos específicos para sistemas auto-modificables. En Argentina, la Secretaría de Innovación Pública publicó lineamientos de IA en 2023 que priorizan el uso responsable, sin cubrir escenarios de autonomía avanzada. La brecha regulatoria es real y creciente.

    Qué implica esto para quienes toman decisiones sobre adopción de IA

    La narrativa del “despegue inminente” tiene consecuencias prácticas: organizaciones que planifican estrategias de IA asumiendo que los modelos serán radicalmente más capaces en 12 o 18 meses pueden sobredimensionar inversiones o posponer decisiones de governance bajo la premisa de que “todo cambiará pronto”. El análisis de MIT Technology Review sugiere que ese horizonte es más incierto de lo que los titulares indican. Para los equipos de gobierno de datos y las áreas legales que evalúan contratos con proveedores de IA, esto tiene una consecuencia directa: las cláusulas de actualización automática de modelos y las garantías de comportamiento estable cobran mayor relevancia cuando no se puede predecir con certeza cuándo ni cómo un modelo evolucionará.

    El debate sobre automejora recursiva no es solo técnico: es un debate sobre cuánto riesgo se externaliza hacia sistemas que nadie puede auditar completamente. En ese contexto, la supervisión humana no es un obstáculo a superar; es, por ahora, el único mecanismo de verificación disponible.

    El análisis completo de MIT Technology Review está disponible en technologyreview.com; para el marco normativo aplicable en la UE, el texto del AI Act puede consultarse en el Diario Oficial de la Unión Europea (Reglamento 2024/1689).

  • Gobernanza de datos en salud: por qué los registros clínicos exigen un marco propio

    Gobernanza de datos en salud: por qué los registros clínicos exigen un marco propio

    Los datos de salud son la categoría más sensible que gestiona cualquier organización, y los marcos genéricos de gobernanza de datos rara vez alcanzan para protegerlos y aprovecharlos al mismo tiempo. La gobernanza de datos clínicos requiere controles específicos sobre calidad, acceso, linaje y consentimiento que van más allá de las políticas corporativas estándar.

    Cuando un hospital o una aseguradora habla de “dato de paciente”, está hablando de información que puede determinar un diagnóstico, condicionar una cobertura o alimentar un modelo predictivo de riesgo. Ese dato no es equivalente a un registro de cliente en un CRM: tiene ciclos de vida que duran décadas, múltiples custodios simultáneos —médico tratante, institución, laboratorio, pagador— y restricciones de uso que emanan tanto de la ética clínica como del derecho. Sin una arquitectura de gobernanza diseñada para esa complejidad, el dato clínico se vuelve un pasivo antes que un activo.

    Por qué el dato clínico rompe los modelos de gobernanza convencionales

    Un framework como DAMA-DMBOK define las disciplinas de gobernanza —calidad, seguridad, arquitectura, metadatos— de forma transversal a industrias. Pero en salud esas disciplinas se cargan con requisitos adicionales que no aparecen en ningún otro sector: el consentimiento informado como condición de tratamiento de datos, la obligación de conservar ciertos registros por plazos fijados por norma (en muchos países, entre cinco y diez años como mínimo), y la necesidad de auditar no solo quién accedió al dato sino con qué propósito clínico lo hizo. El concepto de data stewardship —la asignación de responsabilidad sobre un dominio de datos a una persona o rol específico— adquiere en salud una dimensión ética que va más allá del cumplimiento técnico.

    A esto se suma la fragmentación. Un sistema de salud típico de mediana escala opera con al menos tres o cuatro sistemas de origen —historia clínica electrónica, laboratorio, imágenes, facturación— que rara vez comparten identificadores únicos de paciente, formatos de fecha o catálogos de códigos diagnósticos. Sin data lineage claro que trace el recorrido de cada registro desde su origen hasta su uso en un dashboard o un modelo, cualquier decisión clínica basada en datos acumula un riesgo silencioso de inconsistencia.

    Los tres controles que ningún programa de salud debería omitir

    Los programas de gobernanza de datos más maduros en el sector identifican al menos tres controles que funcionan como base mínima operativa:

    • Clasificación de datos con etiquetas de sensibilidad clínica: no todos los datos de un expediente tienen el mismo nivel de exposición. Diagnósticos de salud mental, información genética o datos de adicciones requieren controles de acceso más restrictivos que, por ejemplo, la fecha de una consulta de rutina. Un catálogo de datos sin clasificación granular impide aplicar controles diferenciados.
    • Gobierno del consentimiento como dato estructurado: el consentimiento del paciente no puede vivir solo como un PDF escaneado en el expediente. Para ser gobernable, debe estar registrado como metadato vinculado al dato que autoriza, con fecha, alcance y posibilidad de revocación trazable.
    • Data quality checks en punto de captura: los errores de calidad en salud —un peso en libras donde se esperan kilogramos, una fecha de nacimiento con año incorrecto— tienen consecuencias clínicas directas. Las reglas de calidad deben ejecutarse en el momento de ingreso del dato, no como limpieza posterior.

    El marco regulatorio en América Latina: obligaciones que ya están vigentes

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como datos sensibles y exige base legal específica para su tratamiento —consentimiento explícito o necesidad de tutela de la salud—, con obligaciones reforzadas de seguridad. La Autoridade Nacional de Proteção de Dados (ANPD) ha señalado al sector salud como prioritario en su agenda de fiscalización. En Argentina, la Ley 25.326 de Protección de los Datos Personales establece que los archivos de datos médicos solo pueden ser recolectados con finalidad directamente vinculada al tratamiento del paciente, y su acceso está restringido al personal sanitario bajo secreto profesional. La Agencia de Acceso a la Información Pública (AAIP) tiene competencia para sancionar el uso indebido de esos registros. En México, la LFPDPPP y su reglamento incluyen a los datos de salud en la categoría de datos sensibles, con requisitos de aviso de privacidad reforzado y consentimiento expreso. Ninguno de estos marcos es opcional: son el piso desde el que debe construirse cualquier programa de gobernanza en la región.

    La convergencia entre regulación de protección de datos y estándares de interoperabilidad clínica —como HL7 FHIR, que define cómo se intercambian registros entre sistemas— está presionando a los equipos de datos de salud a integrar capacidades de gobernanza que antes eran independientes. Un CDO de una red hospitalaria hoy necesita hablar tanto de ISO/IEC 27001 como de FHIR R4 y de los requisitos de la ANPD o la AAIP en la misma reunión.

    Cuándo aplica este tipo de gobernanza especializada y cuándo no

    La gobernanza de datos clínicos aplica a cualquier organización que trate datos de salud como parte de su operación principal: hospitales, clínicas, laboratorios, aseguradoras de salud, empresas de telemedicina y proveedores de tecnología que procesen esos datos por cuenta de instituciones médicas. No aplica —o aplica de forma marginal— a empresas que solo recopilan datos de bienestar general sin correlato clínico, como aplicaciones de fitness que no integran diagnósticos ni prescripciones. La distinción importa porque define si las obligaciones de las leyes de datos sensibles rigen plenamente o solo de forma parcial.

    Para los equipos que gestionan datos de salud en la región, el punto de partida concreto es auditar el catálogo de datos existente contra las categorías de sensibilidad definidas por la regulación local, identificar qué datos carecen de data steward asignado y qué consentimientos no tienen registro estructurado. Esas tres brechas son las que más frecuentemente generan exposición regulatoria y degradan la calidad de los datos disponibles para la toma de decisiones clínicas.

    El marco regulatorio latinoamericano ya establece obligaciones concretas sobre datos de salud; la pregunta para cada organización no es si debe cumplirlas, sino si su programa de gobernanza actual tiene la granularidad necesaria para hacerlo de forma demostrable ante una autoridad de control.

  • Nueva Jersey, tercer estado de EE.UU. en regular precios algorítmicos en 2026

    Nueva Jersey, tercer estado de EE.UU. en regular precios algorítmicos en 2026

    Nueva Jersey promulgó en 2026 una ley que regula la fijación de precios mediante algoritmos e inteligencia artificial, convirtiéndose en el tercer estado de Estados Unidos en hacerlo en lo que va del año. La aceleración legislativa en torno a los llamados “precios de vigilancia” —que usan datos personales para personalizar lo que cada consumidor paga— plantea un modelo regulatorio que ya empieza a resonar en los debates de América Latina.

    El 4 de agosto de 2026, el Comité Judicial del Senado de Estados Unidos celebró una audiencia titulada “Your Data, Their Profit: The Consumer Cost of AI Surveillance Pricing” —”Tus datos, su ganancia: el costo para el consumidor del pricing de vigilancia con IA”—, según informó el Future of Privacy Forum (FPF). La audiencia refleja el nivel de atención política que ha alcanzado una práctica hasta hace poco poco regulada: el uso de datos masivos de comportamiento, historial de compras, geolocalización y perfiles socioeconómicos para ajustar precios de forma individualizada y, en muchos casos, opaca.

    Qué regulan estos tres estados y qué tienen en común

    De acuerdo con el seguimiento legislativo del FPF, al menos tres estados —siendo Nueva Jersey el más reciente— aprobaron en 2026 normas que abordan la fijación de precios basada en datos. Si bien los textos varían, el núcleo regulatorio comparte elementos: obligaciones de transparencia hacia el consumidor sobre el uso de datos en la determinación del precio, restricciones al uso de categorías sensibles como raza, situación económica o historial médico para discriminar precios, y en algunos casos, derechos de oposición o acceso a la lógica de fijación. El término que unifica estas leyes en el debate político estadounidense es “surveillance pricing” —precios de vigilancia—, acuñado para describir sistemas que monitorizan el comportamiento del usuario en tiempo real para maximizar el precio que cada individuo está dispuesto a pagar.

    El fenómeno no es menor en términos de impacto económico. Sectores como retail, plataformas de transporte, turismo, seguros y servicios financieros llevan años aplicando variantes de esta lógica. La diferencia en 2026 es que los legisladores empezaron a tratarlo no solo como un problema de competencia o de mercado, sino como un asunto de derechos vinculado al uso de datos personales.

    Por qué el precio personalizado es también un asunto de datos personales

    La distinción importa porque define quién regula y con qué herramientas. Si el pricing algorítmico se encuadra como práctica anticompetitiva, corresponde a las autoridades de defensa de la competencia. Si se encuadra como tratamiento de datos personales, entran en juego las autoridades de protección de datos y los derechos de los titulares. En Estados Unidos, donde no existe una ley federal de privacidad general, la respuesta está siendo fragmentada y estatal. En América Latina, el panorama es distinto: la mayoría de los países cuenta con leyes generales de protección de datos personales que ya podrían alcanzar, al menos parcialmente, estas prácticas.

    En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) exige base legal para el tratamiento de datos personales y reconoce el derecho a la revisión de decisiones automatizadas que afecten intereses del titular —artículo 20—. El pricing personalizado basado en perfiles de comportamiento podría encuadrar en decisiones automatizadas sujetas a ese artículo, aunque la Autoridade Nacional de Proteção de Dados (ANPD) no ha emitido aún una guía específica sobre el tema. En Argentina, la Ley 25.326 de Protección de los Datos Personales contempla el derecho de acceso y la prohibición de decisiones que produzcan efectos jurídicos o significativos basadas exclusivamente en tratamientos automatizados —artículo 16—, aunque la regulación sobre IA y pricing no ha avanzado de forma explícita. En México, la LFPDPPP y su reglamento establecen bases para el tratamiento de datos con fines de perfilamiento comercial, y el INAI ha publicado criterios sobre decisiones automatizadas, aunque tampoco existe regulación sectorial específica sobre precios algorítmicos.

    Chile y Colombia: las regulaciones más avanzadas de la región en datos y IA

    Chile aprobó en 2024 la Ley 21.719 de Protección de Datos Personales, que moderniza el marco regulatorio e incorpora disposiciones sobre decisiones automatizadas con impacto significativo en los titulares. Su autoridad de control, el Consejo para la Transparencia en transición hacia la nueva Agencia de Protección de Datos, deberá definir en los próximos años si el pricing algorítmico cae bajo su ámbito. Colombia, por su parte, trabaja desde hace años con la Ley 1581 de 2012 y cuenta con la Superintendencia de Industria y Comercio (SIC) como autoridad dual de competencia y protección de datos, lo que la posiciona de forma única para abordar el pricing algorítmico desde ambos ángulos simultáneamente. Ninguno de los dos países ha iniciado, según información disponible, un proceso regulatorio específico sobre surveillance pricing, pero ambos tienen los marcos base para hacerlo.

    Qué sigue: el Senado de EE.UU. y la presión sobre plataformas globales

    La audiencia senatorial del 4 de agosto de 2026 sugiere que el debate no se quedará en el nivel estatal. Si el Congreso de Estados Unidos avanza hacia una regulación federal sobre pricing algorítmico, el impacto se extendería de forma directa a plataformas que operan en América Latina —desde marketplaces hasta servicios de streaming, turismo y fintech—. Las empresas con presencia regional que ajusten precios mediante algoritmos basados en datos de usuarios latinoamericanos deberían revisar si esas prácticas están cubiertas por sus políticas de privacidad actuales y si cumplen con las obligaciones de informar el tratamiento que habilita la personalización de precios.

    Los próximos hitos a monitorear incluyen: el avance de una posible iniciativa federal en Estados Unidos tras la audiencia senatorial, la emisión de guías por parte de la ANPD en Brasil sobre decisiones automatizadas con impacto económico, y el inicio de operaciones de la nueva Agencia de Protección de Datos de Chile, que deberá definir su agenda de supervisión sectorial.

    Nuestro análisis

    El movimiento legislativo en Estados Unidos tiene un valor señalizador claro: cuando tres estados actúan en simultáneo sobre el mismo fenómeno en un solo año, el riesgo de que la presión se traslade a nivel federal —y eventualmente a mercados interconectados— aumenta. Para las empresas que operan en América Latina, el riesgo regulatorio inmediato no viene de Washington sino de las autoridades locales. La LGPD ya tiene las herramientas para sancionar prácticas de perfilamiento sin base legal adecuada; la SIC colombiana combina competencia y privacidad en un mismo órgano; y Chile estrena autoridad con mandato moderno. Lo que falta en la región no es legislación base sino doctrina administrativa: guías, criterios y —eventualmente— sanciones que conviertan el marco general en una obligación operativa concreta para quienes usan datos para fijar precios.

    La pregunta que los equipos legales y de datos de la región deberían hacerse hoy no es si el surveillance pricing es legal en abstracto, sino si sus políticas de privacidad describen con precisión suficiente el tratamiento de datos que habilita esa personalización de precios —y si esa descripción sobreviviría un requerimiento de información de la ANPD, la SIC o la futura Agencia chilena.

  • La caja negra del uso de IA: por qué no podemos verificar lo que dicen Anthropic y OpenAI

    La caja negra del uso de IA: por qué no podemos verificar lo que dicen Anthropic y OpenAI

    Anthropic y OpenAI publican reportes periódicos sobre cómo sus usuarios utilizan Claude y ChatGPT, pero investigadores en inteligencia artificial advierten que esos datos son curados por las propias empresas: no existe fuente independiente que los corrobore. La opacidad sobre los patrones reales de uso tiene implicancias directas para cualquier intento de regular estos sistemas.

    Cada vez que una compañía de IA publica estadísticas de uso, el mensaje implícito es tranquilizador: los usuarios adoptan la tecnología para tareas productivas, creativas o educativas. Pero ese relato lo construyen las mismas empresas con los datos que deciden divulgar. Anka Reuel, candidata doctoral en el Stanford Trustworthy AI Research, lo sintetiza con precisión: “No existe una fuente independiente para corroborarlo”. Ese vacío no es un detalle metodológico menor — es una falla estructural en la gobernanza de los sistemas de inteligencia artificial más usados del mundo.

    Autorregulación sin auditoría: el modelo actual de divulgación

    El mecanismo de divulgación vigente en la industria funciona de manera simple: las empresas recopilan datos masivos sobre interacciones de sus plataformas, seleccionan los hallazgos que consideran relevantes o favorables, y los publican bajo la forma de reportes de transparencia o estudios de uso. No hay un tercero que acceda a los datos brutos, no hay protocolo estandarizado de reporte, y no hay obligación legal — en la mayoría de las jurisdicciones — de revelar métricas específicas sobre comportamiento de usuarios. El resultado es que el campo de estudio sobre el impacto real de la IA en la sociedad depende, paradójicamente, de la buena voluntad de los actores más interesados en que esa narrativa sea positiva.

    El problema se profundiza porque los usos que no se reportan pueden ser los más relevantes desde el punto de vista de riesgo: generación de desinformación, asistencia en tareas con consecuencias legales o médicas sin supervisión profesional, o patrones de dependencia cognitiva. Sin acceso a datos desagregados y auditados, los investigadores deben construir sus propios estudios con muestras pequeñas, encuestas autoreportadas o experimentos de laboratorio que difícilmente capturan el comportamiento real a escala.

    Cuándo esta opacidad viola un marco normativo — y cuándo no

    La ausencia de datos verificables sobre uso de IA no es ilegal en la mayoría de los países, pero entra en tensión creciente con marcos regulatorios que exigen transparencia. El AI Act de la Unión Europea, vigente desde agosto de 2024, impone obligaciones de documentación técnica y registros de sistemas de IA de alto riesgo, y establece que los modelos de propósito general con impacto sistémico deben someterse a evaluaciones independientes. Sin embargo, la definición de qué datos de uso deben compartirse con reguladores — y en qué formato — sigue siendo objeto de negociación técnica en los actos delegados que la Comisión Europea todavía está terminando de redactar.

    El AI Act no aplica directamente en América Latina, pero fija el estándar de referencia al que varios países de la región miran para construir sus propios marcos. En Brasil, el Proyecto de Ley 2.338/2023 — conocido como el PL de IA — incluye disposiciones sobre transparencia y auditoría de sistemas automatizados de alto impacto, aunque en sus versiones más recientes el alcance de las obligaciones de divulgación de datos de uso quedó acotado frente al texto original. En Argentina, la Estrategia Nacional de Inteligencia Artificial no establece obligaciones de reporte para proveedores de modelos fundacionales. Chile y Colombia avanzan con marcos voluntarios que, por definición, reproducen el mismo problema: las empresas reportan lo que quieren.

    Por qué los datos de uso son centrales para la regulación efectiva

    El debate sobre qué regular en IA depende, en gran medida, de entender qué hacen realmente los usuarios con estos sistemas. Si la mayoría de las interacciones de alto riesgo ocurren en dominios que las empresas no reportan — salud, asesoramiento legal informal, contenido generado para influir en decisiones electorales — entonces los marcos regulatorios que se construyan sin ese conocimiento serán, en el mejor caso, incompletos. Los reguladores latinoamericanos que hoy diseñan normativas sobre IA están trabajando con una información base que proviene casi exclusivamente de las empresas que buscan operar en sus mercados.

    La situación tiene un paralelo con los primeros años de las redes sociales, cuando Facebook y Twitter controlaban los datos sobre propagación de contenido hasta que escándalos como Cambridge Analytica forzaron una apertura parcial y reluctante. La diferencia es que los modelos de lenguaje generan interacciones más íntimas, más difíciles de categorizar, y con consecuencias potencialmente más directas sobre decisiones individuales. Esperar un escándalo equivalente para obtener acceso a datos independientes sería una estrategia regulatoria costosa.

    Alternativas que los reguladores pueden exigir ahora

    La investigación independiente sobre uso de IA no requiere necesariamente acceso a datos en bruto con información personal de los usuarios — lo que crearía tensiones legítimas con marcos de protección de datos como la LGPD brasileña o la Ley 25.326 argentina. Existen mecanismos intermedios que algunos reguladores ya contemplan:

    • Auditorías de terceros con acceso a datos anonimizados y agregados, bajo acuerdos de confidencialidad con supervisión regulatoria.
    • Obligación de reportar categorías de uso definidas por la autoridad competente, no por la empresa.
    • Registros de incidentes con impacto en usuarios que las plataformas deben notificar a organismos como el MCTIC en Brasil o la AAIP en Argentina.
    • Habilitación de investigadores académicos acreditados para acceder a datos bajo entornos de análisis seguros, siguiendo el modelo del Digital Services Act europeo para plataformas muy grandes.

    Ninguno de estos mecanismos está completamente operativo en América Latina para sistemas de IA generativa. El PL 2.338/2023 de Brasil es el instrumento más avanzado en la región, pero su aprobación final y reglamentación todavía están pendientes al momento de esta publicación.

    Mientras los reportes de uso los sigan escribiendo solo quienes tienen interés en el resultado, cualquier política de IA que se base en ellos estará regulando el relato, no la tecnología.

  • Filtración de datos en Control Vehicular de Nuevo León: investigan ciberataque

    Filtración de datos en Control Vehicular de Nuevo León: investigan ciberataque

    Las autoridades de Nuevo León investigan una presunta filtración de datos en el sistema de Control Vehicular del estado, ocurrida según se informó como consecuencia de un ciberataque. El incidente podría haber comprometido información personal de titulares de registros vehiculares en la entidad.

    Según se informó el 12 de agosto de 2026, el caso fue detectado en el sistema estatal encargado del registro y control vehicular en Nuevo León. Las autoridades competentes iniciaron una investigación formal para determinar el alcance del acceso no autorizado, aunque al cierre de esta nota no se habían confirmado públicamente el volumen de registros afectados ni la identidad de los presuntos responsables. La información del incidente fue difundida por Heraldo de México.

    Datos confirmados y lo que aún falta establecer

    • Se investiga una presunta filtración en el sistema de Control Vehicular del estado de Nuevo León, México.
    • La causa sería un ciberataque, según se informó; el vector de intrusión no ha sido confirmado oficialmente.
    • Autoridades estatales abrieron una investigación formal sobre el incidente.
    • El número de registros expuestos, la naturaleza exacta de los datos comprometidos y la identidad de los atacantes permanecen sin confirmar.
    • No se ha emitido notificación pública a los titulares de los datos afectados hasta el momento de publicación.

    La LFPDPPP y la obligación de notificación en México

    El incidente activa obligaciones concretas bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y, en el ámbito público, bajo la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados (LGPDPPSO), que rige a entidades gubernamentales como el control vehicular estatal. Esta última obliga a los responsables a notificar a los titulares afectados cuando exista una vulneración de seguridad que pueda afectarles de forma significativa, sin dilación indebida. El Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) es la autoridad de control competente para supervisar el cumplimiento en el sector público federal, mientras que en el ámbito estatal intervienen los organismos garantes locales de Nuevo León.

    Los datos vehiculares —que típicamente incluyen nombre completo, domicilio, RFC, número de placa y datos del vehículo— constituyen información personal susceptible de uso en fraudes de identidad, clonación vehicular y esquemas de phishing dirigido. En regímenes como el brasileño, la Lei Geral de Proteção de Dados (LGPD) exige notificación a la Autoridade Nacional de Proteção de Dados (ANPD) en un plazo de 72 horas para incidentes de riesgo relevante. México no establece ese plazo de forma tan explícita para el sector público, lo que representa una brecha regulatoria que este caso vuelve a poner sobre la mesa.

    El próximo hito crítico es la emisión de un comunicado oficial por parte de las autoridades de Nuevo León que precise el volumen de registros afectados y los plazos de notificación a titulares, información que el INAI y el organismo garante estatal tienen facultad de requerir formalmente.

  • Hidrógeno natural subterráneo: qué es, cómo se forma y cuándo importa

    Hidrógeno natural subterráneo: qué es, cómo se forma y cuándo importa

    El hidrógeno natural —producido por reacciones geoquímicas en la corteza terrestre, sin intervención humana— está captando la atención de gobiernos, empresas energéticas e investigadores como posible fuente de combustible limpio. La pregunta que moviliza millones de dólares en exploración es cuánto hay realmente y si puede extraerse de forma económicamente viable.

    A diferencia del hidrógeno verde (producido por electrólisis con energía renovable) o del hidrógeno gris (derivado del gas natural), el hidrógeno geológico —también llamado hidrógeno blanco o hidrógeno nativo— se origina en procesos físico-químicos que ocurren a kilómetros de profundidad, sin costo energético humano. Su existencia no es nueva: geoquímicos como Barbara Sherwood Lollar llevan décadas encontrando trazas en minas profundas. Lo que cambió es el interés en escalarlo.

    Cómo se genera el hidrógeno en la corteza terrestre

    El mecanismo más documentado es la serpentinización: cuando el agua profunda entra en contacto con rocas ricas en hierro y magnesio —como la peridotita— se desencadena una reacción química que libera hidrógeno molecular (H₂). Este proceso ocurre especialmente en zonas de corteza oceánica y en los bordes tectónicos, pero también en formaciones continentales muy antiguas. En la mina Kidd Creek, en Ontario, el equipo de Sherwood Lollar encontró agua confinada por más de mil millones de años que contenía hidrógeno producido por ese mecanismo. Otra vía de generación es la radiolisis: la radiación emitida por elementos como uranio, torio y potasio rompe moléculas de agua y libera H₂. Ambas fuentes pueden coexistir en una misma formación geológica.

    Por qué es difícil cuantificar las reservas globales

    Estimar cuánto hidrógeno natural existe bajo tierra es metodológicamente complejo por al menos tres razones. Primero, el H₂ es una molécula pequeña y móvil que tiende a escapar hacia la superficie o a ser consumida por microorganismos antes de acumularse en concentraciones aprovechables. Segundo, los modelos geológicos tradicionales se calibraron para hidrocarburos, no para gases tan ligeros. Tercero, muchas de las formaciones más prometedoras —cratones precámbricos, dorsales oceánicas— están en zonas de acceso difícil o bajo jurisdicciones con baja capacidad exploratoria. La USGS y organismos europeos han comenzado a desarrollar marcos de cuantificación específicos, pero según se informó, las estimaciones publicadas hasta ahora varían en varios órdenes de magnitud.

    Cuándo aplica / cuándo NO como fuente energética

    El hidrógeno geológico es técnicamente viable como fuente energética cuando se dan condiciones simultáneas: concentración de H₂ superior al 10% en el gas extraído, profundidad manejable para la perforación comercial (generalmente menos de 3 km), ausencia de contaminantes que encarezcan la purificación, y un marco regulatorio que permita la extracción. Mali es hasta ahora el único caso documentado de producción comercial a pequeña escala, con un pozo que según se informó suministra electricidad a una comunidad rural. En cambio, el hidrógeno nativo NO es una solución cuando las concentraciones son traza (menores al 2%), cuando la formación geológica no garantiza flujo sostenido, o cuando el gas está mezclado con sulfuro de hidrógeno o metano en proporciones que hacen inviable la purificación. Tampoco reemplaza —al menos en el corto plazo— la escala que requieren industrias pesadas como el acero o el amoniaco.

    América Latina: crátones, rifts y un vacío regulatorio

    La región tiene formaciones geológicas de alto interés para la exploración de hidrógeno nativo. El Cratón Amazónico, que abarca partes de Brasil, Colombia, Venezuela y las Guayanas, comparte características litológicas con áreas donde se han detectado emisiones de H₂. La cuenca del Río de la Plata y sectores del escudo brasileño también presentan rocas ultramáficas susceptibles de serpentinización. En Brasil, Petrobras ha declarado interés exploratorio en hidrógeno geológico, aunque sin programas de perforación específicos confirmados públicamente. En Argentina, la Secretaría de Energía incluyó el hidrógeno natural en su mapa de recursos no convencionales emergentes, según se informó, sin que exista todavía un régimen de concesión diferenciado. Esto implica que, en la mayoría de los países de la región, la exploración de H₂ subterráneo quedaría encuadrada bajo los marcos de hidrocarburos existentes —como la Ley 17.319 en Argentina o la Ley del Petróleo en México— lo que genera incertidumbre sobre regalías, titularidad del recurso y obligaciones ambientales.

    El estado actual de la ciencia y los límites del entusiasmo

    La comunidad científica es cautelosa. Si bien hay consenso en que el hidrógeno geológico existe en cantidades significativas, la distancia entre “existe” y “es extraíble a escala industrial” sigue siendo grande. Los principales grupos de investigación —MIT, ETH Zúrich, Bureau de Recherches Géologiques et Minières de Francia— coinciden en que se necesita al menos una década de exploración sistemática antes de poder hablar de reservas probadas en el sentido que la industria energética da a ese término. El riesgo de sobreprometer es real: el ciclo de entusiasmo-decepción que vivió el shale en varios países latinoamericanos es un antecedente que los formuladores de política deberían tener presente.

    Para marcos regulatorios de referencia sobre clasificación de recursos de hidrógeno, el Sistema de Clasificación de Recursos de la ONU (UNFC) publicó en 2023 una guía específica para hidrógeno natural disponible en el sitio de la Comisión Económica para Europa de la ONU (UNECE).