DataTrends LATAM

Blog

  • Agentes de IA y ciberataques: el vacío legal que Chile aún no cierra

    Agentes de IA y ciberataques: el vacío legal que Chile aún no cierra

    Los agentes de inteligencia artificial que operan de forma autónoma en redes corporativas abren un frente jurídico que Chile todavía no ha sabido cerrar: ¿quién responde cuando un sistema de IA es el vector o la víctima de un ciberataque? La pregunta no es teórica. A medida que la adopción de agentes de IA se acelera en el ecosistema empresarial chileno, el ordenamiento jurídico vigente muestra costuras que ninguna ley en tramitación resuelve por completo.

    Chile lleva años construyendo reputación como laboratorio regulatorio en América Latina. Fue el primer país de la región en incorporar la protección de datos a rango constitucional y lleva más de una década con un proyecto de ley de protección de datos personales en el Congreso —finalmente promulgado en 2024 como Ley 21.719, aunque con entrada en vigor escalonada. Sin embargo, la regulación específica sobre sistemas de inteligencia artificial autónomos sigue siendo fragmentaria: existen orientaciones sectoriales de la Comisión para el Mercado Financiero (CMF) y lineamientos del Ministerio de Ciencia, pero ningún marco horizontal que asigne responsabilidad cuando un agente de IA causa daño o es comprometido.

    Ley 21.719 y el silencio sobre sistemas autónomos

    La nueva ley de protección de datos personales chilena moderniza obligaciones de los responsables de tratamiento, incorpora el principio de responsabilidad proactiva y exige medidas técnicas y organizativas proporcionales al riesgo. Pero su redacción sigue pensada para un modelo donde hay un humano identificable detrás de cada decisión de tratamiento. Cuando un agente de IA toma decisiones de forma encadenada —consultando APIs, cruzando bases de datos, ejecutando acciones— la cadena de responsabilidad se difumina. ¿Es el desarrollador del modelo base, el integrador, el cliente empresarial o el propio operador de la infraestructura quien responde ante la Agencia de Protección de Datos Personales (APDP), el nuevo organismo que la ley crea?

    La ley establece un plazo de notificación de vulneraciones de datos, pero no aborda el escenario en que sea el propio agente de IA quien genere o amplifique una brecha —por ejemplo, al ser manipulado mediante prompt injection o al exfiltrar datos como efecto colateral de una instrucción mal formulada. Esos casos exigen interpretación creativa de artículos pensados para contextos de tratamiento tradicional.

    Prompt injection y responsabilidad civil: el caso que ningún tribunal chileno ha resuelto

    Los ataques de prompt injection —técnica mediante la cual un actor malicioso inyecta instrucciones en el contexto de un agente de IA para desviar su comportamiento— ya se documentan en entornos productivos a nivel global. Para un agente desplegado en una empresa chilena que maneja datos de clientes, un ataque exitoso de este tipo puede derivar en exfiltración de información, suplantación de identidad o ejecución de transacciones no autorizadas. Ninguna de esas consecuencias tiene hoy un régimen de responsabilidad civil explícito en el derecho chileno. El Código Civil permite argumentar responsabilidad extracontractual por culpa o dolo, pero la atribución en sistemas de IA multicapa es un ejercicio que los tribunales de la región no han desarrollado con profundidad.

    En contraste, la Unión Europea ya cuenta con el AI Act —vigente desde agosto de 2024— que clasifica los sistemas de IA por nivel de riesgo y establece obligaciones específicas para sistemas de alto riesgo, incluidos requisitos de robustez y ciberseguridad. Los agentes autónomos con capacidad de acción en entornos externos quedarán bajo escrutinio particular en ese marco. Chile no tiene un equivalente funcional.

    Brasil y Colombia avanzan, aunque con distinto ritmo

    En el resto de la región el panorama es desparejo. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) y la Autoridade Nacional de Proteção de Dados (ANPD) ha comenzado a pronunciarse sobre decisiones automatizadas, aunque la regulación específica de agentes de IA es todavía incipiente. El Congreso brasileño tiene en discusión un marco regulatorio de IA —PL 2338/2023— que sigue de cerca la lógica del AI Act europeo y contempla sistemas autónomos como categoría de atención. Colombia, por su parte, opera bajo la Ley 1581/2012 y la Superintendencia de Industria y Comercio (SIC) ha emitido guías sobre IA y datos personales, pero sin fuerza vinculante sobre la responsabilidad en incidentes de seguridad causados o mediados por sistemas autónomos.

    Argentina transita una situación similar: la Ley 25.326 de Protección de Datos Personales data de 2000 y su reforma lleva años paralizada en el Congreso. La Agencia de Acceso a la Información Pública (AAIP) publicó lineamientos sobre IA en 2023, pero sin valor normativo directo. Ninguno de estos países tiene hoy un régimen que responda con claridad a la pregunta de quién asume la obligación de notificación, compensación y remediación cuando un agente de IA es el actor central de un incidente.

    Qué deben monitorear las empresas con operaciones en Chile durante 2025–2026

    La entrada en vigor escalonada de la Ley 21.719 y la instalación de la APDP marcan el calendario inmediato. Las empresas que ya despliegan agentes de IA en Chile deben asumir que la autoridad interpretará las obligaciones de seguridad del responsable de tratamiento de forma extensiva —incluyendo los riesgos que introducen sistemas autónomos. En paralelo, el Ministerio de Ciencia trabaja en una Política Nacional de Inteligencia Artificial actualizada que podría sentar bases para legislación futura. A nivel regional, el avance del PL 2338 en Brasil funcionará como referencia para otros legisladores latinoamericanos, dada la masa crítica del mercado brasileño.

    • Mapear todos los agentes de IA desplegados en entornos que traten datos personales de ciudadanos chilenos, con identificación del responsable de cada capa del sistema.
    • Revisar contratos con proveedores de modelos e integradores para clarificar la asignación contractual de responsabilidad ante incidentes causados o mediados por IA.
    • Incorporar pruebas de adversarial prompting y controles de salida en los protocolos de seguridad de agentes autónomos.
    • Monitorear la reglamentación secundaria que emita la APDP sobre medidas de seguridad y decisiones automatizadas.

    Nuestro análisis

    Chile está mejor posicionado que la mayoría de sus vecinos para dar el salto regulatorio sobre IA: tiene una autoridad de datos en proceso de instalación, una ley moderna recién promulgada y una tradición de diálogo técnico-legal en el sector tecnológico. Pero la velocidad de adopción de agentes autónomos en empresas medianas y grandes ya supera el ritmo legislativo. El riesgo concreto no es abstracto: una empresa chilena que sufra una brecha causada por prompt injection sobre un agente de IA enfrentará hoy un vacío de atribución que beneficia a los actores menos diligentes y perjudica a quienes invirtieron en controles. La APDP necesitará emitir criterios interpretativos sobre sistemas autónomos antes de que ese primer caso llegue a su escritorio —porque cuando llegue, el daño ya estará hecho.

    La pregunta que Chile debe responder no es si regular la IA, sino si lo hará antes o después del primer incidente de escala que protagonice un agente autónomo con datos de sus ciudadanos.

  • 27.000 eventos de seguridad que expusieron los vacíos en datos de salud rurales e indígenas

    27.000 eventos de seguridad que expusieron los vacíos en datos de salud rurales e indígenas

    El análisis de 27.000 eventos de seguridad clínica en comunidades rurales e indígenas de Estados Unidos reveló un problema estructural que trasciende fronteras: cuando los datos de salud son incompletos, fragmentados o directamente inexistentes, los sistemas de gobernanza no pueden hacer su trabajo. La lección tiene peso directo para América Latina, donde poblaciones indígenas y rurales siguen siendo los grandes ausentes en los registros sanitarios digitales.

    Un evento de seguridad clínica es cualquier incidente — error de medicación, caída de paciente, diagnóstico tardío, falla en un protocolo — que se registra formalmente dentro de un sistema de salud. Cuando se acumulan decenas de miles de esos registros, el resultado no es solo un inventario de errores: es un mapa de calidad de datos. Lo que reveló el análisis de 27.000 casos en entornos rurales e indígenas, según se informó en Health Data Management, es que la infraestructura de captura, estandarización y uso de datos clínicos en estas poblaciones presenta brechas sistemáticas que ningún dashboard puede corregir si el dato nunca llegó al sistema.

    Por qué los datos rurales e indígenas fallan en origen, no en el análisis

    El problema no empieza en la capa analítica sino en la captura. Las comunidades rurales e indígenas suelen operar con sistemas de registro clínico desactualizados, personal de salud con baja capacitación en documentación digital, y conectividad insuficiente para sincronizar datos en tiempo real con repositorios centrales. El resultado es un fenómeno conocido en la literatura de gobernanza de datos como “dark data” sanitario: información que existe físicamente — en papel, en memorias locales, en registros discontinuos — pero que nunca ingresa al flujo de datos estructurado que alimenta las decisiones de política pública. Según el marco DAMA-DMBOK, la calidad de datos no es una propiedad del dato aislado sino del ciclo completo: definición, captura, almacenamiento, integración y uso. Cuando alguno de esos eslabones falla por razones estructurales — presupuesto, infraestructura, idioma, confianza institucional —, los reportes agregados reflejan ausencia, no realidad.

    Cuándo aplica la gobernanza de datos de salud / cuándo NO es suficiente

    La gobernanza de datos clínicos funciona cuando hay un flujo mínimo de datos estandarizados sobre el cual aplicar reglas, roles (data stewards, data owners) y controles de calidad. Aplica bien en hospitales urbanos con sistemas de Historia Clínica Electrónica (HCE) maduros, en redes de atención primaria integradas a plataformas nacionales, o en jurisdicciones con interoperabilidad regulada. No alcanza — o directamente no puede operar — cuando la población objetivo no genera registros digitales en primer lugar. En ese escenario, el trabajo previo es de infraestructura y confianza: diseñar procesos de captura que sean culturalmente aceptables, técnicamente accesibles y jurídicamente seguros para las comunidades involucradas. Sin esa base, cualquier framework de gobernanza opera sobre un conjunto de datos sesgado que subestima la carga de enfermedad real.

    El mismo déficit en Argentina, México y Brasil: los registros que nunca se digitalizaron

    En América Latina el patrón es reconocible. En Argentina, el sistema de salud indígena depende en gran medida de registros en papel en las provincias del norte —Chaco, Formosa, Jujuy— con escasa integración al sistema nacional de estadísticas vitales del Ministerio de Salud. En México, el IMSS-Bienestar (ex-IMSS-PROSPERA) lleva años intentando digitalizar la atención en comunidades de alta marginación, con avances parciales documentados por el propio IMSS en sus informes anuales. En Brasil, la Rede Nacional de Dados em Saúde (RNDS), impulsada por el Ministerio de Salud bajo el paraguas de la LGPD, contempla explícitamente la interoperabilidad para poblaciones vulnerables, pero la implementación en territorios indígenas de la Amazonía sigue siendo incompleta según informes del Distrito Sanitário Especial Indígena (DSEI). El denominador común: los datos no existen, o existen en formatos que no dialogan con los sistemas de decisión.

    Qué cambia cuando un CDO toma estos hallazgos en serio

    Para un Chief Data Officer en una institución de salud pública o en una agencia regulatoria regional, el análisis de eventos de seguridad clínica en poblaciones subrepresentadas debería disparar al menos tres movimientos concretos. Primero, auditar la cobertura del catálogo de datos: ¿qué porcentaje de la población objetivo genera registros digitales activos? Los gaps geográficos o demográficos en el catálogo son tan relevantes como los errores de calidad en los datos existentes. Segundo, revisar si los data stewards responsables de dominios de datos de salud tienen mandato explícito sobre fuentes no estructuradas o de baja fidelidad — papel, registros verbales, sistemas desconectados —, algo que el EDM Council (DCAM) clasifica dentro de la capability de “Data Quality Management” en su nivel 3 de madurez. Tercero, evaluar si los procesos de captura están diseñados con participación de las comunidades afectadas: en salud indígena, la confianza institucional es una condición de calidad de datos, no un factor blando. Un formulario en español en una comunidad mayahablante no es un dato de baja calidad; es la ausencia de un dato.

    Los 27.000 eventos registrados son valiosos precisamente porque fueron registrados: la pregunta más urgente para los equipos de gobernanza de datos en salud es cuántos eventos equivalentes nunca llegaron a ningún sistema y qué decisiones de política pública se tomaron, sin saberlo, sobre esa ausencia.

  • IA sin gobierno: las brechas que convierten al CIO en variable de ajuste

    IA sin gobierno: las brechas que convierten al CIO en variable de ajuste

    Cuando la adopción de inteligencia artificial supera la capacidad de gobernanza de una organización, el primer cargo que queda expuesto no es el del CEO ni el del CFO: es el del CIO. Las brechas entre la velocidad de despliegue de herramientas de IA y los marcos de control interno están generando un riesgo operativo y reputacional que los equipos técnicos todavía subestiman.

    El fenómeno tiene un nombre en la industria: AI overload. No se refiere al volumen de datos que procesan los modelos, sino a la saturación institucional que ocurre cuando una organización incorpora múltiples sistemas de IA —agentes, copilotos, herramientas generativas, APIs de terceros— sin que existan políticas claras de ownership, clasificación del dato de entrada, ni criterios de auditoría de outputs. El resultado es un entorno donde nadie puede responder con certeza quién es responsable de qué decide el sistema.

    Tres brechas de gobernanza que concentran el riesgo en el CIO

    La primera brecha es de inventario. La mayoría de las organizaciones no tienen un catálogo actualizado de los sistemas de IA que operan en producción, incluidos los contratados por áreas de negocio sin intervención de TI —lo que el mercado llama shadow AI. Sin ese inventario, el CIO no puede establecer controles de acceso diferenciados, ni garantizar que los datos que alimentan esos modelos cumplen con las políticas de clasificación vigentes. El DAMA-DMBOK v2 trata este punto bajo la capacidad de data asset management: si el activo no está catalogado, no existe para el gobierno.

    La segunda brecha es de linaje (data lineage). Cuando un modelo de lenguaje genera una recomendación o resume un contrato, ¿de qué datos se nutrió? ¿Incluía información confidencial, datos personales de clientes, información regulada? Sin trazabilidad de extremo a extremo —desde la fuente hasta el output del modelo— es imposible demostrar cumplimiento ante una auditoría regulatoria. En jurisdicciones con marcos de protección de datos maduros, como Brasil (LGPD, Lei 13.709/2018) o Argentina (Ley 25.326 y su decreto reglamentario 1558/2001), la ausencia de linaje en tratamientos automatizados puede constituir una infracción directa a los principios de transparencia y finalidad.

    La tercera brecha es de ownership. En muchas organizaciones, los data stewards —los responsables de dominio sobre conjuntos de datos específicos— no fueron incorporados al proceso de selección ni de monitoreo de herramientas de IA. Esto genera un vacío: el modelo opera sobre datos que alguien “gobierna” en papel, pero sin que ese steward haya validado el uso ni pueda responder por los resultados. Es una falla estructural que el EDM Council documenta en su Data Management Capability Assessment Model (DCAM) como riesgo de baja madurez en la capacidad de “data governance accountability”.

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

    Este marco de riesgo aplica a organizaciones que ya tienen al menos una herramienta de IA generativa en producción —sea un copiloto de código, un asistente de atención al cliente, un motor de resumen de documentos— y que operan en sectores regulados: servicios financieros, salud, retail con datos de comportamiento, o cualquier industria que procese datos personales a escala. No aplica del mismo modo a organizaciones en fase de exploración o prueba de concepto, donde los datos utilizados son sintéticos o están completamente desidentificados y el modelo no toca producción.

    Tampoco es un problema exclusivo de empresas grandes. En América Latina, compañías medianas de e-commerce, fintechs y aseguradoras están incorporando APIs de modelos de lenguaje de terceros sin un análisis previo de qué datos fluyen hacia esos proveedores externos. En México, la LFPDPPP y los lineamientos del INAI obligan a establecer cláusulas contractuales con encargados del tratamiento; en Colombia, la Ley 1581 de 2012 exige el mismo estándar. El uso de una API de IA sin contrato de encargo adecuado puede constituir una transferencia no autorizada de datos personales.

    Lo que el CIO necesita resolver antes de escalar más herramientas

    El primer paso no es detener la adopción, sino hacer visible lo que ya opera. Un sprint de inventario de sistemas de IA —incluyendo las herramientas contratadas por áreas de negocio sin aprobación formal de TI— es el punto de partida mínimo. Ese inventario debe cruzarse con el catálogo de datos existente para identificar qué activos de datos están siendo utilizados como input, bajo qué política de clasificación y con qué nivel de sensibilidad. Si no existe un catálogo de datos formal, ese es el déficit previo que hace imposible gobernar la IA.

    El segundo paso es formalizar el rol del data steward en el ciclo de vida de cada sistema de IA: desde la selección del proveedor hasta la revisión periódica de outputs. No como control de calidad técnica, sino como garantía de que el uso del dato es consistente con la política de la organización y con los marcos regulatorios aplicables. En organizaciones que trabajan bajo el estándar CDMC del EDM Council, esto corresponde a la capacidad 10 (“data usage”) combinada con la capacidad 7 (“data protection”).

    El riesgo no es la inteligencia artificial: es operar sistemas que toman decisiones sobre datos que nadie en la organización puede rastrear, explicar ni defender ante un regulador. Ese es el gap que convierte al CIO en el responsable de última instancia de fallos que nunca aprobó. Para profundizar en el marco de madurez de gobernanza aplicable a entornos con IA, el EDM Council ofrece el CDMC de acceso público en edmcouncil.org.

  • IA que diseña virus: qué implica para la regulación de sistemas biológicos

    IA que diseña virus: qué implica para la regulación de sistemas biológicos

    En 2025, Samuel King, estudiante de doctorado en Stanford, utilizó un modelo de inteligencia artificial generativa para proponer planos genéticos de virus microscópicos. El experimento no produce vida artificial todavía, pero abre una pregunta legal y regulatoria que ningún marco vigente responde de forma completa: ¿quién es responsable de lo que un sistema de IA diseña en el plano biológico?

    La investigación de King representa un punto de inflexión conceptual. Hasta ahora, el diseño de organismos sintéticos exigía equipos de biología molecular con décadas de especialización. Un modelo de IA generativa que propone secuencias genéticas viable —aunque sea a nivel preliminar— comprime ese umbral de manera radical. El experimento no implica que el sistema “comprenda” biología: infiere patrones a partir de datos de entrenamiento, igual que cualquier LLM infiere texto. Pero el output es cualitativamente distinto: un blueprint que podría, en teoría, materializarse en un laboratorio.

    El vacío regulatorio que nadie quiere nombrar

    Los marcos regulatorios actuales sobre inteligencia artificial —el AI Act de la Unión Europea, los Executive Orders en Estados Unidos, los lineamientos del Consejo de Derechos Humanos de la ONU— clasifican el riesgo de los sistemas de IA por dominio de aplicación: crédito, empleo, salud, infraestructura crítica. Ninguno contempla de forma explícita el uso de IA para el diseño de entidades biológicas. El AI Act europeo, que entró en vigor en etapas desde 2024, define como “alto riesgo” a los sistemas que operan en infraestructura crítica y en el ámbito de la salud, pero el diseño generativo de secuencias genéticas no encaja con nitidez en ninguna de esas categorías tal como están redactadas.

    En paralelo, la Convención sobre Armas Biológicas (BWC, por sus siglas en inglés) fue negociada en 1972 y no contempla actores no estatales que accedan a capacidades de síntesis biológica asistida por IA. La brecha entre el ritmo de la tecnología y el de los tratados internacionales rara vez fue tan visible como en este caso.

    Cuándo aplica responsabilidad legal sobre el sistema — y cuándo no

    La pregunta de responsabilidad civil y penal sobre sistemas de IA que generan outputs potencialmente peligrosos es, hoy, una pregunta abierta en casi todas las jurisdicciones. En el derecho continental europeo y latinoamericano, la responsabilidad tiende a recaer sobre quien despliega el sistema, no sobre el desarrollador del modelo base —salvo negligencia demostrable en el diseño. Eso significa que, bajo el esquema actual, una universidad o laboratorio que use un modelo generativo para explorar secuencias biológicas asumiría la carga legal de cualquier consecuencia.

    El problema se vuelve más complejo cuando el modelo es de acceso abierto o cuando el output se genera sin intención deliberada de daño. Las teorías de responsabilidad por producto defectuoso —aplicadas con éxito en algunos litigios sobre sistemas de IA en Estados Unidos— requieren demostrar que el sistema tiene un defecto de diseño o fabricación. Un modelo que “hace bien su trabajo” pero cuyo output resulta peligroso en manos de un tercero enfrenta un test de responsabilidad para el que los códigos civiles latinoamericanos no tienen respuesta clara.

    El ángulo de Argentina, Brasil y México ante el diseño biológico asistido por IA

    Ninguno de los tres grandes marcos regulatorios de IA en América Latina —la propuesta de regulación de Brasil en debate legislativo, los lineamientos del Instituto Nacional de Transparencia (INAI) en México, ni la normativa emergente en Argentina bajo la órbita de la Agencia de Acceso a la Información Pública (AAIP)— contempla explícitamente el uso de IA en biología sintética. La región ha avanzado en privacidad y en gobernanza de datos, pero la intersección entre IA y bioseguridad permanece fuera del radar normativo. Esto no es un reproche: la mayoría de las jurisdicciones avanzadas tampoco lo tienen resuelto. Pero sí implica que los laboratorios académicos en São Paulo, Ciudad de México o Buenos Aires que adopten estas herramientas operarán, por ahora, bajo un vacío legal que la analogía con marcos existentes no puede llenar del todo.

    Cuándo aplica / cuándo NO la regulación de IA de alto riesgo

    Aplicaría regulación de IA de alto riesgo —bajo el AI Act o marcos equivalentes— si el sistema se usa en decisiones clínicas directas sobre pacientes identificables, o si el output se integra a procesos de manufactura farmacéutica supervisados. No aplicaría de forma automática cuando el uso es exploratorio o de investigación básica, cuando el modelo no toma decisiones autónomas sino que propone opciones revisadas por humanos, o cuando el output no tiene efecto jurídico inmediato. La distinción entre “asistencia a la investigación” y “sistema de alto riesgo” es, precisamente, el nudo que los reguladores deberán desatar en los próximos años.

    El debate sobre quién regula estos sistemas —agencias de salud, autoridades de IA, organismos de bioseguridad— está apenas comenzando. En la práctica, esa superposición de jurisdicciones crea un espacio gris que los actores académicos y comerciales pueden navegar con relativa libertad, al menos por ahora.

    Para profundizar en el marco técnico y jurídico del AI Act y su clasificación de sistemas de alto riesgo, el texto oficial del Reglamento (UE) 2024/1689 publicado en el Diario Oficial de la Unión Europea es el punto de partida obligado para cualquier análisis comparado con marcos latinoamericanos en desarrollo.

  • Datos indígenas y GDPR: la brecha que los pueblos Sámi pusieron en evidencia

    Datos indígenas y GDPR: la brecha que los pueblos Sámi pusieron en evidencia

    El Reglamento General de Protección de Datos de la Unión Europea —el marco de referencia que inspiró leyes en toda América Latina— tiene un punto ciego estructural: no reconoce la naturaleza colectiva de los datos indígenas. Académicos del pueblo Sámi publicaron una propuesta concreta para corregirlo, y el debate que abrieron tiene implicancias directas para la gobernanza de datos en países como Bolivia, Guatemala, México y Colombia, donde la dimensión colectiva del dato sigue ausente de los marcos legales vigentes.

    Por qué el modelo GDPR falla cuando el dato es colectivo, no individual

    El GDPR está construido sobre una premisa liberal: el dato pertenece a un individuo identificable, y ese individuo ejerce derechos —acceso, rectificación, supresión— de manera autónoma. Para los pueblos indígenas, esa arquitectura no funciona. Los datos sobre lenguas, territorios, prácticas medicinales o genealogías no son atributos de personas individuales: son patrimonio comunitario. El daño de su extracción o mal uso no recae sobre un ciudadano; recae sobre un pueblo.

    Los académicos Sámi —cuya comunidad está repartida entre Noruega, Suecia, Finlandia y Rusia— señalan que incluso cuando un individuo Sámi ejerce sus derechos bajo el GDPR, no puede representar ni proteger los intereses colectivos del grupo. El consentimiento individual, pilar del GDPR, no equivale al consentimiento comunitario libre, previo e informado que exigen instrumentos como el Convenio 169 de la OIT o la Declaración de las Naciones Unidas sobre los Derechos de los Pueblos Indígenas (DNUDPI).

    La propuesta Sámi: soberanía de datos y protocolos comunitarios de gobernanza

    Según se informó, la propuesta elaborada por los investigadores Sámi gira en torno al concepto de soberanía de datos indígenas: el derecho colectivo a determinar cómo se recopilan, almacenan, usan y comparten los datos que conciernen a una comunidad. Este enfoque, desarrollado en paralelo por iniciativas como la Global Indigenous Data Alliance y su marco CARE (Collective Authority, Responsibility, Ethics, uso de IA incluido), propone que las comunidades sean reconocidas como entidades con derechos propios sobre sus datos, no solo como agregados de individuos con derechos individuales.

    La corrección técnica que ofrecen los académicos incluye la habilitación de protocolos comunitarios de gobernanza —mecanismos formales mediante los cuales una comunidad define sus propias reglas de acceso, compartición y uso de datos que le conciernen— y su reconocimiento legal explícito dentro de los marcos regulatorios. El modelo propone que los data stewards en contextos indígenas sean designados comunitariamente, no individualmente, un giro fundamental respecto a cómo el DAMA-DMBOK define el rol de stewardship en organizaciones corporativas.

    México, Colombia y Bolivia: tres marcos que ya enfrentan esta tensión sin resolverla

    América Latina concentra más de 50 millones de personas pertenecientes a pueblos indígenas, según datos de la CEPAL, distribuidas en países con marcos de datos personales que replican —en distintos grados— la lógica individualista del GDPR. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares de México (LFPDPPP) no contempla titularidad colectiva. Colombia, cuya Ley 1581 de 2012 sigue el mismo paradigma, tampoco. Bolivia, pese a su Constitución Política del Estado que reconoce derechos colectivos de las naciones originarias, carece de una ley de protección de datos personales que articule esa dimensión con el tratamiento de datos.

    El caso más avanzado en la región es Brasil. La Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) incluye una base legal específica para la protección de la salud y el interés público que podría interpretarse extensivamente, pero no establece titularidad colectiva de datos. La Autoridade Nacional de Proteção de Dados (ANPD) aún no ha emitido regulación específica sobre datos de comunidades indígenas o quilombolas, grupos con los que la tensión entre dato individual y patrimonio colectivo es igualmente relevante.

    En Chile, la Ley 21.719 —nueva ley de protección de datos personales publicada en 2024— tampoco incorpora una categoría de dato colectivo indígena, pese a que el proceso constituyente previo había abierto ese debate con fuerza en relación al pueblo Mapuche y sus datos territoriales.

    Qué cambia en la práctica para organizaciones que operan con datos de comunidades

    Para un CDO o un Data Governance Manager en una empresa con operaciones en territorios con presencia indígena —sector extractivo, salud, telecomunicaciones, agro-tecnología, investigación académica— el debate Sámi no es teórico. Las preguntas concretas son: ¿quién puede dar consentimiento por datos que conciernen a una comunidad? ¿qué ocurre si ese consentimiento es individual pero el impacto es colectivo? ¿cómo se documenta el linaje de un dato cuya fuente es una práctica comunitaria y no un formulario individual?

    Los pasos accionables arrancan con la clasificación. Si en el inventario de datos de la organización existen activos que derivan de comunidades indígenas —encuestas etnográficas, datos de salud en territorios, registros lingüísticos, cartografía de uso del suelo— esos activos requieren una categoría de sensibilidad diferenciada en el catálogo de datos, con metadata de origen comunitario y restricciones de uso más estrictas que las que aplicaría el GDPR o la LGPD por defecto. El marco CARE de la Global Indigenous Data Alliance ofrece un punto de partida operativo para definir esas reglas de acceso.

    Hitos a monitorear: ANPD, Convenio 169 OIT y la revisión del GDPR en 2026

    La Comisión Europea tiene en agenda una revisión del GDPR cuyo alcance aún no está definido públicamente; la propuesta Sámi llega en un momento en que esa conversación sobre actualizaciones del reglamento está abierta. En América Latina, el hito más próximo es la agenda regulatoria de la ANPD de Brasil, que en 2025 inició un proceso de consulta sobre categorías especiales de datos —y donde organizaciones de la sociedad civil ligadas a derechos indígenas han presentado insumos. El Convenio 169 de la OIT, ratificado por 14 países de la región, ya establece la obligación de consulta previa; traducirlo a obligaciones concretas de data governance es el paso que ningún regulador latinoamericano ha dado formalmente todavía.

    Nuestro análisis: el eslabón perdido entre derechos colectivos y marcos de gobernanza de datos

    El aporte de los académicos Sámi no es solo normativo: es un recordatorio de que los marcos de gobernanza de datos —incluyendo el DAMA-DMBOK, el CDMC del EDM Council y los frameworks regulatorios que los acompañan— fueron diseñados pensando en organizaciones, no en comunidades. La figura del data owner en esos frameworks asume una entidad legal singular con capacidad de decisión centralizada. Esa suposición no sobrevive al contacto con la realidad de un pueblo cuya autoridad es distribuida, oral y comunitaria.

    Para DataTrends LATAM, la pregunta no es si el GDPR debe cambiar —eso lo decidirá Bruselas. La pregunta es si los países latinoamericanos que están actualizando sus leyes de protección de datos (Chile ya lo hizo, Colombia lo está evaluando, Argentina discute la reforma de la Ley 25.326) van a incorporar esta dimensión antes o después de que un litigio o un escándalo los obligue a hacerlo. La experiencia Sámi sugiere que esperar el incidente tiene un costo cultural, político y reputacional que ningún DPO querrá gestionar a posteriori.

    Los datos indígenas son el caso de prueba más exigente para cualquier framework de gobernanza: si el modelo no puede manejar la titularidad colectiva, ¿qué otras formas de propiedad compartida —datos empresariales en joint ventures, datos de salud familiar, datos sindicales— está fallando en proteger?

  • Luna Moth Files: la filtración interna de Silent Ransom Group que el grupo niega

    Luna Moth Files: la filtración interna de Silent Ransom Group que el grupo niega

    Un sitio onion identificado como “Luna Moth Files” publicó el martes 7 de octubre archivos de chat interno atribuidos al grupo de extorsión Silent Ransom Group. Dos días después, el propio grupo negó la autenticidad de la filtración, pero analistas de ciberseguridad que examinaron los documentos afirman que los datos apuntan en dirección contraria.

    El sitio apareció el martes por la mañana en la red Tor. La identidad de quien lo publicó no fue confirmada a la fecha de esta nota. Investigadores del sector comenzaron a analizar los archivos ese mismo día, y el jueves Silent Ransom Group emitió una declaración negando que el material sea legítimo, calificándolo de fabricación. La negativa, sin embargo, no fue acompañada de evidencia técnica que sustente esa versión, según se informó.

    Datos confirmados al 9 de octubre de 2026

    • El sitio “Luna Moth Files” estuvo activo en la red Tor desde el martes 7 de octubre.
    • Los archivos publicados incluirían registros de conversaciones internas del grupo, según se informó.
    • Silent Ransom Group emitió una desmentida el jueves 9 de octubre.
    • La identidad del responsable de la publicación permanece desconocida.
    • Profesionales de ciberseguridad que revisaron el material sostienen que los datos sugieren autenticidad, aunque no hubo verificación independiente pública definitiva al cierre de esta nota.

    Qué se sabe y qué falta confirmar

    Lo confirmado es que el sitio existe, que los archivos están disponibles en la red Tor y que al menos una parte de la comunidad de ciberseguridad considera el material plausible. Lo que aún no está verificado es la cadena de custodia de los archivos, es decir, cómo salieron del entorno operativo del grupo y quién los obtuvo. Tampoco se descartó públicamente la hipótesis de que la filtración provenga de un disidente interno, un actor rival o una operación de contrainteligencia. La táctica de desacreditar una filtración genuina como “fake” es un recurso documentado entre grupos de ransomware y extorsión cuando el material comprometido puede dañar su reputación operativa o exponer a miembros individuales.

    Para organizaciones en América Latina que han sido o podrían ser objetivo de Silent Ransom Group —activo en campañas de vishing y extorsión sin cifrado contra sectores legales, financieros y de salud—, la filtración tiene relevancia directa. Si los archivos son auténticos, podrían revelar tácticas, objetivos y métodos de negociación del grupo. Bajo el marco de la Ley 25.326 en Argentina, la LGPD en Brasil o la LFPDPPP en México, cualquier empresa que haya recibido una demanda de extorsión de este actor tiene obligaciones de notificación a la autoridad de control si se confirmara que datos personales de sus titulares estuvieron en poder del grupo.

    El próximo hito es la verificación forense independiente del material: hasta que un tercero con acceso técnico confirme o refute la autenticidad de los archivos, la desmentida de Silent Ransom Group no cierra el caso.

  • Brecha en protección de datos frena la adopción de IA en África

    Brecha en protección de datos frena la adopción de IA en África

    La ausencia de marcos sólidos de gobernanza de datos en gran parte del continente africano está condicionando la velocidad y la profundidad con que las organizaciones pueden adoptar inteligencia artificial. El patrón no es exclusivo de África: América Latina enfrenta una brecha estructural similar, donde la madurez regulatoria avanza a distinta velocidad que la implementación tecnológica.

    Según se informó en un análisis publicado por ITWeb Africa, la falta de marcos claros de protección de datos en numerosos países africanos representa un obstáculo real para escalar soluciones de IA. La lógica es directa: entrenar, desplegar y auditar sistemas de IA requiere definir con precisión qué datos pueden usarse, bajo qué condiciones, con qué nivel de calidad y con qué mecanismos de rendición de cuentas. Sin esas definiciones operativas, cualquier iniciativa de IA se construye sobre bases frágiles.

    Qué se entiende por “brecha” y por qué importa en 2025

    La brecha no refiere únicamente a la ausencia de una ley de datos personales, sino a la distancia entre las capacidades de gobernanza que los sistemas de IA demandan y las que las organizaciones efectivamente tienen. Según el marco CDMC (Cloud Data Management Capabilities) del EDM Council, los dominios de calidad, clasificación, linaje y control de acceso son prerequisitos para cualquier pipeline de datos que alimente un modelo. Una organización que no puede responder quién es el data owner de un conjunto de datos de entrenamiento no está en condiciones de auditar sesgos ni cumplir eventuales obligaciones de transparencia algorítmica.

    El problema se amplifica cuando los marcos regulatorios son inexistentes o fragmentarios. Sin una autoridad de control activa que exija estándares mínimos, el incentivo para invertir en gobernanza de datos cae. Las organizaciones priorizan el despliegue de IA sobre la infraestructura de datos que lo sostiene, lo que genera deuda técnica y de cumplimiento difícil de revertir.

    Cuándo aplica este análisis / cuándo NO

    Este diagnóstico aplica a organizaciones que están evaluando o ya ejecutando proyectos de IA con datos internos o de terceros, en jurisdicciones donde la regulación de datos es incipiente o no está plenamente implementada. No aplica de la misma forma a organizaciones que operan bajo marcos regulatorios maduros con supervisión activa —como las entidades financieras brasileñas bajo la LGPD y la supervisión del Banco Central, o empresas mexicanas alcanzadas por la LFPDPPP con resoluciones del INAI. En esos contextos, la brecha de gobernanza existe pero está parcialmente acotada por obligaciones legales exigibles.

    El espejo latinoamericano: madurez regulatoria dispar en la región

    América Latina reproduce, con variantes, la misma tensión. Brasil cuenta con la LGPD desde 2020 y una Autoridad Nacional de Protección de Datos (ANPD) con capacidad sancionatoria creciente; Argentina actualiza su Ley 25.326 y avanza —lentamente— hacia un nuevo proyecto de protección de datos que incorpore IA; Colombia opera bajo la Ley 1581 con la Superintendencia de Industria y Comercio como autoridad activa. Pero en paralelo, la mayoría de las organizaciones de la región no han formalizado roles de data stewardship, no mantienen catálogos de datos actualizados y carecen de políticas de clasificación que distingan datos personales de datos operativos. Según el DAMA-DMBOK, esas capacidades son el piso mínimo de madurez antes de que un programa de IA pueda considerarse gobernado.

    El riesgo concreto: una organización latinoamericana que despliega un modelo de IA sobre datos mal clasificados y sin linaje documentado no solo enfrenta riesgo regulatorio bajo las leyes vigentes, sino que es incapaz de responder a un derecho de acceso (ARCO/DSAR) que involucre inferencias generadas por ese modelo. La autoridad de control puede considerar esa incapacidad como una violación de principios de transparencia y responsabilidad proactiva.

    Tres capacidades de gobernanza que un CDO debe tener operativas antes de escalar IA

    • Clasificación de datos de entrenamiento: identificar qué registros contienen datos personales, datos sensibles o datos de uso restringido, con etiquetado en el catálogo de datos.
    • Linaje documentado (data lineage): trazar el origen, transformaciones y destino de cada conjunto de datos que alimenta un pipeline de IA, de modo que sea auditable por el equipo legal y por la autoridad de control.
    • Data ownership formalizado: cada dataset de entrenamiento debe tener un data steward designado con responsabilidad explícita sobre calidad, acceso y ciclo de vida, antes de que el equipo de ciencia de datos lo use en producción.

    Estas tres capacidades no son aspiracionales: son el estándar que marcos como CDMC del EDM Council y la guía Non-Invasive Data Governance de Bob Seiner establecen como prerequisito operativo para entornos de datos que alimentan decisiones automatizadas.

    Para un CDO en la región, la pregunta no es si la organización “está lista para la IA”, sino si puede demostrar, ante una auditoría interna o una inspección regulatoria, quién autorizó el uso de cada dataset de entrenamiento y bajo qué condiciones. Si esa respuesta no existe hoy, el programa de IA tiene un pasivo de gobernanza que crecerá con cada modelo que se despliegue.

  • JR East: posible exposición de 2,06 millones de registros personales en Japón

    JR East: posible exposición de 2,06 millones de registros personales en Japón

    El operador ferroviario JR East informó que sus servicios digitales, incluida la plataforma de reservas Eki-net, podrían haber expuesto hasta 2,06 millones de registros de datos personales de usuarios en Japón. El incidente, dado a conocer el 9 de octubre de 2025, aún está bajo investigación y no se ha confirmado la exfiltración total de los datos.

    East Japan Railway Company (JR East), una de las mayores empresas ferroviarias del mundo por volumen de pasajeros, reveló que múltiples servicios bajo su operación —entre ellos Eki-net, su sistema de reservas y compra de boletos en línea— podrían haber estado involucrados en un incidente de seguridad con exposición potencial de información personal. La empresa no precisó el vector de ataque ni confirmó si los registros fueron efectivamente extraídos por terceros no autorizados.

    Datos confirmados del incidente

    • Registros potencialmente expuestos: hasta 2,06 millones
    • Servicios involucrados: Eki-net y otros no especificados de la misma compañía
    • Empresa afectada: East Japan Railway Company (JR East), Japón
    • Fecha de divulgación pública: 9 de octubre de 2025
    • Estado del incidente: bajo investigación; exfiltración no confirmada

    Qué se sabe y qué falta confirmar

    Según se informó, JR East detectó la posible exposición y procedió a notificar el hecho públicamente, en línea con las obligaciones de reporte establecidas por la Ley de Protección de Información Personal (APPI) de Japón, que desde sus reformas de 2022 exige notificación a la Comisión de Protección de Información Personal (PPC) cuando el número de afectados supera los 1.000 registros. No se han confirmado datos sobre qué tipo de información personal estuvo involucrada —si incluye credenciales, datos de pago o solo información identificatoria básica—, ni si existe evidencia forense de descarga o acceso no autorizado efectivo. Tampoco se identificó públicamente un actor de amenaza responsable.

    El caso es relevante más allá de Japón por su escala y porque involucra infraestructura de transporte crítica con millones de usuarios registrados. En América Latina, incidentes de magnitud comparable en sistemas de transporte o servicios públicos digitales activan marcos de notificación distintos: en Argentina, la Ley 25.326 y las disposiciones de la AAIP obligan a reportar brechas que afecten datos sensibles o de gran escala; en Brasil, la LGPD (Lei 13.709/2018) establece plazos de comunicación a la ANPD y a los titulares afectados; en México, la LFPDPPP y su reglamento exigen aviso inmediato cuando el incidente genera riesgo patrimonial o discriminatorio para los titulares. En los tres casos, la ausencia de confirmación sobre el tipo de dato expuesto —como ocurre en el episodio de JR East— es precisamente el tipo de ambigüedad que las autoridades de control suelen cuestionar durante la investigación.

    El próximo hito crítico es la notificación formal de JR East a la Comisión de Protección de Información Personal de Japón, cuyo resultado determinará si la empresa enfrenta sanciones y si los 2,06 millones de usuarios afectados deben recibir comunicación directa.

  • Shadow AI: por qué los marcos de gobernanza no logran auditarlo

    Shadow AI: por qué los marcos de gobernanza no logran auditarlo

    El uso no autorizado de herramientas de inteligencia artificial generativa dentro de las organizaciones —lo que la industria llama shadow AI— está superando la capacidad de los programas de gobernanza de datos para detectarlo, clasificarlo y auditarlo. Los frameworks existentes no fueron diseñados para un entorno en el que cualquier colaborador puede procesar datos corporativos sensibles desde una pestaña del navegador, sin pasar por TI ni por el área de datos.

    La gobernanza de datos, en su concepción clásica —basada en DAMA-DMBOK o en el CDMC del EDM Council—, asume que el flujo de datos es relativamente conocido: hay sistemas de registro, hay data stewards que custodian dominios, hay pipelines auditables. Shadow AI rompe ese supuesto desde la base. Cuando un analista carga un archivo de clientes en ChatGPT para generar un resumen, o un equipo de ventas usa una extensión de IA para redactar propuestas con datos de CRM, ese flujo no deja rastro en ningún catálogo de datos, no tiene ownership asignado y no activa ninguna política de retención.

    El problema de visibilidad: datos que salen sin pasar por el catálogo

    El nudo central es de visibilidad. Los programas de gobernanza de datos dependen de que los activos estén registrados —idealmente en un catálogo con linaje (data lineage) documentado— para poder aplicar controles. Shadow AI crea canales de exfiltración suave que no generan alertas en las herramientas de Data Loss Prevention (DLP) tradicionales si el volumen por sesión es bajo, y que no quedan registrados en los logs de los sistemas fuente. El dato sale, es procesado por un modelo externo, y vuelve —o no— como output. Ese ciclo es invisible para el CDO.

    A esto se suma un problema de clasificación. Si el dato no está etiquetado previamente —y en la mayoría de las organizaciones de la región, la clasificación formal de activos de datos está en etapas tempranas—, no hay mecanismo automático que impida que un dato catalogado como “confidencial” sea pegado en un prompt. La clasificación tiene que preceder al control, y en muchas empresas latinoamericanas ese paso todavía está en construcción.

    Cuándo aplica y cuándo NO como problema de gobernanza

    Shadow AI es un problema de gobernanza de datos cuando el activo comprometido tiene un data steward asignado, pertenece a un dominio de datos definido, o está sujeto a una política de retención o clasificación. En esos casos, el uso no autorizado de una herramienta de IA externa es un incumplimiento del marco de gobernanza, no solo una infracción de seguridad. En cambio, si el empleado usa IA con datos públicos o propios sin clasificación corporativa, el problema es predominantemente de política de uso aceptable —competencia de RRHH o Legal— y no de gobernanza de datos en sentido estricto. La distinción importa porque define quién debe actuar y con qué autoridad.

    Tres capabilities que el programa de gobernanza debe incorporar

    Los equipos de gobernanza de datos que quieran responder a shadow AI necesitan desarrollar, como mínimo, tres capabilities nuevas. Primero, integración con herramientas de monitoreo de endpoints y tráfico de red para detectar transferencias de datos hacia dominios de IA generativa conocidos —algo que hoy hace el equipo de seguridad, no el de datos, y que requiere coordinación formal entre ambos. Segundo, extensión del catálogo de datos para incluir no solo sistemas de registro sino también flujos de IA sancionados, de modo que el inventario refleje dónde se procesan los datos, no solo dónde viven. Tercero, capacitación de data stewards para identificar y reportar usos de IA no inventariados dentro de sus dominios: el steward como primer sensor humano de shadow AI.

    El marco de Non-Invasive Data Governance de Bob Seiner es particularmente útil aquí: si los stewards ya tienen responsabilidades definidas sobre sus dominios de datos, extender esa responsabilidad al monitoreo de herramientas de IA que procesan esos datos es un paso incremental, no una revolución organizacional.

    En Brasil, Argentina y México: el riesgo regulatorio es concreto

    En América Latina, shadow AI no es solo un riesgo operativo: es un riesgo de cumplimiento con consecuencias legales concretas. La Lei Geral de Proteção de Dados (LGPD) de Brasil exige que el tratamiento de datos personales tenga una base legal y un propósito documentado. Si un empleado procesa datos de clientes en una herramienta de IA externa sin autorización, la empresa puede enfrentar responsabilidad ante la ANPD por tratamiento sin base legal y sin medidas de seguridad adecuadas. En Argentina, la Ley 25.326 establece obligaciones similares, y la AAIP ha dado señales de mayor actividad inspectiva en los últimos dos años. En México, el INAI requiere bajo la LFPDPPP que los responsables garanticen que los encargados de tratamiento —incluyendo proveedores tecnológicos— ofrezcan garantías suficientes. Un proveedor de IA generativa usado en modo shadow no tiene contrato de encargo, no tiene cláusulas de confidencialidad y probablemente no cumple con los estándares requeridos.

    Los bancos y aseguradoras de la región tienen una presión adicional: reguladores sectoriales como el Banco Central de Brasil (BACEN) o la Comisión Nacional Bancaria y de Valores (CNBV) en México están incorporando expectativas de gestión de riesgos tecnológicos que incluyen el inventario de herramientas de IA. Shadow AI es, en ese contexto, un gap de cumplimiento sectorial además de uno de gobernanza.

    El lunes, el CDO tiene cuatro movimientos concretos

    Sin necesidad de esperar una política corporativa de IA completa, un CDO puede iniciar cuatro acciones inmediatas. Primero, mapear junto a seguridad qué dominios de datos de mayor criticidad tienen mayor probabilidad de exposición vía IA (datos de clientes, datos financieros, datos de RRHH). Segundo, revisar si el catálogo de datos incluye campo de “herramientas autorizadas de procesamiento” y, si no existe, agregarlo como metadata. Tercero, convocar a los data stewards de dominios críticos para una sesión de sensibilización: preguntarles si conocen usos de IA generativa en sus áreas y documentar las respuestas. Cuarto, establecer una mesa de trabajo con Legal y Seguridad para definir qué herramientas de IA pasan a la categoría de “encargados de tratamiento” bajo LGPD, Ley 25.326 o LFPDPPP, según la jurisdicción, y qué contratos deben formalizarse.

    El CDMC del EDM Council incluye la gestión de riesgos de datos como capability central; el gap de shadow AI no es nuevo en términos de concepto, pero sí en escala. Las organizaciones que quieran profundizar pueden consultar el marco de referencia del EDM Council en edm-council.org y los lineamientos de la ANPD brasileña sobre uso de IA publicados en 2024.

  • OCDE propone marco de gobernanza de neurodatos ante riesgos de IA en 2026

    OCDE propone marco de gobernanza de neurodatos ante riesgos de IA en 2026

    La Organización para la Cooperación y el Desarrollo Económicos (OCDE) presentó en 2026 una propuesta de marco de gobernanza y supervisión de neurodatos frente a los riesgos de privacidad vinculados a la inteligencia artificial. El documento instala por primera vez en el plano multilateral un estándar específico para el tratamiento de datos cerebrales, una categoría que hasta ahora operaba en un vacío regulatorio casi total, y que los sistemas de IA hacen cada vez más accesible y explotable.

    Los neurodatos —información generada por dispositivos de interfaz cerebro-computadora, electroencefalogramas, resonancias magnéticas funcionales y tecnología neurotec comercial— ocupan un lugar singular en el ecosistema de datos sensibles: revelan estados emocionales, patrones de atención, predisposiciones cognitivas y condiciones neurológicas que ninguna otra categoría de datos puede inferir con tanta precisión. Con la expansión de dispositivos portátiles de monitoreo cerebral y el uso de modelos de IA para interpretar esas señales, la superficie de riesgo creció a una velocidad que los marcos regulatorios existentes no anticiparon.

    Qué propone la OCDE: principios, roles y supervisión sectorial

    Según se informó, el marco de la OCDE articula principios de proporcionalidad, minimización de datos y consentimiento específico para el tratamiento de neurodatos, con énfasis en la supervisión independiente de los sistemas de IA que procesan esa información. La propuesta distingue entre usos médicos —donde ya existen marcos parciales— y usos comerciales y de bienestar, donde la regulación es prácticamente inexistente. Esta distinción es relevante para definir qué entidades quedan sujetas a supervisión y bajo qué condiciones pueden transferir neurodatos a terceros o entre jurisdicciones.

    Desde la perspectiva del DAMA-DMBOK, los neurodatos encajan en la categoría de datos sensibles de alto riesgo que requieren clasificación explícita, políticas de retención diferenciadas y controles de acceso con auditoría continua. La propuesta de la OCDE operacionaliza esas exigencias en un contexto donde el data steward —el rol responsable de custodiar la calidad, el uso y el acceso al dato— todavía no está definido en la mayoría de las organizaciones que manejan este tipo de información.

    Chile, Colombia y Brasil: tres estadios frente a los datos de salud y neurotec

    América Latina presenta un panorama fragmentado. Chile es el único país de la región que incorporó explícitamente los datos neurológicos como categoría protegida: la reforma constitucional de 2021 y la posterior Ley 21.096 reconocieron la “neuroseguridad” como derecho, y la Ley 21.719 de protección de datos personales —vigente desde 2024— consolida ese marco al incluir los datos biométricos y de salud como datos sensibles sujetos a consentimiento reforzado. Es, en este punto específico, la jurisdicción más avanzada de la región y una de las más avanzadas del mundo.

    Colombia opera bajo la Ley 1581 de 2012 y sus decretos reglamentarios, que clasifican los datos de salud como sensibles pero no mencionan neurodatos ni tecnología de interfaz cerebro-computadora. La Superintendencia de Industria y Comercio (SIC) tiene competencia para intervenir, pero la ausencia de definiciones específicas genera inseguridad jurídica para empresas que desarrollan o importan dispositivos neurotec. Brasil, con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018), encuadra los datos de salud como categoría sensible bajo el artículo 11, lo que obliga a base legal específica para su tratamiento; sin embargo, la Autoridade Nacional de Proteção de Dados (ANPD) aún no emitió orientación sectorial sobre neurodatos ni sobre el uso de IA para su interpretación.

    Por qué el marco de la OCDE presiona a los CDO de empresas con operaciones regionales

    Para una organización con presencia en dos o más países de la región, la propuesta de la OCDE tiene un impacto operativo concreto: anticipa el estándar internacional al que convergerán las regulaciones locales y, por tanto, define el piso mínimo de controles que conviene implementar ahora. Un CDO que gestione datos de salud o bienestar con componente neurológico —desde apps de meditación con biofeedback hasta plataformas de salud ocupacional con wearables— necesita revisar si su inventario de datos incluye esta categoría, quién es el data steward asignado y qué controles de acceso y auditoría están activos.

    El marco del EDM Council (CDMC) identifica en su capability 8 —Data Sharing & Use— los requisitos de gobierno para datos transferidos a terceros o procesados por sistemas externos, incluidos modelos de IA. Si la organización ya trabaja con el CDMC o con ISO/IEC 38505, la incorporación de los neurodatos como subcategoría de datos sensibles de alto riesgo no requiere rediseñar el framework: requiere extender las políticas existentes con definiciones específicas y validar que los controles técnicos —cifrado en reposo y en tránsito, tokenización, acceso basado en roles— apliquen con el nivel de rigor adecuado.

    Qué monitorear: hitos regulatorios en los próximos 18 meses

    Tres frentes merecen seguimiento activo. Primero, la respuesta de los países miembros de la OCDE en la región —México, Colombia y Chile— al período de consulta del marco: sus posiciones definirán si adoptan el estándar por referencia o esperan una reforma legislativa propia. Segundo, la agenda de la ANPD en Brasil respecto a IA y datos sensibles: según se informó, la autoridad trabaja en regulación específica sobre decisiones automatizadas, lo que podría incluir criterios para sistemas de IA que procesan neurodatos. Tercero, la implementación efectiva de la Ley 21.719 en Chile, cuyo reglamento de datos sensibles aún está en elaboración y podría incorporar criterios alineados con la propuesta de la OCDE.

    • México (LFPDPPP, 2010): datos de salud como sensibles, sin mención a neurodatos ni a IA; INAI sin orientación sectorial específica.
    • Argentina (Ley 25.326): marco de 2000 con datos de salud como sensibles; proyecto de reforma en el Congreso sin incorporar neurodatos todavía.
    • Perú (Ley 29733): datos sensibles incluyen salud; autoridad de control (ANPD-Perú) con capacidad operativa limitada para regulación tecnológica avanzada.

    Nuestro análisis

    La propuesta de la OCDE no es vinculante, pero su peso como referencia de política pública es alto: el AI Act europeo y la LGPD brasileña surgieron de procesos en los que los estándares de la OCDE actuaron como piso de negociación. Para los equipos de gobernanza de datos en la región, el movimiento más inteligente no es esperar la transposición local —que en varios países puede tomar cinco años o más— sino usar el marco como checklist de madurez ahora. La pregunta operativa concreta es si el inventario de datos de la organización tiene una entrada explícita para “neurodatos” o “datos de interfaz neurológica”, con clasificación de sensibilidad, data steward asignado y política de retención definida. Si esa entrada no existe, el riesgo regulatorio ya es presente, no futuro: las leyes de datos sensibles vigentes en Chile, Brasil y Colombia son suficientes para fundamentar una actuación de la autoridad de control si hay una brecha o un uso indebido.

    Mientras los reguladores de la región debaten si los neurodatos necesitan una categoría propia o encajan en las definiciones existentes de datos de salud, las organizaciones que procesan esa información con IA ya tomaron una decisión regulatoria implícita: la ausencia de controles es, en sí misma, una posición de riesgo.