Etiqueta: Ai Privacy

  • 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.

  • 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.

  • Marca de agua de OpenAI para texto generado por IA: qué tan sólida es

    Marca de agua de OpenAI para texto generado por IA: qué tan sólida es

    OpenAI desplegó un sistema de marca de agua (watermarking) para texto generado por modelos de lenguaje, pero la implementación levantó señales de alerta entre expertos en regulación de IA: la solución está lejos de ser inviolable y plantea interrogantes sobre su valor real como herramienta de cumplimiento normativo.

    El watermarking de texto consiste en incrustar señales estadísticas en las salidas de un modelo de lenguaje grande (LLM), de modo que un detector pueda identificar con cierta probabilidad si un fragmento de texto fue generado por IA. A diferencia del watermarking en imágenes o audio —donde se modifica un archivo binario—, en texto el proceso opera sobre la distribución de probabilidades de los tokens: el modelo ajusta sutilmente qué palabras elige, creando un patrón no visible para el ojo humano pero detectable algorítmicamente. OpenAI, según se informó, integró una variante de este mecanismo en sus APIs de generación de texto.

    Por qué la industria lo califica de insuficiente

    El problema central no es técnico, es de robustez. Los sistemas de watermarking de texto actuales son vulnerables a ataques simples: reescribir el fragmento con otra herramienta de IA, traducirlo y retro-traducirlo, o incluso hacer pequeñas ediciones manuales puede borrar la señal sin afectar el contenido del mensaje. Investigadores de universidades como Maryland y Stanford han demostrado en los últimos dos años que ningún esquema de watermarking textual existente es a la vez indetectable para el usuario, robusto frente a manipulaciones y verificable sin acceso al modelo original. Es lo que el campo llama el trilema del watermarking. Que una empresa del tamaño de OpenAI lance una implementación sin resolver ese trilema —y sin publicar el diseño técnico completo para escrutinio externo— genera desconfianza justificada en la comunidad regulatoria.

    Cuándo aplica y cuándo NO como herramienta de cumplimiento

    El watermarking de texto tiene utilidad real en escenarios acotados: detectar abuso masivo y automatizado de las APIs del propio proveedor (fraude a escala industrial, spam de contenido), hacer auditorías internas donde el sistema de detección y el de generación pertenecen al mismo operador, o generar evidencia forense en litigios cuando el atacante no tuvo incentivo ni capacidad para manipular el texto. Lo que no puede hacer —y aquí está el malentendido regulatorio más peligroso— es funcionar como garantía de cumplimiento en entornos adversariales: si un actor malicioso sabe que el texto está marcado, puede borrarlo. Tampoco sirve como control de calidad para identificar texto de IA en contextos de alto riesgo como evaluaciones académicas, procesos judiciales o información médica, donde el costo de un falso negativo es inaceptable.

    El AI Act europeo y la obligación de revelación que cambia el juego

    El Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, Reglamento UE 2024/1689) establece en su artículo 50 una obligación explícita para los proveedores de sistemas de IA generativa: garantizar que los outputs generados artificialmente sean marcables de forma técnicamente robusta y detectable por herramientas automatizadas. La formulación europea es más exigente que una implementación voluntaria y parcial —incluye texto, imágenes, audio y video— y aplica a modelos de propósito general con impacto sistémico. El plazo de aplicación escalonado llega a su fase plena en agosto de 2026 para los modelos de mayor riesgo. El anuncio de OpenAI podría leerse como un movimiento anticipatorio para alinearse con esa exigencia, aunque los detalles técnicos disponibles no permiten confirmar que la implementación cumple el estándar europeo de “detección técnicamente robusta”.

    América Latina: sin obligación de marca de agua, con exposición igual o mayor

    Ningún país de América Latina tiene hoy una norma equivalente al artículo 50 del AI Act que obligue a los proveedores de LLMs a implementar watermarking. Brasil avanza con el Projeto de Lei 2338/2023 de regulación de IA, que en su texto actual establece principios de transparencia algorítmica pero no prescribe mecanismos técnicos específicos como el marcado de salidas. México, Argentina y Colombia tampoco cuentan con regulación sectorial que lo exija. Sin embargo, la exposición al problema es concreta: contenido generado por IA circula masivamente en campañas electorales, plataformas de desinformación y procesos académicos en toda la región, sin que existan controles técnicos mínimos ni autoridades con capacidad técnica para auditar proveedores extranjeros. La brecha no es regulatoria solamente —es también de capacidad institucional para exigir cumplimiento a empresas que operan desde fuera de la jurisdicción.

    Para los equipos jurídicos y de compliance que evalúan riesgos asociados al uso de IA generativa en sus organizaciones, el punto operativo más inmediato es este: no traten el watermarking como un control de riesgo suficiente en ningún proceso donde la autenticidad del texto tenga consecuencias legales o reputacionales. Si la política interna de uso de IA requiere trazabilidad del origen de los contenidos, el watermarking de proveedor puede ser una capa adicional, pero no la única. Los metadatos de auditoría, los logs de uso de API y los procesos de revisión humana siguen siendo el núcleo de cualquier framework de gobernanza de IA que resista un escrutinio externo.

    La marca de agua que se borra con un copia-pega y un segundo modelo no es cumplimiento normativo: es su apariencia.

  • Benchmarking de privacidad en IA: qué medir cuando los modelos ya deciden

    Benchmarking de privacidad en IA: qué medir cuando los modelos ya deciden

    Los sistemas de inteligencia artificial de frontera procesan volúmenes crecientes de datos personales, pero no existe aún un estándar consolidado para medir cuán bien —o cuán mal— los gestionan. El Future of Privacy Forum (FPF) publicó un análisis que plantea la ausencia de benchmarks de privacidad como un problema estructural del desarrollo de IA, no como una deuda técnica menor.

    Un benchmark, en el contexto de los modelos de IA, es un conjunto estandarizado de pruebas que permite comparar el desempeño de distintos sistemas bajo condiciones equivalentes. Existen benchmarks consolidados para capacidades como razonamiento matemático, comprensión lectora o generación de código. Para privacidad, en cambio, la práctica es fragmentaria: cada laboratorio evalúa lo que considera relevante, con criterios propios, lo que impide comparaciones significativas entre modelos o versiones.

    Por qué la falta de benchmarks de privacidad no es un detalle técnico

    Un modelo de lenguaje de gran escala puede memorizar fragmentos de sus datos de entrenamiento y reproducirlos ante consultas específicas. Puede inferir atributos sensibles —condición de salud, orientación sexual, situación financiera— a partir de información aparentemente inocua. Puede ser utilizado como vector para extraer datos personales de terceros que interactúan con el sistema. Ninguno de estos riesgos es hipotético: son comportamientos documentados en la literatura académica. El problema, según el FPF, es que sin métricas estandarizadas no hay forma de saber si un modelo mejora, empeora o simplemente desplaza esos riesgos de una capa a otra entre versión y versión.

    La ausencia de benchmarks también debilita la rendición de cuentas regulatoria. Cuando una autoridad de control pregunta si un sistema de IA cumple con el principio de minimización de datos o con la obligación de no retener información personal más allá de lo necesario, la respuesta hoy es mayormente narrativa, no cuantificable. Eso convierte la evaluación de conformidad en un ejercicio retórico.

    Qué debería medir un benchmark de privacidad en IA: tres dimensiones críticas

    El análisis del FPF sugiere que cualquier framework de evaluación creíble debería operar al menos en tres planos distintos:

    • Riesgo de memorización y extracción: capacidad del modelo para reproducir datos personales presentes en el corpus de entrenamiento ante prompts diseñados para elicitarlos.
    • Inferencia de atributos sensibles: hasta qué punto el sistema puede derivar información protegida —categorías especiales de datos, en términos del RGPD o de legislaciones latinoamericanas equivalentes— a partir de inputs no sensibles.
    • Comportamiento en despliegue: cómo el modelo gestiona datos personales en tiempo real durante interacciones con usuarios, incluyendo si retiene, reutiliza o transmite esa información a capas del sistema no declaradas.

    Estas dimensiones no son independientes: un modelo puede rendir bien en memorización y mal en inferencia, o viceversa. Por eso el FPF argumenta que los benchmarks deben ser multidimensionales y no colapsar la privacidad en un único puntaje.

    Cuándo aplica este enfoque y cuándo no

    El argumento del FPF aplica con mayor fuerza a los llamados modelos de frontera: sistemas de gran escala, de uso general, entrenados con datos masivos y desplegados en contextos donde procesan información de millones de personas. Para modelos más acotados —entrenados con datos propios, sin acceso a internet, en entornos cerrados— el riesgo de memorización y extracción es estructuralmente menor, aunque no desaparece. El marco tampoco resuelve por sí solo el problema de la privacidad diferencial en entrenamiento, que requiere decisiones de diseño previas al benchmark, no evaluables a posteriori.

    El vacío regulatorio en América Latina se amplifica sin métricas

    Brasil, Argentina, México, Colombia y Chile cuentan con legislaciones de protección de datos personales que imponen obligaciones sobre el tratamiento automatizado de información. La Lei Geral de Proteção de Dados brasileña (LGPD) reconoce el derecho a revisión de decisiones automatizadas y exige transparencia sobre la lógica aplicada. La Ley 25.326 argentina —cuya reforma lleva años pendiente en el Congreso— y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México también establecen principios de finalidad y proporcionalidad que aplican al tratamiento por sistemas de IA. El problema es que ninguna de estas normas define cómo demostrar el cumplimiento cuando el agente que trata los datos es un modelo de lenguaje. Sin benchmarks reconocidos, las empresas que despliegan IA en la región pueden afirmar conformidad sin posibilidad real de verificación independiente.

    La Autoridad Nacional de Protección de Datos de Brasil (ANPD) y la Agencia de Acceso a la Información Pública de Argentina (AAIP) han iniciado consultas sobre IA, pero ninguna ha emitido aún guías técnicas sobre evaluación de privacidad en modelos de lenguaje. En ese vacío, la iniciativa de estandarización que propone el FPF podría funcionar como referencia para reguladores que necesitan criterios operativos antes de que los primeros casos lleguen a sus despachos.

    Lo que hace medible la gobernanza también la hace exigible

    El título del documento del FPF —”lo que se mide se gobierna”— no es un slogan vacío. En la historia de la regulación tecnológica, los estándares técnicos han precedido o acompañado a las normas jurídicas con mayor frecuencia que lo contrario. Los requisitos de auditoría del AI Act europeo, por ejemplo, asumen implícitamente la existencia de metodologías de evaluación comparables. Sin esa infraestructura de medición, la regulación opera sobre declaraciones de intención, no sobre evidencia.

    El documento completo del Future of Privacy Forum está disponible en fpf.org y constituye una referencia de trabajo para equipos legales, de producto y de gobernanza que ya están evaluando —o deberían estar evaluando— el comportamiento de los modelos que despliegan.

  • PwC: las brechas en gobernanza de datos frenan la seguridad en IA

    PwC: las brechas en gobernanza de datos frenan la seguridad en IA

    Una encuesta global de PwC revela que las organizaciones avanzan en adopción de inteligencia artificial mientras sus fundamentos de gobernanza de datos permanecen sin resolver. La brecha no es técnica: es de ownership, clasificación y control del dato antes de que llegue a los modelos.

    El hallazgo central del relevamiento de PwC es que la seguridad en sistemas de IA no puede desacoplarse de la madurez en gobernanza de datos corporativa. Las compañías que despliegan modelos sobre datos sin clasificar, sin linaje documentado y sin un data steward identificable están, en la práctica, introduciendo riesgo sistémico en cada inferencia. No es un problema de firewall ni de modelo: es un problema de quién es responsable del dato que alimenta ese modelo.

    Qué mide PwC y qué encontró en las organizaciones relevadas

    Según se informó a partir del relevamiento, una proporción significativa de empresas encuestadas reconoce no tener controles formales sobre los datos que utilizan para entrenar o alimentar sus sistemas de IA. Esto incluye ausencia de catálogos de datos activos, falta de políticas de retención aplicadas a datasets de entrenamiento, y procesos de data quality que no escalan al ritmo de los proyectos de IA. El reporte identifica tres brechas recurrentes: ausencia de roles de gobernanza formalizados para IA, políticas de acceso a datos inconsistentes entre áreas de negocio, y ausencia de trazabilidad (data lineage) desde la fuente hasta el output del modelo.

    Por qué el data lineage es el punto de quiebre en entornos de IA

    El data lineage —la documentación de cómo un dato es capturado, transformado y consumido a lo largo de su ciclo de vida— no es un requisito nuevo. El DAMA-DMBOK lo ubica como una capability central dentro del área de conocimiento de Data Architecture. Lo que cambia con la IA generativa es la velocidad a la que un dato mal catalogado o sin owner asignado puede propagarse a un output visible, auditable y potencialmente regulado. Si el modelo responde con información personal no depurada o con datos de clientes de una jurisdicción con restricciones de transferencia, el problema de compliance ya ocurrió. El lineage es el único mecanismo que permite reconstruir ese camino y demostrar control ante un regulador.

    El EDM Council y el umbral mínimo de madurez para operar IA de forma segura

    El EDM Council, a través de su framework CDMC (Cloud Data Management Capabilities), establece que las organizaciones necesitan al menos las capabilities de clasificación de datos, gestión de consentimiento y control de acceso granular antes de mover datos sensibles a entornos de IA en la nube. Según el esquema de madurez del CDMC, muchas organizaciones de la región operan entre los niveles 4 y 6 de 12, suficiente para reporting operativo pero insuficiente para soportar un programa de IA con datos regulados. La distancia no es menor: entre el nivel 6 y el 9 —donde el control sobre datos en IA empieza a ser robusto— hay decisiones de presupuesto, de talento y de arquitectura que no se resuelven en un trimestre.

    En América Latina: LGPD, Ley 25.326 y el riesgo de entrenar modelos con datos personales sin base legal

    En Brasil, la LGPD (Lei Geral de Proteção de Dados, Lei nº 13.709/2018) exige que cualquier tratamiento de datos personales, incluyendo el uso para entrenamiento de modelos de IA, cuente con una base legal habilitante. La Autoridade Nacional de Proteção de Dados (ANPD) ya emitió orientaciones sobre tratamiento automatizado que las organizaciones con operaciones en el país deben considerar al diseñar sus pipelines de entrenamiento. En Argentina, la Ley 25.326 de Protección de Datos Personales aplica lógica similar, aunque la Agencia de Acceso a la Información Pública (AAIP) aún no cuenta con una guía específica para IA. En México, el INAI opera bajo la LFPDPPP y ha emitido recomendaciones sobre decisiones automatizadas. El punto común: ninguno de estos marcos habilita el uso de datos personales en IA por defecto. La gobernanza de datos no es preparación para una auditoría futura; es el requisito previo para operar hoy.

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

    Las brechas identificadas por PwC son directamente relevantes para organizaciones que: (a) usan datos de clientes o empleados para alimentar modelos de IA propios o de terceros; (b) operan en industrias reguladas —banca, salud, seguros— con requisitos específicos de control de datos; o (c) tienen proveedores de IA que acceden a datos propios para fine-tuning o RAG (Retrieval-Augmented Generation). No aplica de la misma forma a organizaciones que usan modelos de IA exclusivamente con datos públicos o sintéticos sin trazabilidad a personas identificables. En ese segmento, el riesgo de gobernanza es menor, aunque el riesgo de calidad de output persiste.

    Para un CDO o Data Governance Manager con proyectos de IA activos, el paso inmediato es auditar qué datasets están siendo utilizados por esos proyectos, quién figura como data owner en el catálogo corporativo, y si existe una base legal documentada para ese uso bajo la ley aplicable en cada jurisdicción donde operan. Si alguna de esas tres preguntas no tiene respuesta clara, el riesgo ya existe.

    El reporte completo de PwC está disponible en pwc.com; para el marco regulatorio aplicable en Brasil, la ANPD publica sus resoluciones y guías técnicas en gov.br/anpd.

  • OpenAI despide a tres empleados por una brecha de seguridad interna

    OpenAI despide a tres empleados por una brecha de seguridad interna

    OpenAI desvinculó a tres trabajadores tras detectar una brecha de seguridad interna relacionada con el acceso o filtración de datos, según se informó el 2 de octubre de 2025. El incidente reaviva las preguntas sobre los controles de acceso y las políticas de gobernanza interna en uno de los actores más influyentes del sector de inteligencia artificial.

    El despido de tres empleados fue confirmado según se informó por fuentes vinculadas a la compañía, aunque OpenAI no emitió una declaración pública detallada al momento del cierre de esta nota. Los detalles sobre el tipo de datos comprometidos, el alcance de la brecha y si hubo exfiltración hacia terceros no han sido verificados de manera independiente. Lo que sí trascendió es que la investigación interna derivó en acciones disciplinarias de máxima severidad: la desvinculación de tres personas.

    Datos confirmados y qué falta saber

    • Tres empleados despedidos como consecuencia directa del incidente, según se informó.
    • El evento fue catalogado internamente como una brecha de seguridad de datos.
    • Fecha de reporte público: 2 de octubre de 2025.
    • OpenAI no confirmó si los datos afectados corresponden a usuarios, modelos o información corporativa interna.
    • No se ha informado si el incidente fue notificado a alguna autoridad regulatoria.

    Sin notificación pública a reguladores: el punto que no puede ignorarse en LATAM

    La ausencia de comunicación oficial hacia autoridades de control es un aspecto crítico en cualquier jurisdicción con marco de protección de datos vigente. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece en su artículo 48 la obligación de notificar a la Autoridade Nacional de Proteção de Dados (ANPD) ante incidentes que puedan acarrear riesgo o daño relevante a los titulares, dentro de un plazo razonable. En Argentina, la Ley 25.326 y las disposiciones de la AAIP imponen obligaciones similares para quienes tratan datos de ciudadanos argentinos. En México, el INAI exige la notificación de vulnerabilidades de seguridad conforme a la LFPDPPP y su reglamento. Si OpenAI procesa datos de usuarios en la región —lo que resulta altamente probable dado su base de usuarios global—, el incidente entra en el radar de estas autoridades independientemente de dónde ocurrió físicamente la brecha.

    El caso también expone una tensión estructural en compañías de IA de alto perfil: los mismos sistemas que procesan datos de millones de usuarios son operados por equipos internos con niveles de acceso privilegiado. Sin controles robustos de data access governance —incluyendo separación de roles, auditoría de logs y políticas de need-to-know— el riesgo insider se convierte en el vector más difícil de mitigar. El hecho de que el incidente haya sido detectado y derivado en despidos sugiere que OpenAI cuenta con algún mecanismo de monitoreo interno, pero no dice nada sobre la oportunidad de la detección ni sobre el daño ya producido.

    El próximo hito a seguir es si OpenAI emite una notificación formal a reguladores en las jurisdicciones donde opera — ese silencio, o su ausencia, definirá la exposición legal real del incidente.

  • Cuando la IA de tu cliente te reemplaza: el dilema de los estudios jurídicos

    Cuando la IA de tu cliente te reemplaza: el dilema de los estudios jurídicos

    La inteligencia artificial generativa está permitiendo que departamentos jurídicos internos absorban trabajo que antes delegaban a estudios externos. El caso de Alturas Capital Partners —una firma de inversión inmobiliaria que redujo drásticamente su dependencia de abogados externos para contratos de arrendamiento— ilustra una tendencia que replantea la cadena de valor del asesoramiento legal.

    Durante décadas, los departamentos de legal in-house operaron como coordinadores: definían la estrategia, priorizaban los asuntos y derivaban el trabajo voluminoso —revisión de contratos, due diligence, investigación jurídica— a estudios especializados. Ese modelo asumía una asimetría de capacidades: los externos tenían el músculo procesal, las horas facturables y los especialistas. La IA generativa está erosionando esa asimetría de forma sistemática.

    Alturas Capital Partners: el contrato de arrendamiento como caso de prueba

    Según se informó en MIT Sloan Management Review, Alturas Capital Partners reorientó su flujo de trabajo de lease review hacia herramientas de IA generativa, lo que le permitió internalizar tareas que antes externalizaba y ahorrar cientos de miles de dólares en honorarios a estudios externos. El tiempo de ciclo de esas operaciones —que antes se estancaba durante días en colas de trabajo externo— se comprimió de forma significativa. No se trata de un caso aislado: es el prototipo del cliente que ya no necesita al estudio para cierto tipo de trabajo.

    La pregunta que ese desplazamiento plantea no es tecnológica sino estratégica: si un cliente puede automatizar la revisión de contratos estándar, ¿qué le queda al estudio externo para ofrecer? La respuesta incorrecta es “bajar precios”. La respuesta que emerge de los análisis del sector es “subir en la cadena de valor”: pasar de la ejecución repetitiva al juicio experto, la gestión de riesgo complejo y la representación litigiosa donde la IA aún no puede sustituir al profesional.

    Qué trabajo resiste la automatización y qué ya no

    La distinción operativa más útil para un estudio jurídico hoy es la que separa el trabajo de volumen del trabajo de juicio. El trabajo de volumen —revisión de contratos estandarizados, extracción de cláusulas, checklists de due diligence, research de jurisprudencia conocida— es el primero en migrar a herramientas internas de los clientes. El trabajo de juicio —negociación de cláusulas atípicas, litigios con alta incertidumbre procesal, asesoramiento regulatorio en terreno gris, estructuras transaccionales complejas— mantiene mayor resistencia a la automatización porque requiere contexto acumulado, responsabilidad profesional y criterio bajo incertidumbre.

    El problema es que el trabajo de volumen representaba históricamente entre el 40% y el 60% de los ingresos de muchos estudios medianos, según estimaciones del sector legal global. Perder ese segmento sin reemplazarlo con servicios de mayor complejidad implica una contracción de ingresos estructural, no cíclica.

    Cuándo aplica este desplazamiento y cuándo no

    Este fenómeno no es uniforme. Afecta principalmente a estudios que facturan trabajo repetitivo para clientes corporativos con departamentos de legal in-house suficientemente maduros para adoptar y operar herramientas de IA. Las firmas boutique especializadas en litigio complejo, derecho penal económico o arbitraje internacional tienen menor exposición inmediata. Tampoco aplica de igual forma en mercados donde los departamentos internos son pequeños o donde la regulación local requiere firma de abogado habilitado para actos específicos —lo que en varios países de América Latina sigue siendo la norma para escrituras públicas, presentaciones judiciales y ciertos registros.

    El riesgo es mayor para estudios que compiten por precio en segmentos de contratos masivos: revisión de contratos de trabajo, arrendamientos comerciales, términos y condiciones, NDAs. Esos son exactamente los documentos que los modelos de lenguaje actuales manejan con mayor precisión.

    El marco regulatorio latinoamericano como variable diferenciadora

    En América Latina, la adopción de IA en departamentos jurídicos internos enfrenta fricciones adicionales que los estudios pueden convertir en ventaja competitiva. Brasil, cuyo Marco Legal de IA (PL 2.338/2023) avanza en el Congreso con disposiciones sobre sistemas de alto riesgo —incluyendo aplicaciones en servicios profesionales—, obliga a cualquier empresa que despliegue IA en decisiones con efectos jurídicos a documentar sus procesos de supervisión humana. En Argentina, la Resolución 1/2024 de la Secretaría de Innovación Pública establece lineamientos para el uso de IA en organismos públicos, pero el sector privado opera aún sin un marco equivalente. En México, la discusión en torno a una ley de IA sigue en etapa exploratoria, sin proyecto consolidado.

    Esa asimetría regulatoria crea una oportunidad para los estudios que comprendan el marco de cada jurisdicción: el asesoramiento sobre cómo desplegar IA internamente de forma legalmente válida —qué tareas pueden automatizarse sin incurrir en responsabilidad profesional, qué outputs requieren revisión humana certificada— es en sí mismo un servicio de alto valor que los departamentos internos de los clientes no pueden generar por sí solos.

    La respuesta estratégica: especializarse en lo que la IA del cliente no puede validar

    Los estudios que están respondiendo con mayor eficacia al desplazamiento no compiten con la IA del cliente: la complementan. Ofrecen lo que los modelos no pueden ofrecer con validez jurídica autónoma —firma profesional responsable, representación ante autoridades, criterio en zonas de ambigüedad normativa— y agregan capas de servicio que las herramientas internas no contemplan: auditorías de los propios sistemas de IA del cliente, revisión de los outputs generados, gestión de incidentes cuando un contrato generado automáticamente produce un litigio. Este último punto —el abogado como auditor de la IA del cliente— es el nicho emergente con mayor proyección en el mediano plazo.

    Para los estudios medianos de la región, el camino más concreto es identificar qué porcentaje de sus ingresos actuales proviene de trabajo repetitivo para clientes corporativos, modelar el escenario en que ese trabajo migra a herramientas internas en los próximos 24 meses, y diseñar hoy la oferta que captura al cliente en la capa superior. No hay tiempo suficiente para esperar a que el desplazamiento sea evidente en el estado de resultados.

    El estudio que sobrevive no es el que bloquea la IA de su cliente, sino el que le cobra por entender lo que esa IA no puede hacer sola.

  • Por qué la regulación de IA debe anclar en gobernanza de datos, según expertos

    Por qué la regulación de IA debe anclar en gobernanza de datos, según expertos

    Las nuevas leyes de inteligencia artificial no deberían limitarse a prohibir usos concretos: expertos del sector advierten que sin marcos sólidos de gobernanza de datos en su base, cualquier regulación de IA nace con un déficit estructural de confianza. El argumento no es retórico — apunta directamente a cómo los parlamentos y agencias regulatorias están diseñando sus marcos normativos.

    La discusión parte de una premisa técnica que los legisladores suelen pasar por alto: un sistema de inteligencia artificial es tan confiable como los datos con los que fue entrenado y con los que opera. Si esos datos son de mala calidad, están mal clasificados, carecen de linaje documentado o no tienen propietario formal (data owner), la ley que regule el sistema producirá resultados impredecibles. La gobernanza de datos no es un prerrequisito burocrático — es la infraestructura de confiabilidad sobre la que descansa cualquier obligación regulatoria significativa.

    El AI Act europeo como caso de referencia: qué exige y qué supone

    El Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, Reglamento 2024/1689) es el instrumento más detallado vigente hasta la fecha. Para los sistemas de IA de alto riesgo — que incluyen decisiones de crédito, empleo, educación y servicios esenciales — el texto exige explícitamente prácticas de gobernanza de datos: los conjuntos de datos de entrenamiento, validación y prueba deben cumplir con criterios de calidad, relevancia, completitud y ausencia de sesgos en la medida de lo posible. El artículo 10 del AI Act es, en la práctica, un mandato de data governance codificado en derecho comunitario. Sin embargo, muchas organizaciones aún no cuentan con los procesos internos para cumplirlo.

    El problema no es únicamente europeo. Los marcos que se están discutiendo en Asia, América del Norte y América Latina replican, con variantes, la misma tensión: regular el output de los sistemas de IA sin establecer estándares vinculantes sobre la calidad y el gobierno de los datos que los alimentan. Expertos señalan que esa brecha produce leyes que son formalmente exigibles pero operativamente difíciles de auditar.

    Seguridad de datos como componente de la regulación de IA: el eslabón que falta

    Más allá de la calidad, el eje de seguridad aparece como el segundo componente crítico. La convergencia entre datos sensibles y sistemas automatizados amplía la superficie de riesgo: un modelo de lenguaje grande que procesa datos médicos o financieros sin controles de acceso granulares, sin cifrado en reposo y en tránsito, y sin mecanismos de auditoría representa una exposición que ninguna cláusula de responsabilidad puede compensar ex post. La regulación de IA que no contemple requisitos mínimos de seguridad de datos queda incompleta en su arquitectura de riesgos.

    Esta lectura es consistente con lo que frameworks como el NIST AI Risk Management Framework (AI RMF 1.0) y el Marco de Gestión de Riesgos de IA del NIST ya establecen como buenas prácticas: la función “Map” del NIST AI RMF exige identificar los datos utilizados, su procedencia y los riesgos asociados a su tratamiento antes de desplegar cualquier sistema. Cumplir esa función requiere capacidades de data lineage y clasificación de datos que, en muchas organizaciones de la región, todavía no existen de forma sistemática.

    Cuándo aplica este enfoque y cuándo no alcanza

    Este argumento es más robusto para sistemas de IA de alto riesgo — los que toman o influyen en decisiones con impacto directo sobre personas físicas — que para aplicaciones de bajo impacto. Un chatbot de atención al cliente con datos públicos plantea un perfil de riesgo diferente al de un sistema de scoring crediticio entrenado con historiales bancarios. Los marcos regulatorios que no distinguen entre ambos escenarios tienden a sobrecargar a las organizaciones con menor capacidad técnica sin reducir los riesgos reales. La proporcionalidad entre nivel de riesgo y exigencia de gobernanza es el principio que más frecuentemente aparece en los debates legislativos actuales.

    América Latina frente a este debate: Brasil, México y la brecha de implementación

    En la región, el panorama regulatorio de IA avanza de forma desigual. Brasil tiene el proyecto de ley de IA más avanzado (PL 2338/2023), que retoma la estructura de riesgo del AI Act europeo y establece obligaciones de transparencia y auditoría para sistemas de alto riesgo — pero no fija aún estándares específicos de gobernanza de datos con el nivel de detalle del artículo 10 europeo. México, por su parte, no cuenta con una ley específica de IA, aunque la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y el Reglamento del INAI cubren parcialmente el tratamiento automatizado de datos personales. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) publicó en 2023 recomendaciones no vinculantes sobre IA y datos personales, pero sin fuerza normativa equivalente a un reglamento sectorial.

    La brecha no es solo legislativa: es de capacidad instalada. Según el modelo de madurez CDMC del EDM Council, pocas organizaciones latinoamericanas superan el nivel 1 o 2 de las 14 capabilities evaluadas, lo que significa que los procesos de catalogación, clasificación y linaje de datos todavía son fragmentarios o inexistentes en gran parte del tejido empresarial regional. Exigir por ley estándares de gobernanza de datos para IA sin acompañar esa exigencia con guías de implementación crea obligaciones nominales que no se traducen en mejoras reales.

    La pregunta que deberían hacerse los legisladores de la región antes de aprobar sus leyes de IA no es si deben incluir gobernanza de datos — sino si tienen claro qué nivel de madurez técnica existe en el mercado al que le van a aplicar esa exigencia.

  • LLMs no razonan: qué significa eso para quienes los regulan

    LLMs no razonan: qué significa eso para quienes los regulan

    Los modelos de lenguaje de gran escala no razonan: procesan patrones estadísticos con una sofisticación que imita el razonamiento, pero sin comprensión real. Esa distinción —técnica en apariencia— tiene consecuencias jurídicas y regulatorias concretas para América Latina, donde varios países están construyendo marcos de IA sin haber resuelto esta pregunta de base.

    Cuando un modelo como GPT-4 o Gemini responde una pregunta legal, diagnóstica un síntoma o explica una decisión de crédito, no está siguiendo una cadena lógica de causas y efectos. Está prediciendo qué token viene a continuación en función de patrones aprendidos sobre miles de millones de documentos. La diferencia importa: un sistema que razona puede, en principio, justificar sus conclusiones paso a paso. Un sistema que predice, no. Lo que se parece a una justificación es, en muchos casos, otra predicción estadística.

    Por qué el “razonamiento” de los LLMs es una ilusión funcional

    Los modelos de lenguaje aprenden a asociar estructuras lingüísticas con resultados esperados. Cuando se les pide que “muestren su razonamiento”, generan texto que se parece a un razonamiento —porque ese tipo de texto aparece frecuentemente en los datos de entrenamiento— sin que exista un proceso inferencial subyacente verificable. Esto no los hace inútiles: son herramientas extraordinariamente potentes para síntesis, redacción y recuperación de información. Pero sí los hace inadecuados, sin salvaguardas adicionales, para cualquier función que requiera explicabilidad genuina o responsabilidad sobre una decisión.

    El problema se agrava cuando se encadenan varios LLMs en flujos de trabajo agénticos —los llamados “agentes de IA”— donde la salida de uno alimenta la entrada del siguiente. Cada eslabón de esa cadena hereda la incertidumbre del anterior, sin que ninguno pueda “darse cuenta” de que está propagando un error. En esos sistemas, la trazabilidad de una decisión incorrecta es casi imposible sin instrumentación explícita de cada paso.

    Cuándo aplica esta distinción y cuándo no cambia nada práctico

    Para tareas de bajo riesgo —redactar un borrador, resumir un documento, generar código de prueba— la distinción entre predicción y razonamiento es, en la práctica, irrelevante. El usuario puede revisar el output y corregir errores sin consecuencias graves. El problema aparece en contextos de alto impacto: decisiones sobre crédito, libertad condicional, diagnóstico médico, selección de personal o interpretación jurídica automatizada. Allí, la incapacidad del modelo de razonar genuinamente colisiona con los requisitos de explicabilidad que ya exigen varias normas vigentes.

    En la Unión Europea, el AI Act clasifica estos usos como sistemas de IA de alto riesgo (Anexo III) y exige documentación técnica, supervisión humana y explicaciones comprensibles de las decisiones automatizadas. En América Latina, el cuadro regulatorio es más fragmentado pero avanza: Brasil incorporó en su Estrategia Nacional de Inteligencia Artificial (EBIA) lineamientos sobre explicabilidad y trazabilidad; Colombia emitió en 2023 el CONPES 3975 y una guía de ética de IA que menciona explícitamente la obligación de poder explicar decisiones automatizadas; y Chile avanza en su proyecto de ley de IA, que retoma la lógica del AI Act europeo en materia de sistemas de alto riesgo.

    El nudo jurídico: explicabilidad sin razonamiento real

    Si un LLM no razona, no puede explicar genuinamente por qué llegó a una conclusión. Puede generar texto que suene a explicación, pero esa explicación es en sí misma una predicción estadística, no una reconstrucción causal del proceso. Esto crea una tensión directa con normas que exigen explicaciones “inteligibles” o “comprensibles” para el afectado. El artículo 22 del RGPD europeo y sus equivalentes en la Ley 25.326 de Argentina —que habilita decisiones automatizadas solo con garantías específicas— asumen implícitamente que quien decide puede también explicar. Con los LLMs actuales, esa asunción no se sostiene.

    En México, la LFPDPPP no tiene un artículo equivalente al 22 del RGPD, pero el INAI ha señalado en criterios recientes que el tratamiento automatizado de datos personales que produce efectos jurídicos debe estar documentado y ser auditable. Esa auditabilidad, aplicada a un LLM, requiere algo más que logs de input/output: requiere mecanismos de interpretabilidad del modelo —una disciplina técnica todavía emergente conocida como XAI (Explainable AI)— que la mayoría de las organizaciones desplegando estos sistemas en la región no ha implementado.

    Qué implica esto para los marcos regulatorios que se están diseñando hoy

    Los legisladores y reguladores de la región que están redactando normas de IA enfrentan una elección de diseño: regular los LLMs por sus capacidades declaradas (lo que los proveedores dicen que hacen) o por sus capacidades técnicas reales (lo que los modelos efectivamente pueden y no pueden hacer). La distinción entre predicción estadística y razonamiento genuino debería ser un criterio explícito en las definiciones de “sistema de IA de alto riesgo” en cualquier marco regional. Sin esa distinción, una norma puede quedar vaciada de contenido: un proveedor podría argumentar que su modelo “explica” sus decisiones simplemente porque genera texto con forma de explicación.

    La solución técnica más robusta disponible hoy combina LLMs con sistemas simbólicos verificables —motores de reglas, árboles de decisión auditables, bases de conocimiento estructuradas— en arquitecturas híbridas donde el componente estadístico y el componente lógico tienen roles diferenciados y trazables. Eso no elimina los riesgos, pero sí permite aislar qué parte del proceso tomó qué tipo de decisión. Regular esa arquitectura —no solo el modelo— es el desafío pendiente.

    Para quienes diseñan marcos de IA en la región: una norma que exige explicabilidad sin definir qué cuenta como explicación válida no protege a nadie. La pregunta técnica sobre si los LLMs razonan no es filosófica —es el fundamento de cualquier régimen de responsabilidad que pretenda funcionar.

  • Ciberataques potenciados por IA: identidad y gobernanza de datos como primera línea

    Ciberataques potenciados por IA: identidad y gobernanza de datos como primera línea

    Cuando los atacantes usan inteligencia artificial para automatizar y escalar sus ofensivas, la gobernanza de datos deja de ser un asunto de cumplimiento y se convierte en infraestructura defensiva. Así lo plantea Microsoft en su análisis más reciente sobre el panorama de amenazas: sin saber qué datos existen, dónde están y quién puede acceder a ellos, cualquier control de seguridad queda ciego.

    La premisa es operativa antes que filosófica. Los modelos de lenguaje y las herramientas de automatización ofensiva permiten a los atacantes enumerar superficies de ataque, generar credenciales falsas y moverse lateralmente a una velocidad que supera la capacidad de respuesta humana. En ese escenario, la identidad —quién es quién en el ecosistema digital de una organización— y el gobierno del dato —qué activos existen y bajo qué reglas se accede a ellos— se convierten en los dos vectores que determinan si una intrusión escala o se contiene.

    Por qué la gobernanza de datos es el problema de seguridad que nadie nombra

    Un ataque potenciado por IA no inventa vulnerabilidades nuevas: las explota más rápido. Si una organización no tiene un catálogo de datos actualizado —es decir, no sabe qué información sensible existe ni quién tiene permisos sobre ella—, un atacante que compromete una cuenta privilegiada puede exfiltrar activos críticos antes de que se active cualquier alerta. La gobernanza de datos, en términos de DAMA-DMBOK, es exactamente lo que evita ese punto ciego: clasificación de activos, definición de ownership, control de acceso basado en el nivel de sensibilidad del dato y data lineage que permita rastrear qué se movió y hacia dónde.

    El data steward —el rol responsable de definir reglas de uso y calidad sobre dominios específicos de datos— cobra aquí una función que trasciende el compliance. En un entorno donde la IA ofensiva puede identificar en segundos qué tablas de una base de datos contienen registros de alto valor, tener un steward que mantenga actualizada la clasificación de sensibilidad es una decisión de gestión de riesgo, no una formalidad de auditoría.

    Identidad: el vector que amplifica o neutraliza el daño

    El control de identidad es el complemento necesario. Sin una arquitectura robusta de gestión de identidades y accesos —incluyendo privilegios mínimos, revisiones periódicas de permisos y detección de anomalías de comportamiento—, la mejor clasificación de datos no impide que una cuenta comprometida acceda a activos que no debería tocar. La IA ofensiva es especialmente efectiva en el abuso de identidades: puede generar campañas de phishing hiperpersonalizadas, explotar tokens de sesión y escalar privilegios de formas que los sistemas de detección convencionales no anticipan.

    El vínculo entre identidad y gobierno del dato no es metafórico. En términos del marco DCAM del EDM Council, la capability de seguridad y privacidad del dato requiere que los controles de acceso estén alineados con la clasificación del activo: un dato catalogado como “restringido” debería activar automáticamente políticas de acceso más estrictas en el directorio de identidades. Cuando esa alineación no existe, la brecha entre lo que dice el catálogo y lo que permite el sistema de permisos es exactamente el espacio que un atacante con IA puede explotar.

    Cuándo aplica / cuándo NO este enfoque

    Este marco de defensa es relevante para organizaciones que ya tienen una superficie de datos significativa —múltiples fuentes, entornos híbridos, usuarios con distintos niveles de privilegio— y que enfrentan adversarios con capacidad de automatizar reconocimiento y movimiento lateral. No es la solución prioritaria para una pequeña empresa con un único sistema central y accesos controlados manualmente: en ese caso, los controles de identidad básicos y el backup seguro siguen siendo la inversión más eficiente. La gobernanza de datos como vector defensivo escala en importancia directamente con la complejidad del ecosistema de datos y el valor de los activos expuestos.

    El estado del arte en América Latina: regulación que empuja en la misma dirección

    En la región, varios marcos regulatorios están generando presión convergente. La Lei Geral de Proteção de Dados (LGPD) de Brasil exige que las organizaciones implementen medidas técnicas y administrativas para proteger datos personales, lo que incluye controles de acceso y clasificación. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) ha actualizado sus lineamientos de seguridad exigiendo que los responsables de tratamiento documenten las medidas adoptadas para proteger los datos que tratan. En México, la LFPDPPP —y su reglamento— requieren que los encargados del tratamiento mantengan un inventario de los datos que procesan. Ninguna de estas normas menciona explícitamente “catálogo de datos” o “data steward”, pero todas presuponen capacidades de gobierno del dato para poder cumplirse. Las organizaciones que construyen esas capacidades para defenderse de ataques de IA también están, en paralelo, avanzando en su madurez regulatoria.

    Para un Chief Data Officer o Data Governance Manager en la región, la conversación sobre ciberataques potenciados por IA es una oportunidad concreta: inventariar qué activos de datos de alto valor existen y si su clasificación está actualizada en el catálogo corporativo; revisar si los permisos de acceso en el directorio de identidades son consistentes con esa clasificación; y validar si los data stewards de cada dominio tienen visibilidad sobre quién accede a los datos bajo su ownership. Esas tres acciones son el punto de partida mínimo recomendado por frameworks como CDMC del EDM Council para organizaciones que operan en entornos de amenaza elevada.

    Para profundizar en los principios de clasificación y control de acceso a datos, el DAMA-DMBOK 2 (capítulos de Data Security y Data Governance) y el marco CDMC del EDM Council ofrecen las guías de referencia más completas disponibles para equipos de gobierno de datos en entornos corporativos.