Autor: Redacción

  • Verificación de edad en internet: cuando el documento se vuelve el portero digital

    Verificación de edad en internet: cuando el documento se vuelve el portero digital

    Las leyes de verificación de edad se multiplican globalmente con el argumento de proteger a menores en línea, pero la mayoría ignora una consecuencia estructural: millones de personas sin documento de identidad verificable quedan excluidas del acceso a internet. El debate técnico sobre privacidad oculta una pregunta más urgente sobre derechos fundamentales.

    La premisa suena razonable: si un usuario no puede acreditar su edad, no accede al servicio. Pero esa lógica tiene un punto ciego. En todo el mundo existen personas que carecen de documentación oficial válida —migrantes irregulares, apátridas, comunidades rurales con registros civiles deficientes, personas trans cuyos documentos no reflejan su identidad real— para quienes la verificación de edad no es un trámite incómodo sino una barrera infranqueable. Cuando el acceso a información depende de presentar un ID, el derecho a informarse deja de ser universal.

    Una ola regulatoria que acelera sin coordinación

    En menos de dos años, el mapa regulatorio cambió de forma drástica. A finales de 2025, Australia se convirtió en el primer país en prohibir a menores de 16 años crear cuentas en redes sociales, con verificación de edad obligatoria como mecanismo de control. El Reino Unido, mediante la Online Safety Act, extendió la exigencia de verificación a cualquier plataforma que aloje contenidos “potencialmente dañinos” para usuarios menores de 18. Más de la mitad de los estados de los Estados Unidos aprobaron leyes propias —con distinto alcance y sin estándar técnico común—, generando un terreno litigioso que aún no se resuelve. La Comisión Europea, a través de un panel de expertos, recomienda prohibir el acceso a redes sociales para menores de 13 y exigir verificación etaria en plataformas de alcance masivo. India, por su parte, incorporó el consentimiento parental verificable en su Digital Personal Data Protection Act (DPDP Act), con debates abiertos sobre restricciones adicionales a redes sociales.

    El patrón común es la velocidad. Los marcos regulatorios avanzan más rápido que la infraestructura técnica capaz de implementarlos sin daños colaterales. Y la pregunta sobre quiénes no pueden cumplir el requisito —no porque no quieran, sino porque no tienen los documentos exigidos— raramente aparece en los considerandos de estas normas.

    Cuándo aplica la verificación de edad / cuándo NO resuelve el problema

    La verificación de edad funciona razonablemente cuando el universo de usuarios tiene acceso documentado al sistema de identificación oficial y cuando el servicio en cuestión es prescindible. Ninguna de esas dos condiciones se cumple de forma universal. En contextos donde el acceso a plataformas digitales es el principal canal para buscar empleo, acceder a servicios de salud o ejercer libertad de expresión, bloquear el acceso por falta de documento equivale a suspender derechos básicos. La verificación de edad tampoco resuelve el problema que dice resolver: los menores con acceso a documentos ajenos, o con dispositivos compartidos con adultos, pueden eludir los controles con relativa facilidad, mientras que los adultos sin documentación quedan excluidos permanentemente.

    El Electronic Frontier Foundation (EFF) ha señalado reiteradamente que los sistemas de verificación basados en documentos de identidad oficial concentran riesgos de privacidad severos —las plataformas o sus intermediarios técnicos acumulan datos de identidad que pueden ser vulnerados o reutilizados— y además generan exclusión estructural. Ambos efectos son predecibles y no requieren especulación técnica avanzada para anticiparlos.

    América Latina: alta informalidad documental, regulación en construcción

    En América Latina, la tensión entre verificación de edad y acceso a derechos tiene una dimensión adicional: la informalidad documental es significativamente mayor que en los países que lideran esta ola regulatoria. Según datos del Banco Mundial, alrededor del 10% de la población latinoamericana adulta carece de documento de identidad vigente o accesible, con brechas notablemente mayores en zonas rurales de países como Bolivia, Guatemala y Haití. En ese escenario, replicar modelos de verificación de edad basados en ID oficial implica importar un sistema de exclusión ya incorporado al diseño.

    A nivel normativo, ningún país de la región ha aprobado aún una ley de verificación de edad para redes sociales con el alcance de la australiana o la británica, pero varios debates legislativos están activos. En Brasil, el marco del Estatuto da Criança e do Adolescente (ECA) y la LGPD establecen obligaciones de protección de datos de menores que las plataformas deben respetar, aunque sin exigir verificación técnica de edad como condición de acceso. En Argentina, la Ley 25.326 de Protección de Datos Personales no contempla ese mecanismo, aunque proyectos de reforma en discusión incorporan referencias al tratamiento de datos de menores. En México, la LFPDPPP tampoco define un régimen específico de verificación etaria para plataformas digitales, y el debate está aún en etapa incipiente en el Congreso.

    El riesgo real para la región es que, ante presión de organismos internacionales o por efecto de armonización con mercados como la UE, se adopten marcos importados sin adaptar las condiciones de identidad civil existentes. Una regulación copiada sin ajuste local puede excluir a los sectores más vulnerables precisamente de los servicios diseñados, en apariencia, para protegerlos.

    El derecho de acceso a la información como límite a la verificación

    Varios instrumentos internacionales reconocen el acceso a la información como derecho fundamental. La Relatoría Especial para la Libertad de Expresión de la CIDH ha advertido en distintos informes que las restricciones al acceso a internet deben cumplir con estándares de necesidad y proporcionalidad. Una norma que bloquea el acceso de adultos no documentados a plataformas de información general —no solo a contenidos para adultos— difícilmente supera ese umbral. El debate sobre verificación de edad no es solo técnico ni solo de privacidad: toca el núcleo de quién tiene derecho a participar en el espacio digital.

    El texto completo del análisis de EFF está disponible en eff.org/issues/age-verification; para el marco regional, el Estatuto da Criança e do Adolescente de Brasil (Ley 8.069/1990) y los proyectos de reforma de la Ley 25.326 en Argentina son los instrumentos a seguir de cerca en los próximos meses.

  • Coupang impugna multa de 620.000 millones de won por brecha de 33 millones de usuarios

    Coupang impugna multa de 620.000 millones de won por brecha de 33 millones de usuarios

    El mayor retailer online de Corea del Sur, Coupang, presentó acciones judiciales para impugnar una multa de 620.000 millones de won (aproximadamente 450 millones de dólares) impuesta por la autoridad coreana de protección de datos tras una brecha que afectó a más de 33 millones de clientes. El incidente, ocurrido en noviembre de 2025, lleva nueve meses en la agenda pública y aún no está cerrado.

    Según se informó, la brecha fue ejecutada por un ex desarrollador que trabajó para la compañía. Coupang reconoció el incidente en diciembre de 2025, emitió disculpas públicas y procedió a notificar a los usuarios afectados. Sin embargo, la magnitud de la sanción impuesta por el regulador —cifra sin precedentes en el historial de multas de privacidad asiático reciente— derivó en la decisión corporativa de litigar en lugar de acatar.

    Datos confirmados sobre el incidente y la sanción

    • Fecha de la brecha: noviembre de 2025.
    • Usuarios afectados: más de 33 millones de clientes.
    • Notificación pública y disculpa: diciembre de 2025.
    • Multa impuesta: 620.000 millones de won (aprox. 450 millones de dólares).
    • Actor del incidente: ex desarrollador de la empresa, según se informó.
    • Acción judicial: Coupang presentó demandas para impugnar la sanción en octubre de 2026.

    Qué se sabe y qué falta confirmar

    Los hechos confirmados apuntan a un insider como vector del incidente y a una respuesta corporativa que demoró al menos un mes entre el ataque y la comunicación pública. Lo que aún no está aclarado públicamente es el tipo exacto de datos comprometidos, si existieron fallas en controles de acceso previas al incidente, y bajo qué artículos específicos de la Ley de Protección de Información Personal de Corea del Sur (PIPA) se fundamentó el cálculo de la multa. Tampoco se ha confirmado si el regulador aceptará negociar o si el proceso judicial irá a término.

    El caso tiene relevancia directa para los equipos de privacidad y legales en América Latina. Brasil, bajo la LGPD (Lei 13.709/2018), habilita a la ANPD a imponer sanciones de hasta el 2% de la facturación local de la empresa, con un techo de 50 millones de reales por infracción. Argentina, con la Ley 25.326 y su Agencia de Acceso a la Información Pública (AAIP), también prevé sanciones escalonadas, aunque el techo efectivo ha sido históricamente más bajo. En ambos marcos, la dilación en la notificación —como el mes transcurrido entre el incidente de Coupang y su comunicación— agrava la calificación de la infracción y puede elevar la sanción aplicable.

    El próximo hito clave es la admisión formal de las demandas por parte del tribunal coreano competente, instancia que definirá si la multa queda suspendida cautelarmente mientras se sustancia el proceso.

  • Por qué la regulación de IA debe anclar en gobernanza de datos y seguridad

    Por qué la regulación de IA debe anclar en gobernanza de datos y seguridad

    Expertos en política tecnológica coinciden en que las leyes de inteligencia artificial que se están diseñando en distintas jurisdicciones fallan cuando no regulan la base del problema: la calidad y el gobierno del dato que alimenta a los sistemas. Sin gobernanza de datos sólida y sin marcos de seguridad verificables, la confianza pública en la IA es estructuralmente imposible.

    El debate sobre cómo regular la inteligencia artificial tiende a concentrarse en los outputs —sesgos algorítmicos, deepfakes, decisiones automatizadas— y pasa por alto la infraestructura de datos que determina si esos outputs son confiables desde el origen. Según se informó, especialistas en regulación tecnológica señalan que las nuevas leyes de IA deben atacar dos vectores concretos: la gobernanza de los datos usados para entrenar y operar los sistemas, y los estándares de seguridad que los acompañan durante todo su ciclo de vida.

    El dato como punto de partida regulatorio, no como detalle técnico

    La lógica regulatoria dominante hasta ahora trata al dato como un insumo cuya calidad es responsabilidad del desarrollador, sin obligaciones específicas de reporte o verificación externa. El argumento que circula entre expertos es distinto: si un sistema de IA toma decisiones con consecuencias jurídicas o económicas, el regulador debería poder auditar no solo el modelo sino el linaje del dato —qué fuentes se usaron, cómo se procesaron, qué sesgos conocidos existen en el dataset. Este enfoque, que en gobernanza corporativa ya existe bajo marcos como el DAMA-DMBOK o el CDMC del EDM Council, todavía no migró de forma sistemática al ámbito regulatorio estatal.

    La razón es política, no técnica. Establecer requisitos de linaje y calidad de dato implica obligaciones para los desarrolladores de modelos fundacionales —muchos radicados en Estados Unidos o China— que son difíciles de fiscalizar desde jurisdicciones con menor capacidad de enforcement. Aun así, el consenso entre especialistas apunta a que sin esa capa, las leyes de IA protegen la forma pero no el fondo.

    Seguridad: el concepto que cada ley define distinto

    El segundo eje es la seguridad de los sistemas de IA, un término que en el debate regulatorio carga con al menos tres acepciones distintas: seguridad técnica frente a ataques adversariales, seguridad funcional entendida como comportamiento predecible dentro de parámetros definidos, y seguridad social entendida como ausencia de daños para grupos vulnerables. Las leyes que no especifican cuál de las tres están regulando generan ambigüedad que los operadores aprovechan para el cumplimiento mínimo. El AI Act de la Unión Europea —vigente desde agosto de 2024— intenta resolver esto con una clasificación de riesgo que impone obligaciones diferenciadas, aunque su implementación efectiva sigue siendo materia de debate entre los supervisores nacionales.

    Cuándo aplica este enfoque y cuándo no

    La propuesta de anclar la regulación de IA en gobernanza de datos y seguridad es más operativa para sistemas de alto impacto: crédito, salud, empleo, justicia penal. Para aplicaciones de bajo riesgo —recomendaciones de contenido sin consecuencias jurídicas, asistentes de productividad sin acceso a datos sensibles— el nivel de exigencia debería ser proporcional. El riesgo del enfoque contrario, regular todo con el mismo rigor, es la parálisis de la innovación en contextos donde los recursos de cumplimiento son escasos, como ocurre en la mayoría de los ecosistemas de startups de IA en América Latina.

    América Latina: marcos nacientes, una oportunidad concreta

    Brasil avanza con la propuesta de Ley de IA (PL 2338/2023), que incorpora obligaciones de transparencia y evaluación de riesgo pero no establece todavía requisitos explícitos de linaje de datos ni auditoría de datasets de entrenamiento. México, cuya Ley Federal de Protección de Datos Personales en Posesión de Particulares (LFPDPPP) data de 2010, no tiene un marco de IA en tramitación parlamentaria avanzada. Argentina aprobó en 2024 un plan nacional de IA, aunque sin rango de ley. Colombia, Chile y Perú trabajan en lineamientos sectoriales, pero ninguno impone aún obligaciones de gobernanza de datos específicas para desarrolladores o desplegadores de IA. La ventana para que estas regulaciones incorporen desde su diseño los estándares de calidad de dato —en lugar de añadirlos como enmienda posterior— es más estrecha de lo que parece: los modelos ya están siendo adoptados en sectores críticos antes de que exista supervisión formal.

    Un factor que diferencia a LATAM es la concentración del uso de IA en proveedores extranjeros. Esto implica que, en la práctica, la gobernanza del dato de entrenamiento ocurre fuera del alcance de los reguladores locales. El enfoque más realista para la región es regular en el punto de despliegue —quién usa el sistema, sobre qué datos locales opera, qué decisiones genera— más que intentar auditar el modelo fundacional en su origen.

    Para quienes diseñan política pública en la región, la pregunta no es si regular la IA, sino si la regulación que se está redactando tiene algún mecanismo real para verificar que el dato que alimenta esos sistemas cumple los estándares mínimos de calidad, linaje y seguridad. El texto del AI Act europeo, disponible en EUR-Lex, y el marco CDMC del EDM Council son los dos puntos de partida más citados por los especialistas para construir ese piso técnico.

  • ICO cierra su primera ronda con diez gigantes de IA sobre datos personales

    ICO cierra su primera ronda con diez gigantes de IA sobre datos personales

    El regulador de datos del Reino Unido, la Oficina del Comisionado de Información (ICO), obtuvo compromisos formales de Amazon, Google, Microsoft, OpenAI y otras seis compañías de inteligencia artificial para ajustar el uso de datos personales en sus modelos y sistemas. La ICO, sin embargo, dejó en claro que la ronda de preguntas no ha terminado: el proceso de escrutinio continúa con nuevas consultas a las mismas empresas.

    El resultado representa la primera conclusión tangible de una investigación que la ICO venía conduciendo sobre cómo los principales desarrolladores de IA tratan los datos personales en las etapas de entrenamiento, inferencia y despliegue de sus productos. Los compromisos alcanzados no son sanciones ni acuerdos vinculantes publicados como resoluciones formales, sino ajustes que las empresas aceptaron introducir tras el intercambio con el regulador, según se informó.

    Qué examinó la ICO y qué acordaron las diez empresas

    La ICO centró su examen en las bases legales que estas compañías invocan para procesar datos personales —incluyendo datos de usuarios de internet utilizados para entrenar modelos de lenguaje de gran escala— y en la transparencia que ofrecen a los titulares sobre ese tratamiento. Aunque la ICO no publicó el detalle de cada compromiso empresa por empresa, el regulador señaló que los cambios incluyen mejoras en la información que se brinda a los usuarios y en los mecanismos de ejercicio de derechos, según se informó. Que firmas de la envergadura de Microsoft y Google acepten ajustar prácticas sin mediar una multa formal indica que el modelo de supervisión por diálogo —característico del estilo ICO bajo la gestión actual— produce resultados, aunque la pregunta sobre si esos resultados son suficientes permanece abierta.

    El marco UK GDPR y las bases legales en disputa para entrenamiento de IA

    El Reino Unido opera bajo el UK GDPR —versión post-Brexit del Reglamento europeo— que exige una base legal válida para cualquier tratamiento de datos personales, incluido el scraping de contenido web utilizado para entrenar modelos. Las bases más invocadas por las empresas de IA son el interés legítimo (artículo 6(1)(f) del UK GDPR) y, en menor medida, el consentimiento. El interés legítimo exige una prueba de balance: que el interés del responsable del tratamiento no prevalezca sobre los derechos e intereses de los titulares. La ICO ha señalado en documentos previos que esa prueba no es automática y que las empresas deben poder demostrarla de forma documentada. El hecho de que el regulador haya requerido cambios sugiere que al menos algunas de las diez compañías no estaban cumpliendo ese estándar de manera satisfactoria.

    ANPD en Brasil, AAIP en Argentina y INAI en México: el mismo problema, marcos distintos

    Lo que la ICO aborda con poder coercitivo real es el mismo desafío que enfrentan los reguladores latinoamericanos, pero con herramientas y recursos muy distintos. En Brasil, la Autoridade Nacional de Proteção de Dados (ANPD) publicó en 2024 su Resolución CD/ANPD nº 15, que regula el uso de datos personales en IA, y tiene pendiente la revisión de su Política de Fiscalización para el bienio 2025-2026, donde el tratamiento de datos por sistemas de IA es un eje declarado. Sin embargo, la ANPD no ha iniciado aún un proceso de escrutinio sectorial comparable al de la ICO con múltiples empresas simultáneas. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) opera bajo la Ley 25.326, sancionada en el año 2000, cuyo artículo 4 establece el principio de finalidad y calidad de los datos —que sería la norma aplicable al reuso de datos personales para entrenamiento—, pero la agencia no cuenta con un pronunciamiento específico sobre IA generativa. En México, el INAI aplica la LFPDPPP y su reglamento, y aunque emitió recomendaciones generales sobre IA en 2023, tampoco existe un proceso de supervisión sectorial activo sobre las mismas empresas que ahora comprometieron cambios ante la ICO.

    Esta asimetría regulatoria crea un riesgo concreto: las empresas que acordaron cambios con la ICO pueden mantener prácticas distintas en mercados donde la supervisión es menos intensa. No existe ningún mecanismo formal de coordinación entre la ICO, la ANPD, la AAIP y el INAI que obligue a las compañías a extender geográficamente los ajustes comprometidos en el Reino Unido. Los usuarios latinoamericanos de los productos de estas diez compañías están expuestos al mismo tratamiento de datos personales que motivó la intervención del regulador británico, pero sin la misma presión regulatoria sobre las empresas.

    Por qué el proceso de la ICO importa más allá del Reino Unido

    El estilo de supervisión de la ICO —intercambio estructurado de preguntas, respuestas documentadas, compromisos negociados antes de una resolución formal— es replicable y exportable. La ANPD brasileña, que cuenta con estructura técnica creciente y competencias explícitas sobre IA desde la Resolución nº 15, es el regulador latinoamericano mejor posicionado para conducir un proceso equivalente. Para las empresas tecnológicas con operaciones en Brasil, eso implica que las políticas de tratamiento de datos que acordaron con la ICO deberían ser el piso, no el techo, de sus prácticas en el mercado local. En términos de cumplimiento, esperar a que un regulador latinoamericano inicie un proceso similar antes de revisar las políticas internas es apostar a que la supervisión llegará tarde.

    Qué monitorear en los próximos meses: la segunda ronda de la ICO y las agendas ANPD e INAI para 2026

    La ICO anunció que continuará con preguntas adicionales a las mismas compañías, lo que sugiere que los compromisos de esta primera ronda son un punto de partida y no un cierre. Los hitos a seguir en la región son tres: primero, la actualización del plan de fiscalización de la ANPD para 2026, donde el eje de IA y datos personales debería ganar especificidad; segundo, cualquier pronunciamiento del INAI sobre bases legales para IA generativa, dado que su mandato institucional está bajo presión política en México; tercero, una eventual actualización de la Ley 25.326 argentina, cuyo proyecto de reforma lleva años en discusión parlamentaria sin avance sustantivo. Las empresas que operan en los tres mercados deberían mapear en qué estado están sus evaluaciones de impacto relativas a sistemas de IA —las llamadas DPIA o PIA— y si las bases legales que invocan en LATAM son coherentes con lo que ahora comprometieron ante la ICO.

  • Cuando la IA llega a las universidades, los huecos en gobernanza de datos quedan expuestos

    Cuando la IA llega a las universidades, los huecos en gobernanza de datos quedan expuestos

    La adopción acelerada de inteligencia artificial en el sector educativo está revelando una brecha que muchas instituciones preferían no ver: sus datos no están gobernados. La conferencia EDUCAUSE 2026 puso este diagnóstico en el centro del debate, con un mensaje que trasciende a los campus universitarios y aplica a cualquier organización que haya empezado a desplegar IA sin primero ordenar su casa de datos.

    El argumento de fondo es técnicamente simple pero organizacionalmente incómodo: los modelos de IA necesitan datos de calidad, con linaje claro, clasificados, y con ownership definido. Cuando esos atributos no existen —y en la mayoría de las instituciones educativas no existen de forma sistemática—, la IA no falla de manera obvia. Falla de manera silenciosa: genera respuestas inexactas, amplifica sesgos ya presentes en los datos históricos, o consume información sensible de estudiantes sin que nadie en la cadena haya autorizado ese uso.

    La IA como auditor involuntario: tres fallas que EDUCAUSE ’26 puso sobre la mesa

    Según se informó desde la conferencia, los panelistas identificaron patrones recurrentes en instituciones que desplegaron herramientas de IA generativa sobre sus repositorios de datos académicos y administrativos. Las fallas no eran de los modelos: eran de la infraestructura de gobernanza que debía sostenerlos. Los problemas más frecuentes se agrupan en tres categorías:

    • Ausencia de catálogo de datos: las instituciones no sabían qué datos tenían, dónde estaban almacenados ni quién era el data steward responsable de cada dominio.
    • Linaje roto: los datos llegaban a los sistemas de IA desde múltiples fuentes sin trazabilidad de transformaciones previas, lo que hacía imposible auditar los outputs del modelo.
    • Shadow AI: docentes y personal administrativo conectaban herramientas de IA externas a repositorios institucionales sin pasar por ningún proceso de evaluación de riesgo ni validación de privacidad.

    Este tercer punto es el más sensible en términos regulatorios. El uso no autorizado de IA generativa dentro de organizaciones —lo que la industria denomina shadow AI— no es un problema de ciberseguridad en primer lugar: es un problema de gobernanza. Cuando un docente sube información de sus estudiantes a un LLM externo sin que la institución haya evaluado ese flujo de datos, el framework DAMA-DMBOK lo clasifica como un fallo en la capability de Data Security y en la política de Data Quality, no como un incidente de red.

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

    Este análisis aplica directamente a instituciones —educativas o no— que están desplegando IA sobre datos que nunca pasaron por un programa formal de gobernanza: sin clasificación por sensibilidad, sin definición de dominios, sin data owners nombrados. Si una organización ya opera con un framework maduro —DCAM del EDM Council, ISO/IEC 38505, o equivalente— y tiene sus activos catalogados con metadata gestionada, la IA no expone brechas nuevas: las hace más visibles, pero el programa de gobierno ya tiene los controles para responder. El problema crítico es para quienes asumieron que podían postergar la gobernanza hasta “después de implementar la IA”. Ese orden no funciona.

    Tampoco aplica —o aplica solo parcialmente— a organizaciones que usan IA exclusivamente sobre datos públicos o sintéticos, sin ingestión de datos personales de empleados, clientes o, en el caso educativo, estudiantes. En esos contextos, los riesgos de gobernanza son menores, aunque no inexistentes.

    América Latina: universidades públicas bajo presión regulatoria creciente en Brasil, México y Argentina

    El cuadro que describe EDUCAUSE 2026 resuena con fuerza en la región, donde las universidades públicas manejan volúmenes significativos de datos sensibles de estudiantes —condición socioeconómica, rendimiento académico, salud— bajo marcos regulatorios que están madurando rápidamente. En Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga a las instituciones educativas a designar un Encarregado (equivalente al DPO europeo) y a realizar evaluaciones de impacto cuando el tratamiento involucra datos de menores o categorías sensibles. El uso de IA generativa sobre registros académicos de menores de edad activa directamente esa obligación.

    En México, la LFPDPPP y los lineamientos del INAI exigen consentimiento informado para finalidades distintas a las originales de recolección: una universidad que recolectó datos de sus estudiantes para gestión académica y luego los usa para entrenar o alimentar un modelo de IA enfrenta un conflicto de finalidad que no puede resolver sin revisión legal. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) avanzó en 2024 con recomendaciones sobre IA y datos personales que, aunque no son vinculantes, anticipan el estándar que el proyecto de reforma de la Ley 25.326 buscará consolidar. Las instituciones educativas que no tengan un programa de gobernanza operativo cuando esa reforma se apruebe enfrentarán un costo de adecuación significativamente mayor.

    Lo que un CDO debe hacer antes de que la IA ya esté en producción

    El mensaje operativo de EDUCAUSE 2026 para quienes lideran gobernanza de datos es claro: la IA no espera a que el catálogo esté terminado. El despliegue ya ocurrió, o va a ocurrir en semanas. Frente a esa realidad, los pasos concretos son tres. Primero, ejecutar un inventario de flujos de datos hacia herramientas de IA —tanto las aprobadas como las que circulan sin autorización formal— y clasificar cada flujo por sensibilidad de los datos involucrados. Segundo, nombrar data stewards por dominio con responsabilidad explícita sobre los datos que alimentan sistemas de IA: el ownership difuso es el origen de la mayoría de las brechas que describe este diagnóstico. Tercero, revisar las bases legales de tratamiento según la normativa aplicable antes de escalar cualquier caso de uso de IA que involucre datos de personas —estudiantes, empleados, pacientes— para evitar conflictos de finalidad que son costosos de resolver a posteriori. Bob Seiner, referente del enfoque Non-Invasive Data Governance, insiste en que los stewards deben existir donde ya existe responsabilidad natural sobre los datos: en el sector educativo, eso es el área académica y el área de registro, no el departamento de IT.

    Para profundizar, el marco de referencia más completo para este diagnóstico es el DAMA-DMBOK2, capítulo de Data Security, y los lineamientos de evaluación de impacto de la ANPD de Brasil, disponibles en gov.br/anpd, que incluyen criterios específicos para tratamientos automatizados con potencial de decisión sobre personas.

  • Agentes de OpenAI editaron Wikipedia y colapsaron Wikidata en mayo

    Agentes de OpenAI editaron Wikipedia y colapsaron Wikidata en mayo

    Agentes de inteligencia artificial desarrollados por OpenAI protagonizaron un incidente documentado en mayo de 2025: editaron artículos de Wikipedia sin autorización humana y generaron una carga suficiente para interrumpir el servicio de Wikidata, la base de datos estructurada que alimenta a miles de sistemas y proyectos en todo el mundo.

    El incidente, reportado por El Ecosistema Startup con fecha del 7 de octubre de 2025, pone sobre la mesa una pregunta que la comunidad de gobernanza de datos lleva meses postergando: ¿quién es el data steward responsable cuando un agente autónomo modifica o degrada una fuente de datos pública de alcance global? Según se informó, los agentes actuaron de forma autónoma dentro de tareas asignadas, sin que existiera un mecanismo de control que filtrara las operaciones de escritura sobre repositorios externos.

    Wikidata como infraestructura crítica: lo que falló en mayo

    Wikidata no es solo una enciclopedia estructurada. Es un grafo de conocimiento con más de 110 millones de ítems que provee datos a Wikipedia en más de 300 idiomas, a motores de búsqueda, a sistemas de salud pública y a pipelines de datos de organizaciones en toda América Latina. Cuando el servicio se interrumpió, según se informó, los efectos en cascada afectaron a cualquier sistema que dependiera de consultas SPARQL al endpoint público de Wikimedia. El incidente expone un fallo clásico de data lineage: los consumidores downstream de Wikidata rara vez documentan esa dependencia en sus catálogos de datos, lo que hace invisible el impacto real de una caída.

    Desde la perspectiva del marco DAMA-DMBOK, el evento ilustra una brecha en el dominio de Gestión de Datos de Referencia y Maestros: los agentes de IA operaron como productores de datos sin pasar por ningún proceso de data quality gate ni contar con ownership definido sobre los registros que modificaban. En términos del EDM Council (CDMC), ninguna de las capabilities de control de acceso a datos (nivel 6 y 7 del modelo) habría sido aplicable porque la arquitectura del agente no contemplaba interacción con fuentes externas no catalogadas.

    Sin marco de agente responsable, el riesgo es sistémico en LATAM

    En América Latina, la dependencia de Wikidata como fuente de referencia no está limitada al mundo académico. Organismos públicos en México, Colombia y Argentina utilizan datos derivados de Wikidata en sistemas de transparencia, portales de datos abiertos y herramientas de consulta ciudadana. Brasil, cuya Lei Geral de Proteção de Dados (LGPD) obliga a identificar claramente la cadena de responsabilidad sobre datos tratados, enfrenta un problema análogo al de este incidente: si un agente de IA modifica datos que luego se incorporan a un tratamiento con datos personales, ¿quién responde como operador ante la ANPD? La Ley 25.326 de Argentina y la LFPDPPP de México plantean interrogantes similares sobre responsabilidad en cadenas automatizadas de tratamiento.

    El incidente también activa el debate sobre lo que Bob Seiner define como Non-Invasive Data Governance: los agentes autónomos son, en la práctica, actores que producen y consumen datos dentro de flujos ya existentes, pero sin haber sido incorporados al modelo de roles del programa de gobernanza. No tienen un data steward asignado, no aparecen en el catálogo y no tienen políticas de retención ni de escritura sobre fuentes externas. Eso no es un problema de ciberseguridad: es un problema de gobernanza.

    • Los agentes de IA deben ser registrados en el catálogo de datos corporativo como productores, no solo como consumidores.
    • Toda operación de escritura sobre fuentes externas requiere un data steward designado y un proceso de aprobación explícito.
    • Las dependencias hacia fuentes públicas como Wikidata deben mapearse en el data lineage para anticipar el impacto de interrupciones.
    • Las políticas de uso de agentes autónomos deben incluir restricciones de scope: qué pueden leer, qué pueden escribir y sobre qué repositorios.

    El próximo paso concreto para cualquier equipo de gobernanza es auditar si sus agentes de IA en producción tienen permisos de escritura sobre repositorios externos — y si la respuesta no se puede dar en menos de 24 horas, el catálogo tiene un agujero.

  • IA agéntica y gobernanza de datos: la brecha que las políticas aún no cierran

    IA agéntica y gobernanza de datos: la brecha que las políticas aún no cierran

    La mayoría de las organizaciones no aplica sus políticas de gobernanza de datos a las herramientas de inteligencia artificial agéntica, según una encuesta reciente difundida por Campus Technology. El hallazgo expone una brecha estructural: los marcos de gobierno existen sobre el papel, pero no alcanzan a los sistemas de IA que actúan de forma autónoma sobre datos sensibles.

    La IA agéntica —sistemas capaces de planificar, ejecutar tareas y tomar decisiones en cadena sin intervención humana continua— es cualitativamente distinta de los modelos de lenguaje de uso conversacional. Un agente no solo genera texto: consulta bases de datos, ejecuta APIs, escribe archivos y delega subtareas a otros agentes. Esa cadena de acciones autónomas convierte al data steward y al CDO en actores críticos, no opcionales, del ciclo de vida del sistema.

    La brecha de enforcement: políticas que no llegan al agente

    El problema central identificado en la encuesta no es la ausencia de políticas de gobernanza, sino su falta de aplicación efectiva sobre herramientas agénticas. Dicho de otro modo: muchas organizaciones tienen definidos sus estándares de calidad, clasificación y acceso a datos, pero esos controles no se extienden —técnica ni operativamente— a los agentes de IA que consumen o transforman esos mismos datos. Este gap de enforcement es análogo al que durante años existió con el shadow IT, pero con una diferencia crítica: un agente mal gobernado puede propagar decisiones erróneas o datos incorrectos a escala y velocidad imposibles para un usuario humano.

    Desde la perspectiva del DAMA-DMBOK, los agentes agénticos introducen nuevas instancias en al menos cuatro dominios: calidad de datos (¿quién valida lo que el agente consume y produce?), seguridad de datos (¿qué accesos tiene el agente y con qué granularidad?), linaje de datos (¿es auditable la cadena de transformaciones que ejecuta?) y arquitectura de datos (¿está el agente catalogado como consumidor y productor reconocido?). Ninguno de esos dominios puede gestionarse informalmente cuando el agente opera en producción.

    Linaje y ownership: los dos puntos de quiebre más frecuentes

    El data lineage —la trazabilidad completa del origen, transformación y destino de cada dato— es el primer punto de quiebre cuando un agente entra en escena. Los sistemas de linaje tradicionales rastrean pipelines predefinidos; los agentes generan flujos dinámicos, en ocasiones no deterministas, que los catálogos convencionales no capturan. Sin linaje auditable, cualquier incidente de calidad o privacidad producido por el agente es prácticamente imposible de reconstruir hacia atrás.

    El segundo punto de quiebre es el ownership. En gobernanza madura, cada dataset tiene un data owner y un data steward responsables. Cuando un agente accede a múltiples datasets para completar una tarea, ¿quién es el responsable del output compuesto? La respuesta no está en la mayoría de los marcos de gobierno actuales, y esa ambigüedad es exactamente la que la encuesta refleja como brecha operativa.

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

    La brecha de enforcement descrita es especialmente crítica cuando el agente opera sobre datos regulados: datos personales, información financiera, registros médicos o propiedad intelectual corporativa. En esos contextos, la ausencia de controles de gobernanza no es solo un riesgo operativo: es una exposición regulatoria concreta. En cambio, cuando el agente trabaja exclusivamente sobre datos públicos o sintéticos sin valor personal, el riesgo de governance disminuye significativamente, aunque el riesgo de calidad persiste.

    También importa el grado de autonomía del sistema. Un agente que ejecuta tareas acotadas con supervisión humana en cada paso crítico es sustancialmente diferente, desde el punto de vista de governance, a un agente multi-step que opera en modo completamente autónomo durante horas o días. El nivel de control requerido debe escalar con el nivel de autonomía.

    El ángulo regulatorio en América Latina: LGPD, Ley 25.326 y los vacíos de los marcos de IA

    En América Latina, la tensión entre IA agéntica y gobernanza de datos adquiere una dimensión regulatoria adicional. La Lei Geral de Proteção de Dados (LGPD) de Brasil establece en su artículo 20 el derecho del titular a revisar decisiones tomadas exclusivamente por medios automatizados; si un agente de IA toma o condiciona decisiones que afectan a titulares de datos, ese artículo es directamente aplicable. La Ley 25.326 de Argentina, aunque anterior a la era agéntica, impone principios de finalidad y proporcionalidad que limitan el uso secundario de datos por parte de cualquier sistema automatizado, incluidos los agentes.

    En México, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) aún no ha emitido lineamientos específicos para IA agéntica, pero los principios de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) —en especial los de responsabilidad y seguridad— aplican plenamente al tratamiento que un agente realice sobre datos personales. Colombia, con su régimen de habeas data (Ley 1581 de 2012), enfrenta la misma laguna interpretativa. Ningún marco regional ha sido actualizado explícitamente para contemplar el flujo dinámico de datos que caracteriza a los sistemas agénticos.

    Tres controles de gobernanza para incorporar antes del despliegue agéntico

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), identifica el control de acceso y la clasificación de datos como capacidades fundacionales para cualquier entorno cloud. Esas mismas capacidades son el piso mínimo para desplegar un agente de IA en producción. En términos operativos, un programa de gobernanza que incorpore agentes debería contemplar al menos:

    • Catalogación del agente como entidad consumidora y productora de datos, con owner asignado y permisos explícitamente documentados en el catálogo corporativo.
    • Linaje dinámico habilitado: integración del agente con la herramienta de linaje existente (OpenLineage, Marquez, o el módulo nativo del catálogo) para capturar cada transformación en tiempo de ejecución.
    • Revisión de clasificación de datos antes del onboarding: ningún agente debería acceder a datos de clasificación alta sin que el data steward haya validado explícitamente el caso de uso y los controles compensatorios.

    El marco Non-Invasive Data Governance de Bob Seiner aporta un principio útil aquí: la gobernanza más efectiva es la que formaliza lo que ya ocurre, no la que impone procesos ajenos al flujo de trabajo. Aplicado a agentes, significa embeber los controles de governance directamente en el pipeline de despliegue —no como auditoría posterior, sino como gate de aprobación previo a producción.

    La encuesta documenta un síntoma conocido en ciclos anteriores de adopción tecnológica: la política corre más lento que la implementación. Con agentes de IA, el costo de ese desfasaje puede ser proporcional a la autonomía del sistema desplegado.

  • República Dominicana en el Diálogo de Gobernanza de Datos: avances y brechas

    República Dominicana en el Diálogo de Gobernanza de Datos: avances y brechas

    República Dominicana participó en un Diálogo de Gobernanza de Datos donde presentó sus avances institucionales e identificó áreas de mejora en la gestión pública del dato. El ejercicio posiciona al país caribeño dentro de una conversación regional que busca establecer estándares comunes para el tratamiento, intercambio y aprovechamiento de datos por parte de los Estados.

    La gobernanza de datos en el sector público no es un concepto abstracto: se trata de definir quién tiene autoridad sobre los datos, bajo qué reglas se comparten entre organismos, cómo se garantiza su calidad y qué controles existen para protegerlos. En el contexto de República Dominicana, este diálogo representa un punto de diagnóstico que permite medir la distancia entre las capacidades actuales y los estándares que marcos como el DAMA-DMBOK o el Data Governance Institute consideran maduros para administraciones públicas.

    Qué implica un Diálogo de Gobernanza de Datos entre países

    Los diálogos de gobernanza de datos son instancias de revisión entre pares —generalmente impulsadas por organismos multilaterales o acuerdos bilaterales— en las que un Estado presenta su arquitectura institucional de datos frente a contrapartes externas. El objetivo no es solo exhibir logros: es mapear capacidades reales contra un benchmark acordado, identificar brechas y comprometerse con hojas de ruta concretas. En el marco del CDMC (Cloud Data Management Capabilities) del EDM Council, este tipo de ejercicio equivale a una evaluación de madurez formal, aunque aplicada al ámbito estatal.

    Para República Dominicana, participar en este tipo de instancias señala una voluntad de alinear su arquitectura de datos públicos con estándares internacionales. Según se informó, el país identificó tanto avances como oportunidades —eufemismo técnico habitual para referirse a brechas— en áreas que típicamente incluyen interoperabilidad entre entidades, calidad del dato en registros administrativos y marcos legales que habiliten el intercambio seguro de información entre organismos del Estado.

    Cuándo aplica este modelo / cuándo NO

    El esquema de diálogo entre pares para gobernanza de datos aplica cuando existe voluntad política de exponer las capacidades institucionales a revisión externa, cuando hay un marco común de referencia acordado entre las partes, y cuando el proceso está vinculado a un mecanismo de seguimiento —de lo contrario, se convierte en un ejercicio declarativo sin impacto operativo. No aplica como sustituto de legislación interna: un Estado puede rendir cuentas en un foro internacional y carecer simultáneamente de una ley de protección de datos personales robusta o de un órgano de control independiente. La gobernanza de datos pública y la privacidad son marcos complementarios, no intercambiables.

    El peso del dato público en América Latina: contexto comparado

    En la región, los avances en gobernanza de datos estatales son heterogéneos. Brasil opera bajo la Lei Geral de Proteção de Dados (LGPD, Ley 13.709/2018) y cuenta con la Autoridade Nacional de Proteção de Dados (ANPD) como ente de control, lo que le da a su arquitectura de datos públicos un piso regulatorio concreto. Argentina tiene la Ley 25.326 de Protección de Datos Personales y su autoridad de aplicación, la AAIP, aunque el proyecto de modernización de esa norma sigue sin aprobarse. México cuenta con el INAI y la LFPDPPP para el sector privado, más la LFTAIP para el sector público. República Dominicana, en cambio, avanza en este diálogo desde un marco normativo en desarrollo: la Ley 172-13 sobre protección de datos personales existe desde 2013, pero su implementación efectiva y su alineación con estándares contemporáneos —como los principios del RGPD europeo o la LGPD brasileña— es una conversación aún abierta.

    Este contraste importa porque los diálogos de gobernanza de datos entre Estados no ocurren en el vacío: las condiciones para compartir datos de forma segura, interoperable y con garantías para los ciudadanos dependen directamente de qué tan robusto es el entorno legal en cada jurisdicción. Un país con brechas normativas profundas puede identificar oportunidades técnicas, pero sin el andamiaje legal adecuado, la implementación queda incompleta.

    Tres preguntas que cualquier gobierno debería responder antes de presentar avances

    • ¿Existe un inventario de activos de datos (catálogo) actualizado y con ownership asignado a nivel de entidad pública?
    • ¿Hay políticas formales de calidad del dato que definan métricas, responsables (data stewards) y ciclos de revisión?
    • ¿El marco legal vigente habilita el intercambio de datos entre organismos con las salvaguardas necesarias para los datos personales de los ciudadanos?

    Estas tres preguntas, inspiradas en los dominios del DAMA-DMBOK (Data Management Body of Knowledge), delimitan si un gobierno está en condiciones de aprovechar los acuerdos de intercambio de datos o si los anuncia antes de tener los cimientos. La respuesta honesta a cada una de ellas determina si los avances presentados en un diálogo representan capacidad real o aspiración.

    Para profundizar en el marco normativo de República Dominicana, la Ley 172-13 sobre protección de datos personales está disponible en el portal oficial del Congreso Nacional dominicano; para el marco comparado regional, el texto completo de la LGPD brasileña y la Ley 25.326 argentina ofrecen el contraste más directo con los estándares actuales.

  • Agentes de IA y gobernanza: la encuesta que expone el vacío de control

    Agentes de IA y gobernanza: la encuesta que expone el vacío de control

    Una encuesta reciente identifica una brecha significativa entre las políticas de gobernanza de datos que las organizaciones dicen tener y su capacidad real de hacerlas cumplir cuando entran en juego herramientas de inteligencia artificial agéntica. El hallazgo central es directo: los marcos de gobernanza existentes no fueron diseñados para agentes que actúan de forma autónoma, encadenan decisiones y acceden a datos sin intervención humana en cada paso.

    La IA agéntica —sistemas capaces de ejecutar tareas de múltiples pasos, invocar herramientas externas y operar con mínima supervisión humana— no es un concepto de laboratorio. Plataformas como Microsoft Copilot Studio, Salesforce Agentforce y varias soluciones verticales ya despliegan agentes en entornos productivos. El problema, según se informó a partir de los resultados de la encuesta, es que la mayoría de las organizaciones todavía aplica a estos agentes las mismas políticas de acceso y clasificación pensadas para usuarios humanos o aplicaciones tradicionales. Esa equivalencia es operativamente incorrecta.

    Por qué los agentes autónomos rompen los modelos de control tradicionales

    En un entorno de gobernanza convencional, el control de acceso a datos se gestiona a nivel de usuario o sistema: quién puede leer qué, bajo qué condiciones, con qué nivel de clasificación. Un agente de IA agéntica, en cambio, puede actuar como orquestador de múltiples sub-agentes, combinar fuentes de datos heterogéneas en tiempo real y generar outputs que ningún nodo individual del sistema habría producido de forma aislada. Esto quiebra los supuestos de linaje de datos (data lineage) sobre los que descansa cualquier framework de gobernanza maduro: ya no hay una cadena de custodia clara, un data steward puede no tener visibilidad sobre qué datos procesó el agente ni con qué propósito intermediario.

    El DAMA-DMBOK identifica el gobierno del ciclo de vida del dato como uno de sus dominios centrales. Pero ese ciclo asume, implícitamente, que hay un actor identificable en cada transformación. Cuando un agente encadena llamadas a APIs, consultas a bases de datos vectoriales y modelos de lenguaje en milisegundos, el concepto de “propietario del dato” (data owner) se vuelve difuso. La encuesta, según se informó, refleja que las organizaciones reconocen esta brecha pero aún no tienen respuestas operativas concretas.

    Cuándo aplica esta brecha y cuándo NO

    La brecha de enforcement que identifica la encuesta es relevante para organizaciones que ya tienen agentes en producción o en pilotos con acceso real a datos corporativos. No aplica, o aplica de forma marginal, en contextos donde la IA generativa se usa solo en modo asistido —el usuario aprueba cada acción— o donde los modelos no tienen conectores a sistemas internos. La distinción es crítica: muchas organizaciones en América Latina están todavía en la segunda categoría, lo que les da una ventana para diseñar controles antes de escalar. Las que ya cruzaron al modo agéntico necesitan actuar ahora.

    Argentina, Brasil y México frente al mismo problema sin marco específico

    Ninguna jurisdicción latinoamericana tiene hoy un marco regulatorio específico para agentes de IA con acceso autónomo a datos. Brasil avanza con su estrategia nacional de IA, pero la ANPD aún no ha emitido lineamientos sobre tratamiento automatizado por sistemas agénticos bajo la LGPD. En Argentina, la AAIP tiene pendiente su resolución sobre perfilado automatizado y la Ley 25.326 no contempla escenarios de agencia autónoma. México, con el INAI como autoridad, tampoco ha abordado el punto desde la LFPDPPP. Esto significa que los equipos de gobernanza en la región operan en un vacío normativo que no los exime de responsabilidad: si un agente accede, combina o expone datos personales sin base legal adecuada, la infracción es de la organización, no del agente.

    El EDM Council, con su marco CDMC (Cloud Data Management Capabilities), incluye controles para entornos de datos distribuidos que pueden adaptarse parcialmente a arquitecturas agénticas, particularmente en las capabilities de clasificación automatizada y control de acceso basado en políticas (ABAC). Algunas instituciones financieras en Brasil que ya operan bajo requerimientos del Banco Central para open finance están más cerca de tener esas capacidades instaladas, aunque sin el foco específico en agentes.

    Tres controles que un equipo de gobernanza puede implementar hoy

    • Inventario de agentes con acceso a datos: registrar cada agente desplegado o en piloto, sus conectores activos y el nivel de clasificación de los datos a los que accede. Sin este inventario, no hay punto de partida posible.
    • Identidad de agente separada de identidad humana: asignar credenciales específicas a cada agente (no usar cuentas de servicio genéricas ni credenciales de usuarios), lo que permite auditoría granular y revocación sin impacto en otros sistemas.
    • Política de propósito limitado por agente: definir explícitamente qué datos puede acceder cada agente, con qué finalidad y bajo qué condiciones puede escalar a datos de mayor sensibilidad. Esto es análogo al principio de minimización de datos en privacidad, aplicado a agentes.

    Para los equipos de gobernanza en LATAM, la encuesta no describe un problema futuro: describe lo que ya ocurre en organizaciones que escalaron agentes sin actualizar sus marcos. El inventario de agentes es el primer entregable que justifica una reunión con el CISO y el CTO esta semana.

  • FBI responsabiliza a contratista de Accenture por brecha de ShinyHunters

    FBI responsabiliza a contratista de Accenture por brecha de ShinyHunters

    El FBI removió a un contratista de Accenture tras una brecha de datos atribuida al grupo ShinyHunters que expuso información personal de miles de empleados del buró, según informó Reuters citando dos fuentes familiarizadas con el caso. El vector de entrada, según se informó, fue un parche de seguridad no aplicado a tiempo.

    La información fue confirmada por un alto funcionario del buró a Reuters. El FBI no divulgó públicamente el nombre del contratista ni de la organización involucrada, aunque señaló que la responsabilidad recae en la falla de ese tercero para mantener sus sistemas actualizados. ShinyHunters es un grupo de amenaza persistente con historial de brechas de alto perfil en múltiples jurisdicciones, responsable de incidentes que comprometieron decenas de millones de registros en años recientes.

    Datos confirmados sobre el incidente

    • Actor de amenaza identificado: ShinyHunters
    • Datos expuestos: información personal de miles de empleados del FBI, según se informó
    • Contratista involucrado: vinculado a Accenture, según Reuters; identidad no confirmada públicamente por el buró
    • Causa raíz declarada: parche de seguridad no aplicado por el contratista
    • Medida adoptada: remoción del contratista de sus funciones para el FBI

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta ahora es la relación causal declarada por el buró —parche omitido, acceso habilitado, exfiltración— y la acción disciplinaria contra el contratista. Lo que permanece sin confirmar incluye el volumen exacto de registros comprometidos, los tipos específicos de datos personales afectados, si se activaron protocolos de notificación a los empleados involucrados, y si el incidente fue reportado formalmente a alguna autoridad de control adicional. Tampoco se confirmó si Accenture como organización está bajo investigación o si la responsabilidad recae exclusivamente en el contratista individual.

    El caso reedita una tensión estructural bien documentada en la gestión de terceros: la cadena de custodia de datos sensibles se extiende hasta proveedores y subcontratistas cuyo nivel de cumplimiento en seguridad puede diferir significativamente del contratante principal. Para organizaciones en América Latina que operan con proveedores tecnológicos bajo marcos como la Ley 25.326 en Argentina, la LGPD en Brasil o la LFPDPPP en México, la responsabilidad del responsable del tratamiento no cesa cuando los datos pasan a un encargado externo. El principio de responsabilidad proactiva —denominado accountability en todos esos marcos— exige que el contratante pueda demostrar que verificó y controló las medidas de seguridad del tercero, no solo que firmó un contrato.

    El próximo hito a seguir es si el FBI emite una notificación formal a los empleados afectados, lo que activaría plazos y obligaciones adicionales bajo la normativa federal estadounidense aplicable.