Mejores plataformas de IA empresarial sin retención de datos en 2026

Comparamos nueve plataformas de IA empresarial por cobertura ZDR, límites de agentes, precios y controles para evitar que datos sensibles queden almacenados.

Wednesday, September 2, 2026Omid Saffari
Mejores plataformas de IA empresarial sin retención de datos en 2026

OpenAI API es la mejor plataforma sin retención de datos para la mayoría de los equipos que trabajan con agentes de IA empresarial en 2026: mantiene los modelos de frontera dentro de una ruta ZDR, mientras que Amazon Bedrock resulta más sólido cuando la política de retención debe bloquear por defecto cualquier operación incompatible en todo un entorno de AWS. La salvedad es decisiva: ZDR protege una ruta de inferencia, no un producto de agentes completo. La memoria con estado, los archivos, los entornos aislados para ejecutar código, las búsquedas y las capas de agentes administrados pueden volver a introducir retención. En una carga normalizada de 1 millón de tokens de entrada y 200,000 de salida, GPT-5.6 Luna cuesta $0.44 con las tarifas Standard vigentes; la decisión presupuestaria más importante es si la empresa puede asumir la gestión del estado del agente.

Mejores plataformas de IA empresarial sin retención de datos: comparativa rápida

La retención cero de datos, o ZDR, significa que los prompts y las respuestas compatibles no permanecen almacenados después del procesamiento. No abarca automáticamente todos los repositorios de archivos, capas de memoria, herramientas o agentes administrados conectados al modelo. Esa diferencia es el criterio que más pesa en esta clasificación.

Los precios que aparecen a continuación se verificaron en páginas activas de los proveedores el 22 de agosto de 2026. Salvo que se indique otra unidad, los precios de tokens corresponden a 1 millón de tokens. «No indicada» significa que el proveedor no anunciaba una prueba específica de la plataforma en su página de precios; no implica que su equipo comercial no pueda ofrecer créditos.

HerramientaIdeal paraPrecio inicialPrueba gratuita
OpenAI APIModelos de frontera en una organización con ZDR aprobadoGPT-5.6 Luna: $0.20 de entrada, $1.20 de salidaNo indicada
Amazon BedrockAplicar políticas de AWS que bloqueen llamadas incompatiblesIntelligent Prompt Routing: $1 por 1,000 solicitudes, más el uso del modeloNo indicada
Google Gemini Enterprise Agent PlatformEquipos de Google Cloud capaces de gobernar cada función del agenteGemini 3.1 Flash-Lite: $0.25 de entrada, $1.50 de salidaNo indicada
Anthropic APIAgentes Claude cuyo estado y herramientas controla el clienteHaiku 4.5: $1 de entrada, $5 de salidaNo indicada
Fireworks AIInferencia con modelos abiertos y ZDR predeterminadoGPT OSS 20B: $0.07 de entrada, $0.30 de salidaCrédito de $1
GroqCloudInferencia de baja latencia con modelos abiertosGPT OSS 20B: $0.075 de entrada, $0.30 de salidaNivel gratuito
Microsoft FoundryInferencia sin estado gobernada desde AzureGPT-5.6 Luna: $0.20 de entrada, $1.20 de salidaNo indicada
OpenRouterEnrutamiento entre proveedores con un filtro de política ZDRGratis, o comisión Pay-as-you-go del 5.5%Plan gratuito
Mistral AICargas aprobadas y sin estado en la API de MistralMistral Large: $0.50 de entrada, $1.50 de salidaSin plan ZDR gratuito

La comparación más amplia sobre calidad de modelos, orquestación y encaje empresarial está en este análisis de plataformas de agentes de IA para empresas. Aquí el orden cambia porque la seguridad de la retención pesa más que la amplitud funcional. Una plataforma pierde posiciones cuando sus funciones de agentes más cómodas invalidan la promesa de ZDR.

¿Qué significa la retención cero de datos para un agente empresarial?

«No entrenamos con sus datos» y «no conservamos sus datos» responden preguntas distintas. Un compromiso de no entrenamiento todavía puede permitir que un proveedor guarde prompts para vigilar abusos, depurar errores, conservar historiales de conversación, procesar lotes o recuperar archivos. ZDR es la promesa más estricta y específica de que el contenido compatible no se almacena una vez terminada la solicitud.

En un agente, cumplir esa promesa es más difícil que en una sola respuesta de chat. Un agente empresarial útil suele necesitar al menos cuatro capas:

  • Inferencia: el modelo recibe un prompt y devuelve una respuesta.
  • Estado: memoria, historial de conversación, puntos de control y estado de las tareas.
  • Conocimiento: archivos cargados, bases vectoriales, bases de datos y registros de recuperación.
  • Acciones: búsquedas, ejecución de código, navegadores, servidores MCP y aplicaciones empresariales.

Solo la primera capa carece de estado por naturaleza. Las otras tres existen precisamente porque algo persiste en algún lugar. Por eso, una plataforma puede ofrecer una inferencia ZDR excelente y aun así ser inadecuada para un agente administrado cuyo historial, archivos o entorno aislado viven dentro del producto del proveedor.

Arquitectura en la que una solicitud cruza un perímetro de inferencia sin retención, mientras los archivos, la memoria administrada y terceros siguen siendo riesgos de retención independientes
ZDR protege una ruta de inferencia. Cada acceso lateral con estado necesita su propia política.

Es la factura por asumir el control del estado. Un ZDR estricto suele obligar a la empresa a gestionar la base de datos de memoria, el almacenamiento de objetos para los archivos, el sistema de trazas para investigar incidentes y la cola que reanuda tareas prolongadas. Seguridad y Legal obtienen así un perímetro de control nítido, pero Ingeniería hereda las rutinas de borrado, las políticas de acceso, las reglas de respaldo y las guardias operativas.

El criterio práctico no es «¿El proveedor tiene una página sobre ZDR?», sino este: ¿Puede dibujar la ruta completa de una solicitud y demostrar que todos los sistemas que tocan contenido del cliente aplican una regla de retención compatible? Si la respuesta depende de una casilla predeterminada, un plugin sin documentar o una función administrada que guarda estado sin avisar, el flujo todavía no está preparado para datos sensibles.

Cómo se eligieron estas plataformas

Las nueve plataformas se compararon con páginas activas de controles de datos, documentación y precios de los proveedores el 22 de agosto de 2026. La clasificación no se basó en una prueba inventada ni en una insignia genérica de seguridad. El orden responde a cinco criterios:

  1. Promesa de retención: ¿El proveedor declara que los prompts y las respuestas compatibles no se almacenan después del procesamiento?
  2. Bloqueo por defecto: ¿Se bloquea un modelo o una función incompatible, o un desarrollador puede salir de ZDR sin advertirlo?
  3. Cobertura del agente: ¿Qué ocurre con la memoria, los archivos, los trabajos por lotes, la ejecución de código, la búsqueda web, MCP y los historiales de agentes administrados?
  4. Evidencia administrativa: ¿Un responsable de seguridad puede activar la política de forma centralizada y comprobar que está vigente?
  5. Claridad comercial: ¿Las tarifas actuales y el costo de las alternativas compatibles con la privacidad están suficientemente claros para elaborar un presupuesto?

Se descartaron las plataformas que solo prometen no entrenar con datos del cliente. También quedaron fuera los frameworks de orquestación que no ofrecen un compromiso de retención del lado del proveedor, porque no pueden garantizar qué almacena el servicio que aloja el modelo subyacente. La selección se redujo a proveedores con un control ZDR utilizable o una ruta sin estado defendible para el tráfico de API empresarial.

La clasificación también penaliza los nombres que inducen a error. Mistral, por ejemplo, admite ZDR en varias API sin estado, pero excluye precisamente su producto llamado Agents. Microsoft documenta inferencia sin estado y vigilancia de abusos modificada, aunque no ofrece un único interruptor ZDR de autoservicio. Ambas pueden seguir siendo buenas opciones, siempre que el equipo de implementación entienda esas condiciones.

1. OpenAI API: la mejor opción general para modelos de frontera con ZDR

OpenAI API es la mejor elección general cuando una empresa busca modelos de frontera actuales sin renunciar a una ruta con retención cero de datos.

Documentación de controles de datos de OpenAI API con los requisitos de Zero Data Retention y el comportamiento de los endpoints
Controles de datos de OpenAI API

El anuncio de OpenAI del 19 de agosto importa porque hace explícita la consecuencia empresarial: los clientes de API que cumplan los requisitos pueden conservar ZDR a medida que los modelos asumen tareas más largas y complejas. Según el compromiso publicado, los prompts y las respuestas del modelo no se retienen después del procesamiento, el contenido no queda disponible para el personal de OpenAI y los datos empresariales no se usan para entrenar salvo que el cliente lo autorice. La empresa también adelantó Private Safety Processing, diseñado para detectar patrones de riesgo en interacciones relacionadas sin exponer el contenido subyacente al personal de OpenAI.

La propuesta resulta especialmente sólida para bancos, empresas de software sanitario, plataformas jurídicas o proveedores de SaaS empresarial que necesitan capacidad de modelo, pero no pueden aceptar que el proveedor acceda rutinariamente a sus prompts. OpenAI ofrece a ese comprador una API directa, controles por proyecto, un conjunto amplio de endpoints de inferencia aptos para ZDR y una hoja de ruta clara. GPT-5.6 Luna también reduce de forma poco habitual el costo de entrada: 1 millón de tokens de entrada y 200,000 de salida cuestan $0.44 con las tarifas Standard para contexto corto.

El límite está en el estado de la aplicación. La tabla activa de retención por endpoint de OpenAI marca Chat Completions y Responses como aptos para ZDR, con restricciones, pero Conversations, los hilos de ChatKit, Assistants, Threads, Vector Stores, Files, Evals y Batches no lo son. Los servidores MCP remotos aplican sus propias políticas de retención. Hosted Shell y Code Interpreter pueden escribir datos temporales mientras sus contenedores están activos. Background Responses guarda estado temporal en disco durante aproximadamente 10 minutos para que un cliente pueda consultar el trabajo.

Esto convierte a OpenAI en la mejor plataforma de modelos de la lista, no en una autorización para utilizar todas sus funciones. Una implementación estricta debe mantener la memoria y la persistencia de archivos en la infraestructura del cliente, llamar a un endpoint sin estado compatible y aprobar por separado cada destino de las herramientas. Con ZDR, OpenAI trata store como false en Responses y Chat Completions aunque la solicitud envíe true, lo que elimina una configuración predeterminada peligrosa. Aun así, la organización necesita aprobación previa para ZDR.

Private Safety Processing también debe considerarse una función preliminar, no un control listo para incorporarse hoy a una arquitectura de producción. OpenAI indicó que ya realizaba pruebas con los primeros clientes y que planeaba el lanzamiento y un informe técnico para septiembre de 2026. El ZDR existente es el dato de compra; la función preliminar solo señala la dirección futura. Las imágenes marcadas como posible CSAM siguen siendo una excepción explícita y pueden conservarse para revisión manual y las denuncias legales correspondientes.

Ideal para: Empresas que necesitan modelos de frontera de OpenAI mediante una ruta sin estado aprobada.
Diferencial: ZDR impone store=false en las llamadas compatibles de Responses y Chat Completions.
Precio: La tabla vigente de precios de OpenAI API indica que GPT-5.6 Luna para contexto corto cuesta $0.20 de entrada, $0.02 de entrada en caché, $0.25 por escritura en caché y $1.20 de salida en Standard; $0.10, $0.01, $0.125 y $0.60 en Batch o Flex; y $0.40, $0.04, $0.50 y $2.40 en Fast, por 1 millón de tokens. El procesamiento con residencia regional de datos añade un 10% en los modelos aptos lanzados a partir del 5 de marzo de 2026.
Prueba gratuita: La página activa de precios de la API no indica ninguna prueba específica de la plataforma.

Lo bueno
Lo que hace bien
8 points

  • Compromiso explícito de agosto de 2026 de mantener ZDR en implementaciones con modelos de frontera.
  • Los controles de organización y proyecto permiten aislar las cargas aprobadas.
  • Las llamadas de inferencia compatibles imponen store=false bajo ZDR.
  • La tarifa reducida de GPT-5.6 Luna facilita presupuestar la inferencia de un agente privado.
  • ZDR requiere aprobación y obligaciones adicionales.
  • Muchos recursos útiles de agentes con estado quedan fuera de ZDR.
  • Los servidores MCP y otras herramientas externas crean perímetros de retención independientes.
  • El estado temporal de contenedores, cachés y procesos en segundo plano también exige revisar la arquitectura.
  1. Obtenga el control por escrito

    Solicite ZDR para la organización de API exacta que atenderá el tráfico de producción. Registre la aprobación, el alcance contractual, los modelos aptos, las excepciones y el responsable de seguridad.

  2. Cree un proyecto dedicado

    Coloque el agente sensible en un proyecto propio y seleccione el control de retención aprobado en lugar de heredar una configuración predeterminada ambigua de la organización. Separe las claves de desarrollo de las de producción.

  3. Inventaríe cada endpoint

    Compare el flujo con la tabla vigente de endpoints de OpenAI. Mantenga la ruta principal de inferencia en llamadas aptas de Responses o Chat Completions. Retire Conversations, Assistants, Files, Vector Stores, Evals y Batch de la ruta estricta.

  4. Lleve el estado a su propio perímetro

    Guarde la memoria, el estado de las tareas, los documentos y las trazas de auditoría en sistemas sujetos a su propio calendario de retención. Envíe únicamente el contexto mínimo necesario en cada llamada al modelo.

  5. Ejecute una prueba de retención con datos señuelo

    Envíe un registro sensible sintético, rastree todos sus destinos, verifique store=false, confirme que solo aparece en los sistemas aprobados del cliente y fuerce el fallo de una función incompatible antes de permitir datos reales.

2. Amazon Bedrock: la mejor para aplicar políticas con bloqueo por defecto

Amazon Bedrock es la opción más sólida cuando la política de retención debe aplicarse en toda una organización de AWS, en lugar de depender de que cada desarrollador la recuerde.

Documentación de retención de datos de Amazon Bedrock que describe los modos none, default, uso compartido con el proveedor y aplicación de políticas
Modos de retención de datos de Amazon Bedrock

Bedrock convierte la retención en un modo configurable a nivel de cuenta o proyecto. Al establecer data_retention_mode en none, la documentación de retención de Bedrock indica que ninguna solicitud ni respuesta se escribe en almacenamiento duradero ni se comparte con el proveedor del modelo. Si un modelo exige retención, la solicitud se bloquea. En Responses API, store adopta false de forma predeterminada, store=true se rechaza y el modo Background no está disponible. Chat Completions y Messages nunca se retienen en este modo.

Ese comportamiento de bloqueo por defecto explica por qué Bedrock supera a plataformas con una promesa comercial más sencilla. Una empresa regulada puede usar políticas IAM o Service Control Policies para denegar cualquier configuración de retención distinta de none. Así, el control resiste cambios de personal, lanzamientos apresurados y código de ejemplo copiado. Pasa a formar parte de la postura de seguridad en la nube, en vez de quedar como un punto más en la lista de comprobación de Ingeniería.

El límite señalado es la disponibilidad de modelos. Claude Fable 5 y Claude Mythos 5 requieren provider_data_share, salvo que la cuenta obtenga aprobación ZDR para cada modelo. Si se habilita ese intercambio, los prompts y las respuestas pueden conservarse hasta 30 días. Un equipo que configure none debe esperar que esos modelos no estén disponibles y entender la solicitud bloqueada como una prueba de que el control funciona.

Bedrock también advierte que store=false por sí solo no garantiza ZDR. Un modelo todavía puede retener contenido para revisiones de seguridad si el modo de retención efectivo no es none. Es una distinción valiosa para Compras: un parámetro de API determina el comportamiento de una solicitud, mientras que el modo de retención constituye la política.

Los precios son menos compactos que los de una API directa, porque Bedrock aloja numerosos proveedores en distintas regiones y modalidades de servicio. La página de precios de Bedrock fija Intelligent Prompt Routing en $1 por 1,000 solicitudes, más los tokens del modelo subyacente. Puede enrutar dentro de una familia de modelos, pero quien compre ZDR primero debe confirmar que todos los modelos candidatos admitan none. Optimizar costos solo tiene sentido después de satisfacer la política de retención.

Ideal para: Empresas en AWS que quieren imponer una política de retención de forma centralizada.
Diferencial: Las solicitudes a modelos incompatibles fallan en lugar de retener datos sin advertirlo.
Precio: El uso varía según proveedor, modelo, región y modalidad de servicio. Intelligent Prompt Routing cuesta $1 por 1,000 solicitudes On-Demand, más el uso del modelo.
Prueba gratuita: La página activa de precios de Bedrock no indica ninguna prueba específica.

Lo bueno
Lo que hace bien
8 points

  • Modos de retención explícitos a nivel de cuenta y proyecto.
  • IAM y SCP pueden hacer de none la única configuración permitida.
  • Las llamadas a modelos incompatibles se bloquean.
  • Una plataforma permite gobernar varios proveedores de modelos dentro de un entorno de AWS.
  • ZDR puede retirar del catálogo los modelos deseados.
  • El precio depende del modelo subyacente y de la región.
  • Background Responses no está disponible con none.
  • Algunos de los modelos Claude más recientes exigen una aprobación ZDR independiente por modelo.

3. Google Gemini Enterprise Agent Platform: la mejor para equipos de Google Cloud

Google Gemini Enterprise Agent Platform es la opción más adecuada para organizaciones de Google Cloud capaces de gobernar cada función del agente con el mismo rigor que la llamada al modelo.

Documentación de Google Cloud que explica cómo lograr la retención cero de datos en las funciones de Gemini Enterprise Agent Platform
Controles ZDR de Gemini Enterprise Agent Platform

La documentación de Google del 21 de agosto resulta especialmente útil porque identifica los controles que invalidan una suposición general de ZDR. El punto de partida es sólido: los datos de clientes no se usan para entrenar ni ajustar modelos administrados sin permiso, el registro de solicitudes y respuestas está desactivado de forma predeterminada y los clientes sujetos al registro de prompts para vigilar abusos pueden solicitar una excepción.

La dificultad es que cada función del agente tiene un comportamiento de almacenamiento distinto. Interactions API establece store en true de forma predeterminada, de modo que una solicitud ZDR debe enviar store=false expresamente. Grounding with Google Search conserva las consultas derivadas y el contexto hasta 3 días, sin opción de desactivarlo. Google recomienda Web Grounding for Enterprise como alternativa. Grounding with Google Maps guarda prompts, contexto y resultados generados durante 30 días, también sin interruptor para impedirlo.

CodeMender abre otro perímetro importante. Conserva hasta 7 días los datos cifrados de sesión —incluidos fragmentos de código, diferencias, configuración y puntos de control del análisis— para poder reanudar un análisis prolongado. El contenido del código se elimina en segundos cuando se alcanza un estado terminal, mientras que el resto del registro de sesión vence al llegar al límite de 7 días. Puede ser un calendario de retención empresarial razonable, pero no equivale a cero.

La reanudación de sesiones de Gemini Live es opcional y almacena texto, audio, video y resultados en caché hasta 24 horas. Debe permanecer desactivada en una ruta estricta. La caché predeterminada en memoria de Google también tiene un TTL de 24 horas, aunque Google considera compatible con ZDR esa caché no persistente y aislada por proyecto, y permite a los administradores desactivarla para todo el proyecto. Compras debe decidir si esa definición coincide con la política interna, en vez de suponer que todos los auditores tratarán igual la memoria volátil.

Google destaca para empresas que ya utilizan IAM, redes, registros y servicios de datos de Google Cloud, porque el agente aprobado puede mantener su estado duradero dentro del perímetro existente de la nube. Frente a Bedrock, pierde en simplicidad para bloquear por defecto. Hay que acertar con varias configuraciones y algunas funciones de Advanced AI pueden volver imposible ZDR. Google pide a los clientes que consulten a su equipo de cuenta; esa conversación debe suceder antes de aprobar el modelo.

Ideal para: Empresas en Google Cloud que construyen agentes sobre llamadas sin estado y aprobadas de Gemini.
Diferencial: Guía detallada, función por función, para Search, Maps, Interactions, sesiones Live, caché y CodeMender.
Precio: La tabla vigente de precios de modelos de Google fija Gemini 3.1 Flash-Lite global Standard en $0.25 de entrada, $0.025 de entrada en caché y $1.50 de salida; Priority en $0.45, $0.045 y $2.70; y Flex/Batch en $0.125, $0.0125 y $0.75, por 1 millón de tokens de texto. Web Grounding for Enterprise incluye 5,000 consultas de grounding al mes y después cuesta $14 por 1,000.
Prueba gratuita: La página activa de precios de la plataforma no indica ninguna prueba específica.

Lo bueno
Lo que hace bien
8 points

  • Buen encaje con la gobernanza de Google Cloud y el almacenamiento controlado por el cliente.
  • La documentación vigente detalla la retención de cada función.
  • El registro de solicitudes y respuestas está desactivado de forma predeterminada.
  • Web Grounding for Enterprise ofrece una alternativa orientada a ZDR frente a Grounding with Google Search.
  • Interactions API almacena estado de forma predeterminada si no se especifica store=false.
  • Search, Maps, la reanudación de sesiones y CodeMender introducen retención.
  • Algunas funciones de Advanced AI pueden hacer imposible ZDR.
  • La plataforma exige revisar más configuraciones de lo que sugiere un único interruptor ZDR.

4. Anthropic API: la mejor para usar Claude con estado controlado por el cliente

Anthropic API es la opción indicada para Claude cuando una empresa está dispuesta a montar el agente con funciones sin estado aptas y mantener el estado duradero bajo su propio control.

Documentación de Anthropic API y retención de datos con los requisitos de modelos y funciones para Zero Data Retention
Requisitos ZDR de Anthropic API

Con un acuerdo ZDR aprobado por Anthropic, la empresa afirma que no almacena los prompts ni las respuestas de sus clientes una vez devuelta la respuesta. El acuerdo se activa por organización a través de Ventas. Cubre las llamadas aptas de Messages y Token Counting; Claude Code también puede quedar cubierto cuando utiliza una clave de API de una organización Commercial o Claude Enterprise con ZDR activado.

El principal punto fuerte de Anthropic es el nivel de detalle de su tabla de requisitos. Bash, Text Editor, Computer Use y Memory del lado del cliente, además de Messages estándar, Prompt Caching y Web Search estándar, pueden mantenerse dentro del acuerdo ZDR. Así, un equipo de ingeniería competente puede construir un agente útil y conservar el estado y la ejecución de herramientas en su propio entorno. Prompt Caching mantiene representaciones KV y hashes en memoria durante el TTL de la caché, sin almacenar prompts ni respuestas de forma persistente.

La mayor barrera es la división entre modelos de frontera. Claude Fable 5 y Claude Mythos 5 exigen 30 días de retención y no están disponibles bajo ZDR. Una organización con ZDR aprobado puede habilitar la retención para un workspace, pero el tráfico de ese workspace deja de cumplir la política estricta. Es una decisión de compra, no un simple ajuste del modelo: aceptar la retención de esos modelos o elegir otro que sí sea apto.

Las funciones administradas constituyen el segundo límite. Claude Managed Agents mantiene estado y sus historiales persisten hasta que se eliminan. Batch retiene los datos durante 29 días. Code Execution y Programmatic Tool Calling pueden conservar información del contenedor hasta 30 días. Files persiste hasta su eliminación o vencimiento, y MCP Connector aplica la retención estándar. El filtrado dinámico de Web Search y Web Fetch no es apto para ZDR, aunque las modalidades estándar sí lo son.

Una diferencia respecto de Bedrock merece un recuadro rojo en la revisión de arquitectura: bajo el ZDR de Anthropic, una función no apta no siempre se bloquea. El desarrollador puede utilizarla y sacar esos datos del acuerdo. La flexibilidad de la API devuelve la responsabilidad de aplicar la política a las revisiones de código, las reglas del gateway y las pruebas de integración.

Anthropic también documenta excepciones. Los datos marcados o sujetos a una orden de conservación legal pueden guardarse hasta 2 años. Eso no anula el contrato, pero sí significa que «cero» tiene un límite de seguridad y legal. Los equipos de seguridad deben dejar constancia de ese límite, en lugar de prometer un absoluto que el proveedor no ofrece.

Ideal para: Cargas de Claude cuya memoria y herramientas puedan ejecutarse en sistemas controlados por el cliente.
Diferencial: Una matriz detallada distingue las herramientas del lado del cliente de las funciones administradas que retienen datos.
Precio: La página de precios de Anthropic API fija Haiku 4.5 en $1 de entrada y $5 de salida. Sonnet 5 cuesta $2 de entrada, $10 de salida, $2.50 por escritura en caché y $0.20 por lectura de caché. Opus 5 cuesta $5 de entrada y $25 de salida, por 1 millón de tokens. Fable 5 cuesta $10 de entrada y $50 de salida, pero no es apto para ZDR. Batch ahorra un 50%, aunque también queda fuera de ZDR.
Prueba gratuita: La página activa de precios no indica ninguna prueba de la API.

Lo bueno
Lo que hace bien
8 points

  • Tabla clara de requisitos ZDR para cada función.
  • Ruta apta y sólida con Messages, memoria y herramientas del lado del cliente.
  • Claude Code puede cumplir los requisitos dentro de la organización comercial adecuada.
  • Prompt Caching sigue disponible bajo ZDR.
  • Fable 5 y Mythos 5 exigen 30 días de retención.
  • Managed Agents, Batch, ejecución de código, archivos y MCP pueden salir del perímetro ZDR.
  • Las funciones no aptas no se bloquean automáticamente bajo ZDR.
  • Los datos marcados pueden conservarse hasta 2 años.

5. Fireworks AI: la mejor para inferencia privada con modelos abiertos

Fireworks AI es la opción más limpia para una empresa que busca inferencia con modelos abiertos y Zero Data Retention como comportamiento predeterminado.

Documentación de Fireworks AI que explica la retención cero de datos predeterminada y el almacenamiento en Responses API
Tratamiento de datos en Fireworks AI

En el caso de los modelos abiertos, la documentación sobre tratamiento de datos de Fireworks señala que los prompts y las generaciones solo viven en memoria volátil mientras se procesa la solicitud, y que no se escriben en almacenamiento persistente salvo que el usuario active el registro. La caché de prompts puede mantener tanto los datos del prompt como las cachés KV en memoria volátil durante varios minutos, y se conservan metadatos de uso como el número de tokens. Es un perímetro directo y fácil de explicar en una revisión de seguridad.

El caso de uso ideal es un servicio privado de clasificación, extracción, resumen o planificación de agentes en el que la empresa no necesite un objeto de conversación administrado por el proveedor. El equipo de plataforma puede elegir un modelo abierto, conservar la base de datos de memoria en su propia nube y emplear Fireworks como capa de inferencia de alto rendimiento. El comportamiento predeterminado del proveedor reduce el riesgo de que un proyecto nuevo empiece con los registros activados.

La excepción es importante: Fireworks Responses API usa store=True de forma predeterminada. En ese modo, los prompts, las respuestas y las llamadas a herramientas se conservan durante 30 días. Una carga ZDR en Responses debe configurar store=False. Los demás servicios de Fireworks siguen la política ZDR predeterminada, aunque funciones avanzadas como FireOptimizer pueden implicar aceptar expresamente el registro de prompts.

La tabla de precios Serverless de Fireworks es lo bastante transparente para comparar modalidades de implementación. GPT OSS 120B Standard cuesta $0.15 de entrada, $0.015 de entrada en caché y $0.60 de salida. La ruta Priority cuesta $0.18, $0.018 y $0.72. GPT OSS 20B Standard parte de $0.07 de entrada, $0.035 de entrada en caché y $0.30 de salida. Batch reduce a la mitad el precio de entrada y salida de Serverless, aunque cualquier flujo asíncrono debe contrastarse con el requisito de retención antes de usarlo.

Fireworks queda por debajo de los tres proveedores de modelos de frontera porque el comprador elige dentro de su catálogo, en vez de recibir cada modelo propietario nuevo bajo un único compromiso ZDR. Supera a Groq gracias al comportamiento ZDR predeterminado y a una documentación especialmente clara de Responses API. Entre ambas, la decisión debe basarse en la disponibilidad de modelos, el objetivo de latencia y la compatibilidad del plano de control con la implementación.

Ideal para: Empresas que sirven modelos abiertos detrás de una infraestructura de agentes controlada por el cliente.
Diferencial: ZDR es el valor predeterminado para la inferencia con modelos abiertos, salvo en llamadas almacenadas de Responses.
Precio: GPT OSS 20B Standard cuesta $0.07 de entrada, $0.035 de entrada en caché y $0.30 de salida. GPT OSS 120B Standard cuesta $0.15, $0.015 y $0.60; Priority, $0.18, $0.018 y $0.72, por 1 millón de tokens. Batch cobra el 50% de las tarifas de entrada y salida de Serverless.
Prueba gratuita: Las cuentas nuevas reciben $1 en créditos gratuitos.

Lo bueno
Lo que hace bien
8 points

  • ZDR predeterminado para la inferencia con modelos abiertos.
  • Diferenciación clara entre la caché volátil y el almacenamiento persistente.
  • Tarifas publicadas bajas para los modelos GPT OSS.
  • Las rutas Standard, Priority, Fast y Batch cubren distintas necesidades de costo y latencia.
  • Responses API almacena los datos durante 30 días si no se especifica store=False.
  • Algunas funciones avanzadas requieren activar el registro.
  • Los metadatos de uso se conservan.
  • La cobertura de modelos propietarios de frontera no es el motivo para elegirla.

6. GroqCloud: la mejor para inferencia de baja latencia con modelos abiertos

GroqCloud es la mejor opción cuando un agente basado en modelos abiertos necesita baja latencia y un control ZDR de autoservicio al alcance de todos los clientes.

Documentación de GroqCloud que muestra metadatos retenidos, registros temporales y controles de Zero Data Retention
Controles de datos de GroqCloud

Groq no conserva el contenido de inferencia de forma predeterminada, pero eso no equivale a ZDR. La documentación de datos de GroqCloud explica que la empresa puede registrar temporalmente entradas y salidas hasta 30 días para resolver problemas de fiabilidad o investigar posibles abusos. Cualquier cliente puede activar ZDR en Data Controls, de forma global o por función, y excluirse así de ese almacenamiento.

Esa ruta de autoservicio atrae a startups y equipos de plataformas medianos que no pueden esperar un ciclo de ventas empresarial. También es lo bastante específica para una empresa financiada que construya un agente de voz, clasificación o selección de herramientas sobre modelos abiertos. Los metadatos de uso se conservan siempre, pero Groq afirma que no contienen entradas ni salidas del cliente.

La contrapartida es perder funciones. Los archivos de Batch pueden persistir hasta 30 días, salvo que se eliminen antes. Los conjuntos de datos y pesos de fine-tuning permanecen hasta que se borran. Al activar ZDR se deshabilitan las funciones que necesitan retener datos del cliente para operar. Por tanto, Producto debe elegir entre una ruta de inferencia estricta y la comodidad de Batch o de la personalización alojada.

El catálogo de producción vigente de Groq fija GPT OSS 120B en $0.15 de entrada y $0.60 de salida, y GPT OSS 20B en $0.075 de entrada y $0.30 de salida, por 1 millón de tokens. El nivel de cuenta Free permite validar la integración y los límites de uso con poco riesgo. Pasar a Developer no genera un cargo inmediato: cambia la cuenta a consumo Pay-as-you-go, con límites superiores, Flex, Batch, soporte y controles de gasto.

Los niveles de servicio añaden una decisión operativa. On-Demand es el predeterminado. Flex utiliza el mismo precio por token y ofrece mayor rendimiento, pero puede devolver un error de capacidad. Performance es un nivel aprovisionado exclusivo para Enterprise y con precio comercial. auto elige un nivel disponible. Un agente orientado al usuario que no tolere reintentos puede necesitar la conversación Enterprise aunque la tarifa por token parezca baja.

Ideal para: Agentes de baja latencia con modelos abiertos que puedan permanecer sin estado en el proveedor.
Diferencial: Todos los clientes pueden activar ZDR sin pasar por una aprobación empresarial independiente.
Precio: GPT OSS 20B cuesta $0.075 de entrada y $0.30 de salida; GPT OSS 120B cuesta $0.15 de entrada y $0.60 de salida, por 1 millón de tokens. Hay niveles de cuenta Free y Developer; Performance emplea precios de capacidad aprovisionada Enterprise gestionados por Ventas.
Prueba gratuita: Hay un nivel de cuenta Free.

Lo bueno
Lo que hace bien
8 points

  • ZDR de autoservicio para todos los clientes.
  • Tarifas publicadas bajas para modelos abiertos.
  • El nivel gratuito permite probar la integración antes de pagar.
  • Los planes de pago incluyen límites de gasto.
  • La inferencia predeterminada todavía puede registrarse temporalmente hasta 30 días.
  • ZDR deshabilita Batch y la persistencia del fine-tuning.
  • Los metadatos de uso permanecen.
  • Las garantías de rendimiento requieren un acuerdo Enterprise.

7. Microsoft Foundry: la mejor para empresas gobernadas desde Azure

Microsoft Foundry encaja mejor en una empresa de Azure que busca inferencia sin estado, almacenamiento controlado por el tenant y una vía formal para desactivar el almacenamiento de contenido utilizado en la vigilancia de abusos.

Documentación de privacidad de Microsoft Foundry que muestra inferencia sin estado, funciones almacenadas y vigilancia de abusos modificada
Controles de privacidad de datos de Microsoft Foundry

La documentación de privacidad de Foundry de Microsoft establece que los modelos vendidos por Azure no tienen estado: los prompts y las respuestas no se almacenan en el modelo ni se usan para entrenar o mejorar los modelos base. Los clientes administrados pueden solicitar una vigilancia de abusos modificada. Una vez aprobada, no se utilizan ni el repositorio de datos ni el proceso de revisión humana de dicha vigilancia, aunque el análisis automatizado todavía puede ejecutarse durante el procesamiento de una solicitud.

La combinación ofrece una ruta defendible de estilo ZDR, pero Microsoft no la presenta como una única configuración ZDR universal y de autoservicio. La empresa debe obtener aprobación, escoger funciones sin estado y verificar la suscripción. Un recurso de Foundry aprobado muestra ContentLogging como false entre sus capacidades cuando el almacenamiento para vigilar abusos está desactivado. Es una evidencia valiosa para quien gestiona el control, ya que puede comprobarse en el portal o mediante las API de administración de Azure.

El comprador natural es una empresa cuya identidad, red, gestión de claves, residencia de datos y compras ya pasan por Azure. El agente puede mantener documentos y memoria duradera en recursos de Azure elegidos por el cliente, recurrir a una implementación sin estado para la inferencia y conservar un único modelo de gobernanza en la nube. A menudo, esto importa más que ahorrar unos centavos en la tarifa de un modelo.

El límite está en las funciones que almacenan datos por diseño. Responses puede guardar el historial de mensajes. Assistants Threads, Files, Vector Stores, Stored Completions, Batch y fine-tuning también conservan datos del cliente dentro del tenant. El cifrado, la propiedad del tenant y los controles de borrado pueden hacer aceptable ese almacenamiento, pero no lo convierten en retención cero. Un flujo estricto debe utilizar una llamada sin estado al modelo y una capa externa de estado con su propia política de eliminación.

Los precios de modelos de Azure tienen tres modalidades comerciales: Standard On-Demand, Provisioned Throughput Units y Batch. Batch termina en un plazo de 24 horas con un precio un 50% inferior a Global Standard, pero almacena el trabajo cargado mientras lo procesa, por lo que no es la ruta estricta. GPT-5.6 Luna para contexto corto cuesta $0.20 de entrada, $0.02 de entrada en caché, $0.25 por escritura en caché y $1.20 de salida en Global Standard. Data Zone eleva esas tarifas a $0.22, $0.03, $0.28 y $1.32.

Ideal para: Empresas que ya gobiernan la IA sensible mediante suscripciones y zonas geográficas de Azure.
Diferencial: ContentLogging:false proporciona a un cliente aprobado un control verificable sobre el almacenamiento para vigilar abusos.
Precio: GPT-5.6 Luna para contexto corto en Global Standard cuesta $0.20 de entrada, $0.02 de entrada en caché, $0.25 por escritura en caché y $1.20 de salida; en Data Zone, $0.22, $0.03, $0.28 y $1.32, por 1 millón de tokens. Batch cuesta un 50% menos que Global Standard, pero almacena el trabajo. El precio aprovisionado depende de la implementación y la reserva.
Prueba gratuita: La página activa de precios de modelos no indica ninguna prueba específica de Foundry.

Lo bueno
Lo que hace bien
8 points

  • Buen encaje con los controles de identidad, red, claves y geografía de Azure.
  • La inferencia sin estado no almacena los prompts en el modelo.
  • La vigilancia de abusos modificada puede eliminar el almacenamiento de contenido y la revisión humana.
  • El estado del control puede verificarse en las capacidades del recurso.
  • Ningún interruptor ZDR universal cubre el producto completo.
  • La vigilancia de abusos modificada requiere aprobación.
  • Muchas funciones prácticas para agentes almacenan datos del tenant.
  • Las opciones Data Zone y de implementación aprovisionada aumentan la complejidad de precios.

8. OpenRouter: la mejor para enrutamiento ZDR entre proveedores

OpenRouter es el mejor gateway cuando un único agente empresarial necesita acceder a numerosos proveedores y la capa de enrutamiento debe excluir los endpoints sin una política ZDR.

Documentación de OpenRouter que muestra la aplicación de ZDR de forma global, por grupo de modelos, guardrail y solicitud
Controles de enrutamiento ZDR de OpenRouter

La aplicación de ZDR en OpenRouter funciona globalmente, por grupo de modelos, dentro de un guardrail o por solicitud. Una solicitud con zdr:true solo se dirige a endpoints que OpenRouter identifica como ZDR. La regla de la solicitud se combina mediante un OR lógico con los ajustes de la cuenta y del guardrail, por lo que una petición individual no puede debilitar una política más estricta.

Esto resulta útil tanto al evaluar modelos como al enrutar la producción entre varios proveedores. Un equipo de plataforma puede mantener una única integración compatible con OpenAI, comparar endpoints aptos e impedir que una ruta alternativa termine en un proveedor que retenga prompts. OpenRouter también afirma que no conserva los prompts salvo que el cliente active su registro.

La ventaja tiene dos límites. Primero, la aplicación de ZDR de OpenRouter cubre el enrutamiento de inferencia hacia el proveedor, pero no los plugins ni herramientas como la búsqueda web. Cada tercero necesita su propia revisión. Segundo, una política de grupo de modelos puede cambiar la ruta de una forma inesperada para el comprador. Exigir ZDR para Anthropic elimina los endpoints propios de Anthropic, pero puede dejar disponibles las rutas de Bedrock y Vertex. El grupo OpenAI retira los endpoints propios de OpenAI, pero puede conservar Azure. El grupo Google elimina AI Studio, aunque puede mantener Vertex.

Ese comportamiento solo es útil si Seguridad aprueba la ruta de proveedor que permanece. «Modelo ZDR» no basta. El contrato, la región, la configuración de vigilancia de abusos, la cadena de herramientas y el propietario del endpoint deben coincidir con la política buscada. OpenRouter publica una lista actual de endpoints ZDR, pero una empresa debe guardar una copia del conjunto aprobado y generar una alerta cuando cambie una ruta.

La página de precios de OpenRouter es clara. Free incluye más de 25 modelos gratuitos, 4 proveedores y 50 solicitudes diarias. Pay-as-you-go abarca más de 500 modelos y 80 proveedores, sin gasto mínimo y con una comisión de plataforma del 5.5%. Enterprise ofrece descuentos sobre la comisión mediante compromisos de volumen gestionados por Ventas. El uso con claves propias no paga comisión hasta $25,000 mensuales de inferencia a precio de lista en Pay-as-you-go y $200,000 en Enterprise; después se aplica un 5%.

OpenRouter ocupa el octavo lugar porque un gateway incorpora otro procesador y otra capa de políticas. Puede mejorar la aplicación de controles, pero no hacer que una herramienta o un proveedor incompatible pase a cumplirlos. Conviene cuando la variedad de modelos y las rutas alternativas importan lo suficiente para justificar ese perímetro adicional.

Ideal para: Agentes multimodelo que necesitan enrutamiento y rutas alternativas conscientes de ZDR.
Diferencial: Los controles de cuenta, grupo de modelos, guardrail y solicitud pueden impedir el enrutamiento hacia endpoints sin ZDR.
Precio: Free tiene más de 25 modelos, 4 proveedores y 50 solicitudes al día. Pay-as-you-go cobra una comisión de plataforma del 5.5% y no exige un mínimo. Enterprise emplea compromisos de volumen con precios comerciales. BYOK no paga comisión hasta $25,000 de inferencia mensual a precio de lista en Pay-as-you-go o $200,000 en Enterprise; después cobra un 5%.
Prueba gratuita: Free es un plan permanente, no una prueba limitada en el tiempo.

Lo bueno
Lo que hace bien
8 points

  • Una capa de políticas permite gobernar endpoints de numerosos proveedores.
  • Las reglas por solicitud no pueden anular una política de cuenta más estricta.
  • El plan Free admite pruebas de integración de bajo volumen.
  • Los metadatos de endpoints publicados permiten inspeccionar la política de enrutamiento.
  • Los plugins y las herramientas quedan fuera del perímetro de aplicación de ZDR.
  • Una ruta alojada en la nube que siga disponible necesita igualmente su propia aprobación.
  • Los requisitos de los proveedores pueden cambiar con el tiempo.
  • La comisión de la plataforma eleva el costo del uso enrutado.

9. Mistral AI: la mejor para cargas Mistral sin estado, no para Mistral Agents

Mistral AI es una buena plataforma ZDR para cargas aprobadas de API sin estado, pero su producto administrado Agents queda explícitamente fuera del perímetro ZDR.

Documentación de Mistral que enumera los endpoints sin estado cubiertos por ZDR y los productos con estado que quedan excluidos
Cobertura ZDR de Mistral AI

La documentación ZDR de Mistral ofrece el control previa aprobación en los planes de pago. Entre los endpoints sin estado cubiertos figuran Chat Completions, completions fill-in-the-middle, Embeddings, Moderation, Classification, OCR, Speech y Transcription. Los modelos Labs quedan excluidos. Es un abanico útil para un servicio de extracción multilingüe, un clasificador privado de documentos o un agente de programación controlado por el cliente.

El límite declarado es especialmente directo: Agents, archivos Batch, Conversations, Libraries, Files, Vibe Work y Chat no están cubiertos. Por tanto, el producto llamado Agents no puede servir como capa administrada de un agente con ZDR estricto. Hay que utilizar la API sin estado bajo un orquestador propio y guardar en otro lugar la memoria, los documentos y el estado de las tareas.

Mistral también separa ZDR de la exclusión del entrenamiento. Un cliente no necesita ZDR únicamente para evitar que los datos aptos entrenen modelos, y seleccionar «sin entrenamiento» no crea retención cero. Esa formulación ayuda a Compras a redactar correctamente el requisito.

La página de precios de Mistral API fija Mistral Large en $0.50 de entrada y $1.50 de salida por 1 millón de tokens. Batch reduce el precio de los tokens un 50% y la entrada en caché puede disminuir el costo de entrada hasta un 90%, pero los archivos Batch quedan fuera de ZDR. Los niveles del producto para usuarios son Free, con $10 mensuales en créditos de API; Pro, a $14.99 al mes y con $30 en créditos mensuales de API; Team, a $24.99 por usuario al mes; y Enterprise, mediante Ventas. Ninguno de esos niveles hace apta para ZDR la función administrada Agents. Una organización ZDR necesita un plan de pago y aprobación.

Mistral queda última porque la consulta objetivo trata específicamente sobre agentes empresariales. Su API sin estado es competitiva, el precio es claro y la lista de cobertura resulta útil. Sin embargo, la contradicción en el nombre del producto deja demasiado margen para que un comprador ejecutivo elija la capa equivocada.

Ideal para: Llamadas a modelos Mistral dentro de una arquitectura de agentes construida y almacenada por el cliente.
Diferencial: Amplia cobertura de API sin estado para texto, OCR, clasificación y audio.
Precio: Mistral Large cuesta $0.50 de entrada y $1.50 de salida por 1 millón de tokens. Batch cuesta un 50% menos y la entrada en caché puede ser hasta un 90% más barata, pero los archivos Batch quedan fuera de ZDR. Los productos para usuarios son Free, con $10 mensuales en créditos de API; Pro, a $14.99 al mes y con $30 en créditos mensuales; Team, a $24.99 por usuario al mes; y Enterprise, mediante Ventas. ZDR sigue exigiendo un plan de pago y aprobación.
Prueba gratuita: El plan de producto Free no cumple los requisitos de ZDR.

Lo bueno
Lo que hace bien
8 points

  • Lista clara de endpoints sin estado compatibles.
  • Precio competitivo por token de Mistral Large.
  • La cobertura va más allá del texto e incluye API de OCR y audio.
  • ZDR y la exclusión del entrenamiento están documentados como decisiones distintas.
  • El producto administrado Agents no es apto para ZDR.
  • Batch, Files, Conversations y Libraries están excluidos.
  • Los modelos Labs están excluidos.
  • Se necesitan aprobación y un plan de pago.

El presupuesto mensual de inferencia no es todo el presupuesto de privacidad

Las tarifas por token importan porque un agente empresarial puede generar miles de millones de tokens de entrada a partir de documentos recuperados, resultados de herramientas y memoria repetida. Aun así, no miden la calidad del modelo. La comparación siguiente normaliza una sola carga: 1,000 millones de tokens de entrada y 200 millones de salida, sin caché, herramientas, recargo regional ni descuento por volumen.

Escala de costos en cinco niveles que compara las tarifas mensuales publicadas por token de Fireworks o Groq, OpenAI, Google, Mistral y Anthropic
Tarifas publicadas para un mismo volumen de tokens. Es una comparación presupuestaria, no un benchmark de calidad.

Fireworks o Groq con GPT OSS 120B cuestan $270. OpenAI GPT-5.6 Luna queda en $440. Google Gemini 3.1 Flash-Lite, en $550. Mistral Large, en $800. Anthropic Sonnet 5, en $4,000. Un valor menor no significa que el modelo complete la misma tarea con la misma precisión, latencia o cantidad de reintentos.

El cálculo de compra más útil tiene tres partidas:

  1. Inferencia: tokens del modelo, herramientas, grounding, procesamiento regional y comisiones del gateway.
  2. Control del estado: base de datos, almacenamiento de objetos, secretos, cifrado, rutinas de borrado, trazas y respaldos.
  3. Operación de controles: evidencia de aprobación, pruebas de regresión, seguimiento de proveedores, revisión de incidentes y horas de personal.

Un agente privado resulta rentable cuando la suma de esas tres partidas es menor que el costo y el riesgo de un flujo administrado con retención. El resultado depende de la sensibilidad de los datos. Un agente de soporte que procesa contenido público del centro de ayuda quizá no necesite ZDR. Uno de due diligence que lee documentos de una adquisición sí suele necesitarlo.

Para profundizar en la economía de tokens de distintos proveedores, consulte esta comparación de las API de IA más económicas. Mantenga el benchmark de calidad separado de la tabla de precios.

Qué plataforma conviene en cada caso

Quien dirige una startup financiada y desarrolla un producto sanitario o financiero debería comenzar con OpenAI API si necesita capacidad de frontera y la empresa puede obtener la aprobación ZDR. La memoria de pacientes, clientes o transacciones debe permanecer en la capa de datos de la propia empresa. Si el producto depende de recursos de OpenAI no aptos, hay que corregir la arquitectura antes de que Compras firme por el modelo.

Un CTO de una empresa mediana con un plano de control consolidado en AWS debería elegir Amazon Bedrock cuando el objetivo de seguridad sea aplicar la política en toda la organización. La decisión deja de favorecer a Bedrock si un modelo imprescindible no admite none y el negocio no acepta sustituirlo.

Una empresa de Google Cloud debería optar por Gemini Enterprise Agent Platform cuando IAM, los repositorios de datos y la operación ya residan allí. La balanza cambia si el flujo necesita Grounding with Google Search, Grounding with Google Maps, la persistencia de sesiones de CodeMender u otra función de Advanced AI incompatible con la política.

Un responsable sénior de plataforma que quiera Claude debería escoger Anthropic API cuando el equipo pueda usar llamadas aptas de Messages y herramientas del lado del cliente. La decisión cambia si Fable 5, Mythos 5, Managed Agents, la ejecución de código alojada o MCP Connector son imprescindibles.

Un equipo que trabaje con modelos abiertos debería preseleccionar Fireworks AI y GroqCloud. Fireworks conviene cuando encajan su ZDR predeterminado y su catálogo; Groq, cuando encajan su baja latencia, su ZDR de autoservicio y su modelo de capacidad. Antes de decidir, hay que probar el modelo y la carga exactos.

Una empresa estandarizada en Azure debería utilizar Microsoft Foundry si obtiene aprobación para la vigilancia de abusos modificada y puede verificar ContentLogging:false. La decisión se inclina en contra si la organización busca un único contrato ZDR portable entre nubes, en lugar de controles específicos de Azure.

OpenRouter conviene cuando son requisitos la variedad de modelos, las rutas alternativas y la diversidad de proveedores. No debe usarse como atajo de privacidad. Cada plugin, herramienta y endpoint de proveedor restante sigue necesitando aprobación.

La API sin estado de Mistral es adecuada si sus modelos encajan con la tarea y la empresa puede construir su propia capa de estado. Para un requisito ZDR estricto, no debe elegirse el producto administrado Agents.

Qué debe evitarse si ZDR es un requisito estricto

Evite Claude Fable 5 y Claude Mythos 5 salvo que la organización acepte formalmente 30 días de retención. La misma exclusión acompaña a esos modelos cubiertos tanto en la API propia como en los marketplaces de nube, a menos que la cuenta tenga requisitos ZDR específicos.

Evite Mistral Agents cuando el requisito del flujo diga literalmente «retención cero de datos». Las API sin estado de Mistral pueden cumplirlo; su producto administrado Agents no.

Evite Grounding with Google Search y Grounding with Google Maps dentro de una ruta estricta. Search impone un plazo de retención inevitable de hasta 3 días, y Maps guarda el contenido pertinente durante 30 días. Utilice Web Grounding for Enterprise si satisface el caso de uso y el contrato.

Evite los valores predeterminados que almacenan conversaciones. Fireworks Responses adopta store=True de forma predeterminada. Google Interactions también establece store en true. Una política de producción debe especificar el comportamiento privado y rechazar cualquier implementación que lo omita.

Evite los endpoints prácticos con estado si no tienen una aprobación de retención independiente. Entre ellos están Conversations, Assistants, Threads, Files, Vector Stores y Batch de OpenAI; Managed Agents, Batch, Files, ejecución de código y MCP Connector de Anthropic; Batch y el estado de fine-tuning de Groq; el historial de Responses, Assistants Threads, Files y Batch de Microsoft; y Conversations, Libraries, Files y Batch de Mistral.

Evite una revisión de privacidad limitada al gateway. OpenRouter puede impedir que una ruta de inferencia llegue a un endpoint sin ZDR. No gobierna el plugin de búsqueda web, el servidor MCP, el CRM, el navegador, la herramienta de analítica ni la base de datos que recibe contenido después de la llamada al modelo.

La acción del lunes: ejecute una prueba de retención

No empiece con un proceso de compra para nueve proveedores. El lunes, elija un flujo sensible y demuestre cuál es su perímetro.

  1. Elija un registro

    Cree un registro sintético que se parezca a los datos sensibles que manejará el agente. Añádale una cadena señuelo única para poder buscar cada copia.

  2. Dibuje cada salto

    Enumere el cliente, el gateway, el endpoint del modelo, la caché, la base de datos de memoria, el repositorio de archivos, el sistema de observabilidad, la herramienta y la ruta de revisión humana. Asigne a cada elemento un responsable y una regla de retención.

  3. Active el control estricto

    Habilite la configuración ZDR o sin estado de la plataforma a nivel de organización o proyecto. Defina expresamente los indicadores de almacenamiento de cada solicitud, aunque el proveedor afirme que ZDR los anula.

  4. Fuerce un fallo en el flujo

    Llame a una función incompatible. Un control sólido debe bloquearla, deshabilitarla o generar una alerta. Si la llamada funciona y almacena la cadena señuelo, la arquitectura necesita otra capa de aplicación.

  5. Busque, elimine y firme

    Busque la cadena señuelo en todos los sistemas aprobados, ejecute la ruta de borrado, conserve la evidencia y pida a Seguridad y al responsable de Producto que firmen el diagrama. Repita el ejercicio tras cualquier cambio de modelo, herramienta o función del agente.

El resultado no es una política de 40 páginas. Es un mapa de solicitudes, un paquete de evidencias y una decisión: conservar el flujo, cambiar la función o cambiar de proveedor. Así, ZDR se convierte en un control operativo y deja de ser un adjetivo de compra.

Preguntas frecuentes

¿Cuál es la mejor plataforma de agentes de IA para empresas?

OpenAI API es la mejor plataforma de modelos con ZDR para la mayoría de las empresas que necesitan capacidad de frontera, mientras que Amazon Bedrock resulta superior cuando la política de retención debe bloquear por defecto en toda una organización de AWS. Google Gemini Enterprise Agent Platform es la opción más sólida para un entorno existente de Google Cloud. La mejor elección cambia cuando una función necesaria de memoria, archivos, búsqueda o agentes administrados queda fuera de ZDR.

¿Cuál es el mejor agente de IA en 2026?

No existe un único agente óptimo para todos los flujos empresariales. Con ZDR estricto, el agente debe construirse alrededor de un endpoint de modelo sin estado compatible y guardar el estado duradero en sistemas controlados por el cliente. OpenAI lidera en modelos de frontera con ZDR, Bedrock en aplicación de políticas y Fireworks o Groq en inferencia con modelos abiertos.

¿Cuáles son las tendencias clave de IA empresarial en 2026?

Una tendencia importante es separar el acceso al modelo del control del estado. Las reglas de retención de los modelos de frontera ya condicionan qué modelos son aptos, mientras las empresas necesitan cada vez más controlar la memoria, los archivos, las trazas y la gobernanza de herramientas para mantener privados los flujos sensibles de sus agentes.

¿Cuál es la mejor plataforma de IA en 2026?

Para un programa general de IA empresarial, la mejor plataforma es la que encaja con los controles de nube, los requisitos de modelos, el perímetro de datos y el equipo operativo de la empresa. Para el requisito más específico de ZDR, OpenAI API, Amazon Bedrock y Google Gemini Enterprise Agent Platform son las opciones principales, cada una con distintas contrapartidas en cobertura funcional y aplicación de controles.

¿Quiere una guía de una página para asociar herramientas de IA con flujos de negocio y niveles de riesgo? Consiga el Mapa de herramientas de IA para responsables de empresa a través del boletín.

Última actualización

2 sept 2026

CategoríaAI

Prefiera este sitio en Google

Añadir omidsaffari.com como fuente preferida en la Búsqueda de Google

Marque omidsaffari.com como fuente preferida y Google lo destacará para usted en Top Stories, AI Overviews y AI Mode.

Newsletter

Una carta, cada domingo. Sistemas que funcionan, no opiniones calientes.

Build logs, sistemas en producción y notas de campo de un portafolio de ventures de IA.

Semanal. Sin spam. Cancele cuando quiera.