Autor: Redacción

  • Vigilancia masiva sin control: cómo las bases de datos de patentes se convirtieron en juguete policial

    Vigilancia masiva sin control: cómo las bases de datos de patentes se convirtieron en juguete policial

    Un análisis de la Electronic Frontier Foundation sobre registros de búsqueda del sistema de lectura automatizada de patentes (ALPR) de Flock Safety reveló que agentes policiales de Estados Unidos accedieron a datos de ubicación de millones de vehículos sin justificación legítima, usando razones como “LOL”, “LMAO”, “sexy” o “idk” (“no sé”) en los campos de auditoría obligatorios. El hallazgo expone una falla estructural que va más allá de la anécdota: cuando no hay requisito de orden judicial ni mecanismo de control real, los sistemas de vigilancia masiva se convierten en herramientas de acceso irrestricto.

    El caso más llamativo del análisis corresponde al Departamento de Policía de Goshen, cuyo agente ejecutó el 7 de mayo de 2025 búsquedas sobre 6.474 redes ALPR que representan datos de 82.413 cámaras. En el campo donde debía documentar el motivo, escribió “idk”. No hubo sanción documentada. No hubo invalidación del resultado. La búsqueda simplemente quedó registrada como un hecho más en el log del sistema.

    Flock Safety, Motorola y Axon: la arquitectura de vigilancia que se vende como seguridad pública

    Las lectoras automáticas de patentes operan a través de empresas privadas —Flock Safety, Motorola Solutions y Axon son las más citadas en el análisis de la EFF— que licencian su tecnología a departamentos policiales municipales. El argumento de venta es siempre el mismo: la herramienta es indispensable para resolver crímenes graves como secuestros, robos de autos o homicidios. Pero los logs de auditoría muestran un uso rutinario, aleatorio y, en muchos casos, abiertamente burlesco.

    Flock Safety respondió a las críticas previas implementando un menú desplegable de tipos de delitos que el agente debe seleccionar antes de ejecutar una búsqueda. La EFF señala que esta medida es cosmética: el sistema no verifica que la razón seleccionada corresponda al motivo real de la consulta. Un agente puede elegir “robo de vehículo” en el dropdown y estar rastreando a un ex cónyuge. La uniformidad del menú no reemplaza la accountability.

    Sin orden judicial ni estándar de causa probable: el vacío legal que habilita el abuso

    En Estados Unidos, los sistemas ALPR operan en un vacío normativo significativo. No existe legislación federal que exija orden judicial para consultar bases de datos de ubicación vehicular históricas. Algunos estados tienen regulaciones propias —Illinois y New Hampshire cuentan con restricciones de retención de datos, por ejemplo— pero la mayoría carece de estándares vinculantes sobre proporcionalidad o documentación de búsquedas. La EFF ha documentado que esta arquitectura de acceso irrestricto genera una “cultura de abuso” donde la vigilancia masiva se normaliza como rutina operativa.

    El problema de fondo es de diseño: un sistema de auditoría que depende de que el propio agente documente honestamente sus razones no es un sistema de control, es una declaración de intenciones. Sin validación independiente, sin cruce con resultados de investigaciones reales y sin consecuencias por entradas inválidas, el log de auditoría cumple una función de legitimación formal, no de rendición de cuentas efectiva.

    Argentina, Brasil y México frente a la vigilancia vehicular: tres marcos legales, un mismo riesgo

    La expansión de sistemas ALPR en América Latina sigue una curva similar a la estadounidense, con una brecha regulatoria que en varios países es aún más pronunciada. En Argentina, la Ciudad de Buenos Aires opera el sistema de reconocimiento de patentes CONARC —integrado a la red de videovigilancia urbana— sin que exista una regulación específica sobre retención de datos vehiculares, acceso por parte de fuerzas de seguridad o estándares de auditoría. La Ley 25.326 de Protección de los Datos Personales establece principios de finalidad y proporcionalidad, pero su aplicación a bases de datos de vigilancia estatal en tiempo real es materia en disputa y la Agencia de Acceso a la Información Pública (AAIP) no ha emitido criterios específicos para este tipo de sistemas.

    En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) reconoce en su artículo 4° una excepción amplia para actividades de seguridad pública, defensa nacional e investigación penal, lo que en la práctica significa que los sistemas de vigilancia vehicular operados por organismos estatales quedan fuera del alcance pleno de la norma. La Autoridade Nacional de Proteção de Dados (ANPD) ha avanzado en la regulación de tratamientos de datos personales por parte del sector privado, pero el tratamiento de datos por fuerzas de seguridad sigue pendiente de un marco específico que el Congreso no ha aprobado. En México, la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares) no aplica a organismos gubernamentales; la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados de 2017 rige para el sector público, pero sus mecanismos de control sobre bases de datos de vigilancia masiva son débiles y el INAI ha tenido escasa actuación en este campo específico.

    El patrón regional es consistente: las leyes de protección de datos personales más robustas de la región tienen excepciones amplias para seguridad pública, y ningún país cuenta con legislación específica que establezca estándares de proporcionalidad, retención y auditoría para sistemas ALPR o equivalentes. Ciudades como Bogotá, Santiago, Lima y São Paulo operan redes de lectura de patentes de alcance creciente bajo marcos normativos que no contemplan los riesgos documentados por la EFF.

    Qué monitorear: legislación pendiente y los próximos hitos en la regulación de vigilancia vehicular

    En el plano internacional, el Comité de Derechos Humanos de la ONU ha señalado repetidamente que la vigilancia masiva sin control judicial es incompatible con el artículo 17 del Pacto Internacional de Derechos Civiles y Políticos —que protege la privacidad— independientemente de si el Estado que la ejecuta tiene o no una ley de privacidad avanzada. Este estándar internacional es una palanca disponible para organizaciones de la sociedad civil en la región que quieran cuestionar sistemas ALPR ante organismos de derechos humanos.

    En el corto plazo, vale monitorear tres hitos: la posible actualización de la Ley 25.326 en Argentina, que incluye en su agenda de reforma criterios sobre tratamientos de datos por organismos de seguridad; el avance del proyecto de regulación sectorial de vigilancia urbana en la ANPD brasileña; y la discusión en el Congreso mexicano sobre una ley específica de videovigilancia que varios grupos civiles llevan impulsando desde 2023. Ninguno de estos procesos tiene fecha cierta, pero los tres son espacios donde el caso documentado por la EFF puede funcionar como argumento empírico.

    Nuestro análisis: el log de auditoría no es un control, es una coartada

    El hallazgo de la EFF es técnicamente sencillo pero políticamente devastador: los sistemas de vigilancia masiva que se venden con promesas de accountability no tienen, en la práctica, ningún mecanismo que obligue a los agentes a ser honestos sobre el propósito de sus consultas. El dropdown de Flock Safety es el equivalente digital de un formulario en papel que nadie revisa. La solución no es mejorar el formulario —es requerir autorización previa independiente para búsquedas en bases de datos de ubicación masiva, con estándar de causa probable y revisión judicial posterior.

    Para América Latina, la lección operativa es anterior a la técnica: antes de desplegar o ampliar sistemas ALPR, los gobiernos locales deberían poder responder tres preguntas que hoy ninguno de los contratos con proveedores privados exige responder públicamente. ¿Quién puede consultar la base y bajo qué criterio documentado? ¿Cuánto tiempo se retienen los datos de vehículos que no son objeto de ninguna investigación? ¿Quién audita los logs y con qué consecuencias ante entradas inválidas? Mientras esas preguntas no tengan respuesta vinculante, “LMAO” seguirá siendo una razón tan válida como cualquier otra.

    Si una entrada de log que dice “no sé” da acceso a datos de 82.413 cámaras sin consecuencias, el problema no es la cultura policial: es que el sistema fue diseñado para que eso fuera posible. ¿Cuántos municipios en América Latina firmaron contratos con los mismos proveedores sin exigir respuestas a esas tres preguntas?

  • Colombia: 6 de cada 10 ciberataques apuntan al sector salud

    Colombia: 6 de cada 10 ciberataques apuntan al sector salud

    Seis de cada diez ciberataques registrados en Colombia tienen como blanco instituciones del sector salud, según un reporte de Biofile que toma como base mediciones del IBM X-Force Index. La cifra posiciona a hospitales y clínicas colombianas como el principal objetivo de amenazas digitales en el país, y dispara preguntas urgentes sobre el estado de la gobernanza de datos en el sistema sanitario.

    El dato fue reportado el 13 de septiembre de 2026 por Joseph Freixes en DataBreaches.net, citando el informe de Biofile. La concentración del 60% de los ataques en un solo sector no es casualidad: la información médica combina datos sensibles de alta demanda en mercados ilegales — diagnósticos, historiales clínicos, números de identificación, datos de cobertura — con entornos tecnológicos históricamente subfinanciados en materia de seguridad y gobernanza. No se ha confirmado públicamente el número total de incidentes sobre el que se calcula ese porcentaje, ni si todos los casos involucraron exfiltración confirmada de datos.

    Qué falló: clasificación, ownership y controles de acceso en hospitales colombianos

    Cuando el sector salud concentra la mayoría de los ataques exitosos, el problema raramente es solo técnico. Desde la perspectiva del DAMA-DMBOK, los hospitales colombianos enfrentan déficits estructurales en tres capabilities críticas: clasificación de datos (data classification), definición de propietarios del dato (data ownership) y control de acceso basado en roles. Sin un catálogo activo que distinga qué registros son críticos y quién responde por ellos, cualquier vector de entrada —ransomware, credenciales comprometidas, acceso indebido— puede moverse lateralmente sin fricción. El marco CDMC del EDM Council establece que los controles de seguridad de datos deben estar alineados con la clasificación formal; en entornos hospitalarios públicos de Colombia, ese alineamiento es, en la mayoría de los casos, inexistente o informal.

    Colombia cuenta con la Ley 1581 de 2012 de Protección de Datos Personales y su decreto reglamentario 1377 de 2013, que obligan a los responsables del tratamiento a implementar medidas de seguridad adecuadas para proteger datos sensibles — categoría en la que cae explícitamente la información de salud. La Superintendencia de Industria y Comercio (SIC) es la autoridad de control con facultades sancionatorias. Sin embargo, la brecha entre el marco legal vigente y la capacidad operativa real de los hospitales públicos para implementar gobernanza efectiva sigue siendo amplia. La SIC no ha publicado, hasta la fecha de este reporte, sanciones consolidadas específicas contra instituciones de salud por fallas de seguridad.

    Señal para CDOs y data stewards del sector salud en la región

    El patrón colombiano no es aislado. En Brasil, la ANPD ha señalado al sector salud como uno de los más expuestos bajo la LGPD, y en Argentina la AAIP ha recibido notificaciones de incidentes en clínicas privadas bajo la Ley 25.326. Lo que diferencia a las organizaciones que contienen el daño de las que no es la existencia de un programa activo de gobernanza: inventario de activos de datos, data stewards designados por dominio clínico, y procedimientos de notificación ensayados. Un CDO o responsable de datos en un hospital colombiano debería, como primer paso, mapear qué sistemas contienen datos de pacientes, quién tiene acceso hoy y si ese acceso está documentado y justificado. Esa auditoría de acceso — ejecutable en días con herramientas básicas — es el insumo mínimo para una conversación real con la dirección sobre riesgo.

    • Confirmar si existe un inventario formal de bases de datos con información de pacientes y su nivel de clasificación.
    • Identificar al data steward responsable por cada dominio clínico (historiales, facturación, laboratorio).
    • Revisar si los procedimientos de notificación a la SIC ante incidentes están documentados y tienen un responsable asignado.
    • Evaluar si los controles de acceso están alineados con la clasificación de datos sensibles exigida por la Ley 1581.

    Mientras el 60% de los ataques digitales en Colombia sigan concentrándose en un sector que gestiona la información más sensible de las personas, la pregunta no es si las instituciones de salud serán el próximo blanco — sino si sabrán qué datos tenían cuando ya sea tarde.

  • DFS de Nueva York endurece las evaluaciones de riesgo cibernético en servicios financieros

    DFS de Nueva York endurece las evaluaciones de riesgo cibernético en servicios financieros

    El Departamento de Servicios Financieros de Nueva York (DFS) emitió el 10 de septiembre de 2026 una nueva guía de ciberseguridad que precisa qué espera el regulador de las entidades bajo su supervisión al momento de conducir evaluaciones de riesgo. La directiva no es optativa: define alcance, frecuencia y responsabilidades internas, y en un sector donde la exposición a riesgo sistémico cruza fronteras, su impacto llega hasta los equipos de gobierno de datos de bancos y aseguradoras que operan en América Latina con filiales o corresponsalías reguladas en ese Estado.

    La guía fue firmada por Kaitlin Asrow, Superintendente en funciones del DFS, y complementa el marco de ciberseguridad ya vigente bajo 23 NYCRR Part 500, el reglamento que desde 2017 obliga a las entidades financieras licenciadas en Nueva York a mantener programas de ciberseguridad formales. Lo que agrega la nueva orientación es granularidad operativa: no basta con tener una evaluación de riesgo; debe estar calibrada para informar —y justificar— las decisiones del programa de ciberseguridad de cada entidad.

    Qué exige la guía DFS: alcance, periodicidad y ownership interno

    Según se informó, el documento articula tres ejes principales. El primero es el alcance de la evaluación, que debe cubrir todos los activos de información relevantes, incluidos los sistemas de terceros que procesen datos en nombre de la entidad. El segundo eje es la frecuencia: las evaluaciones no pueden ser un ejercicio anual de cumplimiento formal; deben actualizarse ante cambios materiales en el entorno de amenazas o en la arquitectura tecnológica. El tercero —y el más relevante para la función de data governance— es el rol que cumple la evaluación dentro del programa de ciberseguridad: debe traducirse en controles concretos, con responsables identificados y seguimiento documentado.

    Este tercer eje conecta directamente con conceptos que DAMA-DMBOK categoriza bajo Data Security y que el EDM Council (CDMC) incluye en su capability 9: la gestión de riesgo sobre activos de datos requiere ownership claro, clasificación previa y linaje documentado. Una evaluación de riesgo que no sabe qué datos toca, quién los posee y cómo fluyen es, en la práctica, una declaración de intenciones sin sustento.

    Por qué 23 NYCRR 500 sigue siendo referencia para reguladores latinoamericanos

    El reglamento DFS es uno de los marcos sectoriales más imitados fuera de Estados Unidos. En América Latina, varios bancos centrales y superintendencias financieras han tomado elementos de su arquitectura al diseñar sus propias normas de ciberseguridad. El Banco Central de la República Argentina (BCRA), con la Comunicación A 7724 y sus actualizaciones posteriores, impone requisitos de gestión de riesgo tecnológico a entidades financieras locales que guardan similitud estructural con los pilares de 23 NYCRR 500: identificación de activos críticos, evaluación periódica y reporte a la alta gerencia. Colombia, a través de la Superintendencia Financiera y su Circular Externa 007 de 2018 sobre riesgo de seguridad y ciberseguridad, recorre un camino análogo.

    Lo que la guía del DFS introduce —y que aún no está formalizado con igual nivel de detalle en la mayoría de los marcos latinoamericanos— es la exigencia de que la evaluación de riesgo sea el documento rector del programa de ciberseguridad, no un anexo del mismo. Esa distinción tiene consecuencias prácticas: si el regulador local adopta una lógica similar en una revisión futura, los equipos que hoy tratan la evaluación de riesgo como un checklist anual tendrán que reestructurar su enfoque.

    Para bancos con doble regulación, la carga de compliance se multiplica

    Las entidades latinoamericanas con operaciones o corresponsalías en Nueva York ya están bajo 23 NYCRR 500 y ahora deben incorporar esta guía adicional. Para ellas, el desafío no es solo técnico: es de gobernanza. Mantener evaluaciones de riesgo coherentes entre jurisdicciones —donde los inventarios de activos, la clasificación de datos y los umbrales de riesgo aceptable pueden diferir— exige un modelo de gobierno de datos que trascienda la entidad local y funcione a nivel de grupo. Esto es precisamente lo que el concepto de data mesh organizacional, bien implementado, debería facilitar: dominios de datos con ownership claro, capaces de reportar al regulador de su jurisdicción sin depender de un proceso centralizado que no conoce los activos locales.

    En la práctica, muchos bancos regionales aún operan con catálogos de datos incompletos y sin data stewards formalmente designados para activos críticos. Una evaluación de riesgo que el DFS juzgaría insuficiente en Nueva York probablemente también sería insuficiente ante el BCRA o la Superintendencia Financiera de Colombia si esos reguladores aplicaran el mismo nivel de escrutinio.

    Qué monitorear: revisiones de 23 NYCRR 500 y movimientos regulatorios en Brasil y México

    Los próximos hitos a seguir son dos. Primero, cualquier actualización formal a 23 NYCRR 500 que incorpore los estándares de esta guía al texto regulatorio vinculante, lo que elevaría el nivel de exigencia para entidades supervisadas. Segundo, la evolución de los marcos de ciberseguridad financiera en Brasil —donde el Banco Central (BCB) ya tiene resoluciones específicas sobre riesgo operacional y cibernético bajo la Resolução BCB 85/2021— y en México, donde la CNBV ha avanzado en requisitos de gestión de riesgo tecnológico para instituciones de crédito. Si el DFS formaliza esta guía como enmienda reglamentaria, la presión comparativa sobre otros reguladores de la región crecerá.

    Nuestro análisis

    La guía del DFS es, ante todo, un mensaje sobre madurez de gobierno de datos: no alcanza con tener controles si no podés demostrar que esos controles derivan de una comprensión documentada del riesgo sobre activos de datos identificados. Esa lógica —evaluación como documento rector, no como ejercicio de cumplimiento— es exactamente lo que diferencia a un programa de data governance maduro de uno que existe solo en el organigrama. Para los CDO y líderes de riesgo de entidades financieras en la región, esta guía es una señal anticipada: el estándar de “evaluación suficiente” se está moviendo hacia arriba, y los reguladores locales eventualmente seguirán esa dirección. La pregunta no es si adaptar el modelo; es cuánto tiempo queda antes de que el regulador propio lo exija formalmente.

    Las entidades financieras latinoamericanas con exposición regulatoria en Nueva York tienen hoy una ventaja táctica: pueden usar esta guía del DFS para fortalecer su modelo de gobierno de datos antes de que el equivalente local sea mandatorio. Ignorarla equivale a dejar que el regulador marque el ritmo.

  • Argentina: cinco obligaciones clave antes de que rija la nueva Ley de Datos Personales

    Argentina: cinco obligaciones clave antes de que rija la nueva Ley de Datos Personales

    Argentina avanza hacia la entrada en vigencia de su nueva Ley de Datos Personales, que reemplazará a la Ley 25.326 vigente desde el año 2000. Las empresas que operan en el país tienen una ventana definida para adaptar sus procesos: quienes lleguen tarde al cumplimiento no solo enfrentarán sanciones de la Agencia de Acceso a la Información Pública (AAIP), sino que quedarán expuestos ante consumidores y socios comerciales cada vez más exigentes en materia de privacidad.

    La reforma era inevitable. La Ley 25.326 fue sancionada antes de que existieran las redes sociales, el procesamiento masivo de datos en la nube o los modelos de negocio basados en la monetización de información personal. La nueva normativa, cuyo texto fue debatido durante años en el Congreso, actualiza los estándares argentinos acercándolos al Reglamento General de Protección de Datos (RGPD) de la Unión Europea y a la Lei Geral de Proteção de Dados (LGPD) de Brasil, que lleva operativa desde 2020 con multas ya aplicadas por la Autoridade Nacional de Proteção de Dados (ANPD). El diagnóstico regional es claro: los marcos normativos de primera generación ya no alcanzan.

    Cinco obligaciones que las empresas argentinas no pueden postergar

    El camino hacia el cumplimiento no es lineal, pero hay un conjunto de pasos que concentran la mayor parte del riesgo de incumplimiento. Basándonos en el análisis del marco legal y la experiencia comparada con Brasil y México —donde la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) lleva más de una década vigente—, estas son las áreas críticas que toda organización debe resolver antes de la entrada en vigor:

    • Mapeo y registro de tratamientos: inventariar qué datos personales se recolectan, con qué base legal, por cuánto tiempo se conservan y quién tiene acceso. Sin este registro, el resto del cumplimiento es imposible de auditar.
    • Revisión de bases de legitimación: el consentimiento deja de ser la única ni la principal base legal. Las empresas deben identificar cuándo aplica interés legítimo, ejecución contractual u obligación legal, y documentarlo correctamente.
    • Actualización de avisos de privacidad y políticas internas: los textos vigentes en la mayoría de las organizaciones fueron redactados bajo la lógica de la Ley 25.326 y no contemplan nuevos derechos como la portabilidad o la limitación del tratamiento.
    • Designación del responsable de protección de datos: la nueva ley incorpora la figura equivalente al Data Protection Officer (DPO). Definir si corresponde designarlo, con qué perfil y con qué nivel de independencia es una decisión que requiere análisis jurídico y organizacional.
    • Protocolo de respuesta a brechas de seguridad: la notificación obligatoria a la autoridad de control y, en ciertos casos, a los titulares afectados, exige un procedimiento interno previamente documentado. Improvisar ante un incidente tiene un costo legal y reputacional alto.

    La experiencia brasileña bajo la LGPD: lecciones para Argentina

    Brasil es el espejo más útil para Argentina en este proceso. La LGPD entró en vigor en septiembre de 2020 y las primeras sanciones de la ANPD llegaron en 2023, con un período de gracia que muchas empresas interpretaron como inactividad regulatoria. El resultado: cuando las multas comenzaron, un porcentaje significativo de organizaciones medianas no tenía ni siquiera el mapeo de tratamientos completado, según reportes de consultoras especializadas en compliance de datos en Brasil. Argentina podría replicar ese patrón si las empresas subestiman el tiempo que toma implementar cambios estructurales.

    México ofrece otro ángulo. La LFPDPPP —vigente desde 2010 y complementada por lineamientos del Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI)— demostró que el aviso de privacidad, cuando se trata como un trámite formal en lugar de una herramienta de transparencia real, pierde toda eficacia. Las empresas argentinas tienen la oportunidad de no repetir ese error y diseñar avisos genuinamente informativos desde el inicio.

    La AAIP como autoridad de control: capacidad sancionatoria reforzada

    La nueva ley fortalece las atribuciones de la AAIP para investigar, requerir información y aplicar sanciones. Esto no es un detalle menor: bajo la Ley 25.326, la capacidad sancionatoria de la autoridad de control era limitada y las multas raramente representaban un desincentivo real para las grandes organizaciones. La reforma busca cambiar esa ecuación. Las empresas multinacionales que ya operan bajo RGPD o LGPD reconocerán el esquema; las de capital local, en cambio, necesitarán construir desde cero una cultura de accountability interno.

    Un punto que suele pasarse por alto: la nueva normativa también alcanza a los encargados del tratamiento —proveedores tecnológicos, agencias de marketing, empresas de contact center— que procesan datos por cuenta de terceros. Revisar los contratos con proveedores y exigir garantías de cumplimiento es parte del trabajo de adecuación, no un paso opcional.

    Qué monitorear en los próximos meses: reglamentación y guías de la AAIP

    La ley, una vez promulgada, no opera en el vacío: necesita reglamentación que defina plazos de notificación de brechas, umbrales para la designación obligatoria del DPO y criterios de evaluación del impacto relativo al tratamiento de datos (equivalente al DPIA del RGPD). Las organizaciones deben monitorear activamente las publicaciones de la AAIP en el Boletín Oficial y participar en los espacios de consulta pública que la autoridad suele habilitar antes de emitir guías interpretativas. La experiencia de la ANPD brasileña —que publicó resoluciones clave sobre agentes de tratamiento de pequeño porte y sobre comunicación de incidentes— muestra que esos instrumentos secundarios son tan importantes como el texto de la ley.

    Nuestro análisis

    La actualización de la normativa argentina es positiva y necesaria, pero el riesgo real no está en el texto de la ley sino en el tiempo de implementación. Las organizaciones que esperan a que la AAIP publique la reglamentación completa para recién comenzar su diagnóstico interno llegarán tarde. Los cinco pasos identificados —mapeo, bases legales, avisos, DPO y protocolo de brechas— son independientes de los detalles reglamentarios pendientes y pueden iniciarse ahora. En la región, tanto Brasil como México mostraron que el período de gracia no es un regalo, sino una trampa para quienes lo confunden con inacción del regulador. Argentina tiene la ventaja de poder aprender de esos ciclos. La pregunta es si las empresas locales están dispuestas a usarla.

    El cumplimiento temprano no es ventaja competitiva en abstracto: es el único escenario en el que una organización controla el ritmo de su adecuación en lugar de reaccionar ante una inspección.

  • Kiteworks adquiere Bonfy.AI para integrar IA en gobernanza de datos

    Kiteworks adquiere Bonfy.AI para integrar IA en gobernanza de datos

    Kiteworks anunció la adquisición de Bonfy.AI, una startup especializada en inteligencia artificial aplicada a la gobernanza de datos, con el objetivo de cerrar una brecha operativa que afecta a organizaciones que gestionan contenidos sensibles a escala. La operación señala un movimiento concreto hacia la automatización de controles de clasificación, linaje y acceso en entornos empresariales complejos.

    Kiteworks es una plataforma de gestión de contenido sensible orientada al cumplimiento normativo —usada en sectores como defensa, salud y servicios financieros— que hasta ahora dependía de reglas predefinidas y etiquetado manual para clasificar datos y aplicar políticas de acceso. La incorporación de las capacidades de Bonfy.AI apunta a automatizar ese proceso mediante modelos de lenguaje y clasificación semántica, reduciendo la intervención humana en decisiones de gobernanza que hoy se producen con rezago o directamente no ocurren.

    La brecha que Bonfy.AI promete cerrar: clasificación en tiempo real

    El problema de fondo que motiva esta adquisición es conocido en cualquier equipo de gobierno de datos: los volúmenes de contenido no estructurado crecen más rápido que la capacidad de los data stewards para etiquetarlo y aplicarle políticas. Correos, contratos, reportes regulatorios, archivos compartidos por API —todo eso circula sin que exista una capa automatizada que evalúe en tiempo real qué dato es sensible, quién puede verlo y bajo qué condición normativa. Bonfy.AI, según se informó, aporta exactamente esa capa: un motor de clasificación semántica que opera sobre flujos de contenido activos, no sobre inventarios estáticos.

    En términos del DAMA-DMBOK, esto toca directamente las capacidades de Data Security y Data Quality dentro del ciclo de vida del dato. La automatización de la clasificación no elimina la figura del data steward, pero cambia su rol: de etiquetar manualmente a revisar excepciones y validar reglas del modelo. Es el modelo que el EDM Council identifica en su CDMC (Cloud Data Management Capabilities) cuando habla de controles adaptativos en entornos de nube.

    Cuándo aplica esta integración y cuándo no resuelve el problema

    La propuesta de valor de la combinación Kiteworks-Bonfy.AI aplica con mayor claridad cuando una organización ya tiene definidos sus dominios de datos, sus políticas de acceso y sus obligaciones normativas, pero carece de automatización para aplicarlos a escala. En ese contexto, un motor de IA semántica puede ser un multiplicador real de la capacidad del equipo de gobierno. Sin embargo, si la organización no tiene un marco de gobernanza previo —sin ownership claro por dominio, sin taxonomía de clasificación, sin políticas formalizadas— la IA no suple esa ausencia: clasifica según patrones que nadie definió, y el resultado es ruido con etiqueta automática.

    Tampoco resuelve el problema de linaje (data lineage) en sentido estricto. Clasificar un documento en el momento en que circula no equivale a trazar su origen, transformaciones y destino a lo largo de un pipeline. Son capacidades complementarias, no equivalentes. Los equipos que necesitan linaje para cumplir con obligaciones de auditoría —por ejemplo, bajo la Resolución 4/2019 de la AAIP en Argentina o los artículos 37 a 39 de la LGPD brasileña sobre registros de tratamiento— deben evaluar si Kiteworks ya cubre esa funcionalidad o si requiere integración adicional con herramientas especializadas como Alation, Collibra o DataHub.

    América Latina: el contexto regulatorio que hace urgente esta capacidad

    Para las organizaciones en la región, la automatización de la clasificación de datos no es solo una ventaja operativa: en varios marcos normativos ya es una obligación implícita. La LGPD brasileña (Lei 13.709/2018) exige que el controlador demuestre medidas técnicas y organizativas adecuadas para proteger datos personales, lo que incluye saber qué datos tiene y dónde están. La Ley 25.326 argentina, aunque más antigua, impone obligaciones similares de registro y seguridad. En Colombia, el Decreto 1377 de 2013 y la Ley 1581 requieren identificar la naturaleza de los datos tratados. Sin una capa de clasificación automatizada, cumplir con solicitudes de derechos ARCO o responder ante la Superintendencia de Industria y Comercio en menos de diez días hábiles se convierte en un ejercicio manual costoso y propenso a errores.

    Los bancos y aseguradoras de la región que operan bajo marcos de gestión de riesgos —como las Comunicaciones del BCRA en Argentina o las circulares de la CNBV en México— ya tienen incentivos regulatorios directos para avanzar hacia controles automatizados de clasificación y acceso. La adquisición de Bonfy.AI por Kiteworks es un indicador más de que el mercado de herramientas que combinan gobernanza de datos e IA generativa está entrando en una fase de consolidación, con implicancias de evaluación de proveedores para cualquier CDO de la región que esté en proceso de renovación de su stack de gobierno.

    Organizaciones que aún dependen del etiquetado manual para cumplir con la LGPD o la Ley 25.326 deberían revisar si su arquitectura de gobernanza actual puede absorber una capa de clasificación semántica —o si primero necesitan resolver el ownership y la taxonomía que la alimentaría.

  • Agencia Digital de Japón: 246.000 registros de empleados posiblemente comprometidos

    Agencia Digital de Japón: 246.000 registros de empleados posiblemente comprometidos

    La Agencia Digital de Japón informó que aproximadamente 246.000 conjuntos de datos personales —incluyendo nombres y direcciones de correo electrónico de empleados gubernamentales— podrían haber sido comprometidos tras un acceso no autorizado a uno de sus sistemas de red. Hasta el momento, según se informó, no se registraron daños secundarios como uso indebido de la información.

    El incidente fue comunicado públicamente por la propia agencia el viernes 11 de septiembre. El organismo, creado en 2021 para impulsar la digitalización del Estado japonés, opera infraestructura crítica de gobierno electrónico y gestiona datos de funcionarios de múltiples reparticiones. La notificación fue reportada originalmente por Jiji Press. No se precisaron en la información disponible la fecha exacta del acceso no autorizado ni el vector de ataque utilizado.

    Datos confirmados al cierre de esta nota

    • Registros potencialmente comprometidos: aproximadamente 246.000 conjuntos de datos personales.
    • Tipo de datos expuestos: nombres y direcciones de correo electrónico de empleados gubernamentales.
    • Sistema afectado: red operada por la propia Agencia Digital de Japón.
    • Daños secundarios confirmados: ninguno hasta la fecha del anuncio.
    • Fecha de divulgación pública: 11 de septiembre de 2026.

    Qué se sabe y qué falta confirmar

    La agencia utilizó el término “posiblemente comprometidos” en su comunicación, lo que indica que la investigación forense no ha concluido y que la exfiltración efectiva de datos no está aún confirmada. Permanecen sin precisar el vector de intrusión, la duración del acceso no autorizado, si los registros corresponden exclusivamente a empleados activos o también a ex funcionarios, y si se activaron protocolos de notificación individual a los afectados. Tampoco se informó si el incidente fue reportado a la Comisión de Protección de Información Personal de Japón (PPC), la autoridad de control equivalente a las APDs de la región.

    El caso tiene relevancia más allá de Japón: una agencia cuya función central es la gobernanza digital del Estado sufrió un incidente en su propia infraestructura, lo que pone en cuestión los controles de acceso sobre sistemas que concentran datos de empleados públicos a escala nacional. En América Latina, organismos equivalentes como la Secretaría de Gobierno Digital de Argentina o la Secretaría de Transformación Digital de Brasil gestionan volúmenes similares de datos de empleados del Estado, sin que existan en todos los casos marcos de notificación de brechas con plazos obligatorios comparables. La Ley 25.326 de Argentina y la LGPD brasileña establecen el deber de notificación a la autoridad de control, pero los plazos y criterios de significatividad varían, y la aplicación a organismos públicos sigue siendo dispar en la práctica.

    El próximo hito a seguir es la confirmación o descarte de exfiltración efectiva por parte de la Agencia Digital de Japón, y la eventual comunicación a la PPC, que determinará si corresponde notificación individual a los 246.000 empleados potencialmente afectados.

  • Gobernanza de datos: por qué frena la IA antes de que arranque

    Gobernanza de datos: por qué frena la IA antes de que arranque

    La inteligencia artificial no falla por falta de algoritmos ni de poder de cómputo: falla porque los datos que la alimentan están mal catalogados, sin dueño claro y sin linaje trazable. La gobernanza de datos no es el paso previo a la transformación digital; es la condición de posibilidad de cualquier iniciativa de IA que aspire a escalar.

    Cuando una organización lanza un proyecto de machine learning o un agente de IA generativa, el 60% a 80% del esfuerzo real termina siendo de preparación y limpieza de datos, según estimaciones recurrentes en la industria. Ese número no refleja un problema técnico: refleja la ausencia de un programa de gobernanza de datos maduro. Sin definiciones claras de qué dato es autoritativo, quién es su data steward —el responsable operativo de su calidad e integridad— y cómo se transformó desde el origen hasta el modelo, el output de la IA es, en el mejor caso, impredecible.

    Qué es concretamente un cuello de botella de gobernanza

    Un cuello de botella de gobernanza no es que “los datos son sucios”. Es un conjunto específico de carencias estructurales: ausencia de un glosario de negocio (business glossary) con definiciones únicas y acordadas entre áreas; falta de un catálogo de datos activo que indique dónde vive cada activo, quién lo consume y con qué frecuencia se actualiza; data lineage inexistente o fragmentado, que impide saber si el campo “ingreso mensual” en el modelo de crédito viene del CRM, del ERP o de una planilla de Excel mantenida por alguien que ya no trabaja en la empresa. Cualquiera de esos tres puntos, por separado, basta para que un proyecto de IA no pase de piloto.

    El marco DAMA-DMBOK v2 identifica once áreas de conocimiento en gobernanza de datos; la mayoría de las organizaciones latinoamericanas operan con cobertura parcial en no más de tres o cuatro. El EDM Council, a través de su CDMC (Cloud Data Management Capabilities), ofrece una escala de madurez de doce niveles que permite medir exactamente dónde está la brecha. En la práctica, las empresas que intentan implementar IA sin haber alcanzado al menos el nivel 4 del CDMC —que implica políticas de clasificación de datos documentadas y roles de data steward formalmente asignados— enfrentan retrabajo sistemático en cada sprint.

    El rol del CDO y la confusión frecuente con el CIO

    Una de las fricciones organizacionales más comunes es la ausencia de un Chief Data Officer con mandato explícito sobre gobernanza, o la delegación de esa función al CIO, cuya prioridad natural es la disponibilidad de sistemas y la infraestructura. La gobernanza de datos requiere decisiones de negocio —qué definición de “cliente activo” es la correcta para el área de riesgo versus la de marketing— que no son decisiones tecnológicas. Bob Seiner, referente en Non-Invasive Data Governance, sostiene que la gobernanza más efectiva es aquella que formaliza las responsabilidades que ya existen informalmente en la organización, en lugar de crear estructuras paralelas que generan resistencia.

    En empresas que sí tienen un CDO, el foco operativo debería estar hoy en dos frentes simultáneos: primero, identificar qué dominios de datos alimentan los modelos de IA en producción o en piloto, y auditar si esos dominios tienen ownership definido y SLAs de calidad medibles; segundo, negociar con el área de tecnología la incorporación de metadata de gobernanza —clasificación, linaje, restricciones de uso— en los pipelines de datos desde el diseño, no como capa retroactiva.

    Cuándo aplica este diagnóstico y cuándo NO

    Este análisis aplica a organizaciones que ya tienen o planean tener modelos de IA consumiendo datos internos: bancos, aseguradoras, retailers con motores de recomendación, utilities con mantenimiento predictivo. No aplica —o aplica con menor urgencia— a organizaciones que usan IA exclusivamente a través de APIs de terceros con datos propios del proveedor, donde el problema de gobernanza de datos internos es secundario al contrato de uso y las cláusulas de procesamiento. Tampoco sustituye a los controles de ciberseguridad: una buena gobernanza no es un control de acceso, aunque una buena clasificación de datos sí informa qué activos requieren controles de acceso más estrictos.

    El escenario regulatorio en América Latina agrega urgencia

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que las organizaciones puedan demostrar la base legal del tratamiento de datos personales y respondan solicitudes de titulares en plazos definidos. Eso requiere saber exactamente dónde está cada dato personal, con qué propósito fue recolectado y qué sistemas lo procesan: en otras palabras, requiere gobernanza de datos funcional. La ANPD ha comenzado a intensificar su actividad fiscalizadora desde 2024, y las empresas que no pueden responder un DSAR —Data Subject Access Request— en tiempo y forma exponen su falta de catálogo y linaje ante el regulador. En Argentina, la Ley 25.326 y su autoridad de control, la AAIP, plantean obligaciones equivalentes, aunque con menor capacidad sancionatoria histórica. En México, el INAI fiscaliza bajo la LFPDPPP con criterios similares. En todos los casos, la gobernanza de datos no es solo una ventaja competitiva para la IA: es un requisito de cumplimiento regulatorio.

    Colombia avanza hacia una reforma de su régimen de datos personales con la SIC como autoridad activa, y Chile opera bajo la Ley 19.628 con un proyecto de modernización que fortalecería las obligaciones de accountability. Para los CDOs de la región, el argumento regulatorio suele ser más eficaz que el argumento de productividad a la hora de conseguir presupuesto para un programa de gobernanza.

    Para profundizar en los estándares de madurez aplicables, el CDMC del EDM Council y el DAMA-DMBOK v2 son los marcos de referencia con mayor adopción regional; ambos están disponibles en sus sitios oficiales y tienen comunidades activas en América Latina.

  • Cifrado TAKE de Ring: por qué no resuelve el problema de privacidad

    Cifrado TAKE de Ring: por qué no resuelve el problema de privacidad

    Amazon presentó “Throw Away the Key Encryption” (TAKE) para sus cámaras Ring con la promesa de reducir el acceso de la empresa —y de las fuerzas del orden— al video de los usuarios. El mecanismo introduce una capa adicional en la gestión de claves de cifrado, pero no equivale a cifrado de extremo a extremo real: Ring sigue teniendo acceso descifrado al video durante 24 horas por cada uso de funciones inteligentes.

    TAKE funciona así: el dispositivo del usuario posee una clave propia, mientras Ring retiene temporalmente claves de cifrado en su infraestructura de nube. Eso le permite procesar funciones como alertas inteligentes, descripciones de video y búsqueda de contenido. Transcurridas 24 horas, la clave se elimina —hasta la próxima vez que el usuario quiera acceder a un video antiguo o activar cualquiera de esas funciones, momento en que la clave vuelve al servidor. El ciclo se repite indefinidamente.

    Por qué 24 horas de acceso siguen siendo acceso

    El modelo actual de Ring cifra el video en tránsito y en reposo, pero Ring siempre lo descifra para procesar sus funciones, lo que significa acceso continuo al contenido. TAKE acota ese acceso en tiempo, pero no en términos estructurales: Ring aún recibe el material sin cifrar para operar sus servicios en la nube. Según la Electronic Frontier Foundation (EFF), aunque TAKE incorpora enclaves seguros que dificultan la exportación directa del material de clave base, las claves igualmente se liberan a servicios que pueden ser modificados. En la práctica, el sistema se comporta de manera casi idéntica a un esquema de cifrado en reposo donde el servidor custodia las claves.

    La distinción técnica relevante es que el dispositivo del usuario actúa como un módulo de seguridad de hardware (HSM, por sus siglas en inglés), pero con una limitación crítica: a diferencia de un HSM dedicado, el teléfono del usuario puede actualizarse, parchearse o verse comprometido, y Amazon puede modificar los servicios del lado del servidor que reciben las claves. Esto reduce la garantía de aislamiento criptográfico que la denominación “TAKE” sugiere.

    Lo que TAKE no cubre: pedidos legales y metadatos

    Uno de los vectores de acceso más relevantes para los usuarios de cámaras domésticas no es técnico sino legal. Las fuerzas de seguridad en Estados Unidos han recurrido históricamente a Ring mediante solicitudes administrativas, órdenes judiciales y, en algunos casos, pedidos directos a vecindarios a través del portal Neighbors de la propia compañía. Un cifrado que cede acceso al servidor durante 24 horas por ciclo sigue siendo susceptible a ese tipo de requerimiento legal durante ese período de vulnerabilidad. TAKE no modifica la relación contractual ni los términos de respuesta de Amazon ante autoridades.

    Tampoco aborda los metadatos: frecuencia de activación de la cámara, momentos de encendido y apagado, patrones de movimiento registrados, dirección IP del dispositivo. Esos datos pueden revelar rutinas del hogar con independencia de que el contenido del video esté cifrado o no, y permanecen disponibles para Amazon y, por extensión, para quienes los requieran legalmente.

    Cuándo aplica TAKE como mejora real —y cuándo no

    TAKE representa una mejora marginal respecto al estado actual de Ring en un escenario específico: el acceso no autorizado a material histórico almacenado en la nube más allá de las 24 horas. Si alguien obtiene acceso no autorizado a los servidores de Ring después de ese período, el video debería estar protegido. Eso no es trivial. Sin embargo, TAKE no resuelve el escenario donde el acceso ocurre dentro de la ventana de 24 horas, ni el escenario de pedidos legales formales durante ese período, ni el problema de los metadatos, ni la dependencia estructural de la arquitectura en la nube de Amazon para funcionar. Para quienes busquen privacidad real frente a vigilancia estatal o corporativa, el único esquema que lo garantiza es el cifrado de extremo a extremo sin procesamiento en la nube —que Ring ofrece como opción, pero a costo de perder todas las funciones inteligentes.

    El contexto regulatorio en América Latina importa aquí

    En la región, la adopción de cámaras conectadas al hogar crece sostenidamente, y con ella la pregunta sobre qué marcos protegen los videos capturados. En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige base legal para el tratamiento de datos personales, y los videos de cámaras domésticas que capturan espacios públicos o terceras personas calificaron como datos personales según interpretaciones de la Autoridade Nacional de Proteção de Dados (ANPD). En Argentina, la Ley 25.326 de Protección de Datos Personales establece requisitos de seguridad que aplican al responsable del tratamiento, lo que en este caso incluye al proveedor del servicio de nube. En México, la LFPDPPP obliga a informar de manera clara las finalidades del tratamiento y los destinatarios de los datos, incluidos terceros como las fuerzas del orden. Ninguna de estas leyes impide que Amazon reciba los datos, pero todas habilitan a los usuarios a exigir información sobre quién accede a su video y en qué condiciones —un derecho que TAKE, como arquitectura técnica, no garantiza por sí solo.

    La cuestión de fondo es que el cifrado en dispositivos de vigilancia doméstica conectados a la nube es inseparable del modelo de negocio del proveedor: mientras más funciones inteligentes se ofrezcan, más procesamiento en claro se requiere. Las opciones de cifrado real existen, pero el incentivo comercial apunta en dirección contraria.

    Quienes evalúen la privacidad de sus dispositivos Ring en la región deben leer los términos de respuesta a solicitudes legales de Amazon —disponibles en su Informe de Transparencia— antes de asumir que TAKE los protege de algo más que un acceso histórico no autorizado a los servidores.

  • El incidente de CISA con ChatGPT y el problema de gobernanza de IA que nadie resuelve

    El incidente de CISA con ChatGPT y el problema de gobernanza de IA que nadie resuelve

    Cuando un empleado de la Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) usó ChatGPT en un contexto no autorizado, el incidente dejó al descubierto algo más profundo que un error individual: la mayoría de las organizaciones gubernamentales y privadas no tienen marcos operativos para gobernar el uso de inteligencia artificial generativa por parte de sus equipos. El problema no es tecnológico. Es de gobernanza.

    El caso de CISA, según se informó, involucra el uso de una herramienta de IA generativa fuera de los canales aprobados por la agencia. No se trató de un ataque externo ni de una vulnerabilidad técnica en los modelos: fue un empleado que recurrió a una herramienta de acceso público para realizar tareas laborales. Este patrón tiene nombre en la industria: shadow AI, el equivalente al viejo shadow IT pero con implicancias mucho más complejas cuando los datos involucrados son sensibles o clasificados.

    Shadow AI: el riesgo que los marcos de gobernanza todavía no capturan

    El concepto de shadow AI describe el uso no autorizado o no gestionado de herramientas de inteligencia artificial dentro de una organización, generalmente por fuera de los controles aprobados por TI, seguridad o el área legal. A diferencia del shadow IT clásico —instalar una app no autorizada, usar Dropbox en lugar del servidor corporativo—, el shadow AI implica que el empleado está potencialmente transfiriendo datos hacia modelos de lenguaje externos cuyo tratamiento de la información no está bajo el control de la organización. En el caso de CISA, que opera en el ecosistema de seguridad nacional estadounidense, las consecuencias potenciales van desde la exposición de información sensible hasta la generación de contenido oficial basado en salidas no verificadas de un modelo.

    El problema estructural es que los frameworks de gobernanza de datos vigentes —incluso los más maduros, como el DAMA-DMBOK o el Data Management Capability Assessment Model (DCAM) del EDM Council— no contemplan de manera explícita el ciclo de vida del dato cuando este sale de la organización hacia un modelo de lenguaje de terceros. ¿Qué dato puede ingresarse como prompt? ¿Quién es el data steward responsable de esa decisión? ¿Existe una política de clasificación que defina qué nivel de sensibilidad habilita o prohíbe el uso de IA generativa externa? En la mayoría de las organizaciones, la respuesta a esas tres preguntas es: nadie lo definió.

    Clasificación de datos y ownership: los dos controles que fallaron en CISA

    Un análisis de gobernanza del incidente apunta a dos fallas concretas. Primero, ausencia de una política de clasificación de datos que establezca explícitamente qué categorías de información no pueden salir del perímetro organizacional bajo ningún formato, incluyendo prompts a modelos externos. Segundo, falta de ownership claro: ningún data steward tenía la responsabilidad asignada de definir las reglas de uso de IA generativa para su dominio de datos. Cuando el ownership no está definido, el empleado toma la decisión por defecto —usar la herramienta que tiene disponible— y la organización absorbe el riesgo sin haberlo evaluado.

    El NIST AI Risk Management Framework (AI RMF), publicado en 2023, ofrece un punto de partida para estructurar controles en torno a sistemas de IA, pero su adopción en organismos públicos de América Latina es todavía marginal. El framework distingue entre las funciones Govern, Map, Measure y Manage aplicadas a riesgos de IA —una estructura que puede integrarse con los dominios del DAMA-DMBOK para organizaciones que ya tienen un programa de gobernanza de datos activo.

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

    Este tipo de riesgo de shadow AI aplica a cualquier organización cuyos empleados tienen acceso a herramientas de IA generativa públicas y trabajan con datos que tienen algún nivel de sensibilidad: información regulada, datos personales bajo LGPD, Ley 25.326 o LFPDPPP, información estratégica, datos de clientes, contratos, o comunicaciones internas. No aplica de la misma manera a organizaciones donde todos los datos son públicos por naturaleza o donde los equipos ya operan exclusivamente dentro de entornos de IA privados y auditados. Para el grueso de las organizaciones de la región —bancos, aseguradoras, organismos públicos, empresas de salud—, el caso CISA es un escenario perfectamente replicable.

    En América Latina, el marco regulatorio ya exige controles que el shadow AI vulnera

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) impone al controlador la responsabilidad de demostrar que implementó medidas técnicas y organizativas suficientes para proteger los datos personales. Si un empleado ingresa datos personales de clientes en un prompt de ChatGPT sin que la organización haya definido controles para eso, el controlador está potencialmente expuesto ante la Autoridade Nacional de Proteção de Dados (ANPD). En Argentina, la Ley 25.326 y las disposiciones de la Agencia de Acceso a la Información Pública (AAIP) establecen obligaciones análogas de seguridad sobre los datos. En México, la LFPDPPP exige medidas de seguridad administrativas, físicas y técnicas —una transferencia no autorizada de datos personales a un modelo de IA externo puede interpretarse como una vulneración de esa obligación. Ninguna de estas leyes menciona explícitamente la IA generativa, pero los principios de responsabilidad y seguridad que establecen son suficientemente amplios para alcanzar este tipo de uso.

    La respuesta operativa para un equipo de gobernanza pasa por tres pasos concretos: (1) revisar la política de clasificación de datos e incorporar una capa explícita de “aptitud para IA externa” —definir qué clases de datos pueden usarse en prompts fuera del perímetro—; (2) asignar formalmente a los data stewards de cada dominio la responsabilidad de aprobar o restringir el uso de herramientas de IA generativa sobre sus datos; y (3) implementar un registro de herramientas de IA en uso, aprobadas y no aprobadas, equivalente al inventario de sistemas que ya exige el DCAM en su capability de Data Asset Inventory.

    El incidente de CISA no es una anomalía: es el primer caso documentado de una serie que crecerá mientras las organizaciones sigan tratando la gobernanza de IA como un problema futuro en lugar de un control que debió estar activo hace doce meses.

  • Veradigm: banda criminal reclama 3,5 millones de registros de salud

    Veradigm: banda criminal reclama 3,5 millones de registros de salud

    Un grupo criminal afirma haber exfiltrado 3,5 millones de registros de Veradigm, empresa estadounidense de tecnología para el sector salud, en un incidente reportado el 10 de septiembre de 2026. La compañía aún no ha confirmado oficialmente la magnitud ni el origen del compromiso.

    Veradigm —antes conocida como Allscripts Healthcare Solutions— provee plataformas de datos clínicos, registros médicos electrónicos y servicios de analítica para hospitales, consultorios y aseguradoras en Estados Unidos y mercados internacionales. Según se informó, un grupo de ciberdelincuentes publicó la reivindicación del ataque y asegura tener en su poder 3,5 millones de registros con información de pacientes y proveedores de salud. La divulgación fue detectada por investigadores de seguridad que monitorearon foros de filtración en la dark web.

    Datos confirmados al momento del reporte

    • Volumen reclamado por el grupo criminal: 3,5 millones de registros
    • Empresa afectada: Veradigm (ex-Allscripts), sector healthtech, EE.UU.
    • Fecha de la divulgación pública: 10 de septiembre de 2026
    • Confirmación oficial de Veradigm: pendiente al cierre de esta nota
    • Tipo de datos potencialmente comprometidos: no especificado con precisión en la reivindicación

    Qué se sabe y qué falta confirmar

    Lo que está confirmado es la existencia de la reivindicación pública del grupo criminal y el número de registros que alegan haber obtenido. Lo que permanece sin verificar es si la exfiltración efectivamente ocurrió, qué campos específicos contienen los registros —nombres, diagnósticos, números de seguro, datos de facturación— y si el incidente corresponde a un ataque reciente o a datos acumulados de brechas anteriores. Veradigm ya protagonizó incidentes de seguridad en años previos, incluyendo un ataque de ransomware en 2023 que afectó la operación de farmacias en EE.UU., lo que añade contexto pero no confirma la vinculación con este nuevo reclamo.

    Para los equipos de privacidad y gobernanza de datos en América Latina que operen con proveedores de tecnología sanitaria de origen estadounidense, el incidente es una señal de alerta directa. Bajo la LGPD brasileña (Lei 13.709/2018), los datos de salud son clasificados como datos sensibles y su tratamiento exige salvaguardas reforzadas; lo mismo ocurre bajo el artículo 9 del GDPR europeo y, en el plano local, bajo las leyes de protección de datos de Argentina (Ley 25.326), México (LFPDPPP) y Colombia (Ley 1581/2012). Cualquier organización latinoamericana que haya compartido registros clínicos con Veradigm o sus plataformas integradas debe activar ya una revisión de los contratos de encargado de tratamiento y verificar si existe obligación de notificación ante la autoridad de control local.

    El próximo hito crítico es la notificación regulatoria que Veradigm deberá realizar ante el Departamento de Salud de EE.UU. (HHS/OCR) bajo la HIPAA Breach Notification Rule, cuyo plazo estándar es de 60 días desde que la organización toma conocimiento del incidente.