DataTrends LATAM

Etiqueta: Ai Privacy

  • El hackeo a Hugging Face y la paradoja de la seguridad en IA

    El hackeo a Hugging Face y la paradoja de la seguridad en IA

    Semanas después del incidente en OpenAI, Hugging Face sufrió un hackeo que expuso datos de la plataforma. La conclusión de Heidy Khlaaf, investigadora del AI Now Institute, es contundente: ingeniería de seguridad convencional habría sido suficiente para detenerlo. El problema no fue la IA —fue la gestión humana de los controles.

    El incidente en Hugging Face volvió a instalar una pregunta incómoda en la industria de la inteligencia artificial: ¿cuánto del riesgo que rodea a los sistemas de IA es realmente un problema de la tecnología, y cuánto es el resultado de prácticas de seguridad deficientes en las organizaciones que los construyen y hospedan? Según Khlaaf, la respuesta inclina la balanza hacia lo segundo. La investigadora del AI Now Institute sostuvo que “ingeniería de seguridad ordinaria habría detenido esto antes de llegar a los datos de Hugging Face”, según se informó desde el instituto.

    Qué falló en Hugging Face: controles, no algoritmos

    Hugging Face es una de las plataformas centrales del ecosistema de IA abierta: aloja modelos, datasets y aplicaciones que utilizan millones de desarrolladores en todo el mundo, incluyendo equipos de investigación y empresas en América Latina. Un compromiso en ese entorno no solo afecta datos propios de la plataforma —también puede afectar a los usuarios que confían sus modelos y datasets a esa infraestructura. La naturaleza exacta de los datos comprometidos no fue detallada con precisión en la declaración del AI Now Institute, más allá de la referencia general al alcance del acceso no autorizado.

    Lo que el caso deja en evidencia, según el análisis de Khlaaf, es que los vectores de ataque que afectaron a Hugging Face no eran exóticos ni requerían explotar vulnerabilidades propias de los modelos de lenguaje o de la infraestructura de IA. Se trató, según se informó, de fallas en controles de seguridad estándar —el tipo de controles que cualquier organización que maneja datos sensibles debería tener implementados independientemente de si trabaja con IA o no. Autenticación, segmentación de accesos, monitoreo de credenciales comprometidas: herramientas de seguridad conocidas y documentadas desde hace años.

    El patrón que conecta OpenAI y Hugging Face

    El hackeo a Hugging Face ocurrió semanas después de que OpenAI también reportara un incidente de seguridad. Que dos de los actores más visibles del sector de IA enfrenten brechas en un período corto no es una coincidencia operativa —es una señal de que la aceleración del desarrollo de modelos no siempre viene acompañada de una madurez equivalente en las prácticas de protección de la infraestructura. Las organizaciones que mueven velocidad de producto rara vez acompasan esa velocidad con revisiones de superficie de ataque, gestión de identidades o clasificación de activos.

    Desde la perspectiva del AI Now Institute, un think tank que viene documentando los riesgos sociales y legales de la IA, la lectura del incidente es en realidad optimista en un sentido técnico: si los controles humanos convencionales son suficientes para prevenir este tipo de brechas, entonces el problema es de governance y priorización, no de una amenaza tecnológicamente irresoluble. Los humanos pueden mantener a la IA bajo control —pero solo si aplican los mecanismos que ya existen.

    Cuándo aplica esta lectura / cuándo NO

    El argumento de Khlaaf aplica directamente a incidentes donde el vector de ataque pasa por la infraestructura que rodea a los sistemas de IA: APIs expuestas, credenciales filtradas, permisos excesivos, falta de segmentación. No aplica —o aplica con matices importantes— a riesgos emergentes propios de los modelos en sí: ataques de prompt injection, exfiltración de datos de entrenamiento vía inferencia, o manipulación de outputs. Esos requieren controles específicos que la seguridad convencional no cubre por completo. La distinción importa para no simplificar en exceso: decir que “los humanos pueden controlar la IA” con base en este caso no equivale a decir que todos los riesgos de IA son gestionables con herramientas de seguridad del año 2010.

    El ángulo regulatorio: qué exigen LGPD, Ley 25.326 y el AI Act ante un hackeo a un proveedor de IA

    Para organizaciones latinoamericanas que usan Hugging Face como infraestructura —para alojar modelos propios, procesar datasets que incluyen datos personales, o integrar APIs en productos— un incidente de este tipo activa obligaciones concretas. En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que el controlador notifique a la Autoridade Nacional de Proteção de Dados (ANPD) y a los titulares afectados ante una brecha que pueda generar riesgos relevantes, en un plazo que la ANPD ha precisado en resoluciones posteriores a la entrada en vigor de la ley. En Argentina, la Ley 25.326 y las disposiciones de la Agencia de Acceso a la Información Pública (AAIP) también contemplan obligaciones de notificación ante incidentes de seguridad que comprometan datos personales tratados por terceros bajo contrato. En México, el INAI tiene competencia para revisar si los encargados del tratamiento —rol que cumpliría Hugging Face para quienes le delegan procesamiento— contaban con medidas de seguridad adecuadas conforme a la LFPDPPP.

    El caso también es relevante bajo el AI Act europeo, que clasifica ciertos sistemas de IA como de alto riesgo y exige que los proveedores mantengan controles de seguridad específicos a lo largo del ciclo de vida del sistema. Si Hugging Face es parte de la cadena de suministro de un sistema de IA de alto riesgo desplegado en la Unión Europea, las obligaciones de reporte y remediación se amplían considerablemente.

    El caso Hugging Face no prueba que la IA sea segura —prueba que la seguridad de la IA depende de decisiones organizacionales que los equipos técnicos y legales ya tienen capacidad de tomar. La pregunta es si lo priorizan antes del próximo incidente.

  • Agentes de IA: recuperar hechos, no definirlos

    Agentes de IA: recuperar hechos, no definirlos

    Los agentes de inteligencia artificial no deben ser la fuente de verdad de una organización: deben consultar esa fuente, no reemplazarla. La distinción parece obvia hasta que un agente empieza a responder preguntas de negocio con datos que nadie auditó, en pipelines que nadie gobierna.

    Cuando una organización despliega agentes de IA para automatizar decisiones —desde aprobación de créditos hasta reportes regulatorios—, uno de los riesgos más subestimados no es técnico sino semántico: el agente puede “definir” un hecho porque ningún sistema autoritativo le indicó cuál es la versión correcta. Si no existe un catálogo de datos activo, un ownership claro por dominio y reglas de calidad documentadas, el agente opera en el vacío y llena ese vacío con inferencias. Eso no es inteligencia artificial; es ambigüedad automatizada a escala.

    Qué significa que un agente “defina” un hecho

    En arquitecturas de recuperación aumentada (RAG) o en agentes con acceso a múltiples fuentes, el sistema elige qué dato usar cuando encuentra versiones contradictorias. Si no hay una capa de gobernanza que declare cuál sistema es el registro maestro —el sistema of record— para cada concepto crítico de negocio (cliente, producto, saldo, riesgo), el agente toma esa decisión de facto. Lo hace de forma opaca, no documentada y, en muchos casos, no reproducible. El problema no es el modelo de lenguaje en sí: es la ausencia del marco de datos que debería preceder a cualquier despliegue agentico.

    Cuándo aplica / cuándo NO

    Este riesgo aplica en cualquier flujo donde el agente accede a más de una fuente de datos para construir una respuesta o tomar una acción: consultas sobre clientes en CRM + ERP, generación de reportes desde múltiples data marts, o automatización de procesos con datos de terceros. No aplica —o aplica con menor urgencia— cuando el agente opera sobre una única fuente de datos bien delimitada, con esquema fijo y ownership documentado. En ese escenario reducido, el agente efectivamente “recupera” sin riesgo de “definir”. El problema escala con la complejidad del ecosistema de datos.

    El DAMA-DMBOK y la capa que falta antes del agente

    El marco DAMA-DMBOK identifica la gestión de datos maestros (MDM, Master Data Management) y la gestión de datos de referencia como disciplinas previas a cualquier consumo analítico o automatizado. Un agente de IA es, a efectos prácticos, un consumidor de datos de alta velocidad y baja supervisión humana. Si los datos maestros de cliente no tienen un data steward asignado, si el glosario de negocio no está publicado y si el data lineage no traza de dónde viene cada atributo, el agente heredará todos esos problemas —y los amplificará, porque operará sin fricción humana correctiva. La secuencia correcta es: definir el dato canónico → documentar su linaje → habilitar el acceso al agente, no al revés.

    Tres controles concretos antes de escalar agentes en producción

    • Designar un data steward por dominio crítico (cliente, producto, riesgo, transacción) con autoridad explícita para declarar el sistema of record. Sin ese ownership, el agente no tiene a quién consultar cuando hay conflicto entre fuentes.
    • Publicar un glosario de negocio vinculado al catálogo de datos. Cada concepto que el agente puede consultar debe tener una definición aprobada, una fuente autoritativa y una fecha de revisión. Herramientas como Collibra, Alation o Apache Atlas permiten implementarlo; lo que no puede delegarse en la herramienta es la decisión sobre qué definición es la correcta.
    • Implementar trazabilidad (data lineage) a nivel de atributo en los datasets que alimentan al agente. Si el agente devuelve un resultado que luego se cuestiona, el equipo de gobernanza debe poder responder en minutos de dónde vino ese dato, quién lo transformó y cuándo.

    Bancos y aseguradoras en LATAM ya enfrentan esta tensión

    En Argentina, las entidades financieras bajo supervisión del BCRA deben garantizar la integridad de la información reportada —la Comunicación A 7724 y sus actualizaciones establecen controles sobre la calidad y consistencia de los datos prudenciales—. Si un agente de IA interviene en la generación de esos reportes sin una capa de MDM robusta, la entidad expone no solo la calidad del reporte sino su trazabilidad ante el regulador. En Brasil, la resolución BCB 85/2021 que regula el Open Finance impone estándares similares sobre consistencia de datos compartidos entre instituciones. En ambos casos, el regulador espera datos trazables y auditables; un agente sin gobernanza de datos subyacente no puede garantizar ninguna de las dos condiciones.

    En México, el marco de la CNBV sobre gestión de riesgos tecnológicos también demanda controles sobre la calidad e integridad de los datos utilizados en sistemas de decisión automatizada. Los equipos de datos que estén evaluando agentes de IA para procesos regulados deben mapear primero qué datos consume el agente, qué define como “fuente verdadera” cuando hay conflicto y quién es responsable si esa definición es incorrecta. Si ninguna de esas preguntas tiene respuesta documentada, el agente no está listo para producción regulada.

    Para leer los principios de gestión de datos maestros y referencia en profundidad, el DAMA-DMBOK 2.0 (capítulos 9 y 10) y el framework CDMC del EDM Council son los puntos de partida más rigurosos disponibles para equipos que necesitan construir esa capa antes de escalar agentes.

  • Bioarmas con IA: por qué el sector biotecnológico no puede esperar más

    Bioarmas con IA: por qué el sector biotecnológico no puede esperar más

    Los CEOs de las principales compañías de inteligencia artificial están advirtiendo públicamente que sus propias tecnologías representan riesgos existenciales, y el sector biotecnológico es el terreno donde esa advertencia se vuelve más concreta: la posibilidad de que modelos de lenguaje avanzados reduzcan drásticamente las barreras técnicas para el diseño de agentes biológicos peligrosos es hoy un debate regulatorio urgente en múltiples jurisdicciones.

    El cruce entre inteligencia artificial y biología sintética lleva años siendo señalado por investigadores de bioseguridad como uno de los vectores de riesgo más subestimados del desarrollo tecnológico actual. Lo que cambió en las últimas semanas es la visibilidad del debate: líderes de Anthropic y OpenAI reconocieron abiertamente, en declaraciones públicas, que los sistemas que están construyendo podrían acelerar capacidades que hoy requieren años de formación especializada. Dario Amodei, CEO de Anthropic, argumentó que el ritmo de avance debería moderarse precisamente por estos riesgos. Sam Altman, CEO de OpenAI, coincidió en la necesidad de calibrar el ritmo, según se informó.

    Qué convierte a la IA en un multiplicador de riesgo biológico

    El problema central no es que la inteligencia artificial “sepa” cómo fabricar un agente patógeno. El problema es que puede reducir dramáticamente el tiempo y la expertise requeridos para que un actor malicioso llegue a una capacidad operativa. Los modelos de lenguaje de gran escala entrenados con literatura científica pueden responder preguntas de síntesis, sugerir rutas metabólicas alternativas o ayudar a optimizar procesos que antes requerían equipos especializados durante meses. En bioseguridad, esa compresión temporal es crítica. Investigadores del área denominan este fenómeno “uplift”: la capacidad de un sistema de IA de elevar el nivel técnico efectivo de un usuario sin formación avanzada.

    El marco regulatorio existente tiene vacíos que ninguna ley de IA cubre todavía

    La Unión Europea avanzó con el AI Act, que clasifica ciertos usos de IA como de riesgo inaceptable, pero su articulación con normativas de bioseguridad existentes —como la Convención sobre Armas Biológicas de 1972— es prácticamente nula. En Estados Unidos, el Decreto Ejecutivo sobre IA de 2023 incluyó una sección específica sobre riesgos biológicos y ordenó evaluaciones de bioseguridad para modelos de gran escala, pero la administración posterior no consolidó ese mandato en regulación duradera. El resultado es un vacío: las leyes de bioseguridad existentes regulan laboratorios y agentes patógenos físicos, no modelos de lenguaje que pueden asistir en el diseño de esos agentes desde cualquier dispositivo conectado.

    En América Latina, el panorama es aún más fragmentado. Brasil cuenta con la Lei de Biossegurança (Ley 11.105/2005) y organismos como la CTNBio para la regulación de organismos genéticamente modificados, pero ningún instrumento contempla explícitamente el rol de sistemas de IA en el acceso a información de doble uso. México, Argentina y Colombia aún no han producido marcos normativos que crucen inteligencia artificial con riesgo biológico. En la medida en que los modelos de IA se vuelven más accesibles en la región —con despliegues locales de herramientas como Copilot, Gemini y Claude—, esa brecha regulatoria se amplía.

    Cuándo aplica la preocupación y cuándo no

    Es importante delimitar el alcance del riesgo para evitar tanto la minimización como el pánico regulatorio contraproducente. El riesgo de “uplift” biológico aplica cuando un modelo tiene acceso a literatura científica sin filtros de uso dual, cuando puede responder preguntas técnicas específicas sobre síntesis o modificación de organismos, y cuando opera sin mecanismos de auditoría sobre las consultas realizadas. No aplica de manera equivalente a modelos con restricciones de dominio, sistemas con capas de supervisión humana en tiempo real, o usos de IA en biología orientados al diagnóstico clínico o la investigación de vacunas, donde el beneficio supera ampliamente el riesgo. La distinción es técnica y requiere evaluación caso por caso, no prohibiciones genéricas.

    Lo que el sector biotecnológico debe hacer antes de que lo regule otro

    La advertencia más relevante del debate que protagonizaron Amodei y Altman no es que la IA sea intrínsecamente peligrosa: es que la autorregulación del sector tecnológico ya llegó a sus límites visibles. Para las empresas biotecnológicas —laboratorios de investigación, CROs, startups de biología sintética—, eso significa que el tiempo de esperar una regulación externa antes de implementar controles internos se está agotando. Algunas acciones concretas que organizaciones del sector ya están discutiendo incluyen: políticas de uso aceptable de herramientas de IA generativa en investigación, protocolos de revisión para consultas a modelos externos sobre compuestos de doble uso, y participación activa en iniciativas como el Centro de Bioseguridad Johns Hopkins o el Nuclear Threat Initiative (NTI) Bio, que trabajan marcos de gobernanza específicos para este cruce tecnológico.

    Para quienes diseñan políticas de inteligencia artificial en América Latina, la pregunta ya no es si este riesgo es real: es qué instrumentos concretos —y en qué plazo— pueden articular los marcos de IA con los de bioseguridad antes de que ocurra un incidente que fuerce la agenda.

  • Por qué los líderes de datos no confían aún en que la IA actúe sola

    Por qué los líderes de datos no confían aún en que la IA actúe sola

    En un evento reciente organizado por Ataccama con líderes senior de datos de grandes empresas, ninguno de los participantes se mostró dispuesto a permitir que los agentes de inteligencia artificial operen con autonomía plena. La presión para escalar IA a velocidad de máquina existe, pero el freno está puesto deliberadamente —y los motivos son de gobernanza, no de tecnología.

    La distinción importa. Cuando los responsables de datos frenan la autonomía de los agentes de IA, no es porque los sistemas no funcionen: es porque las estructuras de ownership, trazabilidad y control de calidad del dato no están lo suficientemente maduras como para delegar decisiones consecuentes a un sistema automatizado. Dicho de otro modo, el problema no está en el modelo; está en los cimientos de datos sobre los que ese modelo opera.

    Autonomía de agentes de IA: qué implica ejecutar “a velocidad de máquina”

    Un agente de IA autónomo no solo recomienda una acción: la ejecuta. Puede modificar registros, desencadenar flujos de trabajo, interactuar con sistemas externos o tomar decisiones de negocio sin intervención humana en cada paso. En entornos donde el dato es insumo crítico —bancos, aseguradoras, sistemas de salud, retailers con operaciones de cadena de suministro complejas— esa capacidad de actuación sin supervisión directa representa un riesgo operativo que los líderes de datos evalúan con extrema cautela, según se desprende del encuentro organizado por Ataccama. El marco DAMA-DMBOK ubica esta tensión exactamente en la intersección entre Data Quality Management y Data Architecture: si el dato de entrada no tiene calidad certificada y ownership claro, ningún nivel de sofisticación del modelo mitiga el riesgo de decisión errada.

    Cinco señales de alerta que frenan la ejecución autónoma

    Del evento participado por líderes senior de datos se pueden extraer, según se informó, al menos cinco vectores de preocupación que explican la resistencia a la autonomía total de los agentes:

    • Ausencia de data lineage confiable: si no es posible trazar con certeza el origen y las transformaciones de un dato, no es posible auditar la decisión del agente que lo consumió.
    • Ownership difuso: sin un data steward claramente asignado a cada dominio de dato, no hay un humano responsable de validar que el input del agente es correcto antes de la ejecución.
    • Catálogos de datos incompletos: los agentes necesitan contexto semántico del dato para operar bien; un catálogo desactualizado es un vector de error silencioso.
    • Falta de métricas de calidad en tiempo real: la autonomía requiere que el agente sepa, en el momento de actuar, si el dato que consume cumple los umbrales de calidad definidos.
    • Ausencia de circuit breakers de gobernanza: no existe aún, en la mayoría de las organizaciones, un mecanismo formal que interrumpa la ejecución del agente cuando detecta anomalías en el dato de entrada.

    Cuándo aplica la supervisión humana y cuándo no es suficiente con políticas

    La supervisión humana en el loop de un agente de IA no es lo mismo que tener una política que diga “los humanos aprueban las decisiones”. Aplicar supervisión real implica que el agente genera una recomendación, expone su razonamiento y el data steward o el responsable de dominio puede rechazarla con evidencia antes de que se ejecute. Este modelo —conocido como human-in-the-loop (HITL)— es el que los líderes consultados por Ataccama prefieren para los casos de uso de alto impacto. El modelo human-on-the-loop (HOTL), donde el agente actúa y el humano puede intervenir a posteriori, es aceptable solo cuando el costo de reversión es bajo y el dato de entrada tiene calidad certificada. La autonomía total —sin supervisión activa— no encontró defensores en el evento.

    El contexto regulatorio en América Latina presiona en la misma dirección

    La cautela de los líderes de datos coincide con el marco regulatorio que se está consolidando en la región. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece el derecho a revisión humana de decisiones automatizadas con efectos significativos sobre personas (artículo 20), lo que obliga a las empresas a mantener capacidad de supervisión activa sobre cualquier agente que opere con datos personales. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) viene avanzando en lineamientos sobre IA responsable que apuntan en la misma dirección. En México, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) ha señalado la necesidad de explicabilidad en decisiones automatizadas. Ninguno de estos marcos permite, en la práctica, que un agente de IA tome decisiones sobre datos personales sin trazabilidad auditada y posibilidad de revisión: exactamente lo que los líderes de datos identifican como condición faltante en sus organizaciones.

    Qué necesita estar resuelto antes de escalar agentes autónomos

    Para un Chief Data Officer que evalúa cuándo y cómo escalar agentes de IA con mayor autonomía, el camino crítico pasa por tres decisiones de gobernanza que deben estar tomadas antes de mover el dial hacia la autonomía. Primero, certificar la calidad del dato de entrada para cada dominio donde el agente va a operar —no de forma general, sino dominio por dominio, con umbrales definidos y monitoreados en tiempo real. Segundo, asignar formalmente un data steward con ownership sobre los datos que consume el agente, con capacidad efectiva de vetar una ejecución. Tercero, construir data lineage auditado end-to-end para los flujos que alimentan al agente, de modo que cualquier decisión sea reconstruible y explicable ante una auditoría interna o regulatoria. El EDM Council, a través del marco CDMC (Cloud Data Management Capabilities), ubica estas tres capacidades en los niveles 6, 7 y 8 del modelo de madurez —niveles que la mayoría de las organizaciones latinoamericanas aún no ha certificado formalmente, aunque muchas operen con prácticas equivalentes en sectores regulados como banca y seguros.

    La autonomía de los agentes de IA no es una decisión de arquitectura tecnológica: es una declaración sobre el nivel de madurez del gobierno de datos de una organización. Los líderes que hoy frenan la autonomía total no están siendo conservadores —están siendo precisos.

  • La apuesta billonaria de la IA: qué dicen los modelos económicos sobre el riesgo

    La apuesta billonaria de la IA: qué dicen los modelos económicos sobre el riesgo

    Economistas y analistas debaten si la inversión de billones de dólares en infraestructura de inteligencia artificial se traducirá en productividad real o en la mayor destrucción de capital de la historia tecnológica reciente. La pregunta no es académica: los flujos de inversión ya están comprometidos, y los marcos jurídicos que regulan esa apuesta apenas empiezan a tomar forma.

    Cuando Jessica Wachter, profesora de finanzas de la Universidad de Pensilvania, intentó modelar el impacto económico de la inteligencia artificial en los próximos años, según se informó, encontró que los escenarios divergen de forma radical según un único supuesto: si los sistemas de IA efectivamente aumentan la productividad total de los factores de producción o si simplemente reemplazan tareas sin generar valor agregado neto. Ese condicional —todavía sin respuesta empírica sólida— es el corazón de lo que analistas llaman “la apuesta billonaria”.

    Dónde se concentra el riesgo: infraestructura, energía y deuda corporativa

    Las grandes plataformas tecnológicas han comprometido inversiones que, sumadas, superan el billón de dólares en centros de datos, chips de alta performance y redes eléctricas dedicadas. Ese capital no es líquido: una vez construida la infraestructura, el costo hundido es casi total. Si la demanda de servicios de IA no alcanza las proyecciones —o si tecnologías alternativas desplazan los modelos de lenguaje de gran escala antes de que la inversión madure— el resultado sería una burbuja de activos físicos con muy baja posibilidad de reconversión. El paralelo histórico más cercano es el sobredimensionamiento de fibra óptica durante la burbuja punto-com de finales de los noventa, aunque la escala actual es considerablemente mayor.

    OpenAI y los datos biológicos: un frente regulatorio distinto

    En paralelo al debate macroeconómico, OpenAI habría expresado interés en acceder a grandes volúmenes de datos biológicos para entrenar modelos especializados en ciencias de la vida, según se informó. Este movimiento abre un frente regulatorio que va mucho más allá de la propiedad intelectual o la competencia de mercado: los datos biológicos son, en múltiples jurisdicciones, datos sensibles de primer orden. En la Unión Europea, el Reglamento General de Protección de Datos (RGPD) los clasifica como categoría especial; en Brasil, la Lei Geral de Proteção de Dados (LGPD) los incluye explícitamente en su artículo 11 como datos sensibles con restricciones de tratamiento reforzadas. En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) también establece un régimen diferenciado para datos de salud.

    El cruce entre modelos de lenguaje y datos biológicos activa, además, el debate sobre la aplicación del AI Act europeo a sistemas de IA de alto riesgo en el ámbito médico y científico. Bajo esa regulación, cualquier sistema que tome decisiones con impacto en la salud humana queda sujeto a requisitos de transparencia, auditoría y evaluación de conformidad que hoy ningún modelo de propósito general cumple de forma nativa.

    Cuándo aplica el marco legal de IA y cuándo no

    El AI Act europeo —vigente desde agosto de 2024 con plazos de implementación escalonados— clasifica como “alto riesgo” los sistemas que intervienen en diagnóstico médico, gestión de infraestructura crítica o decisiones con efecto jurídico sobre personas. Un modelo entrenado con datos biológicos para descubrimiento de fármacos podría no caer automáticamente en esa categoría si sus outputs no se usan directamente en decisiones clínicas. Sin embargo, la cadena de uso —del laboratorio al ensayo clínico, del ensayo a la aprobación regulatoria— hace que la frontera sea más difusa de lo que sugiere la letra de la ley. En América Latina, ningún país cuenta aún con una ley de IA equivalente al AI Act, aunque Colombia, Brasil y Chile tienen marcos de referencia no vinculantes o en proceso legislativo.

    El problema de valorar lo que aún no existe como mercado

    La dificultad de los modelos económicos para capturar el impacto de la IA radica en que buena parte del valor proyectado depende de externalidades de red y efectos de plataforma que solo se materializan cuando la adopción alcanza masa crítica. Wachter, según se informó, señaló que los modelos estándar de valoración de activos no están diseñados para capturar tecnologías con rendimientos potencialmente exponenciales pero con distribuciones de probabilidad altamente asimétricas. En términos prácticos: el escenario de alto retorno es posible, pero el escenario de pérdida masiva de capital también lo es, y ambos se parecen mucho en sus etapas tempranas.

    Para los reguladores latinoamericanos, este contexto plantea una tensión concreta: atraer inversión en infraestructura de IA —que varios países de la región están buscando activamente— mientras se construyen marcos de supervisión que no generen incertidumbre jurídica para los inversores. Brasil, con su Autoridade Nacional de Proteção de Dados (ANPD) ya operativa y un proyecto de ley de IA en el Congreso, está más cerca de resolver esa tensión que el resto de la región.

    Si la apuesta billonaria sale mal, la pregunta que enfrentarán los reguladores no será cómo frenar la IA, sino quién asume el pasivo de una infraestructura que nadie quiere y que pocos supieron supervisar a tiempo.

  • Gestión de datos agéntica: qué es y cuándo tiene sentido adoptarla

    Gestión de datos agéntica: qué es y cuándo tiene sentido adoptarla

    La gestión de datos agéntica —el uso de agentes de inteligencia artificial autónomos para ejecutar tareas de gobierno, calidad y orquestación de datos sin intervención humana constante— está dejando de ser un concepto de laboratorio para convertirse en una opción técnica evaluable por equipos de datos maduros. No reemplaza los marcos de gobernanza existentes: los presupone.

    La idea central es sencilla, aunque su implementación no lo es: un agente de IA recibe un objetivo —detectar anomalías en un pipeline, reconciliar definiciones entre dominios, catalogar activos nuevos— y lo ejecuta de forma autónoma, tomando decisiones intermedias sin esperar aprobación humana en cada paso. Lo que distingue a los sistemas agénticos de la automatización tradicional es la capacidad de razonar sobre el contexto, encadenar acciones y ajustar el plan ante resultados inesperados. En términos del DAMA-DMBOK, estos agentes operan sobre las mismas áreas de conocimiento —calidad, metadatos, arquitectura, integración— pero comprimen el ciclo de ejecución de días a minutos.

    Qué hace un agente de datos, en concreto

    Un agente de gestión de datos puede encargarse de tareas como perfilar automáticamente un dataset recién ingerido, asignarle una clasificación de sensibilidad según reglas predefinidas, abrir un ticket de data stewardship si detecta una violación de política, o actualizar el linaje en el catálogo corporativo. Lo que hasta ahora requería la coordinación entre un data engineer, un data steward y un analista de calidad puede, en escenarios bien acotados, ser delegado a un agente que opera dentro de guardarraíles configurados por el equipo de gobernanza. El concepto se alinea con lo que Bob Seiner denomina Non-Invasive Data Governance: el gobierno de datos no como capa burocrática adicional, sino como lógica embebida en los flujos de trabajo existentes. Los agentes, en ese marco, son ejecutores naturales de políticas ya definidas.

    Tres capacidades técnicas que lo hacen viable hoy

    La gestión de datos agéntica no es nueva como concepto, pero tres desarrollos recientes la acercan a la viabilidad operativa. Primero, los modelos de lenguaje de gran escala (LLMs) con capacidad de llamada a herramientas (tool calling) permiten que un agente consulte APIs de catálogos, ejecute queries de validación y escriba resultados en sistemas de registro sin intervención humana. Segundo, los marcos de orquestación de agentes —LangGraph, CrewAI, AutoGen y similares— proveen estructuras para definir flujos multi-agente con roles diferenciados: un agente descubridor, uno validador, uno notificador. Tercero, la proliferación de APIs estandarizadas en plataformas de catálogo (Atlan, Alation, DataHub) facilita la integración sin desarrollo a medida.

    Cuándo aplica y cuándo no

    La gestión de datos agéntica tiene sentido en organizaciones que ya cuentan con un catálogo de datos operativo, políticas de calidad documentadas y roles de data steward definidos. Sin esa base, un agente autónomo no tiene políticas que ejecutar ni contexto semántico sobre el que razonar: amplifica el caos en lugar de reducirlo. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), sitúa las capacidades de automatización avanzada en los niveles 4 y 5 de madurez; llegar a esa automatización agéntica sin haber consolidado los niveles anteriores —clasificación, linaje básico, ownership formal— es técnicamente posible pero operativamente riesgoso. Tampoco es la solución adecuada para decisiones de gobernanza que requieren juicio contextual complejo, negociación entre dominios de negocio o resolución de conflictos de definición entre áreas. Esas tareas siguen siendo territorio humano.

    El riesgo de delegar sin auditar: lo que exigen LGPD y Ley 25.326

    Introducir agentes autónomos en los flujos de gestión de datos abre una pregunta de gobernanza que en América Latina tiene dimensión regulatoria concreta. Si un agente toma decisiones sobre clasificación de datos personales, modificación de registros o generación de metadatos de linaje, ¿quién responde ante la Autoridade Nacional de Proteção de Dados (ANPD) en Brasil o ante la Agencia de Acceso a la Información Pública (AAIP) en Argentina cuando esa decisión automatizada resulta incorrecta? Tanto la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) como la Ley 25.326 de Argentina exigen que las decisiones automatizadas con efectos sobre datos personales sean auditables y, en ciertos supuestos, reversibles a solicitud del titular. Eso implica que cualquier implementación agéntica sobre activos de datos personales debe incluir, desde el diseño, un registro inmutable de las acciones del agente, un mecanismo de revisión humana y un responsable formal (data steward o DPO) que pueda explicar cada decisión. La autonomía del agente no elimina la accountability del equipo de datos.

    Lo que un CDO debería evaluar antes de pilotear

    Antes de lanzar un piloto de gestión de datos agéntica, hay cuatro preguntas operativas que el equipo de gobernanza debe poder responder: ¿El catálogo de datos tiene cobertura suficiente del dominio que el agente va a gestionar? ¿Las políticas de calidad y clasificación están documentadas en formato legible por máquina (reglas, no narrativas)? ¿Existe un proceso de revisión humana para las acciones del agente que afecten datos personales o activos críticos? ¿Hay logging centralizado que permita auditar cada decisión del agente con atribución de causa? Si alguna de estas cuatro respuestas es negativa, el piloto debería empezar por resolver ese gap antes de activar autonomía agéntica. Un primer caso de uso recomendable: delegar al agente el perfilado y etiquetado preliminar de datasets nuevos en un data lake, con revisión humana antes de que esos metadatos se publiquen en el catálogo corporativo.

    Para profundizar en los marcos de madurez que determinan si una organización está lista para automatización agéntica, el CDMC del EDM Council y la versión 2.0 del DAMA-DMBOK son los puntos de partida más completos disponibles en la industria.

  • Noveno Circuito frena intento de expandir la DMCA al entrenamiento de IA

    Noveno Circuito frena intento de expandir la DMCA al entrenamiento de IA

    El Tribunal de Apelaciones del Noveno Circuito de Estados Unidos rechazó en septiembre de 2026 un intento de ampliar la Sección 1202 de la Digital Millennium Copyright Act (DMCA) para crear nueva responsabilidad legal sobre el entrenamiento de modelos de lenguaje. El fallo protege a programadores, artistas y desarrolladores independientes de una teoría que, de haber prosperado, habría convertido usos perfectamente legítimos en fuente de litigios millonarios.

    El caso giró en torno a un grupo de contribuyentes anónimos de GitHub que demandaron a OpenAI y Microsoft. Su argumento: el código generado por los LLMs de ambas compañías —entrenados con repositorios públicos de GitHub, entre miles de millones de otras obras— era similar al suyo, pero sin la información de gestión de derechos de autor (CMI, por sus siglas en inglés), es decir, sin atribución de autoría ni avisos de copyright. Los demandantes invocaron la Sección 1202 de la DMCA, que prohíbe remover intencionalmente ese tipo de información de una obra protegida.

    Qué dice la Sección 1202 de la DMCA y por qué el Noveno Circuito la leyó en sentido estricto

    La Sección 1202 fue diseñada como un mecanismo de respaldo para los derechos de autor en el entorno digital: impide que alguien tome una obra y le arranque los metadatos de identificación antes de redistribuirla. Lo que el tribunal rechazó fue extender esa lógica a un escenario distinto: el de un sistema de IA que genera código nuevo que se parece a obras preexistentes pero que, al ser una creación diferente, nunca tuvo CMI propio. El Noveno Circuito precisó que remover información de gestión de derechos de una obra existente es conceptualmente diferente de producir una obra nueva que simplemente no lleva esa información.

    La Electronic Frontier Foundation (EFF) y la organización Public Knowledge presentaron un amicus brief en el caso, argumentando exactamente esa distinción. El tribunal acogió esa posición. Según EFF, si la teoría de los demandantes hubiera prosperado, habría creado un régimen de responsabilidad que se superponía al derecho de autor tradicional pero sin sus equilibrios: sin fair use, sin umbrales claros, con daños estatutarios potencialmente devastadores para actores pequeños.

    Quiénes habrían quedado expuestos: remix, ingeniería inversa y motores de búsqueda

    EFF advirtió en su brief que la interpretación expansiva habría afectado mucho más allá de la industria de IA. Entre los casos concretos que mencionó la organización:

    • Artistas que crean remixes basados en obras anteriores.
    • Docentes que adaptan materiales para presentaciones en el aula.
    • Ingenieros que realizan ingeniería inversa de código para comprenderlo mejor.
    • Motores de búsqueda que indexan y muestran fragmentos de contenido.

    En todos esos escenarios, la obra resultante no “quita” CMI de un original: simplemente no lo replica. Pero bajo la lectura que proponían los demandantes, cualquier similitud con una obra preexistente sin atribución idéntica podría haberse convertido en un disparador de demandas con daños estatutarios cuantiosos. Las grandes corporaciones pueden litigar esos casos durante años; un desarrollador independiente, en la práctica, se ve obligado a transar aunque su uso sea completamente legal.

    Copyright de IA en América Latina: Argentina, México y Brasil frente a un vacío normativo equivalente

    El fallo del Noveno Circuito no tiene efecto directo en América Latina, pero sí marca un precedente interpretativo relevante para jurisdicciones que aún no han legislado sobre entrenamiento de IA y propiedad intelectual. Argentina, cuya Ley 11.723 de Propiedad Intelectual data de 1933 y no contempla escenarios de machine learning, carece de una respuesta clara sobre si el uso de obras protegidas como datos de entrenamiento configura infracción. México enfrenta el mismo vacío: la Ley Federal del Derecho de Autor (LFDA) no incluye excepciones específicas para minería de datos o entrenamiento de modelos, a diferencia del Text and Data Mining (TDM) exception que incorporó la Unión Europea en su Directiva de Copyright de 2019.

    Brasil es la jurisdicción más avanzada del bloque en este debate. El Projeto de Lei 2338/2023, que regula la IA en el Senado federal, incluye disposiciones sobre el uso de datos para entrenamiento, aunque sin resolver en detalle la interacción con la Lei de Direitos Autorais (Lei 9.610/1998). La ANPD, por su parte, ha comenzado a tratar el entrenamiento con datos personales desde el ángulo de la LGPD, lo que agrega una capa regulatoria que en el caso de GitHub no estuvo en juego —el código, en principio, no es dato personal— pero que en otros corpus de entrenamiento sí lo es.

    Colombia y Chile, con sus respectivos marcos de propiedad intelectual igualmente anteriores a la era de IA generativa, tampoco ofrecen una respuesta legislativa clara. En ausencia de norma específica, los tribunales locales deberán interpretarlo caso a caso, con el riesgo de resoluciones divergentes que generen incertidumbre para empresas que entrenan modelos en la región.

    Qué monitorear: el AI Act de la UE como referencia y los proyectos legislativos regionales

    La resolución del Noveno Circuito llega en un momento en que la Unión Europea ya tiene en vigor el AI Act (Reglamento 2024/1689), cuyo Artículo 53 establece obligaciones de transparencia para proveedores de modelos de propósito general: deben documentar el corpus de entrenamiento y respetar las reservas de derechos que los titulares de obras hayan declarado bajo el mecanismo opt-out del TDM. Esa arquitectura —excepción general con opt-out explícito— es el modelo más articulado disponible hoy, y varios legisladores latinoamericanos lo están mirando de cerca.

    En paralelo, OpenAI y Microsoft aún enfrentan otras demandas vinculadas al uso de contenidos de GitHub y de otras plataformas, incluyendo litigios de medios de comunicación en Estados Unidos. El fallo del Noveno Circuito cierra una puerta —la vía DMCA Sección 1202 como nuevo derecho de atribución— pero no clausura el debate sobre si el entrenamiento con obras protegidas constituye fair use bajo el derecho de autor tradicional. Ese frente sigue abierto.

    Nuestro análisis

    El Noveno Circuito tomó la decisión técnicamente correcta: la Sección 1202 de la DMCA no es, ni fue diseñada para ser, un derecho de atribución autónomo. Pero el fondo del debate no desaparece con este fallo. La pregunta de si un modelo de IA puede entrenarse con obras protegidas sin licencia ni compensación a sus autores es una de las más importantes que enfrentan los sistemas de propiedad intelectual de todo el mundo. Para América Latina, donde los marcos legales son más precarios y los ecosistemas de desarrolladores independientes más vulnerables, la ausencia de una excepción TDM clara —como la que tiene la UE— deja a los actores locales en una posición de desventaja estructural frente a las grandes plataformas globales que ya operan bajo reglas más definidas.

    Mientras los congresos de la región no legiferen sobre minería de datos y entrenamiento de IA, serán los tribunales —con criterios heterogéneos y marcos normativos del siglo pasado— quienes decidan qué es legal construir en América Latina.

  • Qué compran Disney, GM y los bancos sobre vos a los data brokers

    Qué compran Disney, GM y los bancos sobre vos a los data brokers

    Cuando consumidores ejercieron su derecho de acceso ante un importante data broker estadounidense, los archivos que recibieron revelaron algo incómodo: empresas como Disney, General Motors, aseguradoras y bancos compraban datos sobre su peso, consumo de alcohol y probabilidad de hacerse una mamografía. La investigación, publicada por The Markup, expone el mercado de perfiles personales con un nivel de detalle que excede cualquier noción razonable de “dato de marketing”.

    Los data brokers —empresas que recopilan, combinan y venden perfiles de personas a terceros— operan desde hace décadas en un vacío regulatorio relativo. Lo que hace novedoso este caso es el método: los propios consumidores solicitaron sus archivos, y lo que obtuvieron permitió rastrear quién había comprado esos datos y qué categorías específicas incluían. El resultado es una radiografía del mercado secundario de datos personales que normalmente permanece opaco.

    Qué tipos de datos circulan entre compradores corporativos

    Los perfiles revelados incluían variables de salud inferidas —como indicadores de peso corporal y hábitos de consumo de alcohol— junto con predicciones de comportamiento médico, entre ellas la probabilidad de que una persona se realice ciertos estudios de detección temprana. Que una empresa automotriz como GM o un estudio de entretenimiento como Disney accedan a esa clase de información plantea preguntas que van más allá del marketing: ¿para qué sirve saber si alguien es probable que se haga una mamografía al momento de venderle un auto o una suscripción de streaming? La respuesta más probable involucra segmentación actuarial, modelos de riesgo crediticio o perfilado psicográfico de precisión.

    Las aseguradoras y los bancos identificados como compradores representan el caso de uso más preocupante desde el punto de vista regulatorio. En jurisdicciones donde el uso de datos de salud para decisiones de crédito o seguro está restringido, adquirir esa información de un tercero bajo el rótulo de “datos de comportamiento” puede constituir una evasión de facto de esas restricciones.

    Por qué el derecho de acceso funcionó como herramienta de auditoría ciudadana

    El mecanismo que permitió esta investigación es el mismo que leyes de privacidad de todo el mundo reconocen como derecho de acceso o derecho de acceso a datos personales —equivalente al derecho de acceso del RGPD europeo, al acesso previsto en la LGPD brasileña (art. 18), al derecho de acceso de la Ley 25.326 argentina (art. 14) y al acceso regulado por la LFPDPPP mexicana (art. 22). En todos esos marcos, la persona titular puede solicitar qué datos tiene una organización sobre ella. Lo que esta investigación demuestra es que esa solicitud, cuando se dirige a un data broker, puede revelar no solo los datos propios sino también el ecosistema de compradores que los adquirió.

    Ese uso del derecho de acceso como herramienta de investigación y auditoría ciudadana no es nuevo —organizaciones como Privacy International lo han empleado sistemáticamente en Europa— pero sigue siendo subutilizado en América Latina, donde las autoridades de control como la AAIP en Argentina, la ANPD en Brasil o el INAI en México tienen competencia para recibir denuncias derivadas de respuestas incompletas o insatisfactorias a esas solicitudes.

    Cuándo aplica este riesgo en LATAM / cuándo no

    El mercado de data brokers en América Latina es menos maduro que el estadounidense, pero existe y crece. Empresas de enriquecimiento de datos operan en Brasil, México, Colombia y Argentina, y venden perfiles combinados a anunciantes, aseguradoras y entidades financieras. La diferencia relevante es que en Brasil, la LGPD establece que datos de salud son datos sensibles (art. 11) y su tratamiento requiere base legal específica y consentimiento explícito; en Argentina, la Ley 25.326 también clasifica los datos relativos a la salud como datos sensibles con protección reforzada. En México, la LFPDPPP y su reglamento exigen consentimiento expreso para datos sensibles. Eso significa que un data broker que comercialice inferencias de salud —aunque las llame “propensity scores” o “behavioral data”— podría estar violando esas normas si el titular no consintió expresamente ese tratamiento. El riesgo regulatorio es real, pero depende de que las autoridades tengan la capacidad técnica de auditar qué variables se esconden detrás de las etiquetas comerciales que usan los brokers.

    El escenario donde este riesgo no aplica directamente es el de datos estrictamente agregados y no reidentificables. Si un broker vende únicamente estadísticas de segmento sin posibilidad de asociarlas a individuos, los marcos de protección de datos personales no se activan. El problema, ampliamente documentado, es que la reidentificación de conjuntos supuestamente anónimos es técnicamente posible en la mayoría de los casos cuando se cruzan con otras fuentes.

    El circuito que une al broker con el comprador corporativo

    Lo que esta investigación hace visible es el circuito completo: una persona interactúa con servicios digitales, aplicaciones de salud, programas de fidelidad o simplemente navega la web. Ese rastro es recopilado, procesado e inferido por el broker, que construye un perfil comercializable. Ese perfil llega a compradores corporativos —una automotriz, un banco, una aseguradora— que lo integran a sus modelos de decisión. El titular del dato raramente sabe que ese circuito existe, y cuando lo descubre —como en este caso, a través de una solicitud de acceso— la información obtenida puede ser incompleta o técnicamente inaccesible para quien no tenga formación específica.

    Ese déficit de transparencia es precisamente lo que los regímenes de privacidad modernos intentan corregir con obligaciones de información al momento de la recolección, registros de actividades de tratamiento y —en el caso del AI Act europeo— requisitos de explicabilidad para decisiones automatizadas. En LATAM, el eslabón más débil sigue siendo la aplicación efectiva: tener el derecho en la ley y poder ejercerlo con resultado útil son dos cosas distintas.

    Para quienes trabajan en privacidad en la región, el caso refuerza una pregunta pendiente: si los titulares latinoamericanos ejercieran masivamente su derecho de acceso ante los brokers que operan localmente, ¿qué empresas aparecerían en la lista de compradores?

  • El espejismo de capacidades que genera la IA en las organizaciones

    El espejismo de capacidades que genera la IA en las organizaciones

    Cuando una organización adopta IA y parece operar mejor, más rápido y con mayor precisión, puede estar construyendo una fachada: una apariencia de capacidad que no tiene sustento real en procesos, datos ni conocimiento institucional. MIT Sloan Management Review llama a este fenómeno el “espejismo de capacidades” (capability mirage), y sus implicancias van mucho más allá de la productividad.

    El concepto describe una trampa específica: la IA ejecuta tareas que antes requerían competencia humana acumulada, y lo hace con tal fluidez que los líderes —y los propios equipos— asumen que la organización ha mejorado. Pero el conocimiento que antes residía en personas no se ha transferido a la institución: simplemente se ha subcontratado a un sistema cuyo razonamiento interno nadie puede auditar. La organización no aprendió; delegó.

    La diferencia entre automatizar una tarea y consolidar una capacidad

    Automatizar una tarea y desarrollar una capacidad organizacional son cosas distintas. Una capacidad implica que la organización puede entender lo que hace, explicarlo, replicarlo sin el sistema original y corregirlo cuando falla. Un modelo de lenguaje que redacta contratos, clasifica reclamos o sintetiza jurisprudencia puede hacer todo eso con gran velocidad, pero si el equipo jurídico o de compliance no sabe evaluar el output ni detectar sus límites, la organización opera sobre un andamio sin cimientos. El riesgo no es técnico: es institucional.

    El espejismo se vuelve especialmente peligroso cuando la IA se usa para funciones que tienen consecuencias regulatorias directas. En el sector financiero, en el área de cumplimiento normativo, en recursos humanos o en la gestión de datos personales, un error generado por IA que nadie puede detectar porque nadie entiende el proceso subyacente puede derivar en infracciones graves. Y el regulador no acepta como defensa que “lo hizo el algoritmo”.

    Responsabilidad legal cuando el sistema falla y nadie sabe por qué

    Desde una perspectiva de Legal AI, el espejismo de capacidades plantea un problema de imputabilidad. Si un sistema de IA toma una decisión que afecta a un titular de datos —una denegación de crédito, una clasificación de riesgo, una resolución automatizada de un reclamo— la normativa vigente en múltiples jurisdicciones exige que esa decisión sea explicable y revisable por un humano. El artículo 22 del RGPD europeo, que sirvió de modelo para el artículo 19 de la Ley 25.326 argentina y para disposiciones equivalentes en la Ley General de Protección de Datos de Brasil (LGPD, artículo 20), establece el derecho a no ser objeto de decisiones exclusivamente automatizadas con efectos significativos. Ese derecho presupone que existe un humano capaz de revisar la decisión, no solo un humano que firmó la autorización para que la máquina la tome.

    Si el personal que opera el sistema ha perdido la comprensión del proceso —porque la IA lo hizo siempre, porque no hubo transferencia de conocimiento, porque la rotación borró la memoria institucional— la revisión humana se vuelve nominal. Hay una persona que aprueba, pero no hay capacidad real de supervisión. Eso es exactamente el espejismo: apariencia de control sin sustancia.

    El AI Act europeo y su impacto en sistemas de alto riesgo desplegados en LATAM

    El Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, en vigor desde agosto de 2024) clasifica como de alto riesgo los sistemas de IA usados en selección de personal, calificación crediticia, administración de justicia y servicios esenciales, entre otros. Para esos sistemas, el AI Act exige documentación técnica detallada, supervisión humana efectiva y capacidad de intervención. La palabra clave es “efectiva”: no basta que exista un protocolo de revisión; debe haber competencia humana real para ejercerlo. El espejismo de capacidades viola ese requisito de fondo, aunque cumpla los formales.

    Esto importa en América Latina porque varias multinacionales con operaciones en la región están dentro del alcance extraterritorial del AI Act —si sus sistemas afectan a personas en la UE— y porque los marcos regulatorios emergentes en Chile, Colombia, Brasil y México están tomando el AI Act como referencia explícita. La Política Nacional de Inteligencia Artificial de Colombia (CONPES 3975) y el proyecto de ley de IA que avanza en Brasil ya incorporan el concepto de supervisión humana significativa como eje estructural.

    Cuándo aplica esta advertencia y cuándo no

    El espejismo de capacidades no aplica a todas las implementaciones de IA por igual. Si una organización usa IA para tareas que nunca requirieron capacidad institucional crítica —generación de borradores, resúmenes internos, clasificación preliminar de documentos con revisión posterior—, el riesgo es bajo. El problema aparece cuando la IA reemplaza procesos en los que el criterio humano tenía valor regulatorio, legal o de control de riesgo, y ese criterio no se preserva ni se desarrolla en paralelo. También aplica cuando la dependencia de un único proveedor de IA hace que la organización pierda la capacidad de operar si ese proveedor cambia sus modelos, sus condiciones de uso o su disponibilidad.

    Un test simple: si el proveedor de IA retirara su sistema mañana, ¿podría el equipo explicar cómo tomó las decisiones del último año? ¿Podría replicar el proceso con otro sistema o a mano? Si la respuesta es no en áreas reguladas, hay un espejismo activo.

    Lo que distingue adopción real de adopción cosmética

    Las organizaciones que evitan el espejismo hacen al menos tres cosas distintas a las que caen en él. Primero, documentan el razonamiento esperado del sistema y lo comparan periódicamente con el output real. Segundo, mantienen —o construyen— capacidad humana paralela en las funciones críticas, aunque sea a menor escala. Tercero, tratan la IA como una herramienta de aumento, no de sustitución, en los procesos donde la explicabilidad es un requisito normativo. Esto no es conservadurismo tecnológico: es gestión de riesgo regulatorio.

    En la práctica, significa que el área legal, de compliance o de gobernanza de datos debe participar en el diseño de la implementación, no solo en la firma del contrato con el proveedor. El rol del Chief Data Officer o del DPO no termina en la evaluación de impacto inicial; incluye monitorear si la capacidad institucional de supervisión se mantiene a lo largo del tiempo.

    Para profundizar en los marcos de supervisión humana de sistemas de IA de alto riesgo, el texto del AI Act europeo está disponible en el Diario Oficial de la UE (Reglamento UE 2024/1689); la Autoridad Nacional de Protección de Datos de Brasil (ANPD) publicó su guía de decisiones automatizadas bajo el artículo 20 de la LGPD en 2023 y es lectura obligada para equipos que operan en la región.

  • OpenAI financia datos biológicos para IA: cómo se construye el corpus médico

    OpenAI financia datos biológicos para IA: cómo se construye el corpus médico

    OpenAI está financiando la creación de datos biológicos estructurados para entrenar sus modelos de inteligencia artificial en el dominio médico y científico. La estrategia expone una tensión jurídica central: quién controla los datos que alimentan sistemas de IA capaces de acelerar descubrimientos farmacéuticos y clínicos, y bajo qué reglas pueden circular.

    El problema de fondo no es técnico sino de disponibilidad y propiedad. Los modelos de lenguaje de propósito general enfrentan un techo cuando se los aplica a biología molecular, ensayos clínicos o desarrollo farmacéutico: el conocimiento especializado existe, pero gran parte está encapsulado en documentos regulatorios confidenciales, estrategias de fabricación y datos de seguridad que las empresas biotecnológicas tratan como secretos comerciales. Ese corpus no circula libremente porque no fue diseñado para circular.

    La propuesta de usar datos de biotechs quebradas

    La analista de políticas Ruxandra Teslo planteó, según se informó, una idea que llamó la atención en el sector: adquirir datos de empresas biotecnológicas en proceso de quiebra mediante ofertas en sus procedimientos concursales. La lógica es que, al disolverse una compañía, sus activos intangibles —incluyendo presentaciones regulatorias detalladas, datos de eficacia y seguridad, y estrategias de manufactura— quedan disponibles para subasta. En condiciones normales, ese material nunca llega al mercado porque las empresas exitosas lo retienen indefinidamente o lo licencian bajo términos restrictivos. La quiebra crea una ventana legal inusual.

    OpenAI habría identificado en este enfoque una vía para construir datasets de alta calidad y alta especificidad biológica. La compañía estaría financiando la creación y adquisición de este tipo de datos, aunque los detalles exactos del mecanismo de compra y los acuerdos concretos no han sido divulgados públicamente según la información disponible.

    Qué tipo de dato biológico se busca y por qué no basta con lo público

    Los modelos entrenados sobre literatura científica abierta —artículos de PubMed, preprints, bases de datos genómicas públicas— ya existen y tienen limitaciones conocidas: reflejan lo que se publicó, no lo que se investigó y falló. El “publication bias” (sesgo de publicación) hace que los datos negativos de ensayos clínicos, los fracasos de compuestos en fase temprana y los problemas de manufactura queden fuera del registro público. Sin embargo, esa información de fracasos tiene un valor predictivo enorme para sistemas de IA que buscan anticipar qué moléculas o estrategias no funcionarán.

    Los reguladores sí reciben esos datos. La FDA en Estados Unidos, la EMA en Europa y sus contrapartes latinoamericanas —ANVISA en Brasil, ANMAT en Argentina, COFEPRIS en México— acumulan volúmenes masivos de información preclínica y clínica en cada expediente de aprobación. Esos datos son confidenciales durante décadas, salvo que una quiebra los libere o que el regulador decida publicarlos bajo esquemas de acceso controlado. La propuesta de Teslo explota precisamente esa segunda vía concursal.

    Cuándo aplica esta lógica y cuándo no: límites legales y éticos

    El modelo concursal funciona para datos de compañías disueltas, pero tiene restricciones importantes. En primer lugar, los datos de ensayos clínicos contienen información derivada de participantes humanos que otorgaron consentimiento para usos específicos. El hecho de que la empresa propietaria quiebre no extingue automáticamente las obligaciones de confidencialidad frente a esos participantes ni los derechos emergentes de las normativas de protección de datos personales. En jurisdicciones donde rige el GDPR europeo o la LGPD brasileña —que exige base legal específica para el tratamiento de datos sensibles de salud bajo el artículo 11 de la Ley 13.709/2018—, la transferencia de ese corpus a un nuevo controlador para entrenamiento de IA requeriría análisis legal adicional que la simple transacción concursal no resuelve.

    En Argentina, la Ley 25.326 de Protección de Datos Personales clasifica los datos de salud como sensibles y su tratamiento requiere consentimiento expreso o habilitación legal específica. La AAIP (Agencia de Acceso a la Información Pública) no ha emitido lineamientos explícitos sobre el uso de datos sensibles de salud para entrenamiento de modelos de IA, lo que deja un vacío interpretativo relevante para cualquier actor regional que quiera replicar este tipo de operaciones.

    El régimen de propiedad intelectual de los datos generados para IA

    Más allá del dato adquirido, OpenAI estaría financiando también la generación activa de nuevos datos biológicos —anotaciones, datasets sintéticos, experimentos diseñados para producir información estructurada que los modelos puedan ingerir. Aquí emerge otra capa jurídica: quién es el propietario del dato generado bajo encargo. En el derecho anglosajón, el concepto de “work for hire” resuelve parcialmente la cuestión a favor del comitente. En los sistemas de derecho civil latinoamericanos, la respuesta varía por jurisdicción y tipo de dato. Un dataset generado por investigadores de una universidad pública brasileña financiados por OpenAI podría quedar sujeto a restricciones de dominio público o normativa universitaria incompatibles con una licencia exclusiva.

    El AI Act de la Unión Europea, en vigor desde 2024, clasifica los sistemas de IA de alto riesgo usados en medicina y exige documentación sobre los datos de entrenamiento, incluyendo su procedencia y las medidas de gobernanza aplicadas. Si los modelos de OpenAI entrenados con datos biológicos se comercializan en Europa o se usan en productos que llegan a mercados latinoamericanos con acuerdos de adecuación, las obligaciones de trazabilidad del corpus de entrenamiento se vuelven directamente aplicables.

    La carrera por el corpus médico y sus implicancias para América Latina

    América Latina produce una fracción del conocimiento biomédico global pero concentra una diversidad genética y epidemiológica que los grandes modelos actuales subrepresentan. Los ensayos clínicos realizados en Brasil, México o Argentina generan datos regulatorios que reposan en ANVISA, COFEPRIS o ANMAT sin que existan mecanismos formales para su aprovechamiento científico posterior más allá del expediente de aprobación. Si las grandes compañías tecnológicas logran construir corpus biológicos masivos con datos del Norte Global, los modelos resultantes heredarán esos sesgos de representación. La oportunidad para los reguladores latinoamericanos —y para centros de investigación como FIOCRUZ o el CONICET— sería diseñar esquemas de acceso controlado a datos regulatorios propios que permitan participar en la construcción de IA biomédica con representación regional, en lugar de quedar como consumidores netos de modelos entrenados en otra parte.

    Para profundizar en el marco regulatorio aplicable al tratamiento de datos de salud para entrenamiento de IA, el artículo 11 de la LGPD brasileña (Ley 13.709/2018) y las guías de la ANPD sobre datos sensibles ofrecen el punto de partida más desarrollado de la región.