DataTrends LATAM

Etiqueta: Normativa

  • Opt Out October: alternativas reales a los gigantes tecnológicos

    Opt Out October: alternativas reales a los gigantes tecnológicos

    La Electronic Frontier Foundation lanzó la segunda edición de Opt Out October, una iniciativa que este año va más allá de ajustar configuraciones de privacidad: propone abandonar plataformas, aplicaciones y sistemas operativos de las grandes tecnológicas en favor de alternativas con menor huella de datos. El planteo llega en un momento en que legislaciones como la LGPD brasileña, la Ley 25.326 argentina y la LFPDPPP mexicana consolidan el derecho a la portabilidad y a la supresión de datos personales —derechos que solo pueden ejercerse si los usuarios saben que existen.

    Opt Out October nació en 2025 como un recordatorio mensual para revisar configuraciones dentro de las aplicaciones más usadas. En su edición 2026, la EFF amplió el alcance: el eje ya no es solo ajustar permisos, sino evaluar si ciertos servicios deberían seguir siendo parte del ecosistema digital de cada persona u organización. La iniciativa incluye una plataforma de recursos con guías para migrar a software alternativo, explorar redes sociales descentralizadas y controlar el uso de datos personales en el entrenamiento de modelos de inteligencia artificial.

    Por qué migrar es más que una decisión técnica

    Cambiar de plataforma implica ejercer derechos que la regulación reconoce pero que los usuarios raramente activan. En Brasil, el artículo 18 de la LGPD garantiza la portabilidad de datos a otro proveedor de servicio o producto. En México, el derecho de cancelación bajo la LFPDPPP permite exigir la supresión de datos que un responsable ya no necesita. En Argentina, la Ley 25.326 reconoce el derecho a la eliminación de datos inexactos o innecesarios. Migrar de un servicio no solo es posible: en muchos casos, es el único acto que materializa esos derechos, dado que las solicitudes de supresión enviadas a grandes plataformas suelen tener cumplimiento parcial o tardío.

    La EFF no enumera en su comunicado qué alternativas específicas recomienda para cada categoría de software, pero sí organiza su hub de recursos en cuatro ejes: nuevas aplicaciones no desarrolladas por gigantes tecnológicos, opciones de redes sociales fuera del ecosistema Meta-Google-X, sistemas operativos alternativos, y herramientas para limitar el uso de datos personales en el entrenamiento de inteligencia artificial generativa. Este último punto es especialmente relevante: varios proveedores incorporaron cláusulas en sus términos de servicio que autorizan el uso de contenido generado por usuarios para mejorar sus modelos, sin que el usuario promedio lo advierta.

    Cuándo aplica la migración de plataforma y cuándo no es suficiente

    Optar por software alternativo tiene sentido claro cuando el servicio que se abandona monetiza datos de comportamiento, comparte información con terceros para publicidad dirigida o utiliza contenido del usuario para entrenamiento de IA sin consentimiento diferenciado. En esos escenarios, ajustar configuraciones internas resuelve solo una parte del problema: mientras la cuenta permanece activa, el historial de datos sigue disponible para el operador. La migración, en cambio, habilita una solicitud de eliminación de cuenta y datos asociados que —al menos en jurisdicciones con regulación vigente— el responsable tiene la obligación legal de atender.

    Sin embargo, migrar no es suficiente cuando el servicio alternativo no está sujeto a ningún marco regulatorio claro o cuando carece de política de privacidad auditada. Muchas herramientas de código abierto o descentralizadas ofrecen mejores condiciones de privacidad en términos técnicos, pero no tienen domicilio legal en ningún país, lo que dificulta el ejercicio de derechos ante una autoridad de control. En esos casos, el usuario gana autonomía técnica pero pierde respaldo jurídico. La evaluación debe ser caso por caso.

    El ángulo organizacional: cuando la migración involucra datos de empleados y clientes

    Para empresas y organismos públicos en América Latina, la discusión sobre alternativas tecnológicas no es solo de preferencia individual: involucra datos personales de terceros. Una organización que utiliza herramientas de productividad de un hiperescalador y activa funciones de IA generativa sobre documentos internos puede estar transfiriendo datos personales de empleados o clientes a un sistema de entrenamiento sin base legal suficiente. Las autoridades de protección de datos de la región —la AAIP en Argentina, la ANPD en Brasil, el INAI en México— han señalado en distintos pronunciamientos que la incorporación de IA en tratamientos existentes puede requerir una nueva evaluación de impacto o incluso actualizar el aviso de privacidad.

    La iniciativa de la EFF no está dirigida a equipos legales ni a DPOs, pero el principio que la sustenta —revisar activamente si las herramientas en uso son compatibles con los derechos de las personas sobre sus datos— es exactamente el ejercicio que cualquier programa de privacidad corporativa debería realizar de forma periódica. Opt Out October, en ese sentido, funciona como un recordatorio calendárico para lo que en el ámbito organizacional se llama privacy review o revisión del inventario de tratamientos.

    El hub de recursos de Opt Out October de la EFF está disponible en eff.org; para el contexto regulatorio aplicable en la región, las autoridades de referencia son la ANPD (Brasil), la AAIP (Argentina) y el INAI (México), cuyos sitios publican guías sobre ejercicio de derechos y obligaciones de los responsables de tratamiento.

  • Utah SB 73: un juez federal bloquea la ley antiVPN por imposibilidad técnica

    Utah SB 73: un juez federal bloquea la ley antiVPN por imposibilidad técnica

    Un juez federal de Utah emitió una medida cautelar que suspende la aplicación de la SB 73, la ley estatal que exigía a sitios web adultos bloquear a usuarios de VPN o identificar su ubicación física. La decisión, que la Electronic Frontier Foundation (EFF) celebró como un triunfo para los derechos digitales, establece que la norma probablemente viola la Constitución estadounidense al imponer una obligación técnicamente imposible de cumplir. El fallo tiene implicancias directas para el debate latinoamericano sobre verificación de edad y regulación de plataformas.

    Qué ordenaba la SB 73 de Utah y por qué era inviable

    Sancionada a principios de 2026 y firmada por el gobernador de Utah, la SB 73 convirtió a ese estado en el primero del país —según el propio registro de la EFF— en apuntar directamente al uso de VPN como mecanismo para eludir controles de verificación de edad en plataformas de contenido adulto. La ley exigía a los sitios web dos alternativas igualmente problemáticas: bloquear completamente a cualquier usuario que accediera mediante una VPN, o bien identificar la ubicación física real de ese usuario a pesar del enmascaramiento de tráfico que la herramienta provee. Para cerrar el círculo, la norma también prohibía a las plataformas publicar instrucciones sobre cómo usar una VPN para eludir esos controles.

    El tribunal federal suspendió la aplicación de las disposiciones sobre VPN con un argumento central: la ley probablemente viola la cláusula constitucional que impide al gobierno imponer cargas significativas sobre actividades comerciales interestatales. Pero el argumento técnico fue igualmente contundente. Detectar con certeza si un usuario está detrás de una VPN —y más aún identificar su ubicación real— no es un problema de recursos o de voluntad regulatoria: es una imposibilidad técnica en el estado actual de la infraestructura de internet, tal como argumentó la EFF en sus comentarios ante el Departamento de Comercio de Utah.

    La EFF ante el Departamento de Comercio de Utah: privacidad como argumento técnico y de derechos

    Simultáneamente al fallo judicial, la EFF presentó comentarios formales en el proceso de elaboración de reglas del Departamento de Comercio de Utah, donde detalló cómo forzar a las plataformas a detectar y bloquear herramientas de privacidad no solo es técnicamente inviable, sino que compromete la seguridad de usuarios en todo el mundo. Las VPN son utilizadas por periodistas, activistas, trabajadores remotos y ciudadanos en regímenes autoritarios, y cualquier infraestructura diseñada para identificar a sus usuarios crea un vector de vulnerabilidad que va mucho más allá del contexto regulatorio de Utah.

    Verificación de edad en plataformas: el mapa regulatorio en Brasil, Argentina y México

    El caso de Utah no es un fenómeno aislado. La regulación de contenidos digitales para menores y la verificación de edad en plataformas es un debate activo en América Latina, con distintos niveles de avance según el país. En Brasil, la Lei 14.811/2024 refuerza la protección de niñas, niños y adolescentes en entornos digitales y habilita a la Autoridade Nacional de Proteção de Dados (ANPD) para intervenir en casos de tratamiento indebido de datos de menores, aunque la regulación específica sobre verificación de edad en plataformas de contenido adulto aún está en desarrollo. El Marco Legal da IA, aprobado en 2024, también incorpora principios que impactarán en cómo las plataformas gestionan el acceso diferenciado por edad.

    En Argentina, la Ley 25.326 de Protección de Datos Personales no contempla explícitamente mecanismos de verificación de edad en plataformas digitales, y el proyecto de reforma que tramita en el Congreso tampoco ha incorporado ese eje de manera específica. La Agencia de Acceso a la Información Pública (AAIP) tiene competencia sobre el tratamiento de datos de menores, pero carece de un mandato claro sobre verificación de acceso a contenidos. En México, la LFPDPPP tampoco cubre este escenario, aunque el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) ha emitido criterios sobre el tratamiento de datos de menores que podrían ser relevantes si una regulación similar a la SB 73 intentara replicarse a nivel federal o estatal.

    El patrón regional es claro: ningún país latinoamericano ha legislado todavía sobre la obligación de bloquear VPN como mecanismo de verificación de edad, pero la presión regulatoria sobre plataformas de contenido adulto es creciente en varios congresos. El fallo de Utah provee un antecedente jurisprudencial relevante sobre los límites técnicos y constitucionales de ese enfoque.

    Qué cambia para plataformas que operan en la región si este modelo regulatorio avanza

    Para una empresa de tecnología o una plataforma de contenidos con usuarios en América Latina, el escenario regulatorio emergente plantea tres desafíos concretos. Primero, cualquier obligación de verificación de edad que implique identificar o bloquear usuarios de VPN requeriría infraestructura de detección de tráfico que, según el argumento técnico validado por el tribunal de Utah, no existe de forma confiable. Segundo, implementar esa infraestructura —aunque fuera posible— crearía riesgos de privacidad para todos los usuarios, no solo para quienes intentan evadir controles, en directa tensión con las obligaciones de las leyes de protección de datos personales vigentes en la región. Tercero, las plataformas que operen en múltiples jurisdicciones se enfrentan a estándares contradictorios: una regulación en un estado o país puede exigir lo que otra prohíbe.

    Próximos hitos: el litigio sigue y los congresos de la región observan

    La medida cautelar es preliminar: el litigio sobre la SB 73 continuará en los tribunales federales de Utah. Una decisión definitiva sobre la inconstitucionalidad de la norma —o su eventual reformulación— marcará el terreno para regulaciones similares en otros estados de EE.UU. y, por efecto de influencia regulatoria, en países de América Latina que suelen mirar los debates legislativos norteamericanos como referencia. Vale monitorear también la evolución del Marco Legal da IA en Brasil y las discusiones en el Congreso argentino sobre reforma de la ley de datos personales, ambos espacios donde la regulación de acceso por edad podría aparecer como enmienda o artículo separado.

    Nuestro análisis

    El fallo de Utah pone en evidencia una tensión estructural que los legisladores latinoamericanos deberían leer con atención: la presión política por regular el acceso de menores a contenido adulto es legítima, pero el instrumento técnico importa tanto como la intención normativa. Obligar a las plataformas a detectar VPN no es una exigencia de compliance riguroso, es pedirle al derecho que derogue la criptografía. El mismo error conceptual reaparece en debates regionales sobre retención de datos, acceso gubernamental a comunicaciones cifradas y geolocalización forzada. El antecedente judicial estadounidense no es vinculante para los tribunales de la región, pero sí es un argumento técnico documentado y respaldado por un órgano jurisdiccional, lo que le otorga peso en cualquier proceso de elaboración de normas. Las autoridades de protección de datos de la región —ANPD, AAIP, INAI— tienen aquí una oportunidad concreta de emitir criterios preventivos antes de que algún legislador intente replicar la SB 73 en español.

    Cuando una ley exige lo técnicamente imposible, el problema no lo resuelve el cumplimiento: lo resuelve el control judicial. ¿Están las autoridades regulatorias de América Latina equipadas para hacer ese análisis técnico antes de que una norma inviable entre en vigor?

  • Baterías distribuidas: regulación, redes eléctricas y el modelo que llega a LATAM

    Baterías distribuidas: regulación, redes eléctricas y el modelo que llega a LATAM

    Las baterías de almacenamiento energético a gran escala enfrentan en muchas ciudades un laberinto regulatorio que frena su despliegue. Frente a esa barrera, startups en Estados Unidos están apostando por un modelo alternativo: baterías pequeñas, distribuidas y ubicadas en lugares no convencionales. El modelo tiene implicancias directas para los marcos regulatorios de energía en América Latina.

    El almacenamiento de energía es uno de los cuellos de botella más citados en la transición hacia redes eléctricas más limpias y resilientes. En teoría, las baterías permiten guardar energía cuando la generación es abundante y liberarla cuando la demanda pica. En la práctica, instalar un sistema de almacenamiento de gran escala en un entorno urbano denso —como Nueva York— puede implicar años de trámites, aprobaciones sectoriales superpuestas y costos regulatorios que hacen inviable el proyecto antes de que se tienda un cable.

    El problema de Nueva York y qué lo hace un caso de estudio regulatorio

    Nueva York es un ejemplo extremo, pero no una anomalía. La ciudad concentra regulaciones de zonificación, seguridad contra incendios, normativas del operador de red y requisitos ambientales que, según se informó, convierten la habilitación de grandes baterías urbanas en un proceso excepcionalmente complejo. Ese entorno hostil empujó a algunas empresas emergentes a repensar la arquitectura del problema: en lugar de una batería grande que negocia con el sistema, muchas baterías pequeñas que operan de forma coordinada y que, individualmente, caen por debajo de los umbrales que activan los controles más estrictos.

    El enfoque no es solo una ingeniería alternativa. Es también una estrategia regulatoria. Si los marcos normativos están escritos para instalaciones de cierta escala, diseñar por debajo de esa escala es, en la práctica, arbitrar la regulación. Eso abre preguntas sobre si las normas vigentes están capturando adecuadamente el riesgo real del sistema o si, al fragmentarlo, se crea un vacío de supervisión.

    Cuándo aplica el modelo distribuido y cuándo no

    El almacenamiento distribuido tiene ventajas concretas: reduce pérdidas de transmisión, aporta resiliencia local ante cortes y puede integrarse en edificios, estacionamientos o instalaciones industriales sin requerir obra civil mayor. Sin embargo, no es una solución universal. La coordinación de cientos o miles de unidades pequeñas requiere software de gestión sofisticado, acuerdos contractuales con múltiples propietarios de activos y protocolos de interoperabilidad que muchas redes de distribución en la región aún no tienen implementados. Donde la red de distribución es débil o donde falta infraestructura de comunicaciones, el modelo pierde eficiencia rápidamente.

    Argentina, Brasil y México: tres marcos regulatorios con diferente punto de partida

    En América Latina, el almacenamiento energético es una frontera regulatoria abierta. Brasil avanzó con la Resolución Normativa 1.059 de ANEEL (2023), que estableció el marco para el almacenamiento conectado a la red, pero la regulación de sistemas distribuidos de pequeña escala sigue en desarrollo. En Argentina, el Ente Nacional Regulador de la Electricidad (ENRE) no cuenta aún con un marco específico para almacenamiento domiciliario o comercial conectado a la red de distribución, lo que deja a los proyectos piloto en una zona gris. México, por su parte, atraviesa una etapa de redefinición de su política energética que ha generado incertidumbre sobre las reglas de despacho para fuentes no convencionales, incluyendo el almacenamiento.

    Chile es, quizás, el caso más avanzado de la región: la Ley de Almacenamiento y Electromovilidad (Ley 21.505, promulgada en 2022) creó una categoría regulatoria específica para sistemas de almacenamiento y habilitó su participación en el mercado eléctrico. Ese marco es el tipo de habilitador que las startups de almacenamiento distribuido necesitan para operar a escala, y que aún falta en la mayoría de los países del cono sur.

    El arbitraje regulatorio como señal de alerta para los reguladores

    Que las empresas diseñen sus instalaciones para quedar por debajo de los umbrales regulatorios no es necesariamente ilegal ni reprochable, pero sí es una señal que los reguladores deberían leer con atención. Indica que las normas existentes están generando incentivos no previstos. En el sector financiero, ese tipo de arbitraje regulatorio suele anunciar la necesidad de una revisión de los umbrales y definiciones. En el sector energético, el patrón podría repetirse: si muchas instalaciones de 999 kWh evitan las exigencias pensadas para instalaciones de 1 MWh, la política pública no está logrando su objetivo.

    Para los organismos reguladores de energía en la región, el caso estadounidense es un aviso temprano. Diseñar marcos que capturen el riesgo sistémico del almacenamiento distribuido —no solo el de cada unidad individual— será uno de los desafíos centrales de la próxima década regulatoria.

    La Ley chilena 21.505 es, hoy, el único modelo regional con categoría regulatoria explícita para almacenamiento: el resto de la región tiene poco tiempo para observar qué funciona antes de que el despliegue tecnológico supere a las normas.

  • Anti-SLAPP en California: un fallo que protege el periodismo de vigilancia

    Anti-SLAPP en California: un fallo que protege el periodismo de vigilancia

    Un tribunal de apelaciones de California confirmó el rechazo de una demanda interpuesta por el ex CEO de una empresa de tecnología de vigilancia contra el periodista que reveló su arresto por violencia doméstica. El fallo refuerza la vigencia del estatuto anti-SLAPP de California y la Ley de Escudo periodístico del estado, con implicancias directas para el debate regulatorio en América Latina sobre demandas estratégicas contra la prensa.

    Jack Poulson, escritor y editor del boletín All Source Intelligence, publicó detalles del informe policial del Departamento de Policía de San Francisco sobre el arresto de Maury Blackman —entonces CEO de Premise Data, una compañía especializada en inteligencia geoespacial con contratos militares— por un delito grave de violencia doméstica. Poulson obtuvo el documento de una fuente confidencial. Cuando el expediente judicial fue sellado con posterioridad a la publicación, Blackman demandó a Poulson, a Substack, a Amazon Web Services y a otra organización, reclamando daños y la eliminación del contenido de internet.

    Cómo funciona el anti-SLAPP de California: desestimación temprana antes del juicio

    El tribunal de primera instancia desestimó la totalidad del caso bajo el estatuto anti-SLAPP de California. Las siglas SLAPP corresponden a “strategic lawsuit against public participation” —demanda estratégica contra la participación pública— y describen litigios cuyo objetivo real no es obtener una reparación judicial sino imponer costos económicos, de tiempo y de estrés al demandado para silenciar su actividad. La legislación anti-SLAPP de California permite la desestimación anticipada de estas demandas infundadas, cortando de raíz el efecto intimidatorio que buscan generar. Blackman apeló, argumentando que la orden judicial de sellado del expediente de arresto primaba sobre el derecho de Poulson a informar sobre hechos de interés público.

    El Tribunal de Apelaciones rechazó ese argumento. En su decisión, el tribunal señaló que la Primera Enmienda protege la publicación veraz de información obtenida lícitamente, salvo que exista “la necesidad de promover un interés estatal de la más alta jerarquía” —un estándar que, según el tribunal, el interés de privacidad de Blackman no satisface. El fallo también confirmó que Poulson está protegido por la Shield Law de California como editor de un boletín periodístico, apoyándose en precedente establecido por la Electronic Frontier Foundation (EFF) en 2006. Substack y los demás sitios que alojaban el contenido también quedaron amparados por haber actuado simplemente como plataformas de publicación.

    El CEO de una empresa de vigilancia intentó silenciar con el proceso lo que no pudo borrar del registro

    El caso tiene una dimensión adicional que va más allá del derecho de prensa: el demandante no era un particular anónimo sino el máximo ejecutivo de una empresa cuyo modelo de negocio es, precisamente, la recolección y el análisis de datos de inteligencia. Premise Data ha sido señalada en investigaciones periodísticas previas por sus vínculos con contratos militares y el uso de redes de colaboradores civiles para mapear entornos de interés geopolítico. Que el CEO de una compañía de ese perfil intentara suprimir información de interés público sobre su propia conducta personal mediante una demanda civil configura un uso del sistema judicial especialmente incongruente con el debate público legítimo que rodea a la industria de vigilancia.

    Argentina, México y Colombia carecen de estatutos anti-SLAPP equivalentes al californiano

    En América Latina, las demandas estratégicas contra periodistas y activistas constituyen un patrón documentado, pero la respuesta legislativa es fragmentaria. Argentina no cuenta con un mecanismo de desestimación anticipada equivalente al anti-SLAPP californiano; la protección del periodismo frente a demandas abusivas depende en gran medida de la doctrina de la real malicia construida por la Corte Suprema a partir del caso “Campillay” (1986) y sus derivados, que exige probar dolo o negligencia grave del periodista para atribuir responsabilidad civil. Sin embargo, esa doctrina no impide que el proceso mismo —con sus costos y plazos— funcione como mecanismo de presión.

    México presenta una situación similar: si bien el artículo 7 de la Constitución garantiza la libertad de imprenta, no existe un mecanismo procesal que permita el rechazo in limine de demandas identificadas como estratégicas. En Colombia, la Ley 1564 de 2012 (Código General del Proceso) habilita algunas herramientas de saneamiento temprano, pero no están diseñadas específicamente para litigios contra la prensa. Chile avanzó con la Ley 21.394 de 2021 en materia de reforma procesal civil, pero tampoco incorporó disposiciones anti-SLAPP explícitas. La Relatoría Especial para la Libertad de Expresión de la CIDH ha señalado en múltiples informes que la litigación abusiva es uno de los vectores de censura indirecta más extendidos en la región.

    Shield Laws y fuentes confidenciales: el vacío que persiste en las legislaciones latinoamericanas

    El fallo también ratifica la vigencia de la Shield Law de California, que protege a los periodistas de revelar sus fuentes confidenciales. En LATAM, la protección del secreto de las fuentes tiene reconocimiento constitucional en varios países —Argentina (art. 43 CN), Colombia (art. 73 CN) y México (art. 7 CPEUM)—, pero su alcance en entornos digitales y plataformas de publicación independiente como Substack no ha sido objeto de desarrollo jurisprudencial sistemático. La pregunta de si un editor de newsletter cuenta con la misma protección que un periodista de medio tradicional es, en la mayoría de los sistemas jurídicos latinoamericanos, una pregunta sin respuesta clara.

    Nuestro análisis: el anti-SLAPP no es un privilegio de prensa sino una garantía de equilibrio procesal

    El fallo californiano no crea derechos nuevos: los consolida frente al intento de erosionarlos mediante la presión litigiosa. Lo relevante para la región no es el resultado —favorable al periodismo— sino el mecanismo: una vía procesal que permite cortar temprano una demanda identificada como estratégica, antes de que el costo del proceso logre su objetivo real. En ausencia de herramientas equivalentes, los sistemas jurídicos latinoamericanos quedan expuestos a un déficit estructural: la tutela sustantiva de la libertad de expresión existe en el papel, pero el proceso puede convertirse en el castigo. Que el demandante sea el ex CEO de una empresa de vigilancia agrega una ironía difícil de ignorar: la industria que recolecta datos sobre terceros intentó suprimir datos verificados sobre sí misma.

    Mientras la región debate leyes de protección de datos personales y marcos de regulación de plataformas, el instrumento que hace falta en la mayoría de los códigos procesales latinoamericanos es más mundano y más urgente: una vía para detener, antes del primer año de litigio, la demanda que no busca justicia sino silencio.

  • Argentina investiga posible filtración de 6 millones de datos de Mi Argentina

    Argentina investiga posible filtración de 6 millones de datos de Mi Argentina

    El Gobierno argentino abrió una investigación por una posible filtración de datos que afectaría a 6 millones de registros vinculados a la plataforma Mi Argentina, el sistema estatal de identidad digital. El incidente, según se informó, está siendo analizado por las autoridades competentes para determinar su alcance y origen.

    La plataforma Mi Argentina concentra información sensible de los ciudadanos: datos de identidad, licencias de conducir, credenciales de salud y documentación oficial digitalizada. Una eventual exfiltración de esa magnitud —6 millones de registros, según se informó— colocaría al Estado nacional como responsable del tratamiento de datos personales comprometidos en uno de los incidentes más significativos de los últimos años en el país. Al cierre de esta nota, las autoridades no habían confirmado públicamente si la brecha fue efectivamente consumada ni el tipo de datos involucrados.

    Datos confirmados y qué falta verificar

    • Registros potencialmente comprometidos: 6 millones, según se informó.
    • Sistema afectado: Mi Argentina, plataforma de identidad digital del Estado nacional.
    • Estado de la investigación: en curso al momento de la publicación.
    • Exfiltración confirmada: sin confirmación oficial hasta el cierre de esta nota.
    • Tipo de datos expuestos: no especificado públicamente por el Gobierno.

    Qué dice la Ley 25.326 y el rol de la AAIP

    Argentina regula la protección de datos personales mediante la Ley 25.326, que obliga a los responsables de bases de datos —incluyendo organismos estatales— a implementar medidas de seguridad adecuadas para evitar el acceso no autorizado. La autoridad de control es la Agencia de Acceso a la Información Pública (AAIP), que tiene competencia para investigar incidentes de este tipo, aplicar sanciones y ordenar medidas correctivas. Si la brecha se confirma, el Estado actuaría en la doble condición de responsable del tratamiento y de parte investigada, un escenario que tensiona la independencia del proceso.

    La Ley 25.326 no establece un plazo taxativo de notificación a los titulares de datos en caso de brecha, a diferencia del RGPD europeo (72 horas a la autoridad) o de la LGPD brasileña, que fija plazos de comunicación al regulador y al titular. Esta brecha normativa es uno de los puntos que el proyecto de actualización de la ley de datos personales —en discusión en el Congreso argentino desde hace varios años— busca corregir. La ausencia de ese mecanismo deja a los 6 millones de potenciales afectados sin un canal claro ni un plazo garantizado de notificación.

    El próximo hito crítico es la confirmación oficial por parte del Gobierno sobre el alcance de la brecha y el inicio formal de actuaciones por parte de la AAIP, pasos que determinarán si el incidente activa el régimen sancionatorio de la Ley 25.326.

  • Brecha de 29CM es más grave de lo informado: 30.000 registros adicionales expuestos

    Brecha de 29CM es más grave de lo informado: 30.000 registros adicionales expuestos

    La brecha de datos en 29CM, plataforma de comercio electrónico surcoreana, es más extensa de lo que la empresa había reportado inicialmente: según informó el Seoul Economic Daily, se identificaron al menos 30.000 registros adicionales comprometidos que no formaban parte de la divulgación original.

    La información fue publicada el 28 de septiembre de 2025 por el Seoul Economic Daily, que señaló que el alcance real del incidente supera lo reconocido por la compañía en su comunicación inicial. No se confirmaron públicamente los tipos de datos involucrados en el volumen adicional, aunque según se informó el incidente afecta registros de usuarios de la plataforma. 29CM opera en el mercado coreano como una plataforma de moda y estilo de vida con base de usuarios significativa.

    Datos confirmados del incidente

    • Al menos 30.000 registros adicionales expuestos por encima de la cifra originalmente divulgada por 29CM.
    • El incidente fue reportado por el Seoul Economic Daily el 28 de septiembre de 2025.
    • La plataforma afectada opera en el segmento de comercio electrónico de moda y estilo de vida en Corea del Sur.
    • La empresa había realizado una divulgación previa que, según la fuente, subestimaba el alcance real de la brecha.

    Qué se sabe y qué falta confirmar

    Está confirmado que el volumen de registros comprometidos es mayor al declarado inicialmente por 29CM y que la discrepancia fue detectada y publicada por medios externos, no por la compañía. Lo que no está verificado públicamente incluye: la naturaleza exacta de los datos adicionales expuestos (si contienen información sensible como datos financieros, documentos de identidad o credenciales), el vector de ataque utilizado, y si la empresa notificó a las autoridades de protección de datos de Corea del Sur —la Personal Information Protection Commission (PIPC)— sobre el volumen revisado. Tampoco está confirmado si los 30.000 registros adicionales corresponden a usuarios distintos o a campos de datos adicionales de registros ya contabilizados.

    El caso es relevante en términos regulatorios porque la PIPC de Corea del Sur exige notificación a los afectados dentro de plazos estrictos cuando se produce una brecha de datos personales. Una subestimación del alcance en la notificación inicial podría constituir un incumplimiento adicional. Esta dinámica —brecha inicial seguida de una revelación ampliada— es un patrón conocido en incidentes de este tipo y representa un riesgo de cumplimiento específico para organizaciones con operaciones en regímenes de notificación obligatoria, como los que rigen en Brasil bajo la LGPD (artículo 48, con notificación a la ANPD en 72 horas para casos graves) o en Argentina bajo la Ley 25.326 y su Disposición 11/2006, que también impone la comunicación a la Agencia de Acceso a la Información Pública (AAIP). En México, la LFPDPPP establece obligaciones equivalentes ante el INAI. En todos estos marcos, la cifra notificada debe reflejar el alcance real conocido al momento de cada actualización.

    El próximo hito a seguir es la respuesta oficial de 29CM y de la PIPC confirmando si se emitió una notificación revisada a los usuarios y a la autoridad, lo que determinará si la empresa enfrenta sanciones por la divulgación incompleta inicial.

  • “AI Ready” es un eslogan vacío: lo que realmente importa es la calidad del dato

    “AI Ready” es un eslogan vacío: lo que realmente importa es la calidad del dato

    Declararse “AI ready” se convirtió en un ritual corporativo que rara vez sobrevive al primer audit de datos. La promesa de estar preparado para la inteligencia artificial se derrumba sistemáticamente en tres frentes concretos: calidad del dato, gobernanza operativa y confianza institucional en los sistemas de información.

    El término “AI ready” proliferó en presentaciones de directorio y comunicados de prensa durante los últimos dos años, pero en la práctica funciona más como señal de aspiración que como diagnóstico técnico. Cuando los equipos de datos intentan construir un pipeline de machine learning o desplegar un modelo de lenguaje sobre datos corporativos, el primer obstáculo no es el algoritmo: es el estado real del dato subyacente. Duplicados, registros incompletos, esquemas inconsistentes entre sistemas heredados y ausencia de un data owner identificable son los bloqueos más frecuentes que reportan los equipos de ingeniería en organizaciones que se autoproclaman preparadas.

    Calidad de datos: el prerequisito que nadie quiere medir

    La calidad del dato no es un atributo binario. El marco DAMA-DMBOK v2 distingue al menos seis dimensiones relevantes: completitud, consistencia, exactitud, oportunidad, unicidad y validez. Un modelo de IA entrenado o inferido sobre datos que fallan en dos o más de esas dimensiones produce outputs que amplifican los errores de origen, no los corrigen. El problema operativo para un CDO es que la mayoría de las organizaciones no tienen una línea de base medida para ninguna de esas dimensiones. Sin medición, la autoevaluación de “AI readiness” es subjetiva por definición.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), sitúa la gestión de calidad en las capabilities 5 y 6 de su modelo de madurez. Organizaciones que no han formalizado esas capabilities difícilmente pueden sostener que sus datos son aptos para alimentar sistemas de IA de manera confiable. La certificación CDMC no es un requisito universal, pero sus categorías sirven como checklist diagnóstico independiente del proveedor de nube o de plataforma.

    Gobernanza sin data stewards activos es decorativa

    El segundo vector de falla es la gobernanza. Muchas organizaciones tienen políticas documentadas, un comité de datos en papel y un catálogo de datos parcialmente poblado. Pero si no existe un data steward con responsabilidad operativa sobre cada dominio crítico —y con tiempo real asignado para esa función, no como tarea residual—, la gobernanza no escala cuando la IA la exige. Bob Seiner, referente en Non-Invasive Data Governance, señala que la gobernanza efectiva requiere asignar responsabilidad sobre el dato a quien ya toma decisiones sobre él, no crear una capa burocrática paralela. En contextos de IA, esa asignación se vuelve urgente porque los modelos consumen datos de múltiples dominios simultáneamente y el data lineage —la trazabilidad del dato desde su origen hasta el output del modelo— debe ser reconstruible para auditar resultados.

    En América Latina, este déficit tiene consecuencias regulatorias concretas. Los bancos colombianos sujetos a las circulares de la Superintendencia Financiera sobre gestión de riesgo operativo, y las entidades financieras brasileñas bajo la Resolução CMN 4.557, están obligadas a documentar los datos que alimentan modelos de decisión crediticia. Si el data lineage no existe o está incompleto, el cumplimiento regulatorio es formal pero no sustantivo. El Banco Central de Brasil ya incorporó en su agenda supervisora el uso de modelos algorítmicos, y la CNBV en México avanza en lineamientos similares para fintech. Declararse “AI ready” sin linaje documentado en esos contextos es un riesgo regulatorio concreto, no solo un problema de madurez interna.

    Confianza institucional: cuándo aplica y cuándo no

    El tercer componente —confianza— es el menos tangible pero el que más frecuentemente determina si un proyecto de IA llega a producción o muere en piloto. La confianza en este contexto tiene dos dimensiones: confianza técnica (¿el equipo de negocio cree que el dato es correcto?) y confianza institucional (¿los usuarios del sistema aceptarán las recomendaciones del modelo?). Ambas se construyen con transparencia sobre las limitaciones del dato, no con afirmaciones de exactitud que luego se contradicen en el uso diario.

    La confianza técnica se gana mostrando métricas de calidad accesibles para usuarios no técnicos —dashboards de completitud por dominio, tasas de error en validaciones, antigüedad promedio del dato—. La confianza institucional requiere que los data stewards y los responsables de negocio participen activamente en la validación de los datos de entrenamiento antes del despliegue del modelo, no después del primer incidente.

    Cuándo aplica “AI ready” y cuándo no

    El concepto tiene sentido como objetivo de roadmap, no como estado presente. Una organización puede afirmar que trabaja hacia la preparación para IA si tiene: (a) una línea de base medida de calidad del dato en al menos sus dominios críticos, (b) data stewards asignados con mandato formal sobre esos dominios, y (c) un catálogo de datos activo con linaje documentado para los procesos que serán automatizados. Sin esos tres elementos simultáneos, “AI ready” describe una intención, no una capacidad.

    No aplica —y el término resulta contraproducente— cuando se usa para justificar inversiones en infraestructura de IA antes de resolver los problemas de datos subyacentes. Comprar una plataforma de MLOps o un contrato empresarial con un proveedor de modelos fundacionales no resuelve la calidad del dato de origen. La secuencia importa: primero gobernanza, después arquitectura, después modelos.

    Tres verificaciones concretas antes del próximo comité de datos

    Para un CDO que necesita evaluar el estado real de su organización, tres preguntas operativas son más útiles que cualquier encuesta de madurez:

    • ¿Podés identificar, en menos de 48 horas, el data steward responsable de cada dominio de datos que alimentaría el primer caso de uso de IA priorizado?
    • ¿Tenés una métrica de completitud y exactitud medida en los últimos 90 días para esos dominios, con un benchmark definido como umbral de aceptación?
    • ¿El linaje de datos desde el sistema fuente hasta el punto de consumo del modelo está documentado y es auditable por un tercero —regulador, auditor externo o equipo de riesgo interno?

    Si alguna de las tres respuestas es “no” o “parcialmente”, el roadmap de IA necesita un paso previo de gobernanza, no un paso adicional de tecnología. El DAMA-DMBOK y el CDMC del EDM Council ofrecen marcos de referencia públicos para estructurar ese diagnóstico sin depender de consultoras externas.

    Para profundizar en los estándares de referencia: el DAMA-DMBOK v2 está disponible en dama.org y el marco CDMC del EDM Council puede consultarse en edmcouncil.org; ambos son el punto de partida obligado para cualquier diagnóstico serio de preparación para la IA.

  • Databricks CustomerLake: gobernanza de datos de clientes en la banca

    Databricks CustomerLake: gobernanza de datos de clientes en la banca

    Databricks anunció CustomerLake, una solución diseñada para que los bancos centralicen y gobiernen los datos de sus clientes dentro de su propio entorno de datos, sin ceder el control a plataformas de CRM externas. La propuesta reactiva un debate que el sector financiero nunca cerró del todo: quién es el dueño real del dato del cliente y quién responde cuando ese dato falla.

    CustomerLake parte de una premisa operativa concreta: los bancos acumulan décadas de datos transaccionales, de comportamiento y de contacto dispersos en silos —core bancario, CRM, canales digitales, call center— sin un modelo de gobernanza que los unifique bajo un data owner identificable. La propuesta de Databricks es construir esa capa de unificación sobre el lakehouse propio de la institución, manteniendo los datos bajo la jurisdicción y el control de la entidad financiera, no del proveedor de CX.

    Qué hace CustomerLake y por qué importa en banca

    La arquitectura de CustomerLake, según se informó, combina capacidades de ingesta unificada, resolución de identidad de clientes (identity resolution) y perfilado en tiempo real, todo dentro del entorno de datos del banco. El punto de diferenciación frente a soluciones de Customer Data Platform (CDP) tradicionales es que el dato nunca abandona el lakehouse de la institución: no hay sincronización hacia un SaaS de terceros que almacene una copia del perfil del cliente. Para los equipos de gobernanza de datos, eso cambia el mapa de riesgo de forma sustancial: el data lineage —la trazabilidad del dato desde su origen hasta su uso en una campaña o en una decisión crediticia— queda bajo control interno, auditable con las herramientas que ya tiene el banco.

    Desde la perspectiva del DAMA-DMBOK, esta arquitectura aborda directamente dos capability areas críticas: Data Integration & Interoperability y Data Security. La resolución de identidad centralizada elimina duplicados y perfiles fragmentados, que son una de las causas raíz más frecuentes de problemas de calidad en datos de clientes bancarios. Un perfil duplicado no es solo un problema de marketing; en banca es un riesgo de cumplimiento: puede implicar KYC incompleto, alertas de prevención de lavado mal asignadas, o comunicaciones regulatorias enviadas a la dirección equivocada.

    Cuándo aplica CustomerLake y cuándo no

    CustomerLake aplica cuando el banco ya opera sobre Databricks o está en proceso de consolidar su arquitectura de datos en un lakehouse. No es una solución autónoma: presupone que existe —o se está construyendo— un Data Governance Council con capacidad de definir data domains, asignar data stewards por dominio (clientes, productos, riesgo) y mantener un catálogo activo. Si la institución no tiene ese andamiaje de gobernanza, CustomerLake entrega infraestructura técnica sin el modelo operativo que la hace funcionar. La herramienta resuelve el “dónde vive el dato”; no resuelve el “quién responde por él”.

    Tampoco es la respuesta correcta para bancos medianos o cooperativas de crédito que no tienen equipo de ingeniería de datos propio. En esos casos, el costo operativo de mantener un lakehouse gobernado supera los beneficios de tener el dato in-house frente a una CDP SaaS con controles contractuales sólidos.

    El flanco regulatorio en Argentina, Brasil y México

    Para la banca latinoamericana, la propuesta de CustomerLake no es solo una decisión de arquitectura: es una decisión regulatoria. En Argentina, las entidades financieras supervisadas por el BCRA deben cumplir la Comunicación A 7724 y sus actualizaciones sobre gestión de riesgo tecnológico, que exigen trazabilidad sobre los sistemas que procesan datos de clientes. Transferir datos de clientes a un SaaS offshore implica, en muchos casos, informar a la autoridad de control y cumplir con los requisitos de localización o de acuerdo de transferencia que establece la Ley 25.326 y su decreto reglamentario. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige que el controlador —el banco— pueda demostrar una base legal para cada tratamiento y responder ante la ANPD en caso de incidente; si el dato está en manos de un procesador externo sin contrato de procesamiento adecuado, esa demostración se complica. En México, la LFPDPPP y la regulación sectorial de la CNBV imponen obligaciones similares sobre el responsable del tratamiento. Mantener el dato dentro del entorno propio simplifica esa cadena de accountability, aunque no la elimina: el banco sigue siendo responsable de lo que hace con el dato, independientemente de dónde lo almacene.

    Lo que un CDO bancario necesita definir antes de implementar

    Antes de evaluar CustomerLake como solución, un Chief Data Officer del sector financiero debería tener respuestas operativas a tres preguntas: primero, ¿existe un data domain “cliente” formalmente definido, con un data steward asignado y métricas de calidad activas? Segundo, ¿el catálogo de datos corporativo registra hoy qué sistemas son fuente de verdad (system of record) para cada atributo del perfil del cliente —nombre, dirección, score de riesgo, historial de contacto? Tercero, ¿el equipo legal tiene mapeados los flujos de datos de clientes hacia terceros, con los contratos de procesamiento de datos actualizados según la regulación local? Si alguna de esas tres respuestas es “no” o “parcialmente”, la prioridad no es la herramienta: es el modelo de gobernanza que la herramienta va a ejecutar. CustomerLake puede acelerar la implementación técnica, pero el diseño del data ownership es una decisión institucional que ningún proveedor puede tomar por el banco.

    La especificación técnica de CustomerLake está disponible en la documentación oficial de Databricks; los marcos de referencia para el diseño del modelo de gobernanza pueden consultarse en el DAMA-DMBOK (segunda edición) y en el CDMC del EDM Council, que incluye controles específicos para datos de clientes en industrias reguladas.

  • OpenAI lanza Dots: qué preguntas de gobernanza de datos plantea

    OpenAI lanza Dots: qué preguntas de gobernanza de datos plantea

    OpenAI presentó Dots, un sistema diseñado para que los modelos de inteligencia artificial retengan contexto personalizado entre sesiones. La capacidad de persistir información sobre usuarios individuales abre interrogantes concretos sobre propiedad del dato, clasificación, retención y auditoría que los equipos de gobernanza de datos no pueden diferir.

    Dots funciona como una capa de memoria estructurada: en lugar de que cada conversación comience desde cero, el modelo extrae y almacena fragmentos de contexto —preferencias, instrucciones recurrentes, datos de comportamiento— para recuperarlos en interacciones futuras. Desde la perspectiva de un Chief Data Officer, esto no es una mejora de experiencia de usuario sino un nuevo repositorio de datos con ciclo de vida propio, sin que la mayoría de las organizaciones hayan definido quién es el data steward responsable de ese almacén ni cómo se integra al catálogo corporativo.

    Qué tipo de dato genera Dots y por qué importa clasificarlo hoy

    El contenido que Dots retiene puede incluir desde preferencias operativas hasta información inferida sobre comportamientos o roles organizacionales. Según el DAMA-DMBOK, la clasificación es el primer control del ciclo de vida del dato: sin saber qué categoría ocupa un fragmento de memoria persistida, no es posible aplicar controles de acceso, políticas de retención ni reglas de eliminación. Si un empleado le indica a un agente de IA cuál es su área de negocio, su nivel jerárquico o las herramientas que usa, esa información inferida puede calificar como dato personal bajo la Ley 25.326 en Argentina, la LGPD brasileña o la LFPDPPP mexicana, independientemente de que el almacenamiento ocurra en infraestructura de OpenAI.

    La distinción no es trivial. Bajo la LGPD (Lei 13.709/2018), el controlador —la empresa que despliega la herramienta— es responsable de garantizar que el operador (en este caso, OpenAI como proveedor) trate los datos conforme a las instrucciones contractuales. Si Dots almacena datos de colaboradores sin que exista una cláusula de data processing agreement que contemple específicamente la retención de memoria persistente, la empresa está operando fuera del marco del contrato de tratamiento.

    Data lineage y el problema del contexto opaco

    Uno de los desafíos de gobernanza más inmediatos que presenta Dots es el data lineage, es decir, la trazabilidad del origen y transformación de cada fragmento de dato. En un flujo tradicional, un dato entra por un sistema fuente, se transforma en pipelines auditables y llega a un destino documentado. Con memoria persistente en un modelo de lenguaje, la extracción del contexto es semideterminista: el modelo decide qué retener y qué descartar según criterios que no son completamente transparentes para el operador empresarial. Esto rompe la cadena de linaje y dificulta responder ante una solicitud de acceso o supresión bajo cualquier régimen de derechos ARCO.

    El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica la capacidad de rastrear datos personales a través de sistemas de terceros como uno de los requerimientos centrales para organizaciones que operan en la nube. Los bancos colombianos sujetos a la Circular Externa 029 de la SFC, o las entidades financieras argentinas bajo la Comunicación A 8073 del BCRA, ya deben demostrar trazabilidad de datos sensibles en proveedores cloud. Un sistema de memoria de IA no certificado bajo esos esquemas representa un gap de control documentable.

    Cuándo aplica el riesgo de gobernanza y cuándo no

    No toda implementación de Dots genera el mismo nivel de exposición. El riesgo es alto cuando: (1) los usuarios finales son empleados que interactúan con información corporativa confidencial o datos de clientes; (2) la organización opera en sectores regulados —salud, finanzas, educación— donde la retención no autorizada tiene consecuencias específicas; o (3) no existe un data processing agreement actualizado con OpenAI que cubra explícitamente la funcionalidad de memoria persistente. El riesgo es bajo o gestionable cuando el uso se limita a entornos sandbox sin datos reales, cuando se activa la opción de deshabilitar la memoria (si OpenAI la provee a nivel enterprise), o cuando el flujo de datos ya está cubierto por un DPA vigente y revisado por el equipo legal.

    La distinción importa porque la respuesta operativa es diferente: en el primer escenario, la acción es bloquear o restringir el despliegue hasta cerrar los gaps contractuales y de clasificación; en el segundo, alcanza con documentar el análisis de riesgo en el registro de actividades de tratamiento que exigen tanto el artículo 31 del GDPR como sus equivalentes en LGPD y Ley 25.326.

    Tres acciones concretas para equipos de gobernanza ante el lanzamiento de Dots

    • Revisar el inventario de sistemas de IA corporativos e identificar cuáles utilizan o planean utilizar OpenAI con funcionalidades de memoria activa; asignar un data steward responsable para cada caso.
    • Actualizar o solicitar la actualización del data processing agreement con OpenAI para que cubra explícitamente la retención de contexto, los plazos de conservación y los mecanismos de supresión, alineados con los requerimientos de la regulación local aplicable.
    • Incorporar en el catálogo de datos corporativo una categoría para “datos de memoria de IA” con clasificación, nivel de sensibilidad y política de retención definida, tal como se haría con cualquier otra fuente de datos de terceros.

    La documentación técnica de Dots y los términos de servicio empresariales de OpenAI son el punto de partida obligado para cualquier análisis de brecha; el equipo de gobernanza no puede subcontratar esa lectura al área legal sin haber definido primero qué datos están en juego.

  • Calidad de datos: el requisito no negociable para que la IA funcione

    Calidad de datos: el requisito no negociable para que la IA funcione

    Los modelos de inteligencia artificial no fallan solo por arquitecturas deficientes: fallan porque los datos que los alimentan son inconsistentes, incompletos o simplemente incorrectos. La calidad del dato ha dejado de ser un problema de backoffice para convertirse en un requisito de ingeniería de IA tan crítico como la capacidad de cómputo.

    Durante años, la calidad de datos fue un ítem postergado en la agenda corporativa: algo que “había que mejorar” pero que rara vez bloqueaba proyectos. La irrupción de sistemas de IA en producción cambió esa dinámica de forma abrupta. Un modelo de lenguaje entrenado con registros duplicados, un sistema de recomendación alimentado con atributos mal clasificados, o un motor de detección de fraude que consume datos sin linaje verificable producen resultados que no solo son incorrectos, sino que pueden ser jurídicamente problemáticos en contextos regulados.

    Qué significa “calidad de datos” en un pipeline de IA

    En el marco del DAMA-DMBOK, la calidad de datos se descompone en al menos seis dimensiones: completitud, consistencia, exactitud, oportunidad, unicidad y validez. Para un pipeline de IA, cada una de esas dimensiones tiene consecuencias directas sobre el comportamiento del modelo. Un dataset con baja completitud introduce sesgos sistemáticos hacia los segmentos mejor representados. La falta de consistencia entre fuentes provoca que el modelo aprenda contradicciones como si fueran patrones reales. La ausencia de unicidad —registros duplicados— infla artificialmente la frecuencia de ciertos eventos y distorsiona las distribuciones de entrenamiento. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), clasifica la gestión de calidad como una capability de nivel 2, es decir, prerequisito para cualquier uso avanzado de datos, incluida la IA.

    Data lineage: sin trazabilidad, no hay auditabilidad del modelo

    El data lineage —la capacidad de rastrear el origen, las transformaciones y el destino de cada dato a lo largo de su ciclo de vida— es el componente de gobernanza que más directamente habilita la auditabilidad de sistemas de IA. Sin lineaje documentado, es imposible responder preguntas regulatorias básicas: ¿con qué datos fue entrenado este modelo?, ¿esos datos eran representativos de la población objetivo?, ¿existía algún sesgo de selección en la fuente? En jurisdicciones donde los sistemas de IA de alto riesgo deben poder explicar sus decisiones —como establece el AI Act de la Unión Europea en su artículo 13— el lineaje deja de ser una buena práctica y se convierte en evidencia jurídica.

    En América Latina, el vínculo entre lineaje y cumplimiento normativo es menos explícito en los textos legales, pero ya está siendo requerido de forma implícita. El Banco Central de Brasil, por ejemplo, exige a las instituciones financieras supervisadas que demuestren la idoneidad de los modelos de riesgo crediticio que usan en sus decisiones automatizadas, lo que en la práctica demanda tener el linaje de los datos de entrenamiento disponible para inspección. En Argentina, la Comunicación A 8073 del BCRA sobre gestión de riesgo operacional establece controles sobre los modelos utilizados en procesos críticos, con implicancias directas sobre la documentación de los datos que los alimentan.

    Cuándo aplica gobernanza de datos para IA — y cuándo no

    La gobernanza de datos orientada a IA aplica con urgencia cuando una organización está entrenando o ajustando (fine-tuning) modelos propios, cuando consume APIs de modelos externos con datos internos sensibles, o cuando los outputs de IA alimentan decisiones automatizadas sobre personas (crédito, salud, contratación, seguridad). No aplica —o aplica con menor criticidad— cuando el uso de IA es puramente exploratorio, sin datos de producción, y sin impacto en procesos de negocio ni en derechos de terceros. El error frecuente es tratar ambos escenarios con el mismo nivel de exigencia, lo que genera fatiga de compliance sin reducir riesgo real.

    El rol del data steward en proyectos de IA

    Bob Seiner, referente en Non-Invasive Data Governance, sostiene que el data steward —el responsable de un dominio de datos dentro de la organización— es la figura que debe certificar la aptitud de un dataset para un caso de uso específico antes de que ese dataset ingrese a un pipeline de entrenamiento. Este rol, que en muchas organizaciones latinoamericanas todavía se ejerce de forma informal o no existe formalmente, se vuelve crítico cuando los modelos de IA empiezan a escalar. Sin un steward que valide la calidad, la relevancia y los permisos de uso de los datos, el equipo de datos o de ingeniería termina tomando decisiones de gobernanza para las que no tiene mandato ni contexto de negocio.

    La adopción de este rol en la región es desigual. Empresas de servicios financieros en México, Colombia y Brasil con exposición a reguladores internacionales (BIS, FSB) ya tienen estructuras de stewardship activas. En sectores como retail, salud privada y gobierno, el rol existe en el organigrama pero raramente tiene atribuciones formales sobre los datasets que alimentan sistemas de IA.

    Tres controles mínimos antes de poner datos en un modelo

    Las organizaciones que empiezan a formalizar su gobernanza de datos para IA no necesitan implementar un framework completo desde el día uno. Tres controles concretos reducen el riesgo de forma inmediata:

    • Perfil de calidad documentado: completitud, duplicados y distribución de valores nulos por campo, generado antes de cada ciclo de entrenamiento o actualización del modelo.
    • Registro de origen: para cada dataset en producción, un registro legible por humanos que indique fuente primaria, fecha de extracción, transformaciones aplicadas y responsable de aprobación.
    • Control de acceso por sensibilidad: clasificación del dataset según si contiene datos personales, datos financieros regulados o datos de categoría especial, con acceso restringido al equipo de IA según esa clasificación.

    Estos tres controles se alinean con las capabilities de nivel básico del CDMC del EDM Council y son auditables por cualquier regulador que solicite evidencia de diligencia debida en el uso de datos para IA.

    Para profundizar en los estándares aplicables, el DAMA-DMBOK (segunda edición) y el marco CDMC del EDM Council son los documentos de referencia más completos disponibles para equipos de gobernanza que trabajan en contextos de IA. Ambos están disponibles en sus respectivos sitios oficiales.