DataTrends LATAM

Blog

  • Por qué el 60% de los proyectos de IA fracasan antes de escalar

    Por qué el 60% de los proyectos de IA fracasan antes de escalar

    Seis de cada diez proyectos de inteligencia artificial no llegan a producción o no generan valor medible, según cifras atribuidas a Gartner. El denominador común no es la calidad del modelo ni el presupuesto: es la gestión de los datos que lo alimentan. Para los equipos de gobierno de datos en América Latina, ese dato no es una advertencia genérica — es un diagnóstico operativo.

    La estadística circula con fuerza en el debate técnico de 2025 y 2026: la mayoría de las iniciativas de inteligencia artificial corporativa colapsan en la fase de datos, no en la de algoritmos. Los data scientists pasan entre el 60% y el 80% de su tiempo limpiando, reconciliando y buscando datos — tiempo que no se invierte en modelado ni en generación de valor. Detrás de ese cuello de botella hay déficits concretos de gobernanza: ausencia de data lineage documentado, ownership sin asignar, catálogos incompletos o inexistentes, y clasificación de datos que nunca se actualizó desde que se implementó el data lake.

    El dato sin dueño: el origen más frecuente del fracaso

    El DAMA-DMBOK identifica el data ownership como una de las capacidades fundacionales de cualquier programa de gobierno de datos. En la práctica, muchas organizaciones latinoamericanas tienen datos distribuidos entre sistemas legados, plataformas cloud y hojas de cálculo departamentales sin que ningún data steward sea formalmente responsable de su calidad o actualización. Cuando un proyecto de IA intenta consumir esos datos, el equipo técnico descubre inconsistencias que nadie puede resolver porque nadie tiene autoridad para hacerlo. El modelo termina entrenándose con datos incorrectos o el proyecto se paraliza esperando validación.

    El EDM Council, en su marco DCAM (Data Capability Assessment Model), ubica el data ownership y la definición de roles de stewardship entre las capacidades de nivel 2 — las que deben estar consolidadas antes de avanzar a casos de uso analíticos avanzados. Sin embargo, según se informa en relevamientos del sector, una proporción significativa de empresas medianas y grandes de la región inicia proyectos de IA sin haber alcanzado ese nivel de madurez.

    Data lineage y catálogos: la infraestructura invisible que los proyectos IA exigen

    Un modelo de machine learning no puede ser auditado si no se puede rastrear el origen de cada feature que lo alimenta. El data lineage — la trazabilidad documentada de cómo un dato se transforma desde su fuente hasta el output del modelo — es un requisito operativo, no un nice-to-have. Sin él, cuando el modelo arroja un resultado sesgado o erróneo, el equipo no puede determinar si el problema está en la extracción, en la transformación, en el etiquetado o en el modelo mismo. El debugging se vuelve arqueología.

    Los catálogos de datos cumplen una función complementaria: hacen que los datos correctos sean encontrables. En organizaciones donde el catálogo no existe o está desactualizado, los equipos de datos duplican esfuerzos, consumen versiones distintas del mismo dataset o directamente trabajan con datos cuya definición de negocio nadie conoce. Herramientas como Collibra, Alation o soluciones open source como OpenMetadata resuelven el problema técnico, pero solo si hay un proceso de gobernanza que las alimente con metadata real y actualizada.

    En Brasil, Argentina y México: regulación que agrega presión al problema de datos

    El contexto regulatorio latinoamericano amplifica el riesgo. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige que las organizaciones puedan demostrar el propósito del tratamiento de datos personales — incluyendo los usados para entrenar modelos de IA. Si no hay catálogo ni lineage, esa demostración es imposible, y la Autoridade Nacional de Proteção de Dados (ANPD) puede considerar el tratamiento como no conforme. En Argentina, la Ley 25.326 y las disposiciones de la AAIP imponen obligaciones similares de accountability. En México, el INAI ha comenzado a preguntar, en el marco de auditorías, qué datos se usan en sistemas automatizados de toma de decisiones. Un proyecto de IA sin gobernanza de datos no solo fracasa técnicamente: puede generar exposición regulatoria.

    Cuándo aplica este diagnóstico — y cuándo no

    Este problema es especialmente agudo en proyectos de IA que consumen datos operacionales de múltiples sistemas (ERP, CRM, fuentes externas), en modelos que toman decisiones con impacto en clientes o empleados, y en organizaciones que no tienen un Chief Data Officer o un equivalente funcional con autoridad real sobre datos. No aplica de la misma manera a proyectos de IA que trabajan sobre datos sintéticos, datasets cerrados y bien documentados, o experimentos acotados en entornos sandbox sin dependencia de datos productivos.

    Un CDO que quiera evaluar la exposición de su organización puede partir de tres preguntas concretas: ¿Cada dataset crítico para proyectos de IA tiene un data steward nombrado y operativo? ¿Existe lineage documentado desde la fuente hasta el modelo para al menos los tres proyectos de mayor impacto? ¿El catálogo de datos fue actualizado en los últimos seis meses? Si alguna respuesta es negativa, el riesgo de fracaso no es teórico — es inminente. El punto de partida práctico puede ser una evaluación de madurez contra el CDMC (Certified Data Management Professional) del EDM Council o contra los dominios del DAMA-DMBOK, priorizando ownership, calidad y arquitectura de datos antes de aprobar nuevos presupuestos de IA.

    Para profundizar en los marcos de referencia, el DAMA-DMBOK está disponible en dama.org y el DCAM del EDM Council en edmcouncil.org — ambos con versiones de evaluación de madurez descargables que permiten un diagnóstico inicial sin costo.

  • Pruebas de conocimiento cero y verificación de edad: límites reales

    Pruebas de conocimiento cero y verificación de edad: límites reales

    Las pruebas de conocimiento cero (Zero-Knowledge Proofs o ZKPs) se presentan como la solución técnica definitiva para verificar la edad de los usuarios en línea sin comprometer su privacidad. La evidencia disponible indica que esa promesa es, cuando menos, prematura: los esquemas de verificación de edad basados en ZKPs son manipulables, vulnerables a ataques y concentran poder en puntos únicos de falla que representan un riesgo estructural para los derechos digitales.

    La verificación de edad en internet se ha convertido en una tendencia regulatoria global. Aproximadamente la mitad de los estados de EE.UU. ya cuentan con alguna ley de verificación de edad en línea, según se informó. A nivel federal estadounidense avanzan propuestas como la Kids Online Safety Act (KOSA) y la KIDS Act. La Unión Europea impulsa una aplicación centralizada de verificación de edad para antes de fin de año. Australia tiene vigente una restricción especialmente amplia. En este contexto, los ZKPs emergen como el argumento técnico favorito de quienes defienden estas regulaciones.

    Qué es un ZKP y cómo se aplica a la verificación de edad

    Una prueba de conocimiento cero es un protocolo criptográfico que permite a una parte demostrar que conoce o cumple cierta condición —por ejemplo, ser mayor de 18 años— sin revelar los datos subyacentes que lo acreditan. En teoría, un usuario podría probar su mayoría de edad ante una plataforma sin que esa plataforma conozca su nombre, fecha de nacimiento ni número de documento. El atractivo regulatorio es evidente: resolver la tensión entre protección infantil y privacidad con un solo mecanismo.

    El problema empieza en la infraestructura necesaria para que ese mecanismo funcione. Para que un ZKP sea válido, debe existir una fuente autoritativa que certifique el dato de base —la edad real de la persona— y emita la credencial criptográfica que el protocolo luego verifica sin revelar. Esa fuente puede ser una identidad digital nacional, un documento de identidad digital, o un sistema centralizado de atributos. Ahí es donde la promesa de privacidad comienza a erosionarse.

    Punto único de falla: el riesgo que los ZKPs no eliminan

    Crear una infraestructura centralizada de credenciales para el acceso a internet introduce, por definición, un punto único de falla. Si el sistema que emite las credenciales ZKP es comprometido, todos los usuarios quedan expuestos simultáneamente. Si el Estado o un actor privado controla esa infraestructura, también controla —de forma efectiva— quién puede acceder a qué contenidos en línea. Esto contradice la arquitectura descentralizada que históricamente hizo posible una internet abierta.

    Según se informó, los esquemas de verificación de edad basados en ZKPs ya mostraron ser manipulables mediante redes privadas virtuales (VPN) y vulnerables a ataques técnicos. Eso significa que no cumplen su objetivo declarado —mantener a los menores fuera de ciertos espacios— mientras sí generan los riesgos de privacidad y concentración de poder que sus defensores prometían evitar. Es la combinación más desfavorable posible desde una perspectiva de política pública.

    Cuándo aplica un ZKP y cuándo no alcanza

    Los ZKPs son herramientas criptográficas legítimas y útiles en contextos donde el dato a probar proviene de una fuente confiable preexistente, el sistema de emisión de credenciales está suficientemente descentralizado o protegido, y la verificación es puntual y no crea registros de navegación ni patrones de acceso. No son adecuados cuando la infraestructura subyacente centraliza el control de acceso a internet, cuando el dato de base —la edad— requiere vincular la identidad real del usuario a un sistema estatal o privado de certificación masiva, o cuando los incentivos de evasión son altos y los métodos de bypass son accesibles, como sucede con las VPN en el contexto de la verificación de edad.

    El debate regulatorio llega a América Latina con las mismas tensiones

    En la región, la verificación de edad online no tiene aún el peso normativo que exhibe en EE.UU., Australia o la UE, pero el debate ya está instalado. Brasil debate los alcances de la regulación de plataformas para menores en el marco de su Marco Civil da Internet y la Lei Geral de Proteção de Dados (LGPD), que clasifica los datos de niños y adolescentes como datos sensibles con protecciones reforzadas. Argentina, bajo la Ley 25.326 y las resoluciones de la Agencia de Acceso a la Información Pública (AAIP), tiene obligaciones similares. México, con la LFPDPPP y la supervisión del INAI, enfrenta presiones crecientes para definir estándares de verificación de edad en servicios digitales dirigidos a menores.

    El riesgo para la región es importar un modelo regulatorio que ya está mostrando fallas técnicas en las jurisdicciones que lo implementaron primero, sin adaptar los estándares a las condiciones locales de infraestructura de identidad digital —que en varios países latinoamericanos aún es fragmentada o de cobertura desigual. Una solución de verificación de edad que depende de un sistema nacional de identidad digital robusto funciona distinto en Alemania que en un país donde esa infraestructura cubre menos del 40% de la población adulta.

    Para profundizar en el marco técnico y jurídico de los ZKPs en verificación de edad, la Electronic Frontier Foundation mantiene actualizada su sección específica sobre leyes de verificación de edad en eff.org/age, con análisis de las principales propuestas legislativas y sus implicancias para los derechos digitales.

  • Gartner: la mala gestión de datos amenaza 6 de cada 10 proyectos de IA

    Gartner: la mala gestión de datos amenaza 6 de cada 10 proyectos de IA

    Seis de cada diez proyectos de inteligencia artificial fracasan o no alcanzan sus objetivos no por fallas en los modelos, sino por problemas en la gestión de los datos que los alimentan, según advirtió Gartner. La cifra pone en el centro del debate una capacidad que muchas organizaciones latinoamericanas todavía tratan como tarea pendiente: la gobernanza de datos.

    El diagnóstico de Gartner no es nuevo en su dirección, pero sí en su magnitud. Cuando una empresa decide implementar un modelo de lenguaje, un sistema de recomendación o cualquier herramienta de analítica avanzada, el supuesto implícito es que los datos de entrenamiento y operación son confiables, están bien catalogados y tienen un propietario claro. En la mayoría de las organizaciones de la región, ese supuesto es falso. Los datos llegan de silos desconectados, sin linaje trazable, con definiciones inconsistentes entre áreas y sin un data steward —responsable temático del dato— que garantice su calidad antes de que el modelo los consuma.

    Por qué el dato roto destruye al modelo, no al revés

    Un modelo de inteligencia artificial es, en términos operativos, una función matemática que generaliza patrones a partir de datos históricos. Si esos datos contienen duplicados, valores ausentes sin criterio de imputación, o categorías definidas de forma distinta en cada sistema de origen, el modelo aprende esos errores y los amplifica. El fenómeno tiene nombre en la industria: garbage in, garbage out. Lo que Gartner señala es que ese “garbage” no es un accidente técnico: es el resultado predecible de organizaciones que invierten en infraestructura de IA antes de haber resuelto su arquitectura de gobierno del dato.

    El marco DAMA-DMBOK identifica once áreas de conocimiento en gobernanza de datos —desde la arquitectura y el modelado hasta la calidad, la seguridad y el ciclo de vida del dato—. Las organizaciones que lanzan proyectos de IA sin haber madurado al menos las áreas de calidad de datos, catálogo y linaje están operando sin los cimientos mínimos. El EDM Council, a través de su certificación CDMC (Cloud Data Management Capabilities), también establece que la trazabilidad del dato —saber de dónde viene, cómo fue transformado y quién lo aprobó para uso analítico— es una capacidad de nivel básico, no avanzado.

    Cuándo aplica esta advertencia / cuándo NO

    La advertencia de Gartner aplica directamente a proyectos de IA que operan sobre datos internos de la organización: modelos predictivos de riesgo crediticio, sistemas de detección de fraude, motores de recomendación, analítica de clientes o automatización de procesos con datos históricos. El riesgo es más alto cuando los datos provienen de múltiples sistemas legados con escasa integración. En cambio, el problema es menos crítico —aunque no inexistente— en implementaciones que usan modelos fundacionales pre-entrenados con datos propietarios externos, donde el riesgo de dato roto se desplaza al proveedor del modelo. Tampoco aplica de la misma forma a proyectos de IA que operan sobre datos sintéticos o en entornos de laboratorio sin implicancias operativas.

    El estado de la gobernanza de datos en América Latina

    En la región, la brecha es estructural. Muchos bancos colombianos y mexicanos que reportan ante la Superintendencia Financiera de Colombia o la CNBV operan con modelos de scoring crediticio cuya trazabilidad de datos es, en el mejor caso, parcial. En Brasil, la LGPD (Lei Geral de Proteção de Dados, Ley 13.709/2018) obliga a las empresas a documentar el tratamiento de datos personales, lo que ha empujado a algunas organizaciones a construir catálogos de datos reactivamente —para cumplir con la ley— sin integrarlos a una estrategia de gobernanza más amplia. En Argentina, la Ley 25.326 de Protección de Datos Personales está en proceso de modernización, y el debate sobre su reforma incluye requisitos de documentación de tratamientos que, si se aprueban, tendrán el mismo efecto de forzar estructuras mínimas de gobierno del dato.

    La paradoja regional es que la presión regulatoria de privacidad está creando, como efecto secundario, las condiciones para una gobernanza de datos más sólida. Las organizaciones que construyen sus registros de actividades de tratamiento (RAT) para cumplir con LGPD o con la normativa de la AAIP argentina están, sin saberlo, construyendo un inventario de datos que puede convertirse en el punto de partida de un catálogo de datos institucional.

    Tres capacidades que un CDO debe tener antes de aprobar un proyecto de IA

    Si el número de Gartner tiene alguna utilidad práctica, es como criterio de evaluación previa. Antes de aprobar el presupuesto de un proyecto de IA, un Chief Data Officer debería poder responder afirmativamente a tres preguntas concretas: primero, si los datos de entrenamiento tienen un data steward identificado que pueda certificar su calidad y origen; segundo, si existe linaje documentado que permita rastrear cada campo crítico desde su fuente hasta el modelo; y tercero, si hay un proceso de monitoreo de calidad de datos en producción, no solo en el momento del entrenamiento inicial. Si alguna de esas tres respuestas es negativa, el proyecto tiene una probabilidad estadísticamente documentada —según Gartner— de estar entre el 60% que no cumplirá sus objetivos. La decisión de avanzar de todas formas es legítima, pero debe tomarse con esa información sobre la mesa.

    Para profundizar en los marcos de madurez aplicables, el DAMA-DMBOK2 y el framework CDMC del EDM Council son los estándares de referencia que cualquier equipo de gobernanza puede usar como línea de base antes de comprometer recursos en IA.

  • GRC crea consejo para fortalecer la gobernanza de datos de emisiones

    GRC crea consejo para fortalecer la gobernanza de datos de emisiones

    El Global Regulatory Council (GRC) anunció la creación de un consejo dedicado a la gobernanza de datos de emisiones en el sector marítimo, con el objetivo de estandarizar la recolección, calidad y reporte de información climática a escala global. La iniciativa responde a una brecha estructural que los reguladores y operadores del sector ya no pueden ignorar: los datos sobre emisiones que circulan entre armadores, puertos y autoridades nacionales son, con frecuencia, inconsistentes, incompletos o incomparables.

    La gobernanza de datos de emisiones es el conjunto de políticas, roles, procesos y controles que determinan cómo se captura, valida, almacena y reporta la información sobre gases de efecto invernadero generados por operaciones —en este caso, principalmente por buques y flotas comerciales. Sin una capa de gobierno clara sobre esos datos, las declaraciones de descarbonización se vuelven inauditables: una empresa puede reportar reducciones que ningún tercero puede verificar de forma independiente.

    Por qué el sector marítimo necesita un consejo específico para datos de emisiones

    El transporte marítimo mueve aproximadamente el 80% del comercio mundial y representa, según estimaciones de la Organización Marítima Internacional (OMI), cerca del 2,9% de las emisiones globales de CO₂. La fragmentación regulatoria es intensa: conviven el sistema EU MRV (Monitoring, Reporting and Verification) de la Unión Europea, el sistema IMO DCS (Data Collection System) y marcos nacionales que en muchos casos no son interoperables. El resultado es que un mismo buque puede reportar datos de consumo de combustible bajo tres esquemas distintos con metodologías incompatibles, generando inconsistencias que distorsionan los inventarios de emisiones sectoriales. El nuevo consejo del GRC apunta, según se informó, a crear criterios comunes de definición, recolección y auditoría de datos que puedan funcionar como capa transversal sobre esos regímenes existentes.

    Mecanismo: qué hace concretamente un consejo de gobernanza de datos en este contexto

    Un órgano de este tipo opera, en la práctica, como un comité de data stewardship sectorial. Sus funciones típicas incluyen la definición de un glosario común (¿qué se entiende exactamente por “emisión verificada” versus “emisión estimada”?), el establecimiento de reglas de ownership sobre los datos a lo largo de la cadena —quién es responsable del dato desde el sensor en sala de máquinas hasta el registro en la plataforma de reporte—, y la validación de metodologías de cálculo. Bajo el marco DAMA-DMBOK, esto equivale a activar las disciplinas de Calidad de Datos y Gestión de Metadatos con alcance interorganizacional, lo que es considerablemente más complejo que hacerlo dentro de una sola empresa porque implica acordar estándares entre actores con incentivos distintos: armadores, navieras, clasificadoras y reguladores.

    Cuándo aplica este modelo de gobernanza / cuándo NO

    Este enfoque de consejo sectorial es pertinente cuando el problema de calidad de datos no puede resolverse dentro de una sola organización porque los datos cruzan fronteras organizacionales antes de ser usados para decisiones regulatorias o comerciales. Aplica en sectores con múltiples actores interdependientes: marítimo, energía, cadenas de suministro, salud pública. No aplica —o aplica de forma muy limitada— cuando el problema es interno: si los datos de emisiones son capturados y reportados por una sola empresa bajo un único marco regulatorio, la solución es un programa interno de calidad de datos con un data steward designado, no un consejo interinstitucional. La distinción importa porque los consejos sectoriales tienen costos de coordinación altos y tienden a avanzar lentamente; usarlos para problemas que pueden resolverse internamente es un error de diseño frecuente.

    La perspectiva de América Latina: puertos y flotas bajo marcos de reporte disímiles

    Para los países latinoamericanos con actividad portuaria significativa —Brasil, México, Chile, Panamá, Argentina— la iniciativa del GRC tiene implicancias directas. Las flotas que hacen escala en puertos europeos ya están sujetas al EU MRV; las que operan exclusivamente en rutas regionales quedan bajo el IMO DCS y las normativas nacionales, que en la mayoría de los casos carecen de requisitos de verificación independiente de los datos. En Brasil, la ANTAQ (Agência Nacional de Transportes Aquaviários) regula el sector pero no ha establecido aún un esquema de data governance para emisiones equiparable al EU MRV. En Argentina, la Subsecretaría de Puertos y Vías Navegables tampoco cuenta con un marco estandarizado de recolección de datos de emisiones para la flota fluvial y de cabotaje. Eso significa que operadores latinoamericanos que quieran acceder a mercados o financiamiento verde en los próximos años tendrán que adaptar sus sistemas de datos a estándares que se están definiendo hoy en foros como el que impulsa el GRC, sin haber participado activamente en su diseño.

    Para quienes administran datos en organizaciones del sector marítimo o de logística regional, el movimiento del GRC es una señal de que los estándares de reporte de emisiones van a converger —y que el costo de no tener una arquitectura de datos de emisiones auditables hoy será, en pocos años, el costo de rehacerla bajo presión regulatoria. La referencia para profundizar es el marco de reporte del IMO DCS y la regulación EU MRV (Reglamento UE 2015/757), ambos disponibles en los sitios oficiales de la OMI y la Comisión Europea.

  • Brecha en proveedor electoral de Carolina del Norte expone datos de fiscales de mesa

    Brecha en proveedor electoral de Carolina del Norte expone datos de fiscales de mesa

    El Consejo Electoral del Condado de Wake, en Carolina del Norte, suspendió el uso de un proveedor de software tras reportar un posible ciberataque que habría expuesto datos personales de trabajadores electorales. Los sistemas de votación, padrón electoral y conteo de votos no registran evidencia de compromiso, según informó el organismo.

    El incidente se conoció el 15 de agosto de 2026, cuando el Consejo Electoral de Wake dio a conocer que había cortado su relación operativa con el proveedor afectado como medida preventiva. Según se informó, la información potencialmente expuesta corresponde a personas que se desempeñaron como fiscales o trabajadores de mesa en procesos electorales anteriores, no a votantes ni a datos del padrón general. El vector del ataque y la cantidad exacta de registros comprometidos no habían sido confirmados al momento de la publicación.

    Datos confirmados al cierre de esta edición

    • Actor afectado: Consejo Electoral del Condado de Wake, Carolina del Norte (EE. UU.).
    • Tipo de dato expuesto: información personal de trabajadores electorales (poll workers), según se informó.
    • Sistemas electorales críticos —máquinas de votación, boletas, padrón, conteo— declarados sin evidencia de afectación.
    • Medida adoptada: suspensión inmediata del proveedor de software involucrado.
    • Número de registros comprometidos: no confirmado a la fecha de publicación.
    • Naturaleza del ataque: calificado como “posible ciberataque”; autoría y método sin confirmar.

    Qué se sabe y qué falta confirmar

    Lo confirmado es que el proveedor reportó el incidente al Consejo Electoral y que este actuó suspendiendo el contrato como medida de contención. Lo que permanece sin verificar es si hubo exfiltración efectiva de datos, qué volumen de registros pudo haberse comprometido, y si el proveedor cumplió con los plazos de notificación exigidos por la ley estatal de Carolina del Norte. Tampoco se ha confirmado si el acceso fue mediante ransomware, phishing dirigido u otro vector. El uso del término “posible” sugiere que la investigación forense aún no estaba concluida al momento de la divulgación pública.

    El caso pone el foco en un eslabón frecuentemente subestimado: los proveedores terceros de software que gestionan datos operativos de procesos electorales. En América Latina, donde varios países contratan empresas privadas para la gestión de sistemas de apoyo electoral —desde Argentina hasta México y Brasil—, la cadena de custodia de datos de personal electoral rara vez está cubierta por los marcos de notificación de incidentes con plazos explícitos. La Ley 25.326 argentina, la LGPD brasileña y la LFPDPPP mexicana obligan a notificar brechas que afecten datos personales, pero la velocidad y transparencia de esa notificación depende en gran medida de cláusulas contractuales con los terceros, que en muchos casos no están estandarizadas para el contexto electoral.

    El próximo hito a seguir es la publicación del informe forense del proveedor y la determinación oficial de si corresponde notificación individual a los trabajadores electorales afectados, conforme a la normativa de Carolina del Norte.

  • Retención de talento en IA: por qué el dinero no alcanza

    Retención de talento en IA: por qué el dinero no alcanza

    Que una compañía ofrezca compensación promedio de 1,5 millones de dólares por empleado no garantiza retención: OpenAI lo comprobó en 2025, cuando registró salidas de alto perfil pese a ese esquema, según reportó MIT Sloan Management Review. El fenómeno expone una tensión estructural en la industria de la inteligencia artificial que va mucho más allá de los salarios.

    La guerra por el talento en IA tiene una particularidad que la distingue de otros mercados laborales: los perfiles más valiosos son también los más difíciles de vincular mediante incentivos puramente económicos. Cuando Meta —según se informó— extendía ofertas en los cientos de millones de dólares a investigadores específicos de OpenAI, la pregunta dejó de ser cuánto pagar y pasó a ser qué más puede ofrecer una organización que el dinero no compra.

    Por qué la compensación récord de OpenAI no fue suficiente

    La compensación basada en acciones que OpenAI implementó en 2025 —sin precedentes para una empresa pre-IPO— funcionó como señal de valoración, no como ancla de permanencia. Los investigadores y líderes técnicos que se fueron no lo hicieron por falta de dinero: según se informó, las motivaciones incluyeron diferencias sobre la dirección del producto, la velocidad de comercialización, el acceso a recursos computacionales y, en algunos casos, discrepancias sobre el enfoque en seguridad y alineación de los modelos. Estas son variables que ningún paquete de equity resuelve directamente.

    El patrón no es exclusivo de OpenAI. En toda la industria de los grandes modelos de lenguaje y sistemas de IA de frontera, las organizaciones enfrentan el mismo dilema: los empleados más críticos tienen suficiente capital humano para elegir dónde trabajar y, con frecuencia, eligen en función de la misión, la autonomía técnica y la percepción de impacto más que del número de ceros en el contrato.

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

    Este marco es relevante para roles de alto impacto técnico en IA —investigadores de modelos de frontera, líderes de producto con visibilidad estratégica, ingenieros con expertise difícil de reemplazar— donde el mercado laboral es genuinamente competitivo y la oferta de talento es escasa. No aplica de manera directa a roles de IA más estandarizados, donde la compensación sigue siendo el principal diferenciador. La distinción importa porque las estrategias de retención que funcionan para un perfil pueden ser inefectivas o hasta contraproducentes para el otro.

    Implicancias legales y regulatorias: cláusulas, acuerdos de no competencia e IA

    La retención de talento en IA tiene una dimensión legal que se vuelve cada vez más relevante en América Latina. En Estados Unidos, la FTC intentó —sin éxito definitivo, dado que la regla fue bloqueada judicialmente en 2024— prohibir los acuerdos de no competencia a nivel federal. Ese debate cruzó al sur del continente: en Brasil, los pactos de non-compete post-contractual son válidos si tienen compensación económica proporcional al período de restricción, según la jurisprudencia del Tribunal Superior do Trabalho. En Argentina, la Ley de Contrato de Trabajo permite cláusulas de exclusividad durante la relación laboral, pero las de no competencia post-empleo tienen alcance limitado y son objeto de litigio frecuente. En México, el marco es aún más restrictivo para el empleador, ya que la Ley Federal del Trabajo prioriza la libertad de trabajo.

    Esto tiene consecuencias prácticas para las empresas de IA que operan o tienen equipos en la región: los mecanismos legales de retención que funcionan en jurisdicciones anglosajonas no son trasplantables sin adaptación. Las cláusulas de vesting de equity, los acuerdos de confidencialidad sobre modelos propietarios y los pactos de no solicitud de clientes o empleados deben ser estructurados con asistencia jurídica local para tener eficacia real.

    Propiedad intelectual sobre los modelos: el riesgo menos visible

    Hay otro eje legal que la batalla por el talento en IA pone sobre la mesa: ¿qué conocimiento se va con el empleado y qué queda en la empresa? En el contexto de los modelos de lenguaje, la frontera entre know-how personal y propiedad intelectual corporativa es difusa. Un investigador que participó en el diseño de una arquitectura de modelo, en la definición de los datos de entrenamiento o en las técnicas de fine-tuning lleva consigo conocimiento que difícilmente puede ser contenido por un acuerdo de confidencialidad estándar. Las organizaciones que no han formalizado la trazabilidad de sus decisiones de diseño —quién contribuyó qué, bajo qué acuerdo— quedan expuestas cuando ese talento se va a un competidor.

    En América Latina, la legislación de propiedad intelectual sobre software y obras derivadas de IA es heterogénea. Brasil reconoce los derechos de autor sobre software mediante la Lei 9.609/1998, pero la titularidad de outputs generados con herramientas de IA sigue siendo materia de debate doctrinal. Argentina, Colombia y Chile tienen marcos similares para software, pero ninguno contempla aún de manera explícita la situación de los modelos de IA como objeto protegible autónomo.

    Lo que las organizaciones pueden estructurar más allá del salario

    La evidencia del caso OpenAI sugiere que las palancas de retención más efectivas para talento de IA crítico son no monetarias o complementarias al dinero: acceso a infraestructura de cómputo de punta, libertad para publicar investigación, participación real en decisiones de producto, cultura de seguridad y alineación cuando eso es un valor genuino del empleado. Estas variables son más difíciles de replicar por un competidor que un paquete de compensación, porque están atadas a la cultura y la estructura de la organización. Para las empresas de la región que no pueden igualar las cifras de OpenAI o Meta, este es precisamente el terreno donde pueden competir.

    Para los equipos legales y de recursos humanos en América Latina, el caso sirve como recordatorio urgente: los contratos de talento en IA necesitan revisión en tres frentes simultáneos —cláusulas de propiedad intelectual sobre contribuciones a modelos, acuerdos de confidencialidad adaptados al entorno local, y mecanismos de vesting que sean ejecutables en cada jurisdicción— antes de que el próximo investigador clave reciba una oferta de la competencia.

  • Automejora recursiva de IA: por qué el salto explosivo podría llegar más tarde

    Automejora recursiva de IA: por qué el salto explosivo podría llegar más tarde

    La promesa de que la inteligencia artificial se mejorará a sí misma con mínima supervisión humana —lo que la literatura técnica llama automejora recursiva— enfrenta obstáculos concretos que los pronósticos más optimistas tienden a subestimar. Según un análisis publicado por MIT Technology Review, ese salto explosivo podría no llegar tan pronto como sugieren las proyecciones más difundidas del sector.

    La automejora recursiva describe un proceso en el que un sistema de inteligencia artificial es capaz de reescribir su propio código, generar datos sintéticos para su propio entrenamiento y optimizar el hardware sobre el que opera, todo ello sin intervención humana relevante. Los modelos de lenguaje de gran escala (LLMs) ya realizan algunas de estas tareas de forma parcial: escriben código funcional, producen datos sintéticos y participan en la optimización de arquitecturas de chips. El debate no es si estas capacidades existen, sino si pueden encadenarse de forma autónoma y acumulativa hasta producir un ciclo de mejora sostenida.

    Qué requiere realmente el ciclo de automejora

    Para que la automejora recursiva funcione como la describen sus defensores, no basta con que un modelo genere código: ese código debe mejorar al propio modelo de forma medible, y esa mejora debe poder retroalimentarse en ciclos sucesivos sin degradación ni pérdida de alineación. Cada uno de esos pasos introduce fricciones que los benchmarks actuales no logran capturar con precisión. Los sistemas de evaluación que los modelos usan para medir su propio progreso son, en muchos casos, construidos por los mismos modelos, lo que introduce sesgos de autovalidación difíciles de detectar desde afuera.

    A esto se suma el problema del compute: cada iteración de mejora exige más capacidad de cómputo, más datos de calidad y más tiempo de ingeniería humana para verificar que el resultado es efectivamente mejor y no solo diferente. La curva de rendimientos puede volverse decreciente mucho antes del punto de inflexión que los optimistas anticipan.

    Cuándo aplica el concepto y cuándo no

    La automejora recursiva aplica, en sentido estricto, cuando un sistema modifica sus propios parámetros o arquitectura de forma autónoma y verifica que el cambio produce ganancias reales en tareas relevantes. No aplica cuando un modelo simplemente genera código que un ingeniero luego revisa, integra y evalúa: ese proceso sigue siendo asistido por humanos, no autónomo. Tampoco aplica cuando los “avances” son mejoras en benchmarks diseñados por el mismo equipo que entrena el modelo, sin validación independiente. La distinción importa porque buena parte de las afirmaciones actuales del sector cae en esta segunda categoría.

    El marco regulatorio de la UE ya anticipa este escenario

    El AI Act de la Unión Europea, vigente desde agosto de 2024 en sus disposiciones generales, contempla explícitamente los sistemas de IA con capacidad de auto-modificación como una categoría que requiere evaluaciones de conformidad reforzadas. El artículo 9 del AI Act exige que los sistemas de alto riesgo cuenten con sistemas de gestión de riesgos capaces de actualizarse ante comportamientos nuevos o no anticipados. Si un modelo puede reescribirse a sí mismo, ese requisito se vuelve técnicamente complejo de cumplir: ¿quién certifica la versión modificada?

    En América Latina, ningún marco regulatorio vigente aborda todavía la automejora recursiva de forma explícita. El proyecto de ley de inteligencia artificial en Brasil, en discusión en el Congreso durante 2025 y 2026, establece obligaciones de transparencia y evaluación de impacto para sistemas de IA de alto riesgo, pero no define umbrales técnicos específicos para sistemas auto-modificables. En Argentina, la Secretaría de Innovación Pública publicó lineamientos de IA en 2023 que priorizan el uso responsable, sin cubrir escenarios de autonomía avanzada. La brecha regulatoria es real y creciente.

    Qué implica esto para quienes toman decisiones sobre adopción de IA

    La narrativa del “despegue inminente” tiene consecuencias prácticas: organizaciones que planifican estrategias de IA asumiendo que los modelos serán radicalmente más capaces en 12 o 18 meses pueden sobredimensionar inversiones o posponer decisiones de governance bajo la premisa de que “todo cambiará pronto”. El análisis de MIT Technology Review sugiere que ese horizonte es más incierto de lo que los titulares indican. Para los equipos de gobierno de datos y las áreas legales que evalúan contratos con proveedores de IA, esto tiene una consecuencia directa: las cláusulas de actualización automática de modelos y las garantías de comportamiento estable cobran mayor relevancia cuando no se puede predecir con certeza cuándo ni cómo un modelo evolucionará.

    El debate sobre automejora recursiva no es solo técnico: es un debate sobre cuánto riesgo se externaliza hacia sistemas que nadie puede auditar completamente. En ese contexto, la supervisión humana no es un obstáculo a superar; es, por ahora, el único mecanismo de verificación disponible.

    El análisis completo de MIT Technology Review está disponible en technologyreview.com; para el marco normativo aplicable en la UE, el texto del AI Act puede consultarse en el Diario Oficial de la Unión Europea (Reglamento 2024/1689).

  • Gobernanza de datos en salud: por qué los registros clínicos exigen un marco propio

    Gobernanza de datos en salud: por qué los registros clínicos exigen un marco propio

    Los datos de salud son la categoría más sensible que gestiona cualquier organización, y los marcos genéricos de gobernanza de datos rara vez alcanzan para protegerlos y aprovecharlos al mismo tiempo. La gobernanza de datos clínicos requiere controles específicos sobre calidad, acceso, linaje y consentimiento que van más allá de las políticas corporativas estándar.

    Cuando un hospital o una aseguradora habla de “dato de paciente”, está hablando de información que puede determinar un diagnóstico, condicionar una cobertura o alimentar un modelo predictivo de riesgo. Ese dato no es equivalente a un registro de cliente en un CRM: tiene ciclos de vida que duran décadas, múltiples custodios simultáneos —médico tratante, institución, laboratorio, pagador— y restricciones de uso que emanan tanto de la ética clínica como del derecho. Sin una arquitectura de gobernanza diseñada para esa complejidad, el dato clínico se vuelve un pasivo antes que un activo.

    Por qué el dato clínico rompe los modelos de gobernanza convencionales

    Un framework como DAMA-DMBOK define las disciplinas de gobernanza —calidad, seguridad, arquitectura, metadatos— de forma transversal a industrias. Pero en salud esas disciplinas se cargan con requisitos adicionales que no aparecen en ningún otro sector: el consentimiento informado como condición de tratamiento de datos, la obligación de conservar ciertos registros por plazos fijados por norma (en muchos países, entre cinco y diez años como mínimo), y la necesidad de auditar no solo quién accedió al dato sino con qué propósito clínico lo hizo. El concepto de data stewardship —la asignación de responsabilidad sobre un dominio de datos a una persona o rol específico— adquiere en salud una dimensión ética que va más allá del cumplimiento técnico.

    A esto se suma la fragmentación. Un sistema de salud típico de mediana escala opera con al menos tres o cuatro sistemas de origen —historia clínica electrónica, laboratorio, imágenes, facturación— que rara vez comparten identificadores únicos de paciente, formatos de fecha o catálogos de códigos diagnósticos. Sin data lineage claro que trace el recorrido de cada registro desde su origen hasta su uso en un dashboard o un modelo, cualquier decisión clínica basada en datos acumula un riesgo silencioso de inconsistencia.

    Los tres controles que ningún programa de salud debería omitir

    Los programas de gobernanza de datos más maduros en el sector identifican al menos tres controles que funcionan como base mínima operativa:

    • Clasificación de datos con etiquetas de sensibilidad clínica: no todos los datos de un expediente tienen el mismo nivel de exposición. Diagnósticos de salud mental, información genética o datos de adicciones requieren controles de acceso más restrictivos que, por ejemplo, la fecha de una consulta de rutina. Un catálogo de datos sin clasificación granular impide aplicar controles diferenciados.
    • Gobierno del consentimiento como dato estructurado: el consentimiento del paciente no puede vivir solo como un PDF escaneado en el expediente. Para ser gobernable, debe estar registrado como metadato vinculado al dato que autoriza, con fecha, alcance y posibilidad de revocación trazable.
    • Data quality checks en punto de captura: los errores de calidad en salud —un peso en libras donde se esperan kilogramos, una fecha de nacimiento con año incorrecto— tienen consecuencias clínicas directas. Las reglas de calidad deben ejecutarse en el momento de ingreso del dato, no como limpieza posterior.

    El marco regulatorio en América Latina: obligaciones que ya están vigentes

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como datos sensibles y exige base legal específica para su tratamiento —consentimiento explícito o necesidad de tutela de la salud—, con obligaciones reforzadas de seguridad. La Autoridade Nacional de Proteção de Dados (ANPD) ha señalado al sector salud como prioritario en su agenda de fiscalización. En Argentina, la Ley 25.326 de Protección de los Datos Personales establece que los archivos de datos médicos solo pueden ser recolectados con finalidad directamente vinculada al tratamiento del paciente, y su acceso está restringido al personal sanitario bajo secreto profesional. La Agencia de Acceso a la Información Pública (AAIP) tiene competencia para sancionar el uso indebido de esos registros. En México, la LFPDPPP y su reglamento incluyen a los datos de salud en la categoría de datos sensibles, con requisitos de aviso de privacidad reforzado y consentimiento expreso. Ninguno de estos marcos es opcional: son el piso desde el que debe construirse cualquier programa de gobernanza en la región.

    La convergencia entre regulación de protección de datos y estándares de interoperabilidad clínica —como HL7 FHIR, que define cómo se intercambian registros entre sistemas— está presionando a los equipos de datos de salud a integrar capacidades de gobernanza que antes eran independientes. Un CDO de una red hospitalaria hoy necesita hablar tanto de ISO/IEC 27001 como de FHIR R4 y de los requisitos de la ANPD o la AAIP en la misma reunión.

    Cuándo aplica este tipo de gobernanza especializada y cuándo no

    La gobernanza de datos clínicos aplica a cualquier organización que trate datos de salud como parte de su operación principal: hospitales, clínicas, laboratorios, aseguradoras de salud, empresas de telemedicina y proveedores de tecnología que procesen esos datos por cuenta de instituciones médicas. No aplica —o aplica de forma marginal— a empresas que solo recopilan datos de bienestar general sin correlato clínico, como aplicaciones de fitness que no integran diagnósticos ni prescripciones. La distinción importa porque define si las obligaciones de las leyes de datos sensibles rigen plenamente o solo de forma parcial.

    Para los equipos que gestionan datos de salud en la región, el punto de partida concreto es auditar el catálogo de datos existente contra las categorías de sensibilidad definidas por la regulación local, identificar qué datos carecen de data steward asignado y qué consentimientos no tienen registro estructurado. Esas tres brechas son las que más frecuentemente generan exposición regulatoria y degradan la calidad de los datos disponibles para la toma de decisiones clínicas.

    El marco regulatorio latinoamericano ya establece obligaciones concretas sobre datos de salud; la pregunta para cada organización no es si debe cumplirlas, sino si su programa de gobernanza actual tiene la granularidad necesaria para hacerlo de forma demostrable ante una autoridad de control.

  • Nueva Jersey, tercer estado de EE.UU. en regular precios algorítmicos en 2026

    Nueva Jersey, tercer estado de EE.UU. en regular precios algorítmicos en 2026

    Nueva Jersey promulgó en 2026 una ley que regula la fijación de precios mediante algoritmos e inteligencia artificial, convirtiéndose en el tercer estado de Estados Unidos en hacerlo en lo que va del año. La aceleración legislativa en torno a los llamados “precios de vigilancia” —que usan datos personales para personalizar lo que cada consumidor paga— plantea un modelo regulatorio que ya empieza a resonar en los debates de América Latina.

    El 4 de agosto de 2026, el Comité Judicial del Senado de Estados Unidos celebró una audiencia titulada “Your Data, Their Profit: The Consumer Cost of AI Surveillance Pricing” —”Tus datos, su ganancia: el costo para el consumidor del pricing de vigilancia con IA”—, según informó el Future of Privacy Forum (FPF). La audiencia refleja el nivel de atención política que ha alcanzado una práctica hasta hace poco poco regulada: el uso de datos masivos de comportamiento, historial de compras, geolocalización y perfiles socioeconómicos para ajustar precios de forma individualizada y, en muchos casos, opaca.

    Qué regulan estos tres estados y qué tienen en común

    De acuerdo con el seguimiento legislativo del FPF, al menos tres estados —siendo Nueva Jersey el más reciente— aprobaron en 2026 normas que abordan la fijación de precios basada en datos. Si bien los textos varían, el núcleo regulatorio comparte elementos: obligaciones de transparencia hacia el consumidor sobre el uso de datos en la determinación del precio, restricciones al uso de categorías sensibles como raza, situación económica o historial médico para discriminar precios, y en algunos casos, derechos de oposición o acceso a la lógica de fijación. El término que unifica estas leyes en el debate político estadounidense es “surveillance pricing” —precios de vigilancia—, acuñado para describir sistemas que monitorizan el comportamiento del usuario en tiempo real para maximizar el precio que cada individuo está dispuesto a pagar.

    El fenómeno no es menor en términos de impacto económico. Sectores como retail, plataformas de transporte, turismo, seguros y servicios financieros llevan años aplicando variantes de esta lógica. La diferencia en 2026 es que los legisladores empezaron a tratarlo no solo como un problema de competencia o de mercado, sino como un asunto de derechos vinculado al uso de datos personales.

    Por qué el precio personalizado es también un asunto de datos personales

    La distinción importa porque define quién regula y con qué herramientas. Si el pricing algorítmico se encuadra como práctica anticompetitiva, corresponde a las autoridades de defensa de la competencia. Si se encuadra como tratamiento de datos personales, entran en juego las autoridades de protección de datos y los derechos de los titulares. En Estados Unidos, donde no existe una ley federal de privacidad general, la respuesta está siendo fragmentada y estatal. En América Latina, el panorama es distinto: la mayoría de los países cuenta con leyes generales de protección de datos personales que ya podrían alcanzar, al menos parcialmente, estas prácticas.

    En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) exige base legal para el tratamiento de datos personales y reconoce el derecho a la revisión de decisiones automatizadas que afecten intereses del titular —artículo 20—. El pricing personalizado basado en perfiles de comportamiento podría encuadrar en decisiones automatizadas sujetas a ese artículo, aunque la Autoridade Nacional de Proteção de Dados (ANPD) no ha emitido aún una guía específica sobre el tema. En Argentina, la Ley 25.326 de Protección de los Datos Personales contempla el derecho de acceso y la prohibición de decisiones que produzcan efectos jurídicos o significativos basadas exclusivamente en tratamientos automatizados —artículo 16—, aunque la regulación sobre IA y pricing no ha avanzado de forma explícita. En México, la LFPDPPP y su reglamento establecen bases para el tratamiento de datos con fines de perfilamiento comercial, y el INAI ha publicado criterios sobre decisiones automatizadas, aunque tampoco existe regulación sectorial específica sobre precios algorítmicos.

    Chile y Colombia: las regulaciones más avanzadas de la región en datos y IA

    Chile aprobó en 2024 la Ley 21.719 de Protección de Datos Personales, que moderniza el marco regulatorio e incorpora disposiciones sobre decisiones automatizadas con impacto significativo en los titulares. Su autoridad de control, el Consejo para la Transparencia en transición hacia la nueva Agencia de Protección de Datos, deberá definir en los próximos años si el pricing algorítmico cae bajo su ámbito. Colombia, por su parte, trabaja desde hace años con la Ley 1581 de 2012 y cuenta con la Superintendencia de Industria y Comercio (SIC) como autoridad dual de competencia y protección de datos, lo que la posiciona de forma única para abordar el pricing algorítmico desde ambos ángulos simultáneamente. Ninguno de los dos países ha iniciado, según información disponible, un proceso regulatorio específico sobre surveillance pricing, pero ambos tienen los marcos base para hacerlo.

    Qué sigue: el Senado de EE.UU. y la presión sobre plataformas globales

    La audiencia senatorial del 4 de agosto de 2026 sugiere que el debate no se quedará en el nivel estatal. Si el Congreso de Estados Unidos avanza hacia una regulación federal sobre pricing algorítmico, el impacto se extendería de forma directa a plataformas que operan en América Latina —desde marketplaces hasta servicios de streaming, turismo y fintech—. Las empresas con presencia regional que ajusten precios mediante algoritmos basados en datos de usuarios latinoamericanos deberían revisar si esas prácticas están cubiertas por sus políticas de privacidad actuales y si cumplen con las obligaciones de informar el tratamiento que habilita la personalización de precios.

    Los próximos hitos a monitorear incluyen: el avance de una posible iniciativa federal en Estados Unidos tras la audiencia senatorial, la emisión de guías por parte de la ANPD en Brasil sobre decisiones automatizadas con impacto económico, y el inicio de operaciones de la nueva Agencia de Protección de Datos de Chile, que deberá definir su agenda de supervisión sectorial.

    Nuestro análisis

    El movimiento legislativo en Estados Unidos tiene un valor señalizador claro: cuando tres estados actúan en simultáneo sobre el mismo fenómeno en un solo año, el riesgo de que la presión se traslade a nivel federal —y eventualmente a mercados interconectados— aumenta. Para las empresas que operan en América Latina, el riesgo regulatorio inmediato no viene de Washington sino de las autoridades locales. La LGPD ya tiene las herramientas para sancionar prácticas de perfilamiento sin base legal adecuada; la SIC colombiana combina competencia y privacidad en un mismo órgano; y Chile estrena autoridad con mandato moderno. Lo que falta en la región no es legislación base sino doctrina administrativa: guías, criterios y —eventualmente— sanciones que conviertan el marco general en una obligación operativa concreta para quienes usan datos para fijar precios.

    La pregunta que los equipos legales y de datos de la región deberían hacerse hoy no es si el surveillance pricing es legal en abstracto, sino si sus políticas de privacidad describen con precisión suficiente el tratamiento de datos que habilita esa personalización de precios —y si esa descripción sobreviviría un requerimiento de información de la ANPD, la SIC o la futura Agencia chilena.

  • La caja negra del uso de IA: por qué no podemos verificar lo que dicen Anthropic y OpenAI

    La caja negra del uso de IA: por qué no podemos verificar lo que dicen Anthropic y OpenAI

    Anthropic y OpenAI publican reportes periódicos sobre cómo sus usuarios utilizan Claude y ChatGPT, pero investigadores en inteligencia artificial advierten que esos datos son curados por las propias empresas: no existe fuente independiente que los corrobore. La opacidad sobre los patrones reales de uso tiene implicancias directas para cualquier intento de regular estos sistemas.

    Cada vez que una compañía de IA publica estadísticas de uso, el mensaje implícito es tranquilizador: los usuarios adoptan la tecnología para tareas productivas, creativas o educativas. Pero ese relato lo construyen las mismas empresas con los datos que deciden divulgar. Anka Reuel, candidata doctoral en el Stanford Trustworthy AI Research, lo sintetiza con precisión: “No existe una fuente independiente para corroborarlo”. Ese vacío no es un detalle metodológico menor — es una falla estructural en la gobernanza de los sistemas de inteligencia artificial más usados del mundo.

    Autorregulación sin auditoría: el modelo actual de divulgación

    El mecanismo de divulgación vigente en la industria funciona de manera simple: las empresas recopilan datos masivos sobre interacciones de sus plataformas, seleccionan los hallazgos que consideran relevantes o favorables, y los publican bajo la forma de reportes de transparencia o estudios de uso. No hay un tercero que acceda a los datos brutos, no hay protocolo estandarizado de reporte, y no hay obligación legal — en la mayoría de las jurisdicciones — de revelar métricas específicas sobre comportamiento de usuarios. El resultado es que el campo de estudio sobre el impacto real de la IA en la sociedad depende, paradójicamente, de la buena voluntad de los actores más interesados en que esa narrativa sea positiva.

    El problema se profundiza porque los usos que no se reportan pueden ser los más relevantes desde el punto de vista de riesgo: generación de desinformación, asistencia en tareas con consecuencias legales o médicas sin supervisión profesional, o patrones de dependencia cognitiva. Sin acceso a datos desagregados y auditados, los investigadores deben construir sus propios estudios con muestras pequeñas, encuestas autoreportadas o experimentos de laboratorio que difícilmente capturan el comportamiento real a escala.

    Cuándo esta opacidad viola un marco normativo — y cuándo no

    La ausencia de datos verificables sobre uso de IA no es ilegal en la mayoría de los países, pero entra en tensión creciente con marcos regulatorios que exigen transparencia. El AI Act de la Unión Europea, vigente desde agosto de 2024, impone obligaciones de documentación técnica y registros de sistemas de IA de alto riesgo, y establece que los modelos de propósito general con impacto sistémico deben someterse a evaluaciones independientes. Sin embargo, la definición de qué datos de uso deben compartirse con reguladores — y en qué formato — sigue siendo objeto de negociación técnica en los actos delegados que la Comisión Europea todavía está terminando de redactar.

    El AI Act no aplica directamente en América Latina, pero fija el estándar de referencia al que varios países de la región miran para construir sus propios marcos. En Brasil, el Proyecto de Ley 2.338/2023 — conocido como el PL de IA — incluye disposiciones sobre transparencia y auditoría de sistemas automatizados de alto impacto, aunque en sus versiones más recientes el alcance de las obligaciones de divulgación de datos de uso quedó acotado frente al texto original. En Argentina, la Estrategia Nacional de Inteligencia Artificial no establece obligaciones de reporte para proveedores de modelos fundacionales. Chile y Colombia avanzan con marcos voluntarios que, por definición, reproducen el mismo problema: las empresas reportan lo que quieren.

    Por qué los datos de uso son centrales para la regulación efectiva

    El debate sobre qué regular en IA depende, en gran medida, de entender qué hacen realmente los usuarios con estos sistemas. Si la mayoría de las interacciones de alto riesgo ocurren en dominios que las empresas no reportan — salud, asesoramiento legal informal, contenido generado para influir en decisiones electorales — entonces los marcos regulatorios que se construyan sin ese conocimiento serán, en el mejor caso, incompletos. Los reguladores latinoamericanos que hoy diseñan normativas sobre IA están trabajando con una información base que proviene casi exclusivamente de las empresas que buscan operar en sus mercados.

    La situación tiene un paralelo con los primeros años de las redes sociales, cuando Facebook y Twitter controlaban los datos sobre propagación de contenido hasta que escándalos como Cambridge Analytica forzaron una apertura parcial y reluctante. La diferencia es que los modelos de lenguaje generan interacciones más íntimas, más difíciles de categorizar, y con consecuencias potencialmente más directas sobre decisiones individuales. Esperar un escándalo equivalente para obtener acceso a datos independientes sería una estrategia regulatoria costosa.

    Alternativas que los reguladores pueden exigir ahora

    La investigación independiente sobre uso de IA no requiere necesariamente acceso a datos en bruto con información personal de los usuarios — lo que crearía tensiones legítimas con marcos de protección de datos como la LGPD brasileña o la Ley 25.326 argentina. Existen mecanismos intermedios que algunos reguladores ya contemplan:

    • Auditorías de terceros con acceso a datos anonimizados y agregados, bajo acuerdos de confidencialidad con supervisión regulatoria.
    • Obligación de reportar categorías de uso definidas por la autoridad competente, no por la empresa.
    • Registros de incidentes con impacto en usuarios que las plataformas deben notificar a organismos como el MCTIC en Brasil o la AAIP en Argentina.
    • Habilitación de investigadores académicos acreditados para acceder a datos bajo entornos de análisis seguros, siguiendo el modelo del Digital Services Act europeo para plataformas muy grandes.

    Ninguno de estos mecanismos está completamente operativo en América Latina para sistemas de IA generativa. El PL 2.338/2023 de Brasil es el instrumento más avanzado en la región, pero su aprobación final y reglamentación todavía están pendientes al momento de esta publicación.

    Mientras los reportes de uso los sigan escribiendo solo quienes tienen interés en el resultado, cualquier política de IA que se base en ellos estará regulando el relato, no la tecnología.