Blog

  • Gobernanza de datos shift-left: el modelo que PayPal lleva a producción

    Gobernanza de datos shift-left: el modelo que PayPal lleva a producción

    Shift-left en gobernanza de datos significa mover los controles de calidad, clasificación y ownership lo más temprano posible en el ciclo de vida del dato: hacia los equipos de ingeniería, al momento del diseño del pipeline, no en la capa de consumo. Un ejecutivo de PayPal describió públicamente cómo la compañía está transitando ese camino, según se informó en TechTarget en septiembre de 2025. El enfoque tiene implicancias directas para cualquier CDO que hoy pelea contra brechas de calidad descubiertas demasiado tarde.

    El término viene del desarrollo de software —”shift-left testing” implica correr pruebas antes, en etapas tempranas del SDLC, para reducir el costo de corrección. Aplicado a datos, el principio es idéntico: si la clasificación, el etiquetado de sensibilidad y las reglas de calidad se aplican cuando el dato se crea o ingiere, el costo de remediación baja varios órdenes de magnitud. Según el marco DAMA-DMBOK, la gobernanza que opera solo en la capa analítica o de reporte llega cuando el daño ya está hecho.

    Qué implica técnicamente un modelo shift-left en un ecosistema como el de PayPal

    En la práctica, shift-left de gobernanza requiere tres capacidades simultáneas. Primero, que los data stewards —los responsables de dominio del dato, en la nomenclatura del DAMA-DMBOK— participen en el diseño de pipelines de ingestión, no solo en la validación posterior. Segundo, que las políticas de clasificación y calidad estén codificadas como reglas ejecutables en el pipeline mismo, no como documentos en un repositorio de SharePoint. Tercero, que el catálogo de datos activo reciba metadata desde el momento de la creación del asset, no como proceso de backfill retroactivo. En una plataforma de pagos con el volumen transaccional de PayPal, según se informó, esto implica orquestar esas capacidades a escala de miles de pipelines concurrentes.

    El modelo encaja con lo que el EDM Council denomina “Data Management Capability Assessment” (DCAM): la capability 8 del framework —gestión del ciclo de vida del dato— solo alcanza madurez cuando los controles están embebidos en el flujo de producción, no aplicados post-hoc. El enfoque shift-left es, en esencia, el camino operativo hacia ese nivel de madurez.

    Cuándo aplica este enfoque y cuándo no justifica el esfuerzo

    Shift-left de gobernanza aplica cuando la organización tiene pipelines de datos repetibles, equipos de ingeniería de datos con capacidad para implementar controles en código, y un modelo de ownership de dominio suficientemente maduro como para que exista un data steward identificable por cada dominio. También es el modelo correcto cuando la regulación exige trazabilidad desde el origen: por ejemplo, las entidades financieras en Brasil que reportan al Banco Central bajo las normas del open finance están obligadas a demostrar linaje desde la fuente, lo que hace de shift-left no una elección de diseño sino un requisito de cumplimiento. Lo mismo aplica para compañías de pagos operando en México bajo supervisión del CNBV, donde la LFPDPPP exige identificar con precisión qué dato personal fue procesado, cuándo y bajo qué base legal.

    El modelo no justifica el esfuerzo en organizaciones con pipelines ad hoc, baja repetibilidad de flujos de datos, o donde el ownership de dominio aún no está asignado. En esos casos, intentar embeber controles en pipelines que cambian semanalmente produce deuda técnica de gobernanza sin reducir el riesgo. Bob Seiner, autor de Non-Invasive Data Governance, señala que los controles de gobernanza deben anclarse en procesos existentes: si el proceso no existe o es inestable, el control no tiene dónde anclar.

    El gap en América Latina: ownership sin habilitación técnica

    El principal obstáculo regional para adoptar shift-left no es la falta de voluntad de los CDOs, sino una brecha estructural entre la asignación formal de roles de gobernanza y la habilitación técnica de esos roles. En la región, es común que un data steward tenga responsabilidad nominal sobre un dominio de datos pero no tenga acceso a las herramientas de catalogación, ni visibilidad sobre los pipelines que procesan ese dominio. Sin esa habilitación, shift-left es solo un nombre: los controles siguen corriendo en la capa de consumo, si es que corren. Los bancos argentinos que operan bajo la Comunicación A 8073 del BCRA ya enfrentan exigencias de trazabilidad de datos de clientes equivalentes a las capabilities de nivel 8 del DCAM, pero sin la infraestructura de catálogo activo que las soporte, el cumplimiento es manual y frágil.

    El modelo de PayPal es relevante para la región no como caso a replicar en escala, sino como referencia de diseño: el camino empieza por mapear qué pipelines tienen ownership claro y repetibilidad suficiente, y aplicar shift-left solo ahí primero. Nicola Askham, referente en implementación práctica de gobernanza, llama a esto “gobernanza por dominio piloto”: consolidar un dominio con controles embebidos antes de intentar el rollout horizontal.

    La documentación de referencia del DCAM del EDM Council y el capítulo 13 del DAMA-DMBOK sobre gestión del ciclo de vida del dato ofrecen los criterios concretos para evaluar si una organización tiene las condiciones mínimas para ejecutar este tipo de migración de controles.

  • Cuando el dato escolar compromete la puerta: convergencia de ciberseguridad y seguridad física

    Cuando el dato escolar compromete la puerta: convergencia de ciberseguridad y seguridad física

    Un número de ID estudiantil expuesto en una brecha de datos no es solo un dato administrativo comprometido: en muchas instituciones educativas, ese mismo número abre puertas de dormitorios, activa lectores de acceso en laboratorios y se autentica contra sistemas de automatización edilicia. La exposición digital se convierte, de forma directa, en un vector de riesgo físico.

    El escenario no es hipotético. En entornos universitarios donde la infraestructura de control de acceso físico comparte el mismo identificador que los sistemas de información académica, una base de datos comprometida invalida simultáneamente el perímetro lógico y el perímetro físico. La credencial en la billetera del estudiante y la contraseña en el portal de notas apuntan al mismo registro. Si ese registro se filtra, la exposición no se detiene en la pantalla.

    Por qué la integración de sistemas crea una superficie de ataque única

    La convergencia entre sistemas de información y control de acceso físico fue diseñada para simplificar operaciones: un solo ID para todo. Pero esa decisión de arquitectura tiene consecuencias de seguridad que pocas instituciones evaluaron con rigor. Cuando el número de legajo o matrícula estudiantil actúa como clave maestra —tanto para el sistema de gestión académica como para las cerraduras inteligentes de los edificios— el modelo de seguridad descansa sobre un único punto de falla. Una sola base de datos comprometida habilita el acceso a espacios físicos restringidos sin necesidad de clonar tarjetas ni forzar cerraduras.

    Este modelo integrado es especialmente común en universidades con campus cerrados, donde los sistemas de badge readers, torniquetes y automatización edilicia fueron conectados al directorio institucional principal por razones de eficiencia operativa. El problema es que la mayoría de esas decisiones de integración se tomaron antes de que la amenaza de exfiltración masiva de bases de datos fuera un riesgo cotidiano.

    Cuándo aplica este riesgo — y cuándo no

    Este vector de riesgo aplica cuando se cumplen al menos dos condiciones: que el identificador de control de acceso físico sea idéntico o derivado directamente del identificador almacenado en la base de datos institucional, y que esa base de datos tenga una superficie de exposición suficiente como para ser comprometida —ya sea por ataque externo, error de configuración o acceso interno indebido. No aplica, en cambio, cuando la institución utiliza identificadores físicos independientes no derivados del número de legajo, o cuando el sistema de control de acceso opera sobre una base de datos aislada con rotación periódica de credenciales. La distinción importa porque determina si una brecha en sistemas académicos tiene o no consecuencias sobre la seguridad de las personas en el campus.

    El dato personal en el centro: qué implica esto en términos de protección de datos

    Desde la perspectiva de la protección de datos, la convergencia digital-física eleva la categoría de riesgo de cualquier brecha que involucre identificadores estudiantiles. En jurisdicciones como Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que el tratamiento de datos personales contemple medidas técnicas y administrativas proporcionales al riesgo —y el riesgo de habilitar acceso físico no autorizado a espacios donde hay personas supera ampliamente el daño reputacional de una filtración de notas académicas. En Argentina, la Ley 25.326 y las disposiciones complementarias de la AAIP establecen obligaciones similares de seguridad adecuada al tipo de dato tratado.

    En México, la LFPDPPP —aunque orientada al sector privado— y los lineamientos del INAI plantean que el responsable del tratamiento debe evaluar el contexto completo de uso del dato, no solo el sistema donde reside. Una universidad pública o privada que vincula el número de matrícula a sistemas de control de acceso físico está ampliando, sin necesariamente documentarlo, el alcance del tratamiento de ese dato personal. Eso tiene implicancias directas sobre los avisos de privacidad vigentes y sobre la evaluación de impacto que debería haberse realizado antes de integrar los sistemas.

    Arquitectura de identidad como decisión de gobierno de datos

    La solución estructural no pasa por desintegrar los sistemas, sino por separar los identificadores según su función y su exposición. Un modelo de identidad federada —donde el ID académico y el ID de acceso físico son distintos, y el vínculo entre ambos está bajo control estricto con rotación programada— limita el radio de impacto de cualquier brecha. Esto es equivalente, en términos de gobernanza, al principio de minimización de datos aplicado a la arquitectura de sistemas: el dato que no necesita estar en un lugar, no debe estar.

    Instituciones que ya adoptaron controles de acceso basados en credenciales físicas independientes —tarjetas con chip propio, tokens rotantes o autenticación biométrica desvinculada del directorio LDAP central— tienen un perímetro físico que sobrevive a una brecha del sistema académico. La separación no elimina el riesgo, pero lo compartimenta.

    El ecosistema educativo latinoamericano: exposición sin marco técnico claro

    América Latina cuenta con un número creciente de universidades que han modernizado su infraestructura de campus con sistemas de control de acceso digital, especialmente en Brasil, México, Colombia y Argentina. Sin embargo, la adopción de marcos técnicos de seguridad que contemplen la convergencia digital-física es todavía limitada. Las autoridades de protección de datos de la región no han emitido, hasta ahora, lineamientos específicos para instituciones educativas sobre el tratamiento de datos personales en sistemas integrados de control de acceso. Esa ausencia normativa no reduce la responsabilidad institucional: el principio de responsabilidad proactiva —presente en la LGPD brasileña y en la reforma propuesta a la Ley 25.326 argentina— obliga a las organizaciones a anticipar riesgos, no solo a reaccionar ante ellos.

    Para quien gestiona datos en una institución educativa: la pregunta no es si el sistema de control de acceso físico está conectado al directorio de datos personales, sino qué sucede con cada puerta del campus cuando esa base de datos queda expuesta.

  • CNIL multa con €500.000 a hospital francés por brecha en registros de pacientes

    CNIL multa con €500.000 a hospital francés por brecha en registros de pacientes

    La CNIL, autoridad francesa de protección de datos, impuso el 3 de septiembre de 2026 una multa de €500.000 al Hospital Privado del Loira por no haber adoptado medidas de seguridad adecuadas para proteger la información de sus pacientes y algunos de sus familiares. El incidente se originó en el verano de 2025, cuando un atacante logró acceder al sistema de historia clínica electrónica de la institución.

    El caso se desencadenó durante el verano boreal de 2025, cuando un actor no autorizado consiguió conectarse al sistema de registro electrónico de pacientes (EPR, por sus siglas en inglés) del hospital. La CNIL concluyó su investigación casi un año después y determinó que la entidad sanitaria incumplió las obligaciones de seguridad contempladas en el Reglamento General de Protección de Datos (RGPD) de la Unión Europea, concretamente en lo relativo a medidas técnicas y organizativas proporcionales al riesgo que representa el tratamiento de datos de salud.

    Datos confirmados sobre la sanción al Hospital del Loira

    • Organismo sancionador: CNIL (Commission Nationale de l’Informatique et des Libertés), Francia.
    • Monto de la multa: €500.000.
    • Fecha de la resolución: 3 de septiembre de 2026.
    • Período del incidente: verano de 2025.
    • Sistema comprometido: registro electrónico de pacientes (EPR) del Hospital Privado del Loira.
    • Afectados: pacientes del hospital y algunos de sus familiares, según se informó.
    • Infracción principal: ausencia de medidas de seguridad apropiadas para datos de salud, categoría especial bajo el RGPD.

    Qué se sabe y qué falta confirmar

    La resolución de la CNIL establece con claridad la existencia de acceso no autorizado al EPR y la consecuente exposición de datos de salud, categoría especial que exige el nivel más alto de protección bajo el artículo 9 del RGPD. Lo que no ha trascendido públicamente hasta el momento es el volumen exacto de registros comprometidos, el vector de ataque utilizado por el intruso ni si la información fue exfiltrada o únicamente consultada de forma indebida. Tampoco se conoce si el hospital recurrirá la sanción ante los tribunales administrativos franceses.

    El caso tiene resonancia directa en América Latina, donde el tratamiento de datos de salud enfrenta un entorno regulatorio en rápida evolución. En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como sensibles y la Autoridade Nacional de Proteção de Dados (ANPD) ha intensificado su actividad fiscalizadora sobre el sector sanitario desde 2024. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) también considera los datos de salud dentro de las categorías que requieren protección reforzada bajo la Ley 25.326, aunque el techo de las sanciones locales —aún pendiente de actualización legislativa— dista significativamente de los montos que aplica la CNIL. En México, el INAI ha emitido criterios específicos sobre el tratamiento de datos clínicos bajo la LFPDPPP, pero la capacidad de enforcement en el sector privado de salud continúa siendo un punto débil estructural.

    El próximo hito a seguir es la eventual publicación íntegra de la resolución en el registro oficial de la CNIL, que determinará si el hospital tiene plazo para adecuarse a medidas correctivas específicas o si la sanción económica agota el mandato de la autoridad.

  • Brecha en proveedor C-Track afecta tribunales de decenas de estados de EE.UU.

    Brecha en proveedor C-Track afecta tribunales de decenas de estados de EE.UU.

    Un incidente de seguridad en C-Track, proveedor de software de gestión judicial, comprometió datos del Tribunal Supremo de Dakota del Norte y habría impactado a sistemas judiciales de decenas de estados de EE.UU. La brecha fue notificada al tribunal en julio de 2026 y una investigación criminal se encuentra en curso.

    El Sistema de Tribunales de Dakota del Norte confirmó que fue informado a fines de julio de que C-Track —plataforma de gestión de casos utilizada por cortes estatales— sufrió una brecha de datos que pudo haber involucrado información vinculada a ese tribunal. La divulgación fue realizada mediante un comunicado oficial, según reportó DataBreaches.net el 3 de septiembre de 2026. Las autoridades iniciaron una investigación criminal en respuesta al incidente.

    Datos confirmados sobre el incidente de C-Track

    • Proveedor afectado: C-Track, software de gestión de casos judiciales.
    • Notificación al tribunal: fines de julio de 2026.
    • Alcance reportado: decenas de estados de EE.UU. utilizan C-Track como proveedor.
    • Estado de la investigación: investigación criminal en curso al momento de la publicación.
    • Entidad confirmada afectada: Tribunal Supremo de Dakota del Norte.

    Qué se sabe y qué falta confirmar sobre el alcance real

    Hasta la fecha de publicación no se había confirmado públicamente qué tipo de datos fueron comprometidos ni el número exacto de registros afectados. Tampoco se había identificado públicamente al actor responsable del ataque, ni se habían difundido detalles técnicos sobre el vector de acceso. Según se informó, la brecha habría impactado a tribunales de “decenas de estados”, pero la lista completa de jurisdicciones afectadas no estaba disponible al cierre de esta nota. La naturaleza de los datos judiciales —que pueden incluir información de víctimas, testigos, menores e imputados— eleva el nivel de riesgo si la exfiltración se confirma en toda su extensión.

    El caso recuerda un patrón que se repite con creciente frecuencia en el sector público: la concentración de riesgo en proveedores tecnológicos transversales, cuya brecha compromete en cascada a múltiples organismos sin que estos tengan visibilidad directa sobre sus propios datos. En América Latina, este vector de ataque a terceros es igualmente crítico. Países como Brasil, bajo la Lei Geral de Proteção de Dados (LGPD), y Argentina, bajo la Ley 25.326 y la Disposición AAIP 7/2022, establecen que el responsable del tratamiento —en este caso, el tribunal— mantiene obligaciones frente a los titulares de datos incluso cuando la brecha se origina en un operador externo. La cláusula contractual con proveedores y la auditoría de terceros son requisitos que muchos organismos judiciales de la región aún no formalizan.

    El próximo hito a seguir es la notificación formal a las personas afectadas, cuyo plazo y alcance dependerán del resultado de la investigación criminal y de la identificación completa de los estados comprometidos.

  • Texas y Florida frenan redes de lectores de patentes por vigilancia masiva

    Texas y Florida frenan redes de lectores de patentes por vigilancia masiva

    En el lapso de tres días, Texas y Florida adoptaron medidas de emergencia para desmantelar sus redes de lectores automáticos de patentes (ALPR, por sus siglas en inglés). Texas prohibió el gasto de fondos públicos en cámaras Flock Safety el 28 de agosto; Florida ordenó retirar todos los dispositivos instalados en rutas estatales antes del 1° de octubre.

    La decisión del gobernador Greg Abbott llegó horas antes de que el medio The Texas Tribune publicara una investigación que reveló cómo una agencia estatal había canalizado al menos 30 millones de dólares hacia la construcción de una red de vigilancia vehicular sin autorización legislativa explícita. El decreto prohíbe a las agencias estatales contratar o renovar acuerdos con Flock Safety, la empresa más extendida en el mercado de ALPR municipal en Estados Unidos.

    Florida: 30 días para retirar cámaras de rutas estatales

    El 31 de agosto, el Departamento de Transporte de Florida (FDOT) emitió un memorándum respaldado por el gobernador Ron DeSantis que revoca todos los permisos de instalación aprobados previamente y prohíbe la emisión de nuevos permisos. Funcionarios del FDOT justificaron la medida citando “el aumento exponencial de despliegues a lo largo de nuestras rutas, acompañado de reportes preocupantes de mal uso, riesgos de privacidad de datos y esquemas de vigilancia que ameritan acción inmediata para preservar la soberanía y calidad de vida de los floridanos”, según se informó en medios locales. La orden desencadenó una ola de respuestas de sheriffs y autoridades municipales que comenzaron a retirar los dispositivos de sus jurisdicciones.

    Qué se confirma y qué falta precisar

    Está confirmado que ambas órdenes tienen carácter ejecutivo y efecto inmediato sobre el ámbito estatal, aunque su alcance sobre contratos municipales ya vigentes es aún objeto de debate legal en Florida. No está confirmado si Texas extenderá la prohibición a fondos federales canalizados por agencias estatales, ni si Florida contempla legislación permanente o la orden puede ser revertida por una administración futura. Tampoco se ha informado sobre auditorías formales a los datos de patentes ya recolectados ni sobre plazos de retención o eliminación de esa información.

    El movimiento bipartidista que impulsó estos cambios lleva años activo: decenas de municipios en distintos estados habían rescindido contratos con Flock Safety antes de las órdenes estatales, según registros de agosto de 2026 citados por Ars Technica. La EFF documentó que agosto de 2026 marcó un récord en cancelaciones de contratos a nivel municipal.

    En América Latina, el debate sobre ALPR tiene un marco legal distinto pero igualmente urgente. Argentina carece de regulación específica sobre sistemas de reconocimiento de patentes, aunque la Ley 25.326 de Protección de Datos Personales y las resoluciones de la AAIP obligan a encuadrar cualquier tratamiento masivo de datos de movilidad como dato personal cuando permite identificar a una persona. Brasil, por su parte, aplica la LGPD a sistemas similares desplegados por estados y municipios, y la ANPD ha señalado que el tratamiento de datos vehiculares con fines de seguridad pública requiere base legal expresa. México, bajo la LFPDPPP y la Ley General de Protección de Datos para el Sector Público, enfrenta un escenario similar: múltiples alcaldías y estados operan redes de ALPR sin marcos de retención ni auditoría formalmente establecidos.

    El próximo hito es el 1° de octubre de 2026, fecha límite para el retiro físico de las cámaras en rutas estatales de Florida; cualquier incumplimiento municipal activará el primer conflicto jurisdiccional derivado de la orden del FDOT.

  • Cuando el catálogo de datos es la brecha: por qué rotar credenciales no alcanza

    Cuando el catálogo de datos es la brecha: por qué rotar credenciales no alcanza

    Si un atacante compromete el catálogo de datos corporativo, no roba registros: roba el mapa completo de todo lo que la organización sabe sobre sus propios datos. Esa diferencia convierte a este tipo de incidente en una categoría aparte, y hace que la respuesta estándar —rotar credenciales, parchear el vector, cerrar el ticket— sea radicalmente insuficiente.

    Un catálogo de datos centraliza la metadata técnica y de negocio de una organización: qué tablas existen, qué contienen, quién las accede, cómo se relacionan entre sí, qué tan sensibles son y bajo qué política de retención operan. Herramientas como Apache Atlas, Alation, Collibra, DataHub o Amundsen acumulan esa inteligencia en un único punto. Según el marco DAMA-DMBOK, el catálogo es la columna vertebral del capability de Metadata Management, sin el cual el resto de las disciplinas de gobernanza de datos no puede operar. Eso lo convierte también en el activo de mayor valor estratégico para un adversario que quiera planificar ataques futuros o entender la arquitectura de datos de su objetivo.

    El catálogo no guarda datos: guarda el conocimiento sobre los datos

    La diferencia de impacto frente a una brecha convencional es estructural. En un incidente típico, el atacante extrae un conjunto de registros —números de tarjeta, correos, datos de salud— y el daño está acotado a esos registros. En una brecha de catálogo, el adversario obtiene el inventario completo: sabe qué base de datos contiene los datos de clientes premium, qué pipeline los mueve, quién tiene acceso privilegiado y qué controles (o ausencia de ellos) los protegen. Es, en términos prácticos, un reconocimiento total del entorno de datos. Los equipos de seguridad ofensiva llaman a esto “living off the land” aplicado a la capa de metadata.

    El data lineage —la trazabilidad de cómo un dato se mueve desde su origen hasta su destino final— amplifica el daño. Un catálogo moderno que almacena linaje completo le entrega al atacante el grafo de dependencias de toda la infraestructura de datos: desde los sistemas fuente hasta los data marts que alimentan los reportes ejecutivos. Con esa información, un atacante paciente puede planificar intrusiones quirúrgicas en sistemas downstream sin necesidad de escanear la red.

    Por qué rotar credenciales no resuelve la exposición del catálogo

    La rotación de credenciales corta el acceso activo, pero no borra el conocimiento ya adquirido. Si el catálogo estuvo expuesto durante horas o días, el atacante ya tiene una copia del inventario de metadata. Cambiar contraseñas o revocar tokens resuelve el vector de entrada, no el daño informacional. Es equivalente a cambiar la cerradura de una caja fuerte después de que alguien fotografió el contenido. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica explícitamente la protección de metadata sensible como un control de nivel 2 bajo el capability de Data Control, diferenciado del control de acceso a los datos en sí. Muchas organizaciones aplican controles de clase A a sus bases de datos productivas y dejan el catálogo con controles de clase C, sin clasificación de sensibilidad propia ni auditoría de acceso detallada.

    El problema se agrava porque los catálogos modernos tienden a integrarse con sistemas de identidad corporativa (LDAP, Azure AD), orquestadores (Airflow, Dagster), plataformas de transformación (dbt) y herramientas de observabilidad. Un catálogo comprometido puede ser el punto de pivote hacia toda esa cadena. El data steward responsable de ese dominio raramente tiene visibilidad sobre los logs de acceso al catálogo con el mismo nivel de detalle con el que el equipo de seguridad audita los sistemas productivos.

    Cuándo aplica este riesgo / cuándo NO

    Este vector de riesgo aplica a organizaciones que operan un catálogo de datos centralizado con metadata enriquecida: clasificación de sensibilidad, linaje automatizado, integración con pipelines activos y perfiles de datos. Si el catálogo es una planilla Excel o un repositorio estático sin conexión a sistemas productivos, el riesgo es considerablemente menor, aunque no nulo. No aplica —al menos no con esta criticidad— en entornos donde el catálogo está aislado de la red, opera sin autenticación federada y no contiene metadata operativa actualizada. En arquitecturas de data mesh, donde cada dominio puede operar su propio catálogo local, el riesgo se distribuye pero no desaparece: un catálogo de dominio financiero sigue siendo un activo de alto valor.

    El ángulo en América Latina: cumplimiento normativo post-brecha

    En la región, una brecha de catálogo tiene implicancias regulatorias que van más allá de lo técnico. En Brasil, la LGPD (Lei 13.709/2018) obliga a notificar a la ANPD cuando el incidente puede acarrear riesgo relevante a los titulares. Si el catálogo expuesto documenta el tratamiento de datos sensibles —salud, biometría, datos financieros— la organización debe evaluar si la exposición de esa metadata activa la obligación de notificación, incluso si los datos en sí no fueron exfiltrados. En Argentina, la Ley 25.326 y las disposiciones de la AAIP siguen una lógica similar. En México, el INAI ha comenzado a interpretar el concepto de “tratamiento” de datos de forma más amplia, lo que podría incluir la exposición de metadata que revela el alcance de ese tratamiento. Esta ambigüedad regulatoria es un riesgo legal no trivial que los equipos jurídicos de muchas organizaciones de la región aún no tienen mapeado.

    Para un CDO que quiere evaluar la exposición real de su organización, el punto de partida es concreto: auditar los logs de acceso al catálogo con la misma rigurosidad que se auditan los sistemas productivos; clasificar el catálogo como activo de datos sensible con su propio data owner y política de acceso; revisar si el data steward de cada dominio tiene visibilidad sobre quién accede a la metadata de su dominio y cuándo; y documentar el proceso de respuesta a incidentes específico para el catálogo, separado del playbook genérico de seguridad.

    Para profundizar en los controles de metadata bajo el framework CDMC del EDM Council, el punto de partida es el capability 8 (Data Control) disponible en edmcouncil.org; para el marco regulatorio de notificación en la región, la Guía de Medidas de Seguridad de la AAIP y las Resoluções de la ANPD ofrecen los criterios de evaluación más actualizados.

  • Juez falla que el Pentágono retalió ilegalmente contra Anthropic por negarse a la vigilancia masiva

    Juez falla que el Pentágono retalió ilegalmente contra Anthropic por negarse a la vigilancia masiva

    Un juez federal dictaminó que el Departamento de Defensa de Estados Unidos violó la Primera Enmienda al declarar a Anthropic un “riesgo en la cadena de suministro” como represalia por negarse a permitir que su tecnología fuera usada para la vigilancia masiva de ciudadanos estadounidenses. La designación, que impedía al gobierno y a sus contratistas utilizar los productos de la compañía, fue calificada por el tribunal como “retaliación ilegal e inconstitucional”.

    El conflicto se originó en febrero de 2026, cuando el Pentágono comenzó a presionar a Anthropic para que abandonara su postura de no permitir que su modelo de lenguaje Claude fuera utilizado en programas de vigilancia masiva de personas en suelo estadounidense ni en sistemas de armas autónomas. Ante la negativa de la empresa, el Departamento de Defensa —argumentando que no toleraría que contratistas privados limitaran el uso de sus propias herramientas— activó la designación de “riesgo en cadena de suministro”, con consecuencias comerciales inmediatas para Anthropic. El tribunal concluyó que esa maniobra constituyó una represalia ilegal en violación de la Primera Enmienda.

    Lo que el fallo confirma y lo que deja sin resolver

    • Confirmado: la designación de “supply chain risk” del DoD fue retaliación inconstitucional contra el discurso protegido de Anthropic.
    • Confirmado: la Electronic Frontier Foundation (EFF) presentó amicus briefs en apoyo de Anthropic en dos instancias del proceso.
    • Sin resolver: el tribunal no se pronunció sobre si las decisiones de una empresa respecto al uso de su tecnología constituyen, en sí mismas, discurso protegido.
    • Sin resolver: el Congreso de EE.UU. no ha adoptado salvaguardas estatutarias que regulen cuándo el gobierno puede usar IA privada para vigilancia.

    El vacío legal que el fallo no tapa: vigilancia, contratos y sin ley del Congreso

    La EFF celebró el fallo pero advirtió que el problema estructural persiste: la decisión de si los ciudadanos son o no susceptibles a la vigilancia estatal queda en manos de negociaciones a puertas cerradas entre funcionarios militares y ejecutivos de empresas de IA. El Congreso, según la organización, ha abandonado su responsabilidad de legislar protecciones de privacidad concretas, dejando a la ciudadanía dependiente de la voluntad de compañías privadas para delimitar el alcance del estado de vigilancia.

    Este escenario tiene resonancias directas para América Latina. En la región, el uso de sistemas de inteligencia artificial por fuerzas de seguridad y agencias estatales avanza con marcos legales fragmentarios. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD) y, desde 2024, con el marco regulatorio de IA en discusión parlamentaria, pero no existe aún una prohibición expresa del uso de IA para vigilancia masiva. Argentina, cuya Ley 25.326 de Protección de Datos Personales es anterior a la era de los modelos generativos, tampoco contempla restricciones específicas al uso gubernamental de IA en este contexto. México enfrenta un escenario similar bajo la LFPDPPP, orientada al sector privado. El caso Anthropic ilustra que incluso en jurisdicciones con mayor desarrollo institucional, la protección depende hoy más de la ética corporativa de un proveedor que de una ley.

    La próxima batalla en este expediente —Anthropic v. Department of War et al.— será definir si las políticas de uso aceptable de una empresa de IA son discurso constitucionalmente protegido: una pregunta cuya respuesta podría reconfigurar la relación entre proveedores de IA y estados en todo el hemisferio.

  • El apagón de DonWeb y la pregunta que nadie te puede responder

    El apagón de DonWeb y la pregunta que nadie te puede responder

    Imaginate que tu empresa depende de un proveedor de hosting. Un día, sin aviso previo, todos tus servicios dejan de andar. No podés facturar, no podés atender a tus clientes, ni siquiera podés entrar a bajar tus propios datos para mudarte a otro lado. Pasan las horas, pasan los días, y lo único que recibís es un comunicado de manual que habla de “reemplazo de un componente de conexión” y de trabajos para “normalizar el entorno”. Nada más. Ni una cifra, ni un plazo, ni una explicación real.

    Eso es lo que vivieron esta semana miles de usuarios de DonWeb, después de que una falla dejara caído el 100% de los Cloud Servers del nodo NOVA. Coaches, pymes, estudios profesionales: negocios enteros con la persiana bajada durante días, mientras la empresa administraba el silencio como si fuera parte del servicio.

    El problema no es la caída. Es lo que vino después

    Los sistemas se caen. Eso, lamentablemente, es parte de operar infraestructura crítica y ninguna empresa está exenta. Lo que no debería tener excusa es la respuesta: un comunicado que suena más a parte de prensa redactado para no decir nada que a una rendición de cuentas real. “No existe riesgo de pérdida de datos”, dijeron. Sin métricas, sin cronología, sin una sola precisión sobre el alcance real del incidente. La confianza no se recupera con una frase tranquilizadora; se recupera con información verificable.

    Lo planteé en el hilo que disparó la conversación: la magnitud de lo que pasó ameritaba mucho más que eso. Y la respuesta de la comunidad en Twitter/X lo confirmó de sobra. No fue una queja aislada, fue una catarata de usuarios frustrados, algunos de ellos con su negocio literalmente parado, otros directamente imposibilitados de entrar a exportar sus propios datos para irse a otro proveedor. Eso no es un detalle técnico menor: es quedar secuestrado por la misma empresa que te falló.

    Lo grave: nada de esto es ilegal

    Y acá está el verdadero problema, el que me interesa remarcar: hoy en Argentina, una empresa puede tener un incidente que afecte al 100% de su infraestructura, decidir contar lo mínimo indispensable, tardar días en dar señales de vida, y no violar una sola norma. La Ley 25.326 no establece ninguna obligación de notificar incidentes de seguridad, ni a los titulares de los datos ni a la AAIP. La autoridad de aplicación lo recomienda dentro de las obligaciones generales de seguridad, pero una recomendación no obliga a nadie a nada. Es una sugerencia con la que cualquier empresa puede quedar bien parada haciendo lo mínimo.

    Esa laxitud no es neutral. Termina premiando el silencio. Mientras comunicar con transparencia implica exponerse a la crítica pública, no comunicar no tiene ningún costo legal. Así de simple, así de desalentador.

    Un sistema pensado para proteger a la empresa, no al usuario

    La Ley 25.326 tiene más de dos décadas y sigue vigente prácticamente intacta en este punto, mientras el país entero se mudó a la nube, tercerizó su infraestructura crítica y depende por completo de proveedores tecnológicos para sostener cualquier actividad económica. No es un desfasaje menor: es una ley diseñada para un mundo que ya no existe, aplicada sobre un ecosistema digital completamente distinto.

    El resultado es previsible: los usuarios no tienen ninguna herramienta legal para exigir una explicación completa y oportuna. No pueden tomar decisiones informadas sobre sus propios datos porque no cuentan con la información necesaria para hacerlo. Y la autoridad de aplicación pierde cualquier posibilidad de intervenir a tiempo, porque se entera de los incidentes -si se entera- por Twitter, no por una notificación formal. La reputación quedó como único mecanismo de control. Y la reputación no repone datos perdidos, no compensa a una pyme que estuvo días sin facturar, ni le devuelve a nadie la posibilidad de haber tomado una decisión distinta a tiempo.

    La buena voluntad no escala

    Comunicar con transparencia el alcance, el impacto, las medidas adoptadas y el estado de recuperación de un incidente debería ser lo mínimo esperable de cualquier proveedor serio, sin que haga falta una ley que lo obligue. Pero seamos honestos: si dependemos de la buena voluntad corporativa para garantizar derechos básicos, ya sabemos cómo termina esa historia. La buena voluntad no escala, y mucho menos cuando lo que está en juego es la reputación de la propia empresa que tiene que dar la cara.

    Por eso la discusión no puede quedar en el plano de las buenas prácticas. Argentina necesita, ya, una reforma de su ley de protección de datos personales que incorpore la obligación expresa de notificar incidentes de seguridad -tanto a los titulares de los datos como a la AAIP- dentro de plazos concretos y con contenido mínimo obligatorio. No es una idea exótica ni una imposición burocrática: es el estándar que rige hace años en buena parte del mundo. El RGPD europeo exige notificar a la autoridad dentro de las 72 horas de conocido el incidente, con multas severas para quien no lo haga. Argentina, que supo tener uno de los regímenes de protección de datos más avanzados de la región, hoy quedó rezagada frente a una exigencia que en otros lugares ya es moneda corriente.

    ¿Cuántos incidentes como el de DonWeb están pasando ahora mismo, en otras empresas, sin que nadie se entere porque no hubo un hilo de Twitter que los visibilizara? Esa es la parte más inquietante de todo esto: lo de DonWeb se supo porque generó ruido público, no porque el sistema esté diseñado para que se sepa.

    Mientras la reforma de la Ley 25.326 siga cajoneada, cada incidente de seguridad va a seguir resolviéndose de la misma manera: puertas para adentro, con la empresa decidiendo unilateralmente cuánto le cuenta al usuario sobre lo que pasó con su propia información. Eso no es un problema de comunicación corporativa. Es un problema de derechos, y ya es hora de tratarlo como tal.

  • Gobernanza de datos en minería: decisiones críticas bajo datos confiables

    Gobernanza de datos en minería: decisiones críticas bajo datos confiables

    La industria minera opera con decisiones de miles de millones de dólares que dependen de datos geológicos, operativos y financieros. Sin una gobernanza de datos sólida, esos datos son ruido —y los errores se miden en pozos secos, paradas de planta o accidentes evitables.

    El concepto de gobernanza de datos en minería no se reduce a proteger información sensible: abarca definir quién es propietario de cada dato, qué versión del dato es la oficial, cómo se trazó desde su origen y con qué calidad llega a la sala de decisiones. En términos del marco DAMA-DMBOK —el estándar de referencia para la disciplina—, hablamos de las capabilities de data quality, data lineage y data ownership aplicadas a un entorno industrial de alta criticidad.

    Qué datos mueven la aguja en una operación minera

    Una mina activa genera volúmenes masivos de datos heterogéneos: telemetría de equipos pesados, modelos de bloques geológicos, registros de perforación, datos de ley del mineral, consumo energético, variables de planta y métricas de seguridad operacional. El problema no es la cantidad —es la fragmentación. Cada área suele operar con sus propias fuentes, sus propias definiciones y, con frecuencia, sus propias hojas de cálculo paralelas. Cuando la dirección consolida esa información para decidir si avanzar con una nueva fase de extracción, puede estar trabajando con versiones distintas del mismo dato sin saberlo.

    El data lineage —la trazabilidad que permite saber de dónde viene un dato, qué transformaciones sufrió y quién lo modificó— es la herramienta que permite detectar esas inconsistencias antes de que lleguen al tablero ejecutivo. Sin ese linaje documentado, la auditoría de decisiones pasadas es prácticamente imposible, y la mejora continua queda reducida a intuición.

    Ciberseguridad como extensión del gobierno del dato, no como disciplina separada

    La ciberseguridad en entornos mineros ha ganado visibilidad tras incidentes en operaciones de países productores como Chile, Perú y Australia, donde ataques a sistemas SCADA o de gestión de flota comprometieron tanto la continuidad operativa como la integridad de los datos de producción. Este punto es clave: cuando un sistema de control es comprometido, el daño no es solo operativo —los datos que ese sistema registró durante el ataque pierden confiabilidad. Si no hay controles de calidad ni mecanismos de detección de anomalías en el flujo de datos, esos registros corruptos pueden alimentar modelos de decisión sin que nadie lo advierta.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), establece que la seguridad del dato no es una capa externa sino una dimensión intrínseca del gobierno del dato. Esto implica que los equipos de data governance y los equipos de ciberseguridad deben trabajar con taxonomías compartidas: qué datos son críticos, qué nivel de sensibilidad tienen, quién puede acceder a ellos y bajo qué condiciones. En minería, eso se traduce en clasificar, por ejemplo, los modelos de recursos como activos de información de máxima criticidad —con controles equivalentes a los que se aplican a información financiera material.

    Cuándo aplica una arquitectura de gobierno del dato en minería — y cuándo no

    Una arquitectura formal de gobierno del dato tiene sentido en operaciones con múltiples fuentes de datos integradas, equipos multidisciplinarios que comparten información para decidir, y regulaciones sectoriales que exigen trazabilidad —como los reportes de recursos y reservas bajo el Código JORC o el Código NI 43-101 en América del Norte, que obligan a documentar la metodología y los datos subyacentes usados para estimar recursos minerales. En esos contextos, un catálogo de datos con data stewards asignados por dominio (geología, producción, mantenimiento, finanzas) no es un lujo: es un requisito de cumplimiento.

    Por otro lado, en operaciones pequeñas o de una sola fase, un programa formal de gobierno puede ser desproporcionado. Allí, la prioridad es establecer definiciones mínimas acordadas, identificar las fuentes únicas de verdad para las métricas críticas y documentar los procesos de transformación de datos antes de que escalen. El marco Non-Invasive Data Governance de Bob Seiner ofrece una alternativa pragmática: formalizar lo que ya existe en los procesos sin imponer burocracia nueva.

    El ángulo regulatorio en América Latina: minería, datos y obligaciones emergentes

    En la región, la gobernanza de datos en minería empieza a cruzarse con marcos regulatorios más amplios. En Chile, donde el sector representa cerca del 15% del PBI según datos del Banco Central, la Comisión para el Mercado Financiero (CMF) ya exige estándares de divulgación de información que incluyen datos operativos materiales —lo que obliga a las mineras listadas a tener trazabilidad sobre cómo se construyen esas cifras. En Perú, la Superintendencia del Mercado de Valores (SMV) avanza en línea similar. En Brasil, las empresas mineras de escala están alcanzadas por la Lei Geral de Proteção de Dados (LGPD) cuando procesan datos de empleados, contratistas y comunidades impactadas —lo que exige identificar y clasificar esos datos dentro del mismo ecosistema de gobierno que gestiona los datos operativos. Tratar ambos mundos como silos separados es uno de los errores más frecuentes en la madurez de gobierno del dato del sector.

    Para profundizar en los estándares de clasificación y trazabilidad aplicables a datos de recursos minerales, el Código JORC (Joint Ore Reserves Committee) y el marco CDMC del EDM Council son los puntos de partida obligados para cualquier equipo de gobierno del dato en el sector.

  • Irlanda multa al sistema de salud con €645.000 por registros médicos mal gestionados

    Irlanda multa al sistema de salud con €645.000 por registros médicos mal gestionados

    La Comisión de Protección de Datos de Irlanda (DPC) multó al Ejecutivo de Servicios de Salud (HSE) con €645.000 por el manejo deficiente de registros históricos en papel en dos hospitales públicos: St. Loman’s de Mullingar, en el condado de Westmeath, y St. Conal’s de Letterkenny. La sanción cierra una investigación formal sobre cómo ambas instituciones gestionaron —o dejaron de gestionar— archivos físicos con datos de pacientes.

    Según se informó, la DPC concluyó su indagación determinando que el HSE incumplió obligaciones de protección de datos en relación con registros históricos almacenados en esos dos centros. El organismo regulador irlandés no detalló públicamente la cantidad de personas afectadas ni el período exacto al que corresponden los documentos comprometidos, pero la investigación habría abarcado archivos de carácter sensible por tratarse de historial clínico. La multa de €645.000 fue comunicada el 1 de septiembre de 2026.

    Datos confirmados sobre la sanción al HSE

    • Autoridad sancionadora: Data Protection Commission (DPC) de Irlanda
    • Monto de la multa: €645.000
    • Entidad sancionada: Health Service Executive (HSE), sistema público de salud irlandés
    • Instalaciones involucradas: St. Loman’s Hospital (Mullingar, Westmeath) y St. Conal’s Hospital (Letterkenny)
    • Tipo de registros: archivos históricos en papel con datos de pacientes
    • Origen del caso: investigación formal de la DPC sobre manejo de registros físicos

    Qué se sabe y qué falta confirmar

    Lo confirmado es que la infracción se vincula a la gestión de registros físicos —no a un ciberataque— lo que ubica el caso en el terreno del cumplimiento documental y los procedimientos internos de custodia. Lo que no surge de la información disponible es si hubo acceso no autorizado por terceros, cuántos titulares de datos resultaron afectados, ni si el HSE había notificado previamente a los pacientes. Tampoco se conoce si la entidad impugnará la resolución ante los tribunales, una vía que el GDPR habilita. No hay información pública sobre medidas correctivas exigidas en paralelo a la multa.

    El caso es relevante más allá de Europa porque pone de relieve un vector de riesgo frecuentemente subestimado en hospitales públicos de América Latina: los archivos en papel. En Argentina, la Ley 25.326 obliga a cualquier responsable de base de datos —incluyendo organismos de salud— a garantizar condiciones de seguridad adecuadas para la información, independientemente del soporte. El Ministerio de Salud y la Agencia de Acceso a la Información Pública (AAIP) han avanzado en digitalización, pero los acervos físicos de larga data siguen sin protocolos uniformes de custodia, acceso y destrucción segura. En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como sensibles y exige tratamiento diferenciado; la Autoridade Nacional de Proteção de Dados (ANPD) aún no ha publicado un marco específico para archivos hospitalarios históricos en soporte físico.

    La próxima referencia temporal a monitorear es la posible resolución del HSE sobre si apelará la sanción, lo que determinaría si los €645.000 quedan firmes o ingresan a un proceso judicial que podría extenderse meses.