Etiqueta: Ai Privacy

  • Auditoría de visibilidad en LLMs: cómo medir lo que la IA dice de tu empresa

    Auditoría de visibilidad en LLMs: cómo medir lo que la IA dice de tu empresa

    Cuando los motores de búsqueda tradicionales dominaban la visibilidad digital, las empresas podían auditar su posicionamiento con herramientas estándar. Con los grandes modelos de lenguaje (LLMs) como punto de consulta, ese tablero de puntuación desapareció: no hay ranking visible, no hay índice público, no hay certeza sobre qué dice un modelo cuando un usuario pregunta por tu categoría o tu marca.

    El problema tiene nombre propio en el ecosistema de inteligencia artificial aplicada al negocio: LLM visibility audit, o auditoría de visibilidad en modelos de lenguaje. La práctica consiste en medir sistemáticamente cómo —y con qué frecuencia— un LLM menciona, describe o posiciona a una organización, producto o concepto cuando recibe preguntas relevantes de un usuario. No es SEO. No es brand monitoring. Es una disciplina nueva que mezcla evaluación de modelos, ingeniería de prompts y análisis cualitativo de outputs.

    Por qué los LLMs cambian las reglas del juego para cualquier empresa con presencia digital

    Hasta hace poco, la visibilidad online era medible: impresiones, clics, posiciones en SERP, menciones en redes. Los LLMs generativos introducen una capa opaca entre el dato y el usuario. Cuando alguien le pregunta a un chatbot “¿cuál es la mejor solución de observabilidad de datos?” o “¿qué herramientas usan los equipos de datos en Latinoamérica?”, el modelo produce una respuesta sintetizada a partir de su entrenamiento —sin revelar fuentes, sin ordenar resultados, sin ofrecer transparencia sobre por qué menciona a ciertos actores y omite a otros. Para las empresas que compiten en mercados técnicos o de nicho, esa caja negra tiene consecuencias comerciales directas.

    El fenómeno no es trivial: analistas de Gartner proyectaron que para 2026 el tráfico orgánico a sitios web caerá hasta un 25% en sectores donde los LLMs respondan consultas de forma directa. Si el modelo no te menciona, simplemente no existís para ese usuario en ese momento de decisión.

    Cómo se estructura una auditoría de visibilidad en LLMs: cinco capas de análisis

    Una auditoría rigurosa no consiste en preguntarle al modelo “¿conocés a tal empresa?” y anotar el resultado. Requiere un protocolo reproducible que opere sobre al menos cinco dimensiones:

    • Frecuencia de mención: qué porcentaje de prompts relevantes al mercado generan una referencia a la organización auditada, sobre un conjunto de cientos o miles de consultas representativas.
    • Posición en la respuesta: si el modelo menciona a la empresa, ¿lo hace en primer lugar, en una lista, como alternativa secundaria o en un contexto negativo?
    • Exactitud factual: los modelos alucinen con regularidad. Parte de la auditoría consiste en comparar lo que el LLM afirma sobre una organización con lo que es verificablemente cierto: fundación, producto, clientes, geografías.
    • Cobertura de categoría: cuando el modelo define la categoría de mercado a la que pertenece la empresa, ¿la define correctamente? ¿La empresa aparece como referente o como entrante tardío?
    • Varianza entre modelos: GPT-4o, Claude, Gemini y Llama tienen datasets de entrenamiento y fechas de corte distintos. La misma consulta puede generar respuestas radicalmente diferentes entre modelos.

    Cuándo aplica una auditoría de visibilidad en LLMs — y cuándo NO

    Esta práctica es relevante cuando una organización compite en mercados donde los tomadores de decisión usan LLMs como primer punto de investigación: software B2B, consultoría tecnológica, servicios financieros especializados, salud digital. No aplica, o aplica con menor urgencia, para negocios cuyo canal de adquisición es completamente independiente de la búsqueda informacional —ventas directas de campo, marketplaces con algoritmo propio, o marcas de consumo masivo donde la intención de compra no pasa por preguntas abiertas a un chatbot. Tampoco reemplaza la auditoría SEO tradicional: ambas miden canales distintos que coexisten.

    El desafío técnico-legal que llega a LATAM: opacidad de modelos y derechos de rectificación

    En América Latina, la auditoría de visibilidad en LLMs abre una dimensión jurídica que todavía no tiene respuesta clara. Si un modelo afirma algo factualmente incorrecto sobre una empresa o sobre una persona —que una compañía tiene sede en un país distinto, que un profesional fue sancionado cuando no lo fue— ¿quién responde y bajo qué marco? En Brasil, la Lei Geral de Proteção de Dados (LGPD) reconoce el derecho de rectificación de datos inexactos en su artículo 18, inciso III, pero su aplicación sobre outputs de modelos generativos es un territorio sin jurisprudencia consolidada. En Argentina, la Ley 25.326 contempla el derecho de rectificación y actualización de datos personales, con supervisión de la Agencia de Acceso a la Información Pública (AAIP); sin embargo, la AAIP no ha emitido hasta la fecha lineamientos específicos sobre LLMs. México, a través del INAI, enfrenta la misma laguna regulatoria.

    El AI Act de la Unión Europea, aplicable a sistemas de IA de alto riesgo, exige documentación sobre los datos de entrenamiento y mecanismos de supervisión humana, lo que teóricamente permitiría auditar la fuente de una mención incorrecta. Para empresas latinoamericanas que operan o aspiran a operar en el mercado europeo, ese estándar empieza a ser una referencia práctica incluso antes de que exista legislación regional equivalente.

    Tres pasos para iniciar una auditoría de visibilidad sin infraestructura especializada

    No hace falta una plataforma dedicada para comenzar. Un equipo de datos con acceso a las APIs de los principales modelos puede construir un protocolo básico en semanas. El primer paso es definir el universo de consultas: entre 200 y 500 prompts que representen las preguntas reales que un comprador, periodista o investigador haría sobre la categoría. El segundo paso es ejecutar esas consultas de forma sistemática —automatizada vía API, no manual— y registrar los outputs en una estructura comparable. El tercer paso es codificar los resultados: mención positiva, mención neutral, mención negativa, ausencia, error factual. Con esa matriz, es posible calcular una métrica de visibilidad baseline y repetir el proceso cada vez que los modelos publiquen nuevas versiones o actualizaciones de entrenamiento.

    Para quienes diseñan estrategias de posicionamiento de marca o de producto en mercados técnicos, la pregunta ya no es si los LLMs influyen en la percepción —es si sus organizaciones tienen algún instrumento para saberlo antes de que el daño sea visible en pipeline.

  • IA que diseña fármacos: quién se lleva el crédito (y la responsabilidad)

    IA que diseña fármacos: quién se lleva el crédito (y la responsabilidad)

    Cuando Insilico Medicine anunció que su plataforma de inteligencia artificial había “descubierto” una molécula candidata para tratar la fibrosis pulmonar, abrió sin quererlo un debate jurídico que va mucho más allá del marketing farmacéutico: si una IA diseña un fármaco, ¿a quién pertenece ese hallazgo y quién responde si falla?

    La atribución de autoría en ciencia siempre fue complicada. Pero la irrupción de sistemas de inteligencia artificial generativa en el descubrimiento de fármacos agrega una capa de ambigüedad que los marcos legales vigentes —pensados para inventores humanos— no resuelven con claridad. El caso de Insilico Medicine, que usó sus modelos computacionales para proponer una molécula prometedora contra la fibrosis pulmonar, ilustra exactamente esa tensión: la empresa no dudó en atribuirle a su IA el rol de descubridora, una afirmación con consecuencias directas sobre patentes, responsabilidad civil y regulación sanitaria.

    Patentes sin inventor humano: el límite que ya se está probando en tribunales

    El sistema de patentes fue diseñado bajo un supuesto que hoy tambalea: que detrás de cada invención hay una persona física. En Estados Unidos, la Corte de Apelaciones del Circuito Federal resolvió en 2022 que el sistema DABUS —desarrollado por Stephen Thaler— no podía figurar como inventor en una solicitud de patente porque la ley exige que el inventor sea humano. El Reino Unido llegó a la misma conclusión por la vía del Supremo en 2023. La pregunta que queda abierta es cuánto cambia la ecuación cuando la IA no figura como inventora pero es la que, en los hechos, genera la hipótesis central del compuesto.

    Insilico y otras empresas del sector —Exscientia, Recursion, Absci— posicionan a sus plataformas como co-diseñadoras o aceleradoras del proceso de descubrimiento. Desde el punto de vista de la estrategia de propiedad intelectual, esa distinción importa: si la IA “descubre” y el humano solo valida, la solidez jurídica de la patente puede cuestionarse por insuficiencia inventiva humana. Si el humano es quien dirige y la IA es una herramienta sofisticada —equivalente a un espectrómetro de masas muy avanzado—, la patente se sostiene. El lenguaje del press release, entonces, no es inocente.

    Responsabilidad downstream: quién responde cuando el fármaco falla en fase clínica

    La atribución de crédito no es solo una cuestión de ego corporativo o relaciones públicas. Tiene un correlato directo en la cadena de responsabilidad. Si un compuesto propuesto por IA llega a ensayos clínicos y genera efectos adversos imprevistos, los marcos de responsabilidad vigentes necesitan identificar un responsable: ¿el desarrollador del modelo, la empresa farmacéutica que lo adoptó, el equipo científico que validó la hipótesis, o el organismo regulador que habilitó el ensayo? La respuesta depende en parte de cómo se documentó la participación de la IA en cada etapa del proceso.

    Este problema no es teórico. La FDA de Estados Unidos ya publicó lineamientos preliminares sobre el uso de inteligencia artificial y machine learning en el desarrollo de dispositivos médicos, y está trabajando en marcos similares para el proceso de aprobación de nuevos fármacos. La EMA europea sigue una trayectoria paralela. La pregunta es si la atribución narrativa —lo que una empresa dice en un comunicado— puede tener efectos jurídicos en un litigio posterior sobre daños.

    El AI Act europeo y la clasificación de riesgo en aplicaciones biomédicas

    El Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, Reglamento UE 2024/1689) clasifica como sistemas de alto riesgo a aquellos usados en el ámbito de la salud cuando toman o influyen decisiones relevantes. Un sistema de IA que propone moléculas para uso terapéutico humano califica, en principio, dentro de esa categoría: exige documentación técnica exhaustiva, supervisión humana verificable y trazabilidad de las decisiones del modelo. Eso significa que “la IA lo descubrió” no puede ser el final del relato regulatorio —tiene que haber un humano que pueda explicar, auditar y asumir la decisión.

    Cuándo aplica este debate / cuándo NO

    El conflicto de atribución se vuelve jurídicamente relevante cuando el output de la IA es la hipótesis central de una solicitud de patente, cuando el compuesto avanza hacia ensayos en humanos, o cuando la empresa hace afirmaciones públicas sobre la autoría del sistema. No aplica con la misma intensidad cuando la IA funciona como herramienta de cribado masivo (virtual screening) dentro de un proceso en el que el equipo científico genera y selecciona hipótesis de forma sustantiva. La distinción operativa —IA como autor versus IA como instrumento— es la que definirá los casos que lleguen a litigio en los próximos años.

    América Latina: marcos de IA en construcción, sector farmacéutico ya activo

    En la región, el debate llega antes que los marcos regulatorios. Brasil avanza con el Projeto de Lei 2.338/2023 sobre regulación de IA, que incluye disposiciones sobre sistemas de alto riesgo en salud pero no aborda específicamente la atribución de autoría inventiva a sistemas automatizados. Argentina no tiene legislación de IA aprobada al cierre de esta nota, aunque el INPI —Instituto Nacional de la Propiedad Industrial— ya enfrenta solicitudes que implican procesos asistidos por IA. México, por su parte, tiene una industria farmacéutica de escala regional y un IMPI que todavía opera bajo los criterios tradicionales de inventiva humana contemplados en la Ley Federal de Protección a la Propiedad Industrial. Ninguno de los tres países tiene hoy una respuesta clara para la pregunta que Insilico planteó en su press release.

    La presión llegará desde afuera hacia adentro: cuando una empresa extranjera intente patentar en México, Brasil o Argentina un compuesto cuyo origen sea un sistema de IA, las oficinas de propiedad industrial deberán decidir sin doctrina previa. Ese vacío no es neutral —favorece a quien primero defina el marco.

    Para profundizar en el marco regulatorio europeo, el texto completo del AI Act está disponible en el Diario Oficial de la Unión Europea (DO L, 12 de julio de 2024); el Proyecto de Lei 2.338/2023 de Brasil puede consultarse en el sitio del Senado Federal.

  • Bailment e inteligencia artificial: una doctrina del siglo XIX ante las brechas de datos de IA

    Bailment e inteligencia artificial: una doctrina del siglo XIX ante las brechas de datos de IA

    Cuando dos ingenieros de OpenAI presentaron en Black Hat los detalles del incidente de Hugging Face, no esperaban que la respuesta más resonante viniera de una doctrina jurídica que precede a la computadora por más de un siglo: el bailment, o depósito legal anglosajón. La tesis, desarrollada por Jake L. Ramsey del estudio Offit Kurman, propone que la responsabilidad por brechas de datos en sistemas de inteligencia artificial puede —y debería— analizarse bajo la misma lógica con que el derecho común regula la entrega de bienes en custodia.

    El bailment es una figura del common law que describe la relación jurídica que surge cuando una persona entrega un bien a otra para un fin específico, con obligación de devolución o uso conforme a lo pactado. El depositario —quien recibe el bien— asume deberes de cuidado proporcionales al beneficio que obtiene de esa custodia. Si el bien resulta dañado o perdido, la carga de la prueba se invierte: es el depositario quien debe demostrar que actuó diligentemente. Aplicado a datos: quien recibe información de terceros para entrenar o ejecutar un modelo de inteligencia artificial puede quedar, bajo esta lógica, en la posición del depositario.

    El incidente de Hugging Face como caso de prueba para la doctrina

    La presentación en Black Hat que sirvió de detonante fue protagonizada por dos ingenieros de OpenAI, quienes describieron el incidente de Hugging Face —plataforma central en el ecosistema de modelos abiertos— como un escenario con implicancias que van más allá del análisis técnico de vulnerabilidades. Según se informó, sus declaraciones subrayaron tanto la naturaleza del acceso no autorizado como la exposición de datos de terceros almacenados o procesados en la infraestructura de la plataforma. El artículo de Ramsey toma esas afirmaciones como punto de partida para argumentar que la relación entre quienes suben datasets o modelos a plataformas como Hugging Face y la propia plataforma encaja con los elementos constitutivos del bailment: entrega voluntaria, custodia ajena, finalidad determinada y deber de restitución o uso conforme.

    El argumento tiene relevancia práctica inmediata: si un tribunal acepta el encuadre del bailment, la víctima de una brecha de datos no necesita probar negligencia específica. Basta con acreditar que entregó datos al custodio y que esos datos fueron comprometidos. La carga probatoria pasa entonces al proveedor de la plataforma, que debe demostrar haber ejercido el nivel de cuidado exigido por la relación de depósito.

    Por qué la figura del depósito legal presiona a los proveedores de IA más que los marcos actuales

    Los marcos regulatorios vigentes —desde el Reglamento General de Protección de Datos europeo hasta el AI Act— operan sobre la distinción entre responsable y encargado del tratamiento, con obligaciones contractuales y técnicas relativamente bien delimitadas. El bailment, en cambio, no requiere que los datos sean “personales” en sentido legal: aplica sobre cualquier bien entregado en custodia. Eso amplía potencialmente el universo de activos protegidos: modelos propietarios, conjuntos de datos no personales, embeddings, pesos de modelos finetuneados por terceros. Para los proveedores de infraestructura de IA —plataformas de hosting de modelos, entornos de entrenamiento en nube, repositorios colaborativos— la implicancia es que su exposición legal podría ser mayor que la derivada exclusivamente de la normativa de privacidad.

    El debate también tiene consecuencias contractuales directas. Si los términos de servicio de una plataforma no contemplan explícitamente el estándar de cuidado aplicable a los datos y modelos depositados, un tribunal de tradición anglosajona podría inferirlo desde la doctrina del bailment, sin necesidad de que las partes lo hayan pactado. Eso convierte la redacción de cláusulas de responsabilidad en los contratos de servicios de IA en un ejercicio jurídico más complejo de lo que muchos equipos legales anticipan.

    Cuándo aplica la doctrina del bailment sobre datos — y cuándo no

    La doctrina, tal como existe en jurisdicciones de common law (Estados Unidos, Reino Unido, Australia, Canadá), no tiene equivalente directo en los sistemas de derecho civil continental que predominan en América Latina. En Argentina, Brasil, México, Colombia y Chile, la figura más próxima es el contrato de depósito o custodia regulado en los códigos civiles y comerciales, aunque sin la inversión automática de la carga probatoria que caracteriza al bailment. La analogía, sin embargo, no es irrelevante: los principios subyacentes —responsabilidad proporcional al control efectivo sobre el bien ajeno— informan el análisis de responsabilidad civil en cualquier sistema jurídico.

    La doctrina no aplica cuando el proveedor de IA no actúa como custodio sino como mero procesador técnico sin acceso real a los datos, o cuando los datos nunca abandonan el entorno del propio titular. Tampoco aplica, en principio, sobre outputs del modelo —las respuestas generadas— sino sobre los inputs y parámetros entregados al sistema. Esa distinción es importante porque delimita qué tipo de activos quedan potencialmente bajo el estándar de cuidado del depositario.

    La perspectiva desde América Latina: depósito civil, responsabilidad por riesgo y regulación de IA

    En la región, el encuadre jurídico más cercano combina tres fuentes: el contrato de depósito del derecho civil, la responsabilidad objetiva por actividad riesgosa —reconocida en los códigos civiles de Argentina, Brasil y México— y, de forma incipiente, los marcos de gobernanza de inteligencia artificial que varios países están desarrollando. Brasil avanza con el Projeto de Lei 2.338/2023 de regulación de IA, que contempla responsabilidad diferenciada para sistemas de alto riesgo. Colombia publicó en 2023 su marco de ética e IA con lineamientos sobre gestión de riesgos para proveedores. Argentina, por su parte, trabaja en una propuesta de regulación de IA cuya discusión aún no tiene fecha de resolución legislativa confirmada.

    Para los equipos legales y de gobernanza de datos en empresas latinoamericanas que utilizan plataformas internacionales de IA —ya sea para alojar modelos propios o para acceder a modelos de terceros— el argumento del bailment ofrece una señal de alerta concreta: los contratos con proveedores de infraestructura de IA deberían explicitar quién responde, con qué estándar de cuidado y bajo qué ley aplicable, antes de que un incidente lo defina un juez. La brecha entre lo que dicen los términos de servicio estándar y lo que una corte podría imponer bajo doctrinas como el bailment o la responsabilidad por actividad riesgosa es, hoy, sustancial.

    El análisis completo de Jake L. Ramsey está disponible en el blog de Offit Kurman; la presentación de Black Hat sobre el incidente de Hugging Face constituye el punto de partida técnico para quienes quieran evaluar la cadena de hechos que motivó la discusión legal.

  • Gobernanza de datos con IA en minería: qué significa construir bases confiables

    Gobernanza de datos con IA en minería: qué significa construir bases confiables

    La industria minera genera volúmenes masivos de datos operacionales, geológicos y ambientales, y la incorporación de inteligencia artificial a esos flujos no simplifica el problema de gobernanza: lo amplifica. Para que los modelos de IA sean confiables en este sector, los cimientos de datos tienen que estarlo primero.

    La minería es uno de los sectores donde la calidad del dato tiene consecuencias físicas directas: una estimación de reservas mal modelada, un sensor de tolva con datos duplicados o una lectura ambiental sin linaje verificable pueden derivar en decisiones operativas de alto riesgo. Cuando se agrega IA encima de esa infraestructura —modelos predictivos de mantenimiento, optimización de procesos, análisis de variabilidad geológica— la deuda técnica de gobernanza se convierte en deuda de confiabilidad de negocio.

    Qué entiende la industria minera por “datos confiables”

    En el marco del DAMA-DMBOK, la confiabilidad del dato se sostiene sobre al menos cuatro dimensiones: exactitud, completitud, consistencia y linaje (data lineage). En minería, el linaje es especialmente crítico porque los datos recorren un camino largo —sensores IoT en campo, sistemas SCADA, plataformas MES, ERP y finalmente capas analíticas— y cada transformación representa un punto de pérdida de trazabilidad. Un dato que llega limpio a un dashboard puede haberse degradado en tres integraciones previas sin que ningún data steward lo haya detectado.

    El problema se agudiza cuando los modelos de IA consumen esos datos sin que exista un catálogo de datos (data catalog) actualizado que describa origen, frecuencia de actualización, propietario y nivel de calidad de cada dataset. Sin ese inventario, el modelo aprende patrones sobre información cuya confiabilidad nadie puede garantizar formalmente.

    Cuándo aplica un marco de gobernanza de IA / cuándo NO

    Un marco de gobernanza de IA en minería aplica cuando los modelos toman decisiones que afectan operaciones, seguridad o reportes regulatorios —por ejemplo, sistemas de detección de fallas en equipos críticos o modelos de predicción de calidad de mineral que alimentan contratos comerciales. No aplica —o aplica con menor urgencia— cuando la IA se usa en análisis exploratorios internos sin impacto en decisiones formales, aunque incluso allí el riesgo de acostumbrarse a datos de baja calidad es real.

    Tampoco es suficiente aplicar gobernanza de datos genérica. Las normativas ambientales y de seguridad minera en América Latina —como las exigencias de reporte del Servicio Nacional de Geología y Minería (SERNAGEOMIN) en Chile o los estándares de la Agencia Nacional de Minería (ANM) en Brasil— requieren que los datos reportados sean auditables. Si esos datos son generados o transformados por modelos de IA, la cadena de custodia debe estar documentada con precisión.

    Los tres pilares operativos que fallan con más frecuencia en minería

    • Ownership sin autoridad real: Es común que las compañías mineras designen data stewards por área (geología, operaciones, medio ambiente) pero sin mandato formal para rechazar datos de baja calidad que provienen de sistemas legados. El steward documenta el problema; nadie lo resuelve.
    • Linaje roto en integraciones campo-nube: Los sensores IoT en mina raramente cuentan con metadata estructurada desde origen. Cuando esos streams llegan a una plataforma cloud para entrenar modelos, el linaje ya es incompleto. El EDM Council (DCAM) identifica el linaje automatizado como una capability de nivel intermedio que pocas organizaciones industriales han alcanzado.
    • Ausencia de controles de calidad previos al entrenamiento: No existe, en la mayoría de operaciones mineras de la región, un proceso formal de data quality gate antes de que un dataset ingrese a un pipeline de entrenamiento de modelos. El dato llega, el modelo entrena, y los sesgos o errores se heredan silenciosamente.

    Minería en LATAM: regulación ambiental como driver de gobernanza

    En América Latina, la presión regulatoria ambiental está actuando —quizás antes que cualquier marco de IA— como catalizador involuntario de gobernanza de datos. En Chile, las empresas mineras que operan bajo resoluciones de calificación ambiental (RCA) deben reportar periódicamente indicadores de consumo hídrico, emisiones y relaves. Si esos indicadores son calculados mediante modelos automatizados, la auditabilidad del cálculo depende directamente de que exista linaje de datos verificable. En Perú, el Organismo de Evaluación y Fiscalización Ambiental (OEFA) tiene facultades de fiscalización que pueden alcanzar los sistemas de monitoreo digital. En ese contexto, la gobernanza de datos no es una práctica de madurez organizacional: es un requisito implícito de cumplimiento.

    Un CDO o Data Governance Manager en una operación minera latinoamericana debería revisar esta semana si los datasets que alimentan modelos de IA están incluidos en el catálogo corporativo, si tienen un data owner formalmente asignado con nombre y área, y si existe algún registro de las transformaciones aplicadas antes del entrenamiento. Si alguna de esas tres respuestas es negativa, el modelo que corre sobre esos datos no tiene bases confiables, independientemente de su performance técnica.

    Para profundizar en el marco de capacidades de gobernanza aplicable a este sector, el DCAM Assessment del EDM Council (edmcouncil.org) ofrece un punto de partida estructurado; en la región, SERNAGEOMIN y la ANM publican sus estándares de reporte en sus sitios oficiales y pueden usarse como ancla regulatoria para definir qué datos son auditables por obligación.

  • OpenAI promete retención cero de datos para empresas: ¿qué garantiza realmente?

    OpenAI promete retención cero de datos para empresas: ¿qué garantiza realmente?

    OpenAI anunció una política de retención cero de datos para clientes corporativos, en un movimiento que apunta directamente a reducir la ventaja competitiva de Anthropic en el segmento enterprise. La promesa central: los prompts y las respuestas no se almacenan una vez que la sesión termina. Pero el anuncio viene con una capa que merece atención: la compañía también presentó “Private Safety Processing”, un mecanismo de vigilancia automatizada de los inputs que, según informó la empresa, operaría de forma discreta.

    La retención cero de datos —conocida en contratos de servicios cloud como zero data retention o ZDR— es una condición que los equipos legales y de privacidad de grandes organizaciones vienen exigiendo cada vez con más frecuencia al contratar modelos de lenguaje como servicio. Bajo este esquema, el proveedor se compromete a no guardar ningún dato transmitido durante la inferencia: ni el prompt del usuario, ni la respuesta del modelo, ni metadatos asociados a la consulta. Para sectores como salud, banca o servicios jurídicos, donde los prompts pueden contener datos sensibles de clientes o información protegida por secreto profesional, esta condición suele ser el umbral mínimo de negociación.

    Qué significa “retención cero” y qué no cubre

    Una política ZDR no equivale a ausencia total de procesamiento. Los datos aún transitan por la infraestructura del proveedor, son procesados por el modelo y pueden quedar expuestos a mecanismos intermedios de seguridad. Precisamente ahí entra en escena Private Safety Processing: según se informó, OpenAI incorpora un sistema automatizado que analiza los prompts con fines de moderación y seguridad, incluso bajo el esquema de retención cero. La empresa describe este procesamiento como discreto, lo que plantea una pregunta técnica y jurídica inmediata: ¿qué datos se procesan, por cuánto tiempo, con qué base legal y quién los controla?

    Esta distinción importa porque en la mayoría de los marcos de protección de datos vigentes, el procesamiento sin almacenamiento permanente sigue siendo tratamiento de datos personales. La LGPD de Brasil, la Ley 25.326 de Argentina y la LFPDPPP de México exigen que cualquier operación sobre datos personales —incluyendo la simple lectura en memoria— cuente con una base legal habilitante, un propósito declarado y, en muchos casos, un contrato de encargado de tratamiento debidamente suscrito. Que los datos no se “guarden” en un disco no los saca del ámbito regulatorio.

    Cuándo aplica la política ZDR y cuándo no

    La retención cero es relevante cuando los prompts contienen datos personales de terceros, información confidencial protegida por ley o datos sujetos a regulación sectorial —expedientes médicos, datos financieros, información de menores. No aplica, o aplica con matices, cuando el modelo se usa para tareas internas sin datos sensibles, cuando el proveedor opera bajo un acuerdo de procesamiento de datos (DPA) que ya regula la retención, o cuando la organización despliega el modelo en infraestructura propia. En esos casos, la política ZDR es un plus comercial, no una salvaguarda regulatoria crítica.

    También conviene distinguir entre retención cero en inferencia y retención cero en fine-tuning o entrenamiento. Los modelos personalizados con datos del cliente abren una categoría diferente de riesgos: los pesos del modelo podrían codificar, de forma difusa pero real, información presente en los datos de entrenamiento. Una política ZDR sobre inferencia no cubre ese vector.

    El contexto competitivo: Anthropic lleva ventaja en el segmento legal y de salud

    Anthropic construyó parte de su posicionamiento enterprise precisamente sobre compromisos de privacidad más estrictos que los de OpenAI, al menos en la percepción del mercado. Sectores como el legal, el financiero y el sanitario en Estados Unidos —y sus equivalentes en América Latina— eligieron Claude en parte por ese diferencial. El movimiento de OpenAI busca cerrar esa brecha, pero la credibilidad de un compromiso de privacidad no se establece solo con un anuncio: requiere cláusulas contractuales auditables, mecanismos de verificación independiente y, en jurisdicciones con autoridades de control activas, la posibilidad de que esas autoridades revisen el cumplimiento efectivo.

    En América Latina, ese último punto es relevante. La Autoridad Nacional de Protección de Datos de Brasil (ANPD) ha avanzado en lineamientos sobre uso de inteligencia artificial con datos personales, y la Agencia de Acceso a la Información Pública de Argentina (AAIP) ha publicado criterios sobre tratamiento de datos en entornos de IA. Cualquier empresa de la región que evalúe adoptar OpenAI bajo política ZDR debería revisar si el DPA ofrecido por el proveedor es compatible con las exigencias locales de subencargados de tratamiento y transferencias internacionales.

    El problema específico del “safety processing” discreto

    El punto más delicado del anuncio no es la retención cero sino el procesamiento de seguridad que coexiste con ella. Si Private Safety Processing implica que un sistema automatizado analiza el contenido de los prompts —aunque sea para detectar usos prohibidos— esa operación debe estar declarada en la política de privacidad, en el DPA y, si los datos son personales, debe contar con base legal. “Seguridad del servicio” puede constituir un interés legítimo bajo GDPR o LGPD, pero no es automático: requiere un test de proporcionalidad y, en algunos casos, una evaluación de impacto (DPIA). Las empresas que asumen que retención cero equivale a privacidad total asumen demasiado.

    Para los equipos jurídicos y de privacidad en LATAM que evalúan proveedores de IA, la pregunta correcta no es “¿ofrecen retención cero?” sino “¿qué datos procesan, durante cuánto tiempo, bajo qué base legal, y pueden acreditarlo ante una autoridad de control?”. Los documentos contractuales —no los anuncios de producto— son donde esa respuesta debe aparecer.

  • Bibliotecas de anuncios móviles filtran ubicación sin que los desarrolladores lo sepan

    Bibliotecas de anuncios móviles filtran ubicación sin que los desarrolladores lo sepan

    Un informe de la Electronic Frontier Foundation (EFF) revela que las bibliotecas de software publicitario integradas en aplicaciones móviles recolectan y filtran datos de ubicación de los usuarios, en muchos casos sin que los propios desarrolladores de esas apps sean conscientes de ello. El negocio de datos de localización mueve miles de millones de dólares al año y el mecanismo de fuga opera de forma silenciosa, embebido en el código que los developers incorporan para monetizar sus productos.

    Las ad libraries —bibliotecas de código de terceros que los desarrolladores insertan para mostrar publicidad— son el vector central del problema documentado por la EFF. Cuando un desarrollador integra una de estas bibliotecas, no siempre recibe documentación completa sobre qué datos recopila el SDK ni a qué servidores los envía. El resultado es que la app puede estar transmitiendo coordenadas GPS, identificadores de dispositivo y patrones de movimiento del usuario hacia redes publicitarias, sin que el equipo que construyó la aplicación haya tomado esa decisión de forma explícita.

    Por qué la ubicación es el dato más sensible del ecosistema publicitario

    La dirección de un hogar, los horarios de trabajo, las visitas a clínicas o lugares de culto, las rutas habituales: todo eso puede inferirse a partir de un historial de coordenadas. La EFF señala que la ubicación no es simplemente “un punto en un mapa”, sino una fuente de información íntima sobre la vida de una persona. Esta densidad informativa es exactamente lo que convierte al sector de datos de localización en un mercado multimillonario, donde brokers de datos compran, procesan y revenden trayectorias sin que el titular del dato haya prestado un consentimiento informado real.

    El reporte de la EFF también aborda las reformas recientemente anunciadas por Flock, empresa conocida por sus sistemas de reconocimiento de patentes vehiculares, y analiza legislación en el Senado de Estados Unidos que, según la organización, introduciría riesgos adicionales de privacidad bajo la sigla KOSA (Kids Online Safety Act). Aunque el foco geográfico del informe es el mercado estadounidense, los mecanismos técnicos descriptos operan en cualquier jurisdicción donde esas apps estén disponibles, lo que hace el hallazgo directamente relevante para usuarios latinoamericanos.

    Cuándo aplica esta vulnerabilidad y cuándo no

    El problema aplica cuando una aplicación móvil —independientemente de su categoría: juegos, utilidades, comercio electrónico— incorpora SDKs publicitarios de terceros sin auditar el comportamiento de recolección de datos de esos componentes. No aplica, en cambio, cuando el desarrollador construye su propio sistema de monetización sin dependencias externas, o cuando el SDK ha sido auditado y contractualmente limitado en su alcance de recolección. La distinción importa porque desplaza la responsabilidad: no es siempre una decisión deliberada del desarrollador, sino una consecuencia de integrar código de terceros sin due diligence de privacidad.

    El marco legal en América Latina frente a la recolección encubierta por SDKs

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que el tratamiento de datos personales —incluida la ubicación— cuente con una base legal válida y que el titular haya recibido información clara sobre los fines del tratamiento. La recolección silenciosa a través de una biblioteca de anuncios sin divulgación adecuada en la política de privacidad de la app constituiría, en principio, una violación a los artículos 7 y 9 de la ley, que regulan las hipótesis de tratamiento y la transparencia. La Autoridade Nacional de Proteção de Dados (ANPD) tiene competencia para investigar tanto al desarrollador de la app como, potencialmente, al operador del SDK como agente de tratamiento.

    En Argentina, la Ley 25.326 de Protección de los Datos Personales impone obligaciones de consentimiento informado y finalidad determinada. La Agencia de Acceso a la Información Pública (AAIP) ha avanzado en los últimos años en la regulación de aplicaciones móviles, aunque la capacidad de fiscalización sobre SDKs de origen extranjero sigue siendo un desafío práctico. México, a través del INAI y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), tiene un esquema similar: el responsable del tratamiento —en este caso el desarrollador de la app— responde por los datos que su producto recopila, incluso si la recolección la ejecuta un tercero integrado en el código.

    Qué implica esto para desarrolladores y equipos de compliance

    El hallazgo de la EFF refuerza una obligación que el marco regulatorio latinoamericano ya impone pero que pocas organizaciones implementan con rigor: el inventario y la auditoría de componentes de terceros antes de publicar una aplicación. Un desarrollador que integra una ad library sin revisar su política de datos no puede escudarse en el desconocimiento como eximente; la responsabilidad por el tratamiento de datos personales de los usuarios de su app recae sobre él como responsable ante la ley. Esto aplica con especial fuerza cuando la app tiene usuarios en jurisdicciones con regulación activa, como Brasil o Colombia —que cuenta con su propia Ley 1581 de 2012 y la Superintendencia de Industria y Comercio como autoridad de control.

    El informe completo de la EFF sobre bibliotecas de anuncios móviles está disponible en eff.org/deeplinks/2026/07/developers-beware-ad-libraries-betray-your-users-location-privacy y detalla los SDKs analizados y los mecanismos técnicos de exfiltración de ubicación identificados por el equipo de investigación de la organización.

    Que el código que filtra datos de ubicación sea invisible para el propio desarrollador no es un argumento legal en ninguna regulación de la región: la cadena de responsabilidad empieza en quien publica la app, no en quien escribió el SDK.

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

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

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

  • Copilot en Windows y el desafío para la gobernanza de endpoints corporativos

    Copilot en Windows y el desafío para la gobernanza de endpoints corporativos

    La integración de Copilot directamente en Windows introduce una capa de procesamiento de datos asistido por IA en el endpoint que los marcos de gobernanza corporativa no estaban diseñados para gestionar. El modelo de control centralizado de datos enfrenta una tensión concreta: el dato ya no viaja solo hacia el servidor; ahora es procesado, resumido y potencialmente enviado a servicios externos desde el propio dispositivo del usuario.

    Durante años, la gobernanza de endpoints en entornos empresariales se resolvió con políticas de DLP (Data Loss Prevention), clasificación de archivos y controles de acceso gestionados por el área de TI. Copilot en Windows cambia la ecuación: el asistente puede acceder a correos, documentos, portapapeles y contexto de pantalla para generar respuestas, lo que significa que datos bajo clasificación sensible pueden ser parte de un prompt sin que el data steward responsable de ese activo haya intervenido en la decisión.

    Qué dato fluye, hacia dónde y bajo qué política

    El problema central para los equipos de gobernanza no es técnico sino de ownership: ¿quién es el data steward del contexto que Copilot consume en tiempo real? En el marco DAMA-DMBOK, el dato tiene un custodio definido por dominio; pero el contexto ensamblado por un modelo de lenguaje en el endpoint mezcla activos de múltiples dominios —finanzas, RRHH, operaciones— sin respetar los límites de clasificación establecidos. Esto no es un fallo de seguridad informática; es un fallo de data lineage: la trazabilidad del dato se rompe en el momento en que ingresa al contexto del modelo.

    Microsoft ha documentado configuraciones de privacidad para Copilot en entornos empresariales, incluyendo la posibilidad de deshabilitar el envío de datos a servicios en la nube y operar en modo “con datos comerciales protegidos” bajo licencias Microsoft 365. Sin embargo, según se informó, la granularidad de esos controles varía según el plan de licenciamiento y la configuración de tenant, lo que crea brechas de governance para organizaciones que aún no han actualizado sus contratos o revisado sus políticas de uso.

    Shadow AI en el endpoint: el riesgo que DAMA no anticipó

    La irrupción de Copilot como función nativa del sistema operativo —y no como aplicación instalable separada— representa un vector nuevo de shadow AI: el uso ocurre antes de que el área de gobernanza tome conocimiento de él. A diferencia de un empleado que descarga ChatGPT, aquí el asistente viene preinstalado con el sistema operativo. Las políticas de uso aceptable y los registros de consentimiento informado que muchas organizaciones latinoamericanas desarrollaron en 2023-2024 para herramientas de IA generativa externa no cubren, en la mayoría de los casos, capacidades nativas del OS.

    Desde la perspectiva del EDM Council y su marco CDMC (Cloud Data Management Capabilities), el control relevante es el capability 9: gestión de consentimiento y uso de datos. En una arquitectura con Copilot activo en el endpoint, ese control requiere ser reimplementado a nivel de política de grupo (GPO) o mediante Microsoft Intune, no solo a nivel de contrato o aviso de privacidad corporativo.

    Cuándo aplica como problema de gobernanza / cuándo no

    Este desafío aplica directamente cuando la organización maneja datos clasificados como confidenciales o restringidos bajo cualquier esquema de clasificación (sea propio, basado en ISO/IEC 27001 o en normativa sectorial), y Copilot está habilitado por defecto en los endpoints de esos usuarios. No aplica —o el riesgo es bajo— cuando el tenant de Microsoft 365 tiene Copilot deshabilitado a nivel de administrador, cuando los dispositivos operan en entornos air-gapped, o cuando la organización solo procesa datos públicos. El punto crítico es el gap entre organizaciones que asumen que “Copilot empresarial es seguro por contrato” y aquellas que han verificado efectivamente qué datos salen del endpoint y bajo qué base legal.

    El vector regulatorio en América Latina

    En Brasil, la LGPD establece que el responsable del tratamiento (controlador) debe garantizar medidas técnicas y administrativas para proteger los datos personales de accesos no autorizados y situaciones accidentales. Un Copilot que accede a correos con datos de clientes sin que el usuario haya recibido información clara sobre ese procesamiento configura, al menos, una tensión con el artículo 46 de la ley. En Argentina, la Ley 25.326 y las disposiciones de la AAIP en materia de cesión de datos a terceros —incluyendo proveedores tecnológicos extranjeros— obligan a revisar si los acuerdos de procesamiento de datos vigentes con Microsoft cubren los nuevos flujos introducidos por Copilot. En México, el INAI ha sido explícito en que los responsables no pueden delegar en el contrato con el proveedor la responsabilidad de informar al titular sobre los tratamientos realizados.

    Las organizaciones que operan bajo regulación sectorial adicional —bancos supervisados por el BCRA en Argentina, instituciones financieras bajo la CNBV en México, o entidades de salud con obligaciones bajo normativas locales— enfrentan una capa extra: el regulador sectorial puede exigir controles más estrictos sobre dónde y cómo se procesan datos de clientes, independientemente de lo que el contrato con Microsoft establezca.

    Tres controles concretos para equipos de gobernanza

    • Auditar qué usuarios tienen Copilot habilitado y sobre qué datos clasificados tienen acceso, cruzando el inventario de activos de datos con el directorio de licencias de Microsoft 365 Copilot.
    • Revisar los Data Processing Agreements (DPA) con Microsoft para confirmar que los nuevos flujos de Copilot están cubiertos y son compatibles con las bases legales de tratamiento establecidas en las políticas internas.
    • Actualizar las políticas de clasificación de datos para incluir una regla explícita sobre qué categorías de datos no pueden ser expuestas al contexto de modelos de lenguaje, y trasladar esa regla a controles técnicos en Intune o mediante etiquetas de sensibilidad de Microsoft Purview.

    La documentación oficial de Microsoft sobre controles de privacidad para Copilot en entornos empresariales está disponible en el Centro de confianza de Microsoft (Microsoft Trust Center); revisarla junto al DPA vigente es el punto de partida obligado antes de cualquier decisión de habilitación masiva.