Blog

  • DAMA llega a Kenia: qué significa para la gobernanza de datos en el Sur Global

    DAMA llega a Kenia: qué significa para la gobernanza de datos en el Sur Global

    El lanzamiento oficial de DAMA Kenya extiende la red global de gobernanza de datos al África Oriental, sumando una nueva comunidad de práctica a un framework que ya tiene presencia en más de 50 países. Para la región latinoamericana, el movimiento confirma una tendencia que los CDOs locales deberían leer con atención: los marcos de referencia como el DAMA-DMBOK dejan de ser patrimonio de economías avanzadas y se convierten en infraestructura profesional de mercados emergentes.

    DAMA International —la asociación global dedicada a la gestión y gobernanza de datos— formalizó su capítulo en Kenia según informó CIO Africa. El nuevo capítulo se incorpora a una red que incluye nodos activos en Europa, América del Norte, India, Australia y varios países de América Latina. La iniciativa apunta a profesionalizar el ejercicio de la gestión de datos en un mercado que combina expansión acelerada de infraestructura digital con marcos regulatorios todavía en consolidación.

    Qué es DAMA y qué ofrece el DMBOK a una comunidad que recién se organiza

    DAMA International publica el Data Management Body of Knowledge (DMBOK), el estándar de facto para la disciplina de gestión de datos a nivel global. El DMBOK estructura el campo en once áreas de conocimiento —entre ellas gobernanza de datos, arquitectura, calidad, seguridad, metadatos y master data management (MDM)— y sirve de base para certificaciones profesionales como el CDMP (Certified Data Management Professional). Un capítulo local no solo difunde el framework: organiza exámenes, genera comunidad de práctica y conecta a los profesionales del país con el ecosistema global. Para mercados donde la disciplina de datos no cuenta con una comunidad articulada, ese efecto de red es frecuentemente más valioso que el contenido técnico en sí mismo.

    El patrón de expansión de DAMA y lo que indica para América Latina

    La expansión de DAMA hacia África Oriental sigue un patrón ya visible en América Latina: capítulos que nacen impulsados por consultores y ejecutivos que buscan un lenguaje común con sus pares globales, y que terminan funcionando como catalizadores de demanda de gobernanza formal en sus mercados. En la región, DAMA tiene presencia documentada en Brasil, Argentina, México y Colombia. El capítulo brasileño es el más maduro, con comunidad activa en São Paulo y Rio de Janeiro, y suele articularse con las exigencias que la LGPD (Lei Geral de Proteção de Dados) impone sobre ciclo de vida del dato, lineage y ownership. En Argentina, donde la Ley 25.326 de Protección de los Datos Personales está en proceso de actualización legislativa, los data stewards y CDOs que operan bajo marcos DAMA tienen una ventaja concreta al momento de mapear flujos de datos personales y demostrar accountability ante la Agencia de Acceso a la Información Pública (AAIP).

    Cuándo aplica el modelo de capítulo DAMA / cuándo NO

    Un capítulo DAMA agrega valor real cuando existe una masa crítica de profesionales que ya trabajan con datos de manera sistemática y necesitan certificación, red de pares y actualización continua. No reemplaza una estrategia de gobernanza corporativa ni equivale a adoptar el DMBOK como política interna: son planos distintos. Una organización puede certificar a su equipo en CDMP y operar con una gobernanza de datos deficiente si no hay patrocinio ejecutivo, ownership de dominios definido y procesos de calidad activos. Del mismo modo, un mercado puede tener un capítulo DAMA vibrante y carecer de regulación de datos que exija estándares mínimos. El capítulo es condición necesaria para elevar la madurez del mercado, no condición suficiente.

    Lo que los CDOs de LATAM pueden extraer del caso Kenia

    El lanzamiento de DAMA Kenya es un recordatorio de que la gobernanza de datos se está profesionalizando de forma simultánea en múltiples mercados emergentes. Para un CDO en Ciudad de México, Buenos Aires o Bogotá, eso implica al menos tres lecturas concretas. Primero, la escasez de talento certificado en DMBOK no es exclusiva de LATAM: es un problema global con soluciones locales, y los capítulos son uno de los mecanismos para atacarla. Segundo, los marcos como el CDMC (Cloud Data Management Capabilities) del EDM Council —que comparte terreno con el DMBOK en áreas de calidad y lineage— están siendo adoptados por reguladores financieros de mercados emergentes como referencia de madurez; en Brasil, el Banco Central ya utiliza vocabulario de governance alineado con estos estándares en sus exigencias de open finance. Tercero, la consolidación de comunidades DAMA regionales genera benchmarks comparables: un CDO que participa activamente en su capítulo local puede medir la madurez de su organización contra peers reales, no solo contra cuestionarios genéricos de autoevaluación.

    Para organizaciones que aún no tienen representación formal en DAMA, el momento de evaluar la afiliación corporativa o individual es antes de que la demanda de certificación provenga de un requisito regulatorio o contractual, no después. Los capítulos de Argentina, Brasil, México y Colombia cuentan con información de membresía en el sitio de DAMA International.

    La referencia completa del DAMA-DMBOK v2 está disponible en dama.org; el EDM Council publica el framework CDMC —que incluye los niveles de madurez de cloud data management— en edmcouncil.org.

  • Burger King Japón expone más de 11 millones de registros de clientes

    Burger King Japón expone más de 11 millones de registros de clientes

    Burger King Japón expuso más de 11 millones de registros de clientes en una brecha de datos confirmada, según informó TechRadar el 19 de octubre de 2025. El incidente representa uno de los mayores compromisos de datos en la industria de comida rápida registrados en la región Asia-Pacífico.

    La compañía, que opera su programa de fidelización digital en Japón a través de una aplicación propia, habría dejado al descubierto una base de datos con información personal de más de 11 millones de usuarios, según se informó. No se precisaron públicamente los vectores de ataque ni el período durante el cual los datos estuvieron accesibles. La divulgación del incidente se produjo a través de medios especializados y no mediante una comunicación oficial proactiva de la empresa hacia sus clientes, según la información disponible.

    Datos confirmados del incidente

    • Registros expuestos: más de 11 millones de clientes
    • Empresa afectada: Burger King Japón
    • Fecha de reporte público: 19 de octubre de 2025
    • Sistema comprometido: base de datos del programa de clientes / app de fidelización, según se informó
    • Vector de ataque y período de exposición: no confirmados públicamente

    Qué se sabe y qué falta confirmar

    La información disponible confirma el volumen de registros afectados y la identidad de la empresa, pero no detalla qué categorías de datos personales estuvieron comprometidas —si nombres, correos electrónicos, historiales de compra, datos de pago u otros— ni si el incidente fue producto de un ataque externo, una mala configuración de infraestructura o un acceso interno no autorizado. Tampoco se ha informado si la Comisión de Protección de Información Personal de Japón (PPC), autoridad nacional competente bajo la Ley de Protección de Información Personal (APPI), fue notificada dentro de los plazos legales vigentes. Bajo la APPI reformada, las organizaciones tienen la obligación de reportar brechas que afecten a más de 1.000 personas dentro de los 30 días posteriores a la detección del incidente.

    Para las operaciones de Burger King en América Latina —Brasil, México, Argentina y Colombia entre los mercados principales—, este incidente plantea preguntas directas sobre la arquitectura de datos compartida entre franquicias. Si los sistemas de fidelización digitales de la región comparten infraestructura o proveedores con la operación japonesa, las obligaciones de notificación bajo la LGPD brasileña (Autoridade Nacional de Proteção de Dados, con plazo de 72 horas para brechas de riesgo relevante), la LFPDPPP mexicana o la Ley 25.326 argentina entrarían en juego de forma inmediata. Ninguna de estas jurisdicciones ha emitido pronunciamiento al respecto, según la información disponible a la fecha.

    El próximo hito crítico es la confirmación —o ausencia— de la notificación formal a la PPC japonesa, cuyo plazo máximo bajo la APPI vence 30 días después de que Burger King Japón haya tomado conocimiento del incidente.

  • Ingenieros de seguridad en IA: el rol que más crece mientras el mercado cae

    Ingenieros de seguridad en IA: el rol que más crece mientras el mercado cae

    Las ofertas de empleo en ciberseguridad en Estados Unidos cayeron un 26% según el informe de mercado de CyberSN, pero una categoría va en sentido contrario: los ingenieros de seguridad especializados en inteligencia artificial registran una demanda en ascenso sostenido. La divergencia ilustra una reconfiguración del mercado laboral tech que ya empieza a presionar sobre los perfiles disponibles en América Latina.

    El informe de CyberSN —que agrega datos de JobSpikr y elimina duplicados antes de clasificarlos según su propia taxonomía de 45 roles funcionales en diez categorías— ofrece una lectura más precisa que los simples conteos de vacantes. En lugar de registrar el título que usa cada empresa reclutadora, el estudio mapea las habilidades requeridas. Esa metodología permite detectar señales que los rankings convencionales oscurecen: el mercado general retrocede, pero la demanda de profesionales capaces de asegurar sistemas de IA está creciendo.

    Qué distingue al AI Security Engineer del analista de ciberseguridad tradicional

    El perfil de AI Security Engineer no es una variante cosmética del rol clásico de seguridad. Combina conocimiento de amenazas tradicionales —gestión de vulnerabilidades, control de accesos, respuesta a incidentes— con capacidades específicas para entornos de modelos de lenguaje y sistemas de aprendizaje automático: evaluación de riesgo en pipelines de datos de entrenamiento, detección de ataques adversariales, auditoría de outputs de modelos y gobernanza de APIs expuestas a sistemas de IA. La superposición con marcos regulatorios también es parte del cargo: en la Unión Europea, el AI Act ya clasifica ciertos sistemas como de alto riesgo y exige medidas técnicas de seguridad documentadas; en América Latina, varios proyectos de ley en trámite —como el de Colombia y la propuesta argentina de 2024— incorporan lenguaje similar sobre evaluación de riesgos en sistemas automatizados.

    Por qué cae el total de vacantes mientras sube una categoría específica

    La caída del 26% en el total de publicaciones no responde a un desinterés por la ciberseguridad, sino a una combinación de factores: consolidación presupuestaria en el sector tecnológico estadounidense, automatización de tareas antes asignadas a analistas de nivel junior, y una reorientación de la inversión hacia capacidades más especializadas. El resultado es un mercado con menos vacantes totales pero con una demanda más concentrada y con requisitos más exigentes. Para los profesionales de la región que buscan posicionarse en el mercado global —o en las subsidiarias locales de empresas multinacionales—, la señal es clara: la brecha entre perfiles genéricos y perfiles de alta especialización se está ampliando.

    Cuándo aplica esta tendencia al mercado latinoamericano / cuándo NO

    La demanda de AI Security Engineers está, por ahora, concentrada principalmente en Estados Unidos y Europa Occidental. En América Latina, el mercado local de ciberseguridad especializada en IA aún es incipiente: la mayoría de las organizaciones regionales —salvo grandes bancos, fintechs y telecomunicadoras— no tienen presupuesto ni madurez operativa para contratar este perfil de manera autónoma. Donde sí aplica de forma inmediata es en tres contextos: profesionales de la región que trabajen de forma remota para empresas norteamericanas o europeas; equipos de seguridad de corporaciones multinacionales con operaciones en LATAM que replican los estándares de su casa matriz; y organismos reguladores que necesitan capacidad técnica interna para supervisar sistemas de IA en sectores críticos. En cambio, una pyme colombiana o una startup chilena difícilmente formule una búsqueda con este perfil específico en el corto plazo.

    Brasil, México y Argentina: señales regulatorias que aceleran la demanda

    El contexto regulatorio latinoamericano está creando condiciones para que este perfil gane relevancia más rápido de lo esperado. En Brasil, la Autoridade Nacional de Proteção de Dados (ANPD) ha avanzado en lineamientos sobre decisiones automatizadas en el marco de la LGPD (Lei 13.709/2018), lo que obliga a las empresas a documentar cómo sus modelos de IA procesan datos personales —una tarea que requiere exactamente las capacidades de un AI Security Engineer. En México, el INAI supervisa el cumplimiento de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) en contextos donde el uso de IA genera tratamientos automatizados. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) publicó en 2024 recomendaciones sobre el uso de inteligencia artificial por organismos públicos. Ninguno de estos marcos exige formalmente el título “AI Security Engineer”, pero todos están generando requerimientos técnicos que ese perfil está diseñado para cubrir.

    Para quienes gestionan talento o definen estrategias de seguridad en organizaciones con exposición regulatoria en la región, la pregunta relevante no es si este perfil llegará a LATAM, sino qué tan preparados estarán los equipos locales cuando la demanda lo haga obligatorio.

  • Colombia supera la OCDE en gobierno digital, pero la integración de datos públicos es su talón de Aquiles

    Colombia supera la OCDE en gobierno digital, pero la integración de datos públicos es su talón de Aquiles

    Colombia logró posicionarse por encima del promedio de la OCDE en madurez de gobierno digital, según se informó a partir de la edición más reciente del índice de la organización. El dato es relevante en una región donde Brasil, México y Argentina aún consolidan sus marcos de interoperabilidad. Sin embargo, el diagnóstico también expone una brecha estructural: superar métricas de adopción tecnológica no equivale a tener datos públicos integrados, interoperables y gobernados de manera coherente.

    Qué mide la OCDE y dónde quedó Colombia en el índice 2025

    El índice de Gobierno Digital de la OCDE evalúa seis dimensiones: digital by design, gobierno impulsado por datos, gobierno como plataforma, gobierno abierto, proactividad y fiabilidad. Colombia habría obtenido una puntuación agregada que supera el promedio de los 38 miembros plenos de la organización, según se informó desde Portafolio.co. El logro no es menor: el país no es miembro pleno de la OCDE —aunque se encuentra en proceso de adhesión— y compite en el índice junto a naciones con infraestructuras digitales consolidadas desde hace más de una década.

    La dimensión donde Colombia acusa mayor rezago, según la misma fuente, es la integración de servicios: la capacidad de que distintas entidades del Estado compartan datos entre sí para ofrecer trámites sin fricción al ciudadano. Esa brecha no es técnica en su origen —es de gobernanza: quién es el responsable del dato, bajo qué condiciones se comparte, quién resuelve conflictos de calidad o clasificación entre entidades.

    La Ley 1581 de 2012 y el Decreto 1413 de 2023 como marco de fondo

    Colombia opera su ecosistema de datos públicos bajo un doble marco normativo. Por un lado, la Ley Estatutaria 1581 de 2012 regula la protección de datos personales y establece restricciones al intercambio de información entre entidades públicas cuando ese intercambio involucra datos de ciudadanos. Por otro, el Decreto 1413 de 2023 —que adopta la Política de Gobierno Digital— obliga a las entidades del orden nacional a implementar estándares de interoperabilidad a través de la plataforma X-Road Colombia, adaptación local del sistema estonio. La tensión entre ambos marcos es real: los equipos jurídicos de muchas entidades interpretan la Ley 1581 como un freno al intercambio de datos, cuando en rigor la norma permite el tratamiento con base legal distinta al consentimiento si existe una función pública legítima.

    El Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC) y el Departamento Nacional de Planeación (DNP) comparten responsabilidad en este ecosistema, pero la línea de ownership sobre los datos sectoriales —salud, tributario, registral— sigue siendo difusa. Esa difusión de responsabilidad es exactamente lo que los marcos de gobernanza de datos describen como ausencia de data stewardship efectivo a nivel organizacional.

    Brasil, México y Chile: tres modelos de integración con distinto grado de madurez

    La comparación regional permite calibrar dónde está parada Colombia. Brasil avanzó con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) y, en paralelo, con el programa Conecta Gov, que articula APIs entre ministerios bajo supervisión de la Secretaria de Governo Digital (SGD). La ANPD brasileña ha emitido resoluciones específicas sobre el tratamiento de datos en contexto de gobierno digital, lo que da certeza jurídica al intercambio intersectorial. México, por su parte, opera la Plataforma Nacional de Transparencia bajo el INAI, pero la fragmentación entre poderes federales y estados hace que la interoperabilidad sea más aspiracional que efectiva; la LFPDPPP aplica al sector privado y la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados (2017) regula el sector público, aunque su enforcement sigue siendo inconsistente. Chile presenta el caso más avanzado en términos de diseño institucional: la Ley 21.719 de Protección de Datos Personales —promulgada en 2024— contempla disposiciones específicas para el tratamiento por parte de órganos del Estado y establece la futura Agencia de Protección de Datos con competencia sobre el sector público, algo que Colombia todavía no tiene de manera plena con la Superintendencia de Industria y Comercio (SIC).

    Por qué el dato de integración importa más que el ranking agregado

    Un índice agregado puede enmascarar desequilibrios internos. Que Colombia puntúe bien en dimensiones como gobierno abierto o proactividad —donde la publicación de datasets y la comunicación proactiva al ciudadano suman puntos— no resuelve el problema operativo de que un trámite de subsidio habitacional requiera que el ciudadano aporte documentación que el Estado ya posee en otro sistema. Esa fricción tiene un costo medible: según estimaciones del Banco Mundial para países de ingreso medio-alto, la falta de interoperabilidad en servicios públicos puede representar hasta un 2% del PIB en ineficiencia administrativa acumulada. Colombia no ha publicado una estimación propia de ese costo.

    Para los equipos de gobernanza de datos en el sector público colombiano, el diagnóstico de la OCDE es una palanca de gestión concreta. El Modelo de Gestión de Datos del sector público colombiano —articulado en la Guía para la Gestión de Datos del MinTIC— tiene correspondencia con el marco DAMA-DMBOK en sus componentes de calidad, integración y metadatos, pero su adopción efectiva por entidad varía de manera significativa. La ausencia de un catálogo de datos centralizado con ownership asignado por dominio es el punto de mayor fricción.

    Nuestro análisis: el riesgo de confundir madurez digital con gobernanza de datos

    El resultado de Colombia en el índice OCDE es genuinamente positivo y merece reconocimiento. Pero el riesgo político de un ranking favorable es que desvía la atención de las brechas que el propio índice señala. La dimensión de integración de servicios no es un detalle técnico: es el test de si el Estado puede operar como una plataforma de datos coherente o si sigue siendo un archipiélago de silos. La OCDE, en sus recomendaciones de Gobierno Digital de 2022 (OECD Recommendation on Digital Government Strategies), es explícita al señalar que la interoperabilidad requiere acuerdos de gobernanza antes que infraestructura tecnológica. Colombia tiene la infraestructura —X-Road funciona— pero los acuerdos de gobernanza intersectorial siguen siendo ad hoc, bilaterales y frágiles ante cambios de gobierno.

    El punto de acción más urgente no es técnico: es definir quién tiene autoridad para resolver desacuerdos de datos entre entidades. Esa figura —equivalente a un data steward ejecutivo con mandato transversal— no existe formalmente en el organigrama del Estado colombiano. Mientras no exista, cada integración de servicios será una negociación política, no un proceso gobernado.

    Superar a la OCDE en el promedio agrega un logro al historial; resolver la integración de datos públicos sería el argumento real para la adhesión plena.

  • Multa de USD 2,7 M por brecha en datos de menores: NY y CT responsabilizan al proveedor TI

    Multa de USD 2,7 M por brecha en datos de menores: NY y CT responsabilizan al proveedor TI

    Los fiscales generales de Nueva York y Connecticut obtuvieron USD 2,7 millones de Boston Children’s Health Physicians (BCHP) y su proveedor de tecnología XTIUM por una brecha de datos ocurrida en 2024 que comprometió información sensible de pacientes pediátricos. El acuerdo establece además un plan de acción correctiva en materia de seguridad.

    La fiscal general de Nueva York, Letitia James, y su par de Connecticut, William Tong, anunciaron el 17 de octubre de 2026 el cierre del caso contra BCHP y XTIUM, el proveedor de servicios de TI que gestionaba la infraestructura del sistema de salud. El punto central del acuerdo es la responsabilidad compartida: ambas entidades —la organización de salud y su contratista tecnológico— fueron consideradas legalmente responsables por las deficiencias que permitieron el incidente, según se informó.

    Proveedor externo como vector: el dato que cambia la ecuación

    La decisión de extender la responsabilidad a XTIUM marca un precedente relevante en la cadena de custodia de datos sensibles. No es habitual que una fiscalía estatal imponga obligaciones formales —y parte de la sanción económica— sobre un proveedor de TI tercerizado, en lugar de limitarse al titular del dato. El acuerdo implica que XTIUM deberá cumplir con el plan correctivo junto a BCHP, lo que convierte al contratista en un actor regulado de facto, según se informó.

    Datos confirmados

    • Monto total del acuerdo: USD 2,7 millones
    • Entidades sancionadas: Boston Children’s Health Physicians (BCHP) y XTIUM (proveedor de TI)
    • Fiscalías intervinientes: Nueva York (AG Letitia James) y Connecticut (AG William Tong)
    • Año del incidente: 2024
    • Acuerdo incluye: plan de acción correctiva para mejorar la seguridad de datos
    • Fecha del anuncio: 17 de octubre de 2026

    Qué se sabe y qué falta confirmar

    Se confirmó que el incidente involucró datos de pacientes pediátricos y que derivó en una acción coordinada entre dos fiscalías estatales. No se han divulgado públicamente el volumen exacto de registros comprometidos, el vector técnico específico del ataque ni el desglose de la multa entre BCHP y XTIUM. Tampoco está claro si el plan correctivo exige certificación externa o auditorías periódicas, según se informó.

    Para organizaciones de salud en América Latina, el caso enciende una señal de alerta directa. En Argentina, la Ley 25.326 de Protección de Datos Personales —actualmente en proceso de reforma legislativa— no establece expresamente la responsabilidad solidaria de proveedores TI, una laguna que el proyecto de actualización busca cerrar siguiendo el modelo del GDPR europeo. En Brasil, la LGPD (Lei 13.709/2018) ya contempla la figura del “operador” con obligaciones propias, lo que coloca a los proveedores de servicios en una posición jurídica más cercana al escenario que acaban de enfrentar BCHP y XTIUM en EE.UU. Hospitales, clínicas y redes de salud de la región que tercerizan su infraestructura de datos sin cláusulas contractuales de responsabilidad compartida operan hoy con un riesgo legal subvaluado.

    El próximo hito a seguir es la publicación del plan de acción correctiva acordado entre BCHP, XTIUM y las fiscalías, que definirá los estándares técnicos y plazos de cumplimiento que podrían convertirse en referencia para reguladores de la región.

  • Agentes de IA y ciberataques: el vacío regulatorio que Chile aún no cerró

    Agentes de IA y ciberataques: el vacío regulatorio que Chile aún no cerró

    Los agentes de inteligencia artificial autónomos abren una nueva categoría de riesgo jurídico que los marcos regulatorios vigentes en Chile —y en gran parte de América Latina— no contemplaron: la de un sistema que actúa, decide y puede causar daño sin intervención humana directa en cada paso. La pregunta sobre quién responde cuando un agente de IA es el vector de un ciberataque no tiene hoy una respuesta legal clara en la región.

    Un agente de IA no es un chatbot que responde preguntas. Es un sistema capaz de planificar secuencias de acciones, ejecutarlas en entornos digitales reales —navegar sitios, escribir código, enviar correos, interactuar con APIs— y adaptarse a los resultados de cada paso sin que un humano apruebe cada decisión. Esa autonomía operativa es precisamente lo que los convierte en herramientas de alto valor para ciberataques sofisticados: pueden escalar ataques de phishing, explorar vulnerabilidades de forma sistemática o exfiltrar datos con una velocidad y personalización que supera ampliamente la capacidad humana.

    Chile ante un marco legal diseñado para amenazas del pasado

    Chile cuenta con la Ley 21.663, promulgada en 2024, que modernizó el marco de delitos informáticos alineándolo con el Convenio de Budapest. Sin embargo, esa norma fue diseñada con el paradigma del atacante humano: alguien que accede, alguien que intercepta, alguien que daña. Cuando el agente que ejecuta las acciones es un sistema autónomo de IA, la cadena de atribución de responsabilidad se fragmenta entre el desarrollador del modelo, el operador que lo desplegó, el usuario que lo instruyó —o nadie, si el agente actuó por derivación de sus propios objetivos entrenados. La Ley Marco de Ciberseguridad (Ley 21.459, vigente desde 2023) obliga a operadores de infraestructura crítica a reportar incidentes ante la Agencia Nacional de Ciberseguridad (ANCI), pero no define criterios específicos para incidentes mediados por sistemas de IA.

    El proyecto de ley de inteligencia artificial que Chile tiene en tramitación legislativa sigue un enfoque de riesgos inspirado en el AI Act de la Unión Europea, pero a la fecha no ha sido aprobado. Eso significa que el país enfrenta la proliferación de agentes de IA sin una norma vigente que establezca qué obligaciones tienen quienes los desarrollan o despliegan cuando esos sistemas participan —de forma activa o como vector explotado— en un incidente de seguridad.

    Responsabilidad civil y penal: el nudo que el AI Act europeo tampoco resolvió del todo

    La Unión Europea aprobó el AI Act en 2024, clasificando los sistemas de IA por niveles de riesgo. Los agentes con capacidad de acción autónoma en entornos abiertos pueden caer en la categoría de “alto riesgo” o incluso enfrentar restricciones específicas, dependiendo del dominio de uso. Pero el AI Act es un marco de gobernanza y certificación, no un régimen de responsabilidad civil directa: para eso, la Comisión Europea trabaja en paralelo con la revisión de la Directiva de Responsabilidad por Productos Defectuosos. Chile y el resto de América Latina observan ese proceso como referencia, pero sin un equivalente regional consolidado. Brasil, cuyo Proyecto de Ley 2.338/2023 de regulación de IA avanza en el Senado, es el país de la región que más ha progresado en definir obligaciones para sistemas de alto riesgo, aunque tampoco ha cerrado el capítulo de responsabilidad por daños causados por agentes autónomos.

    Cuándo aplica la regulación vigente y cuándo no

    La regulación actual en Chile cubre los efectos del ciberataque —acceso no autorizado, daño a sistemas, interrupción de servicios— con independencia de si el vector fue humano o automatizado. En ese sentido, las obligaciones de reporte a la ANCI se activan ante el incidente, no ante su causa. Lo que no cubre es la responsabilidad prospectiva del desarrollador o desplegador de un agente de IA que fue el instrumento del ataque, ni establece estándares de diseño seguro para esos sistemas. Tampoco existe en Chile —ni en Argentina, México o Colombia— una obligación legal de realizar evaluaciones de impacto de seguridad antes de desplegar agentes de IA en entornos críticos, algo que el AI Act europeo sí exige para sistemas de alto riesgo.

    El escenario cambia si el agente de IA procesa datos personales durante el ataque o como parte de su funcionamiento normal. En ese caso, la Ley 21.719 de protección de datos personales —aprobada en Chile en 2024 y con entrada en vigor gradual— establece obligaciones de seguridad y notificación a la Agencia de Protección de Datos Personales que sí aplican, con independencia de si el incidente fue causado por un agente autónomo o por un humano.

    El vector de ataque más subestimado: el agente comprometido desde adentro

    El riesgo más inmediato no es necesariamente que un actor malicioso construya un agente de IA para atacar desde afuera. Es que un agente desplegado internamente en una organización —para automatizar procesos, gestionar correos, interactuar con sistemas internos— sea manipulado mediante técnicas de prompt injection para exfiltrar información, escalar privilegios o ejecutar acciones no autorizadas. Este vector combina las vulnerabilidades propias de los modelos de lenguaje con el acceso legítimo que la organización ya le concedió al agente. En términos de gobernanza, es equivalente a una cuenta de servicio con permisos excesivos y sin auditoría: un problema conocido, pero potenciado por la capacidad del agente de razonar y adaptarse. Las organizaciones que ya desplegaron agentes de IA en Chile —y en toda la región— operan en su mayoría sin políticas formales de gestión de esos sistemas, sin inventarios de los accesos que tienen y sin procedimientos de respuesta específicos para incidentes donde el agente es parte del vector.

    Para profundizar en el marco regulatorio vigente, la Ley 21.719 de protección de datos personales de Chile y la Ley Marco de Ciberseguridad 21.459 están disponibles en el sitio del Diario Oficial de Chile; el texto consolidado del AI Act europeo puede consultarse en el Diario Oficial de la Unión Europea (OJ L, 2024/1689).

  • Ciberpatrullaje estatal, vigilancia y filtraciones: quién accede a tus datos y bajo qué marco legal

    Ciberpatrullaje estatal, vigilancia y filtraciones: quién accede a tus datos y bajo qué marco legal

    El Estado puede monitorear perfiles públicos en redes sociales sin orden judicial en varios países de América Latina, mientras que las filtraciones de bases de datos oficiales siguen sin tener consecuencias legales claras para los responsables. La pregunta no es si existe vigilancia digital, sino bajo qué reglas opera y quién controla a quienes controlan.

    El ciberpatrullaje —la práctica por la cual agencias estatales rastrean actividad en plataformas digitales, foros y redes sociales con fines de inteligencia, investigación penal o seguridad pública— existe en prácticamente todos los países de la región. Lo que varía dramáticamente entre jurisdicciones es si esa actividad tiene base legal expresa, control judicial previo y algún mecanismo de rendición de cuentas. En la mayoría de los casos, ninguna de las tres condiciones se cumple de forma completa.

    Tres actores con acceso a datos personales, tres lógicas distintas

    Cuando hablamos de quién tiene acceso a nuestros datos, hay que separar al menos tres tipos de actores con lógicas radicalmente diferentes. Primero, las plataformas privadas —Meta, Google, X, TikTok— que recolectan datos de comportamiento para fines publicitarios y los entregan a gobiernos cuando reciben una orden legal válida, o incluso antes si sus políticas internas lo permiten. Segundo, los Estados, que acceden a datos tanto mediante requerimientos formales a plataformas como a través de sistemas propios de vigilancia: scrapers de redes, software de análisis de contenido público, o herramientas de inteligencia de fuentes abiertas (OSINT). Tercero, actores no autorizados —desde grupos criminales hasta ex empleados con acceso residual— que obtienen datos mediante filtraciones, vulneración de sistemas o compra en mercados ilegales.

    La combinación de los tres flujos crea un ecosistema donde los datos de una persona pueden circular entre sistemas privados, estatales e ilegales sin que esa persona tenga forma práctica de saberlo, ni mucho menos de impedirlo.

    Ciberpatrullaje en Argentina, México y Brasil: distinto encuadre legal, misma opacidad

    En Argentina, la Ley 25.326 de Protección de Datos Personales establece que el tratamiento de datos por parte del Estado debe tener finalidad explícita y base legal, pero no contempla de forma específica el ciberpatrullaje como actividad regulada. La Agencia de Acceso a la Información Pública (AAIP) tiene competencia para fiscalizar archivos estatales, pero su capacidad de auditar operaciones de inteligencia digital es, en la práctica, muy limitada. El debate se agudizó con el uso de herramientas de monitoreo de redes durante protestas sociales, sin que exista un marco normativo que defina qué puede observarse, por cuánto tiempo y con qué autorización.

    En México, la LFPDPPP rige para el sector privado; el sector público se regula por la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados (LGPDPPSO), sancionada en 2017. Esta ley obliga a las dependencias a publicar avisos de privacidad y a designar un responsable, pero las áreas de seguridad nacional quedan expresamente fuera de su ámbito. El Instituto Nacional de Transparencia (INAI) puede investigar a entidades públicas, pero no a las fuerzas de seguridad cuando actúan bajo la lógica de inteligencia. En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) tiene excepciones similares: el artículo 4 excluye del régimen general el tratamiento de datos para seguridad pública, defensa nacional e investigación penal, delegando esa regulación a legislación específica que aún no existe en forma completa.

    Cuándo aplica la ley de protección de datos y cuándo no

    Esta es la delimitación que más frecuentemente se omite en el debate público. Las leyes de protección de datos personales de la región —Ley 25.326 en Argentina, LGPD en Brasil, Ley 19.628 y su reforma en Chile, Ley 1581 en Colombia, Ley 29733 en Perú— protegen al individuo frente al tratamiento de sus datos por parte de empresas y, en distintos grados, frente al Estado actuando en su función administrativa ordinaria. No aplican, o aplican con excepciones amplias, cuando el Estado actúa en funciones de seguridad, inteligencia o investigación penal. Esa brecha es sistémica y reconocida: el Convenio 108+ del Consejo de Europa, que varios países de la región toman como referencia, exige que incluso esas excepciones sean proporcionadas, necesarias y sujetas a control independiente —condiciones que rara vez se verifican en la práctica regional.

    Las filtraciones de bases de datos estatales —padrones electorales, registros de salud, sistemas de beneficios sociales— caen en una zona gris adicional: técnicamente el Estado es “víctima” de la brecha, pero también es responsable de no haber implementado medidas de seguridad adecuadas. Las leyes de protección de datos de la región imponen esa obligación de seguridad, pero las sanciones por incumplimiento son bajas y los procesos de fiscalización, lentos.

    El dato que falta: registros de acceso y auditoría sobre bases estatales

    Lo que distingue a los sistemas de mayor madurez regulatoria no es solo la existencia de una ley, sino la existencia de controles técnicos auditables: logs de acceso a bases de datos sensibles, políticas de retención documentadas, auditorías periódicas por organismos independientes y mecanismos de notificación al titular cuando sus datos fueron consultados o comprometidos. En la región, esos controles son la excepción. Los marcos de referencia como el NIST Privacy Framework o el estándar ISO/IEC 29101 proveen arquitecturas concretas para implementarlos, pero su adopción en el sector público latinoamericano es incipiente y voluntaria.

    Mientras ese déficit persista, el debate sobre ciberpatrullaje y filtraciones seguirá siendo político antes que técnico-jurídico: quién tiene acceso a nuestros datos dependerá menos del marco legal vigente y más de quién gobierna y con qué criterio decide usar esa capacidad.

    Para profundizar en el marco regional, el texto del Convenio 108+ y los informes de adecuación de la Comisión Europea sobre países de América Latina son el punto de partida más riguroso disponible públicamente.

  • Rusia detiene a tres presuntos miembros del grupo DataSuckers por brecha en Dodo Pizza

    Rusia detiene a tres presuntos miembros del grupo DataSuckers por brecha en Dodo Pizza

    Autoridades rusas detuvieron a tres presuntos integrantes del grupo de hackers DataSuckers tras un ciberataque a la cadena de comida rápida Dodo Pizza que expuso datos de clientes a gran escala. Un tribunal de Moscú ordenó el miércoles 15 de octubre arresto domiciliario para Denis Fridman, de 19 años, hasta el 8 de diciembre, según se informó.

    El caso se originó en el ataque a Dodo Pizza, una cadena de restaurantes de alcance internacional con presencia en varios países de Europa del Este y Asia Central. Según se informó, la brecha expuso cantidades significativas de información de clientes, aunque el volumen exacto de registros comprometidos no fue confirmado públicamente por las autoridades rusas al cierre de esta nota. La detención de Fridman fue reportada por Daryna Antoniuk para DataBreaches.net, con base en la resolución del tribunal moscovita.

    DataSuckers: un grupo con víctimas en Rusia y Ucrania

    DataSuckers habría estado activo en operaciones que afectaron a organizaciones tanto en Rusia como en Ucrania, lo que convierte este caso en un episodio inusual: la persecución penal dentro del propio territorio ruso de actores que también operaron contra objetivos ucranianos. La coexistencia de víctimas en ambos países no es un detalle menor en el contexto del conflicto en curso, aunque las autoridades no precisaron si las investigaciones sobre los ataques en Ucrania forman parte del expediente judicial abierto en Moscú.

    Datos confirmados y estado del proceso

    • Tres personas detenidas, presuntos miembros de DataSuckers, según se informó.
    • Denis Fridman, 19 años, bajo arresto domiciliario hasta el 8 de diciembre de 2026.
    • El tribunal que dictó la medida cautelar tiene sede en Moscú.
    • El ataque afectó a Dodo Pizza, cadena con operaciones en múltiples países.
    • El grupo es vinculado a brechas en organizaciones rusas y ucranianas.
    • Volumen de registros expuestos: no confirmado oficialmente.

    Qué se sabe: un tribunal dictó medidas cautelares, al menos un imputado está identificado con nombre y edad, y el ataque a Dodo Pizza es el disparador procesal. Qué falta confirmar: la identidad de los otros dos detenidos, los cargos formales, el alcance real de la brecha en términos de registros y categorías de datos afectados, y si existe coordinación con autoridades de otros países donde Dodo Pizza opera. Tampoco está confirmado si los atacantes tenían motivación económica, política o una combinación de ambas.

    Para las organizaciones con operaciones en América Latina que manejan datos de clientes en escala similar —cadenas de retail, plataformas de delivery, restaurantes con programas de fidelización—, el caso reitera una brecha de gobernanza frecuente: la ausencia de clasificación formal de datos de clientes y controles de acceso granulares que permitan detectar exfiltración masiva antes de que se materialice el daño. En jurisdicciones como Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga a notificar a la Autoridade Nacional de Proteção de Dados (ANPD) dentro de un plazo razonable tras tomar conocimiento de un incidente; en Argentina, la Ley 25.326 y las disposiciones de la AAIP imponen obligaciones similares. El incumplimiento de esos plazos agrava la exposición regulatoria más allá del daño reputacional.

    El próximo hito procesal es el 8 de diciembre, fecha límite del arresto domiciliario de Fridman, cuando el tribunal deberá resolver si extiende la medida o avanza hacia una imputación formal.

  • Por qué escalar IA más allá de las POC exige gobernanza de datos primero

    Por qué escalar IA más allá de las POC exige gobernanza de datos primero

    Empresas de Argentina y Chile están atascadas en el mismo punto: los pilotos de inteligencia artificial funcionan, pero no escalan. El cuello de botella rara vez es el modelo; casi siempre es la gobernanza de datos que debería sostenerlo.

    Superar la prueba de concepto (POC, por sus siglas en inglés) es el desafío que hoy define la madurez de IA corporativa en la región, según informó Revista Mercado. El patrón es repetido: un equipo de datos construye un prototipo convincente, la dirección aprueba presupuesto, y el proyecto se frena cuando intenta consumir datos productivos a escala. Los datos no tienen dueño claro, no están catalogados, los pipelines no están documentados y el modelo entrenado en el sandbox no puede replicarse en producción con los controles que el negocio exige.

    El gap entre POC y producción: un problema de ownership, no de algoritmos

    En el marco DAMA-DMBOK, la transición de un piloto a un sistema productivo activa al menos cuatro capabilities críticas: calidad de datos, integración y arquitectura, seguridad de datos, y metadatos. Cuando esas capabilities no están operativas, el modelo de IA hereda los problemas del dato subyacente — sesgo, inconsistencia, falta de linaje — y falla en producción de maneras que son difíciles de diagnosticar si no existe un data catalog con trazabilidad activa. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica el ownership del dato como prerequisito del nivel 3 de madurez; sin un data steward asignado por dominio, los proyectos de IA corporativa no avanzan más allá del nivel 1.

    El data lineage — la trazabilidad end-to-end de cada atributo desde su origen hasta el consumo por el modelo — no es un lujo técnico: es el mecanismo que permite a un auditor o a un regulador entender por qué el sistema tomó una decisión. En Argentina, esto adquiere relevancia concreta: la Agencia de Acceso a la Información Pública (AAIP) tiene competencia para examinar tratamientos automatizados de datos personales bajo la Ley 25.326, y cualquier sistema de IA que tome decisiones con impacto en personas físicas puede quedar alcanzado por esa obligación de transparencia.

    Qué falla estructuralmente en las organizaciones argentinas y chilenas

    Tres patrones se repiten en la región cuando los proyectos de IA no logran salir de la POC:

    • Datos sin clasificación ni ownership: los atributos no tienen un data steward responsable, lo que impide aplicar controles de acceso granulares cuando el modelo pasa a operar sobre datos sensibles o regulados.
    • Ausencia de catálogo activo: los equipos de IA descubren en producción que los datos que usaron en el piloto no estaban autorizados para ese uso, o que su definición de negocio difiere entre sistemas fuente.
    • Linaje no documentado: cuando el modelo produce un resultado inesperado, no existe forma de trazar qué dato de entrada lo causó, lo que hace imposible la corrección sistemática y el cumplimiento de obligaciones de explicabilidad.

    En Chile, el escenario regulatorio agrega presión adicional: la Ley 21.719 de protección de datos personales, promulgada en 2024, incorpora principios de minimización y finalidad que obligan a revisar si los datos usados para entrenar modelos fueron recolectados con un propósito compatible. Esa validación requiere linaje y un inventario de datos actualizado — exactamente lo que falta en la mayoría de las organizaciones que hoy tienen POCs detenidas.

    Cuándo aplica el problema de gobernanza / cuándo NO

    No todos los proyectos de IA atascados tienen un problema de gobernanza de datos. Si el piloto opera sobre datos sintéticos o sobre un dataset acotado y estático que ya está bajo control, el cuello de botella puede ser de infraestructura, de change management o de modelo de negocio. El problema de gobernanza es determinante cuando el escalado implica incorporar datos de múltiples sistemas fuente, cuando los datos incluyen información personal o regulada, o cuando el modelo debe operar en tiempo real sobre flujos de datos en producción. En esos escenarios — que describen la mayoría de los casos corporativos relevantes en banca, retail y salud en Argentina y Chile — la gobernanza no es paralela al proyecto de IA: es su prerequisito.

    El paso concreto que los equipos de datos pueden dar esta semana

    Antes de escalar cualquier POC de IA, un Chief Data Officer o Data Governance Manager debería ejecutar un inventario de los dominios de datos que el modelo consumirá en producción y verificar tres condiciones: que cada dominio tenga un data steward nombrado con responsabilidad formal, que los atributos clave estén catalogados con definición de negocio acordada, y que el linaje desde el sistema fuente hasta el modelo esté documentado al menos a nivel de dataset. Si alguna de esas tres condiciones no se cumple, el escalado va a encontrar el mismo muro que encontraron los pilotos anteriores. No es necesario completar un programa de gobernanza full antes de avanzar — la táctica correcta, en línea con el enfoque de Non-Invasive Data Governance de Bob Seiner, es asignar stewardship sobre los dominios específicos que el proyecto de IA necesita, no sobre toda la organización a la vez.

    El marco regulatorio de Argentina y Chile ya exige respuestas sobre el origen y el uso de los datos en sistemas automatizados; la pregunta para los equipos de datos no es si van a necesitar gobernanza, sino si la van a construir antes o después del próximo piloto fallido.

  • La apuesta de 5 billones en IA: quién paga la cuenta

    La apuesta de 5 billones en IA: quién paga la cuenta

    El financiamiento público y las políticas de compra gubernamental están subsidiando de forma silenciosa la expansión de las grandes plataformas de inteligencia artificial. Amba Kak, codirectora ejecutiva del AI Now Institute, sostiene que la concentración del poder tecnológico en un puñado de empresas no es un resultado inevitable del mercado, sino el producto de decisiones regulatorias que la sociedad termina pagando.

    La cifra es orientadora aunque no siempre se desglosa con precisión: el ecosistema de IA generativa opera sobre apuestas de capital que, sumadas las valuaciones proyectadas y los contratos públicos asociados, rondan los cinco billones de dólares a nivel global, según se informó. Lo que rara vez aparece en los titulares es quién absorbe el riesgo cuando esas apuestas fallan o cuando el retorno tarda más de lo prometido. La respuesta, argumenta el AI Now Institute, es la ciudadanía: a través de contratos estatales, exenciones fiscales, subsidios a infraestructura y tarifas de servicios públicos que financian los centros de datos.

    Concentración de mercado y el rescate silencioso a las Big Tech de IA

    El patrón que describe Kak no es nuevo en la historia de la tecnología: una industria emergente recibe apoyo estatal masivo durante su fase de riesgo y, una vez consolidada, captura la regulación que debería supervisarla. Lo que distingue al ciclo actual es la velocidad y la escala. Los modelos de lenguaje de gran tamaño requieren inversiones en cómputo que solo unas pocas empresas —Microsoft, Google, Amazon, Meta y, en menor medida, startups como OpenAI o Anthropic respaldadas por ellas— pueden costear. Eso convierte la infraestructura de IA en un oligopolio de hecho antes de que exista un marco regulatorio que lo aborde. El resultado es que las barreras de entrada no las fija el mérito tecnológico sino el acceso al capital y a los contratos públicos.

    La narrativa del “rescate” no implica transferencias directas en todos los casos, sino una combinación de mecanismos menos visibles: contratos de computo en la nube con agencias gubernamentales, financiamiento de investigación universitaria que luego se privatiza, y el uso de datos producidos por el sector público para entrenar modelos comerciales. Según se informó en el episodio del podcast Agents of Tech donde participó Kak, este proceso equivale a socializar el costo y privatizar el beneficio.

    Cuándo aplica el argumento regulatorio y cuándo no

    El análisis del AI Now Institute es más pertinente cuando se trata de infraestructura crítica —cómputo, datos de salud, sistemas de decisión en beneficios sociales— que cuando se aplica a productos de consumo masivo donde la competencia, aunque imperfecta, existe. No toda inversión privada en IA equivale a captura regulatoria, y no todo contrato público con una empresa tecnológica constituye un subsidio encubierto. La distinción relevante es si el Estado podría recuperar el activo generado —datos, modelos, infraestructura— o si ese valor queda privatizado de forma permanente. Cuando la respuesta es la segunda, el argumento sobre quién paga la apuesta cobra fuerza.

    América Latina: contratos públicos de IA sin marcos de transparencia equivalentes

    En la región, la dinámica de subsidio público a la IA privada adopta formas propias. Brasil ha avanzado con la Estratégia Nacional de Inteligência Artificial (EBIA) y su revisión de 2024, pero la mayoría de los contratos de implementación de IA en organismos federales y estaduales se adjudican a subsidiarias de los mismos conglomerados globales señalados por el AI Now Institute, sin requisitos de apertura de modelos ni de compartición de datos derivados. En México, el uso de herramientas de IA en el sector salud y en el sistema tributario del SAT también opera sobre acuerdos con proveedores privados cuyas condiciones de licencia no son públicas. Argentina, por su parte, carece aún de una política nacional de IA con fuerza de ley, lo que deja los contratos de este tipo bajo la discrecionalidad administrativa de cada organismo. En ninguno de estos casos existe hoy un mecanismo formal para que el Estado recupere valor de los datos que aporta como insumo al entrenamiento de modelos comerciales.

    La ausencia de marcos de gobernanza para contratos de IA pública no es solo un problema de transparencia: es un problema de soberanía sobre infraestructura crítica. Cuando un ministerio de salud cede registros anonimizados para mejorar un modelo de diagnóstico propiedad de un proveedor extranjero, el beneficio del dato se transfiere permanentemente fuera de la jurisdicción que lo generó. Este es exactamente el tipo de transferencia de valor que el AI Now Institute identifica como el mecanismo central del subsidio público a la IA privada.

    Regulación sectorial vs. regulación estructural: el debate de fondo

    El argumento de Kak apunta a algo que las regulaciones de IA vigentes —incluyendo el AI Act de la Unión Europea— abordan de forma parcial: los marcos actuales regulan usos de la IA pero no la estructura de mercado que determina quién puede desarrollarla. El AI Act clasifica riesgos por aplicación, no por poder de mercado. Las leyes de competencia, por su lado, actúan ex post y con ciclos demasiado lentos para industrias que consolidan posiciones en meses. El debate sobre cómo regular la concentración en IA —si mediante obligaciones de interoperabilidad, licencias obligatorias de modelos fundacionales, o límites a la integración vertical— está en curso en el Parlamento Europeo y en la Comisión Federal de Comercio de Estados Unidos, pero sin equivalente en ninguna jurisdicción latinoamericana.

    La discusión sobre quién financia la IA y quién captura su valor no es técnica ni filosófica: es una pregunta de política fiscal y regulatoria que los gobiernos de la región deberán responder antes de firmar el próximo contrato de nube. Para profundizar, el trabajo del AI Now Institute está disponible en ainowinstitute.org.