Privacidad y confidencialidad de datos en LLM y WorkOS

Privacidad y confidencialidad de los datos en la era de los LLM: cómo lo aborda WorkOS

Los modelos de lenguaje de gran escala, conocidos como LLM, ya forman parte de muchas herramientas digitales. Redactan respuestas, resumen documentos, clasifican correos, analizan reuniones y ayudan a automatizar decisiones. El problema no es solo qué puede hacer cada modelo, sino qué ocurre con los datos que recibe para hacerlo.

En WorkOS, la inteligencia artificial puede trabajar con correos, contactos, documentos, notas, reuniones y datos de terceros. Eso convierte la privacidad y la confidencialidad en una cuestión central: una respuesta útil no compensa que la información de un cliente termine almacenada durante más tiempo del necesario, se utilice para entrenar modelos o se procese en una jurisdicción que la empresa no había previsto.

Esta guía explica qué riesgos hay en un entorno lleno de proveedores y modelos LLM, qué controles estamos aplicando desde WorkOS, la solución de Befocusy, y cómo evaluamos qué proveedores pueden utilizarse. El análisis se realizó el 21 de septiembre de 2026 y no constituye asesoramiento legal. Cualquier cambio en contratos, políticas públicas o configuraciones de tratamiento debería revisarlo la persona responsable del cumplimiento normativo.

La preocupación real: cada modelo añade una nueva ruta para los datos

Cuando una aplicación utiliza un LLM, los datos pueden salir de la aplicación principal para ser procesados por una API externa. Esa ruta adicional puede incluir:

El prompt o la instrucción enviada al modelo.
El contexto añadido para que el modelo responda, como un correo, una nota o un documento.
La respuesta generada.
Archivos, embeddings, historiales o estados de conversación asociados.
Metadatos técnicos, registros de abuso y datos de monitorización.

Por eso, decir que un proveedor «no entrena con tus datos» es importante, pero no suficiente. También hay que saber cuánto tiempo conserva la información, si existe revisión humana, dónde se almacena, dónde se procesa, qué funciones guardan datos y qué garantías contractuales ofrece.

En WorkOS enfocamos esta cuestión como un problema de control de datos, no solo como una comparación entre modelos. La pregunta no es únicamente «qué modelo responde mejor», sino «qué datos necesita, qué recorrido siguen y qué límites podemos aplicar en cada paso».

Glosario rápido de privacidad y proveedores de IA

Antes de comparar proveedores, conviene aclarar algunos términos técnicos que aparecen a lo largo del artículo.

¿Qué es un LLM?

Un LLM, o modelo de lenguaje de gran escala, es un sistema de inteligencia artificial entrenado para comprender y generar texto. Puede resumir, clasificar, redactar o responder preguntas a partir de la información que recibe.

¿Qué es una API?

Una API es el mecanismo que permite que WorkOS envíe una solicitud a un proveedor de IA y reciba una respuesta. En esa solicitud pueden viajar instrucciones, contexto, documentos o datos personales, según la función utilizada.

¿Qué es un prompt?

Es la instrucción o conjunto de datos que se envía al modelo. En un entorno empresarial, el prompt puede incluir información confidencial aunque el usuario no la escriba directamente, porque la aplicación puede añadir contexto automáticamente.

¿Qué es la retención de datos?

Es el tiempo durante el que el proveedor conserva prompts, respuestas, archivos, registros o metadatos. Una retención breve reduce la exposición, aunque hay que revisar qué excepciones existen.

¿Qué significa Zero Data Retention o ZDR?

Es una configuración mediante la que el proveedor no conserva los datos de las solicitudes para determinados usos o endpoints. No siempre está disponible para todas las funciones y puede desactivar capacidades con estado, archivos o conversaciones encadenadas.

¿Qué es un DPA?

Un DPA, o Data Processing Agreement, es un acuerdo de tratamiento de datos. Define cómo actúa el proveedor como encargado del tratamiento, qué datos procesa, qué subproveedores utiliza y qué garantías ofrece para las transferencias internacionales.

¿Qué es la monitorización de abuso?

Son los controles que utiliza el proveedor para detectar usos indebidos, incidentes o vulneraciones de sus políticas. Puede ser automática y, en determinadas condiciones, incluir revisión humana.

¿Qué es la residencia de datos?

Indica dónde se almacenan o procesan los datos. No es lo mismo almacenar una conversación en Europa que garantizar que el modelo se ejecuta en Europa.

¿Qué es el procesamiento en reposo?

Es el almacenamiento de datos que no se están transmitiendo o utilizando activamente, como archivos, historiales, lotes o estados de conversación.

¿Qué significa una función con estado?

Es una función que conserva información entre varias interacciones. Puede facilitar conversaciones encadenadas, pero también implica que el proveedor necesita guardar contexto o referencias a solicitudes anteriores.

¿Qué son los embeddings?

Son representaciones numéricas de textos, documentos u otros datos que permiten buscar similitudes y recuperar contexto. Aunque no sean texto legible, pueden seguir siendo información sensible.

¿Qué es un modelo «contributor»?

Es un identificador que puede indicar que el proveedor permite utilizar las entradas y respuestas para contribuir al desarrollo de modelos futuros. En WorkOS se bloquean estos identificadores hasta confirmar sus condiciones.

Resumen rápido: proveedores aptos y no aptos para WorkOS

La evaluación combina seis criterios: uso de datos para entrenamiento, retención, DPA, certificaciones de seguridad, residencia de datos y claridad de la documentación pública.

Proveedores aptos o condicionados

OpenAI: apto y ya integrado. Conviene revisar el DPA, la retención, los controles de intercambio de datos y la residencia europea.
Google Gemini: apto solo con facturación activa. La clave debe pertenecer a un proyecto de Google Cloud con condiciones de pago.
Anthropic: alternativa apta desde el punto de vista de privacidad, aunque todavía no está integrada en WorkOS.
Microsoft Foundry: alternativa apta para entornos empresariales, especialmente con una zona de datos adecuada.
xAI: opción condicionada a la confirmación del DPA, la residencia y las limitaciones de Zero Data Retention.

Proveedores bloqueados por ahora

Meta Model API: falta documentación estable sobre retención, DPA y residencia.
MiniMax: sus condiciones permiten utilizar entradas y respuestas para desarrollar y mejorar sus servicios.
DeepSeek: plantea riesgos por el uso de datos para entrenamiento, el almacenamiento en China y la ausencia de un DPA adecuado.

La clasificación es operativa y puede cambiar si se modifican las condiciones contractuales, la documentación o la configuración de cada proveedor.

Actualmente, solo OpenAI y Gemini están integrados en el código de WorkOS y aparecen reflejados en su política de privacidad pública.

Cómo enfocamos la privacidad desde WorkOS

WorkOS, la solución de Befocusy, aplica una estrategia de control por capas. No damos por válida una integración únicamente porque el proveedor tenga un modelo potente o publique una declaración general de privacidad.

1. Lista cerrada de proveedores y modelos

Mantenemos una lista limitada de proveedores y modelos permitidos. Esto evita que una clave, una dependencia o un identificador nuevo introduzca un proveedor no evaluado.

También bloqueamos identificadores de nivel «contributor», como muse-spark-1.3-contributor, hasta confirmar sus condiciones de uso.

2. Minimización del contexto enviado

El modelo debería recibir únicamente la información necesaria para realizar una función concreta. Cuanto más contexto se envía, mayor es la superficie de exposición y más difícil resulta explicar el recorrido de los datos.

3. Separación entre utilidad y almacenamiento

Una función puede necesitar el contexto de una conversación para responder bien, pero eso no significa que deba conservarlo indefinidamente. Revisamos qué funciones requieren estado, archivos, lotes o historiales y cuáles pueden funcionar sin almacenamiento adicional.

4. Revisión de la configuración real

Las condiciones de privacidad pueden depender del proyecto, la organización, la cuenta, la región, la clave API o el modelo concreto. Por eso revisamos la configuración efectiva, no solo la documentación comercial del proveedor.

5. Revisión contractual y operativa

Además de la configuración técnica, comprobamos la existencia del DPA, las transferencias internacionales, la subcontratación, la retención y las posibilidades de revisión humana.

6. Revisión periódica

Las condiciones de los proveedores cambian. Revisamos estos controles al menos cada seis meses y también después de cambiar claves, proyectos, modelos o condiciones contractuales.

Qué debe comprobarse antes de aprobar un proveedor de IA

1. Uso de los datos para entrenar modelos

El proveedor debería confirmar que las entradas, respuestas, embeddings y archivos enviados mediante API no se utilizan para entrenar o mejorar modelos, ni por defecto ni mediante una cláusula contractual ambigua.

2. Plazo de retención

La retención debería estar limitada, idealmente a 30 días o mediante una opción de retención cero. Conviene comprobar si la retención afecta solo a la supervisión de abusos o también a funciones con estado, archivos, lotes y conversaciones encadenadas.

3. DPA y transferencias internacionales

Debe existir un acuerdo de tratamiento de datos que defina las responsabilidades del proveedor, las subcontrataciones y las garantías para transferencias internacionales.

4. Seguridad y certificaciones

Certificaciones como SOC 2 Tipo II o equivalentes aportan contexto, aunque no sustituyen la revisión de las condiciones específicas de la API.

5. Residencia y procesamiento

Hay que distinguir entre el lugar donde se almacenan los datos y el lugar donde se ejecuta el modelo. Un proveedor puede guardar los datos en Europa y procesarlos fuera de la Unión Europea, o al contrario.

6. Documentación estable

Las condiciones deben estar documentadas de forma pública, clara y suficientemente estable como para incorporarlas a contratos, políticas internas y compromisos con clientes.

OpenAI: opción integrada, con controles que revisar

OpenAI no utiliza por defecto los datos de la API para entrenar sus modelos. La API puede conservar entradas y salidas hasta 30 días para prestar el servicio y detectar abusos. También existen opciones como Modified Abuse Monitoring y Zero Data Retention, aunque requieren aprobación y no se aplican a todas las funciones.

WorkOS utiliza store:false en todas las llamadas salvo en Kairos, que necesita store:true para encadenar turnos mediante previous_response_id. Esto crea una limitación importante: la retención cero fuerza store:false, por lo que Kairos no sería compatible con ZDR hasta disponer de una versión sin estado.

Las comprobaciones recomendadas son:

Confirmar que los controles de intercambio de datos están desactivados.
Revisar los ajustes tanto a nivel de organización como de proyecto.
Firmar el DPA si todavía no se ha formalizado.
Solicitar Modified Abuse Monitoring o ZDR para los endpoints elegibles.
Valorar la residencia europea cuando un cliente la exija.

OpenAI puede ofrecer almacenamiento y procesamiento en Europa, sujeto a aprobación comercial, modelos compatibles y condiciones específicas de monitorización de abuso.

Google Gemini: la facturación activa es imprescindible

Gemini presenta una diferencia crítica entre sus servicios gratuitos y de pago. En el nivel gratuito, Google puede utilizar las entradas y respuestas para proporcionar, mejorar y desarrollar sus productos, además de permitir la revisión humana en determinados casos.

En los servicios de pago, vinculados a un proyecto de Google Cloud con facturación activa, los datos no se utilizan para mejorar los productos y se procesan bajo condiciones de encargado del tratamiento.

Por eso, la comprobación más urgente en WorkOS es confirmar que GEMINI_API_KEY pertenece a un proyecto con facturación activa. Crear o rotar una clave en un proyecto sin facturación puede devolver el sistema al nivel gratuito.

Incluso en el nivel de pago, Google puede conservar prompts, contexto y respuestas hasta 55 días para detectar abusos. Si se necesita una residencia europea más sólida, la alternativa recomendada es Vertex AI, no la API de AI Studio. Vertex permite elegir regiones europeas y solicitar una excepción de supervisión de abusos para alcanzar una retención cero, siempre que no se activen funciones que almacenen datos.

Anthropic: alternativa con buena posición de privacidad

Anthropic declara que no utiliza los datos retenidos para entrenar modelos sin permiso expreso. La API ofrece controles de retención y una opción de Zero Data Retention por organización, aunque algunos modelos «Covered» mantienen una retención obligatoria de 30 días por motivos de seguridad.

La retención habitual puede variar entre cero y 30 días según el producto y la configuración. También conviene evitar programas opcionales de intercambio de datos, como el Development Partner Program, si se busca minimizar el uso secundario de la información.

La API directa de Anthropic no ofrece actualmente una residencia europea completa. Si la residencia en la Unión Europea es un requisito, Claude tendría que utilizarse a través de Amazon Bedrock o Google Vertex AI, con un cliente y una configuración diferentes de los actuales.

Anthropic puede ser una alternativa razonable desde el punto de vista de privacidad, pero todavía no está integrado en WorkOS.

Microsoft Foundry: residencia configurable para entornos empresariales

Microsoft Foundry, anteriormente relacionado con Azure OpenAI, establece contractualmente que Microsoft y los proveedores de los modelos no utilizan las peticiones, respuestas, embeddings ni datos de ajuste para entrenar modelos fundacionales sin permiso.

La monitorización de abuso puede implicar una revisión automática y, en determinados casos, humana. Las organizaciones pueden solicitar Modified Abuse Monitoring y verificar que ContentLogging = false en el recurso correspondiente.

Para la Unión Europea, Foundry permite elegir despliegues Data Zone UE o Standard regional, siempre que el modelo sea compatible. Las funciones con estado, las stored completions y otros mecanismos de almacenamiento deberían activarse solo cuando sean necesarios.

xAI: opción condicionada a una revisión contractual

xAI declara que no entrena con entradas ni salidas de la API sin permiso explícito. La retención estándar es de 30 días para auditoría y existe una opción de Zero Data Retention activable por el administrador del equipo.

El principal inconveniente es que ZDR desactiva funciones con estado, Files, Collections, Batch y otras capacidades que Kairos podría necesitar. Además, la residencia europea no está confirmada y conviene verificar que el DPA incluido en los términos Enterprise cubre realmente la cuenta de API utilizada.

Por tanto, xAI solo debería considerarse después de firmar el DPA, confirmar la cobertura contractual y aceptar las limitaciones técnicas de ZDR.

Meta, MiniMax y DeepSeek: por qué deben permanecer bloqueados

Meta Model API

La Meta Model API ofrece modelos estándar que, según el identificador, no entrenan con los datos. Sin embargo, los modelos cuyo nombre termina en -contributor sí pueden utilizar prompts y respuestas para entrenar modelos futuros.

Además, la retención, el DPA, la residencia y las certificaciones de la API no están suficientemente documentados. Por ahora, no es una opción adecuada para procesar datos empresariales de WorkOS.

MiniMax

MiniMax se reserva en sus términos el derecho a utilizar las entradas y el contenido generado para proporcionar, mantener, desarrollar y mejorar sus servicios. Tampoco se ha localizado un DPA específico para la API ni un plazo fijo de retención.

DeepSeek

DeepSeek declara que almacena los datos en China y utiliza las entradas para entrenar y mejorar su tecnología. Sus términos contemplan usos amplios, incluida la destilación de otros modelos, sin un mecanismo de exclusión suficientemente claro.

La ausencia de un DPA adecuado y la jurisdicción aplicable hacen que no sea recomendable para datos empresariales de WorkOS.

Residencia europea: almacenamiento y procesamiento no son lo mismo

La residencia de datos tiene al menos dos dimensiones:

Almacenamiento en reposo: archivos, estados de conversación, lotes y otros datos guardados.
Procesamiento: lugar donde se ejecuta el modelo para generar la respuesta.

Las opciones con una residencia europea más completa son:

OpenAI, mediante aprobación, proyectos europeos y endpoints compatibles.
Gemini a través de Vertex AI, usando regiones europeas o la multirregión de la Unión Europea.
Claude mediante Amazon Bedrock o Vertex AI, con el perfil o endpoint europeo adecuado.
Microsoft Foundry, mediante Data Zone UE o despliegues regionales compatibles.

La API de Gemini con clave de AI Studio y la API directa de Anthropic no ofrecen actualmente la misma garantía de residencia europea.

Checklist de privacidad y confidencialidad para WorkOS

Antes de incorporar o cambiar un proveedor de IA, conviene completar esta lista:

Confirmar qué datos salen de WorkOS y por qué son necesarios.
Confirmar si los datos se utilizan para entrenar o mejorar modelos.
Documentar el plazo de retención y las excepciones aplicables.
Verificar la existencia y el alcance del DPA.
Revisar la residencia del almacenamiento y del procesamiento.
Comprobar si existe monitorización humana para detectar abusos.
Identificar funciones con estado, archivos, lotes o almacenamiento adicional.
Confirmar la configuración real del proyecto, la cuenta y la clave API.
Mantener una lista cerrada de proveedores y modelos permitidos en el código.
Bloquear identificadores de nivel «contributor», como muse-spark-1.3-contributor.
Actualizar la política de privacidad antes de incorporar un proveedor nuevo.
Revisar estos controles al menos cada seis meses y después de cambiar claves, proyectos o condiciones del proveedor.

Qué debería hacer WorkOS ahora

Las prioridades más importantes son:

Comprobar la clave de Gemini. GEMINI_API_KEY debe pertenecer a un proyecto de Google Cloud con facturación activa.
Valorar Vertex AI si se necesitan residencia europea y controles de retención más sólidos.
Revisar OpenAI, firmar el DPA si falta y solicitar los controles de monitorización o retención que correspondan.
Mantener una lista cerrada de proveedores y modelos permitidos en el código.
Documentar el recorrido de los datos para cada función de IA, desde el contexto que sale de WorkOS hasta la respuesta que vuelve a la aplicación.
Actualizar la política de privacidad antes de incorporar un proveedor nuevo y comunicar los cambios a los clientes cuando proceda.
Revisar periódicamente las garantías contractuales y técnicas, porque las condiciones de los proveedores pueden cambiar.

Conclusión: usar LLMs sin perder el control de la información

La expansión de los LLM no elimina la responsabilidad sobre los datos. Al contrario, hace necesario saber qué información se envía, a qué proveedor, durante cuánto tiempo puede conservarse, quién puede revisarla y en qué país se procesa.

Desde WorkOS, la solución de Befocusy, abordamos esta cuestión con una combinación de minimización de datos, lista cerrada de proveedores y modelos, revisión contractual, configuración técnica, control de funciones con estado y revisiones periódicas. El objetivo no es evitar la inteligencia artificial, sino utilizarla de forma útil sin convertir cada automatización en una nueva vía de exposición.

Para WorkOS, OpenAI sigue siendo la opción más integrada y Gemini puede utilizarse siempre que se confirme la facturación activa. Anthropic y Microsoft Foundry son alternativas razonables para ampliar el catálogo, especialmente cuando se necesita una configuración europea. xAI requiere más comprobaciones. Meta, MiniMax y DeepSeek deberían permanecer bloqueados mientras sus garantías contractuales y técnicas no sean suficientes.

Si estás revisando la arquitectura digital de tu negocio y quieres reducir la dependencia de herramientas desconectadas, puedes empezar por una consultoría en Notion para negocios o explorar plantillas de Notion para emprendedores. Un sistema digital coherente facilita documentar proveedores, decisiones, controles y revisiones periódicas.

Preguntas frecuentes sobre privacidad y confidencialidad en entornos con LLM

¿Por qué preocupa la privacidad cuando una empresa utiliza varios modelos LLM?

Porque cada modelo puede convertirse en una nueva ruta para prompts, documentos, respuestas, archivos y metadatos. El riesgo depende de qué datos se envían, cuánto tiempo se conservan, quién puede acceder a ellos y dónde se procesan.

¿Qué diferencia hay entre privacidad y confidencialidad?

La privacidad se refiere al tratamiento legítimo y controlado de los datos. La confidencialidad se refiere a evitar que la información llegue a personas, proveedores o usos no autorizados. En un entorno con LLM, ambas cuestiones están relacionadas, pero no son idénticas.

¿Qué es un DPA y por qué es importante?

Un DPA es un acuerdo de tratamiento de datos que define las obligaciones del proveedor, los subencargados, las transferencias internacionales y las garantías aplicables. Es una pieza contractual esencial cuando una API procesa datos empresariales.

¿Basta con elegir un proveedor que diga que no entrena con los datos?

No. También hay que revisar la retención, la monitorización humana, la residencia, el DPA, las funciones con estado y la configuración concreta de la cuenta, el proyecto y la clave API.

¿Cómo limita WorkOS la exposición de los datos?

WorkOS aplica una lista cerrada de proveedores y modelos, minimiza el contexto enviado, revisa las funciones que almacenan información y comprueba periódicamente las condiciones técnicas y contractuales.

¿La retención cero elimina todos los riesgos?

No. Zero Data Retention puede reducir la conservación de datos, pero no siempre está disponible para todas las funciones y puede desactivar capacidades necesarias. Además, hay que controlar los datos durante el tránsito y la configuración de la aplicación.

¿La residencia europea garantiza que el procesamiento ocurre en Europa?

No necesariamente. Hay que comprobar por separado dónde se almacenan los datos y dónde se ejecuta el modelo. La residencia debe evaluarse para cada proveedor, región, endpoint y función.

¿Este análisis sustituye una revisión legal?

No. Es una evaluación técnica y operativa desde la perspectiva de WorkOS. Los contratos, las políticas públicas y los compromisos con clientes deben revisarse con la persona responsable del cumplimiento normativo.