OpenAI Presence: despliegue gestionado de agentes de IA, no autoservicio
OpenAI Presence despliega agentes de IA gestionados para voz y chat empresarial. Analizamos qué incluye, sus límites y cuándo conviene contratar o desarrollar.
OpenAI afirma que Presence ya resuelve sin intervención humana el 75% de las incidencias que recibe su línea telefónica de soporte en inglés, y que su ciclo de mejora redujo las derivaciones a personas en 15 puntos porcentuales en 10 días. El producto detrás de esas cifras no es un creador de agentes de IA que cualquiera pueda contratar. Es un despliegue empresarial gestionado que reúne el agente, las políticas, las evaluaciones, la integración de sistemas y el trabajo operativo continuo.
El veredicto: Presence vende el despliegue, no el modelo
OpenAI Presence merece consideración cuando un flujo de voz o chat de cara al cliente debe ejecutar acciones reales bajo políticas estrictas y la empresa quiere que OpenAI comparta la carga del despliegue. No es el punto de partida adecuado para un equipo pequeño que busca un creador de agentes de autoservicio, para quien necesita un SDK ni para una empresa que todavía no ha elegido un único flujo de trabajo acotado del cual hacerse cargo.
Las condiciones de lanzamiento resultan especialmente reveladoras: Presence solo está disponible para clientes empresariales elegibles mediante una disponibilidad general limitada. Los Forward Deployed Engineers de OpenAI y algunos integradores globales de sistemas dirigen los despliegues, y OpenAI deja claro que el producto no es de autoservicio. Ni la página de lanzamiento ni la página actual de Frontier muestran un precio de lista público.
Por eso, el modelo de entrega es el producto. Un modelo de frontera ya puede interpretar una solicitud de soporte. Lo difícil es proporcionarle el contexto correcto de la cuenta, limitar sus permisos, aplicar una política de reembolsos, validar sus acciones, decidir cuándo una aprobación es obligatoria, derivar un caso de riesgo a una persona y actualizar el sistema sin romper lo que funcionaba el día anterior. Presence agrupa todas esas tareas en un único servicio gestionado.
Qué incluye realmente Presence
Presence es una capa de producción diseñada para una tarea concreta, no un empleado digital de propósito general. Cada despliegue parte de un flujo de trabajo específico. El agente recibe únicamente el conocimiento y el acceso a sistemas que requiere esa tarea, mientras el cliente define sus políticas, los puntos de aprobación y las reglas de derivación a personas.
El término guardrail puede parecer un filtro aplicado después de la respuesta del modelo. Aquí designa un sistema de control mucho más amplio: reglas que restringen las entradas, las herramientas, las acciones, los permisos y las escalaciones. Presence combina políticas y procedimientos operativos estándar, guardrails, acciones autorizadas, simulaciones, herramientas de evaluación y un proceso de mejora basado en Codex.
Delimitar una sola tarea
Elija un resultado completo, como resolver una incidencia de facturación, atender una reclamación de seguro o gestionar una solicitud de TI de un empleado. Una instrucción tan amplia como «ayudar a todos los clientes» no permite crear un conjunto de evaluación útil ni establecer un límite de permisos defendible.
Limitar el contexto y el acceso
Conecte solo los registros y sistemas necesarios para esa tarea. Un agente de facturación puede requerir datos de identidad, cuenta, facturas y pagos. No necesita acceso irrestricto a todo el patrimonio de datos de clientes.
Codificar las políticas y aprobaciones
Defina qué puede responder el agente, qué acciones puede ejecutar, cuándo debe solicitar aprobación y cuándo debe intervenir una persona. Una frase correcta acompañada de una acción no autorizada sigue siendo un fallo en producción.
Simular antes del lanzamiento
Evalúe las solicitudes habituales, los casos límite y los escenarios de mayor riesgo con sistemas de calificación. OpenAI afirma que las comprobaciones cubren la calidad del resultado, el cumplimiento de políticas, el uso de herramientas y el comportamiento de escalación.
Mejorar con control de cambios
Las sesiones en producción, las escalaciones y las señales de calidad revelan carencias. Codex investiga esas señales y propone actualizaciones que el equipo puede comparar con la versión en producción antes de aprobar un despliegue controlado.
El ciclo importa más que la demostración. Un agente de voz puede sonar natural el día del lanzamiento y aun así fallar cuando cambia un producto, aparece una nueva excepción en la política de reembolsos o las personas aprenden a formular solicitudes que el conjunto de pruebas original no contemplaba. Presence utiliza el comportamiento en producción como fuente de cambios propuestos y exige pruebas y aprobación antes de llevarlos al sistema activo.
Para quien dirige atención al cliente, esa es la diferencia práctica entre un chatbot y un sistema operativo para un flujo de trabajo. El chatbot responde. El agente en producción verifica, decide, actúa dentro de su autoridad, registra lo ocurrido y deriva el caso cuando el riesgo supera esa autoridad.
La evidencia es prometedora, pero limitada
Los datos del lanzamiento demuestran que Presence puede operar un canal real de soporte, aunque todavía no prueban un retorno generalizable para cualquier empresa. OpenAI comunica resultados de su propia línea telefónica de soporte en inglés, 1-888-GPT-0090, de modo que son evidencia útil sobre el producto y, al mismo tiempo, datos aportados por el propio proveedor.
La lista de socios de diseño se encuentra en una fase anterior. BBVA estudia el soporte por voz para necesidades bancarias cotidianas en México. SoftBank prueba conversaciones naturales con clientes en japonés. IAG explora la asistencia durante episodios de alta demanda, como condiciones meteorológicas severas. Estos programas muestran amplitud en idiomas y flujos regulados, pero OpenAI no los presenta como resultados equivalentes en producción.
El lanzamiento tampoco aporta los datos que necesita un equipo de compras: precio público, plazo de implantación, volumen mínimo, modelo de soporte, tasas de error por acción y costo por contacto resuelto correctamente. La disponibilidad general limitada explica esta ausencia, pero también significa que todavía no existe una comparación pública y creíble de costos. Cualquier cálculo preciso de ROI que no parta de un contrato y de la línea base del flujo de trabajo debe considerarse ficticio.
Dónde encaja Presence en la oferta de agentes de IA de OpenAI
Presence es la vía de flujos gestionados dentro de una familia de productos que también incluye ChatGPT Workspace Agents, OpenAI Agents SDK y Frontier. Tratar esos nombres como si fueran intercambiables conduce a una mala compra, porque cada opción sitúa la responsabilidad en un lugar distinto.
ChatGPT Workspace Agents: trabajo interno y repetible
ChatGPT Workspace Agents es la vía más ligera para tareas repetibles que ya se realizan dentro de un workspace Business o Enterprise. Quien crea el agente puede elegir el modelo y el nivel de razonamiento, conectar aplicaciones y herramientas, publicarlo para sus colegas, usarlo en Slack, programarlo o activarlo mediante una API.
Los controles son relevantes, aunque el margen de ejecución es más estrecho. Las acciones de escritura para aplicaciones y conectores tienen Always ask como opción predeterminada. Connector Action Constraints permite restringir lo que puede hacer una integración, si bien OpenAI advierte que esas restricciones no filtran los datos que devuelve un conector. Los archivos tienen un límite de 512 MB cada uno y de 10 GB en total por agente.
La limitación decisiva de la API es operativa: un activador pone una ejecución en cola y devuelve 202 Accepted sin cuerpo de respuesta. No proporciona un identificador de ejecución y, por ahora, tampoco permite recuperar la respuesta mediante esa API. Puede servir para tareas internas que se envían y no requieren seguimiento. En cambio, es un contrato deficiente para un producto de cara al cliente que necesita estado síncrono, lógica de reintentos y un resultado trazable.
OpenAI Agents SDK: control de un producto propio
La vía de OpenAI Agents SDK encaja en una empresa que quiere integrar el agente en su propio producto o infraestructura. La guía para crear agentes de OpenAI reduce la arquitectura a tres componentes centrales: un modelo que razona, herramientas que leen o actúan e instrucciones que definen el comportamiento.
Estos componentes son solo el núcleo del sistema. Quien desarrolla sigue siendo responsable de la identidad, la autorización, los contratos de las herramientas, los datos de evaluación, la supervisión, el comportamiento alternativo ante fallos, la respuesta a incidentes y el costo. OpenAI recomienda comenzar con el modelo más potente para establecer una línea base de evaluación y luego sustituirlo por modelos más pequeños allí donde la precisión siga siendo aceptable. También aconseja llevar un solo agente al máximo de sus capacidades antes de adoptar una arquitectura multiagente.
La opción personalizada es la correcta cuando el flujo de trabajo diferencia el producto, las restricciones de despliegue son inusuales o el negocio necesita ajustar con precisión los costos de modelos y herramientas. Si la portabilidad entre proveedores es importante, la capa de abstracción debe diseñarse por encima del SDK de cualquier proveedor. Elegir un SDK, por sí solo, no crea portabilidad.
OpenAI Frontier: la plataforma para toda la organización
OpenAI Frontier es la vía de plataforma amplia para empresas que operan muchos agentes en distintos departamentos y sistemas. Sus capas publicadas son Business Context, Agent Execution, evaluación y optimización, y seguridad y gobernanza empresarial.
Frontier está diseñado para gobernar en una sola plataforma los agentes creados por el cliente, los de OpenAI y los de terceros. OpenAI describe identidad y gestión de acceso para agentes, permisos explícitos, acciones auditables, supervisión y registros detallados. Su Enterprise Frontier Program también reúne a ingenieros de despliegue directo con el cliente para diseñar la arquitectura, llevar la gobernanza a la práctica y operar agentes en producción.
El mapa de productos es sencillo: Workspace Agents ofrece una experiencia de agente interno; el SDK, componentes de desarrollo; Presence, un flujo desplegado; y Frontier, el plano de control empresarial. OpenAI no ha publicado un mapa contractual que detalle qué componentes de Frontier incluye un servicio de Presence, así que conviene preguntar en lugar de darlo por hecho.
Para ampliar la comparación más allá de OpenAI, consulte las plataformas empresariales y sus implicaciones operativas en los mejores agentes de IA de 2026.
Quién debería contratar Presence y quién debería desarrollar su propio agente
Conviene contratar Presence cuando el flujo es acotado, valioso, orientado a acciones y costoso si falla. Conviene desarrollar un agente propio cuando este constituye propiedad intelectual estratégica, cuando las restricciones operativas son inusuales o cuando el control a largo plazo pesa más que una vía gestionada hacia producción.
Presence resulta especialmente convincente en un servicio sujeto a muchas políticas. Pensemos en una aseguradora que atiende llamadas sobre el estado de reclamaciones durante condiciones meteorológicas severas. El agente debe identificar a quien llama, recuperar la póliza y la reclamación correctas, distinguir una consulta de estado de una solicitud de cambio, actuar solo dentro de su autoridad y derivar el caso a una persona cuando aumente el riesgo. El lenguaje natural es apenas una parte. El acceso y la escalación determinan si el flujo es seguro.
El desarrollo propio gana cuando el agente genera una ventaja competitiva. Una empresa de software vertical puede necesitar herramientas exclusivas, un conjunto de evaluación específico del sector, una experiencia de usuario distintiva, compatibilidad con varios proveedores de modelos o un despliegue en un entorno al que no puede adaptarse un servicio gestionado. En ese caso, externalizar el ciclo operativo también puede significar externalizar un aprendizaje que debería permanecer dentro del equipo de producto.
La perspectiva del operador cambia la respuesta. Un CTO de una empresa mediana, con una cola de soporte cargada de políticas y sin interés en crear una función permanente de operaciones de agentes, tiene motivos válidos para probar Presence. Una startup financiada cuyo producto es el agente normalmente debería controlar la arquitectura y los datos de evaluación. Un responsable sénior que automatiza aprobaciones internas debería comenzar con Workspace Agents o con un flujo determinista. Para un desarrollador técnico independiente, la vía del SDK resulta más adecuada, porque Presence no es autoservicio ni está pensado como experimento ligero.
No desarrolle un agente solo porque un LLM pueda interpretar la entrada. Si un motor de reglas puede decidir de forma fiable y la capa de lenguaje se limita a recopilar campos estructurados, mantenga la decisión en un sistema determinista. Use razonamiento probabilístico únicamente cuando la ambigüedad lo exija de verdad.
Exija un cuadro de mando del flujo antes de firmar
El piloto debe evaluarse por la corrección de sus resultados y por la forma en que controla los fallos, no por lo humana que parezca la conversación. La cifra del 75% de resolución funciona como titular, pero el contrato necesita definiciones que resistan el escrutinio de finanzas, riesgos y operaciones.
Mida, como mínimo, estos indicadores:
- Tasa de resolución correcta: proporción de contactos elegibles completados con precisión, no solo cerrados sin intervención humana.
- Tasa de falsas resoluciones: contactos marcados como completos pese a una respuesta errónea, una acción incorrecta o una necesidad sin resolver.
- Cumplimiento de políticas: si el agente siguió la regla y la ruta de aprobación vigentes en ese momento.
- Calidad de ejecución de herramientas: si las lecturas y escrituras actuaron sobre el registro correcto, utilizaron los parámetros adecuados y generaron el cambio de estado previsto.
- Calidad de la escalación: si los casos inciertos o de riesgo llegaron a la persona indicada con el contexto necesario para continuar.
- Costo por contacto resuelto correctamente: costos de contrato, modelo, integración, revisión y soporte divididos entre los resultados satisfactorios verificados.
- Latencia y abandono: comportamiento del tiempo de respuesta con demanda normal y en picos, y si las personas abandonan antes de obtener una solución.
- Seguridad de los cambios: si una modificación propuesta de política o prompt mejora los casos objetivo sin perjudicar los ya resueltos.
El denominador importa. Un sistema puede mejorar la contención si asume las solicitudes fáciles y deriva todo lo costoso. También puede inflar la resolución al cerrar conversaciones que vuelven a abrirse más tarde. Segmente los resultados por intención, tipo de acción, nivel de riesgo, idioma y canal para impedir que el agregado oculte los fallos más caros.
Elegir un resultado completo
Defina la tarea en términos de negocio: dónde comienza, cómo es un final correcto, qué acciones puede ejecutar y qué casos deben pasar siempre a una persona.
Crear el conjunto de evaluación
Utilice documentos reales de políticas y patrones históricos anonimizados para cubrir solicitudes normales, ambigüedad, información ausente, formulaciones adversarias, cambios de políticas y casos límite de alto riesgo.
Establecer la matriz de autoridad
Enumere cada acción de herramienta y clasifíquela según su reversibilidad, permisos, impacto económico y posible daño al cliente. Mantenga las acciones irreversibles o de alto riesgo bajo supervisión humana hasta que la evidencia permita ampliar el límite.
Operar en paralelo con el proceso actual
Compare las respuestas, acciones y escalaciones propuestas con la operación existente antes de permitir que el agente modifique registros activos. Investigue los desacuerdos en lugar de diluirlos en un promedio.
Ampliar por intención verificada
Lleve a producción los tipos de solicitud ya comprobados en grupos controlados. Mantenga una vía de reversión inmediata y exija pruebas de regresión antes de publicar cambios en políticas, herramientas o instrucciones.
El comprador también debe resolver la asignación de responsabilidades antes del lanzamiento. Alguien tiene que aprobar los cambios de políticas, revisar los incidentes, mantener las integraciones, hacerse cargo del conjunto de evaluación y decidir cuándo se amplía la autoridad del agente. Presence puede aportar tecnología y experiencia de despliegue. No puede eliminar la responsabilidad de la empresa sobre el flujo de trabajo.
La lectura estratégica
OpenAI Presence importa porque traslada la venta de agentes empresariales del acceso al modelo a la responsabilidad operativa. La promesa deja de ser «use nuestra inteligencia» y pasa a ser «permítanos ayudar a operar un flujo sujeto a controles y a mejorarlo después del lanzamiento».
Es una propuesta de producto más sólida que otro creador de agentes generalista. También genera una dependencia mayor del equipo de despliegue, los modelos, el proceso de mejora y el contrato de OpenAI. El intercambio tiene sentido cuando la velocidad gestionada y la experiencia operativa compartida valen más que controlar el sistema. Se convierte en una dependencia costosa cuando el flujo debería transformarse en una capacidad propia.
La pregunta decisiva de compra, por tanto, no es si Presence parece inteligente. Hay que preguntar quién responde por el resultado, quién controla cada acción, quién demuestra que una actualización es segura y quién sostiene el flujo cuando falla el agente. Si el contrato responde esas preguntas y el piloto demuestra la viabilidad económica, Presence puede acortar la parte más difícil de adoptar agentes empresariales. Si no lo hace, conviene desarrollar un sistema más acotado que la empresa pueda medir y controlar.
¿OpenAI Presence está disponible como producto de autoservicio?
No. OpenAI afirma que Presence está disponible para clientes empresariales elegibles mediante una disponibilidad general limitada. Los Forward Deployed Engineers y algunos integradores globales de sistemas dirigen los despliegues, y la página de lanzamiento remite a los compradores a su equipo de cuenta de OpenAI.
¿En qué se diferencia OpenAI Presence de ChatGPT Workspace Agents?
Workspace Agents son agentes compartidos creados dentro de ChatGPT para tareas repetibles, con aplicaciones, herramientas, Slack, programaciones y activadores por API. Presence es un despliegue gestionado en producción para flujos de voz y chat en tiempo real que utilizan sistemas de la empresa, ejecutan acciones sujetas a controles y escalan a personas.
¿OpenAI publica el precio de Presence?
Ni la página de lanzamiento del 22 de julio de 2026 ni la página actual del producto Frontier muestran un precio de lista público. Una cotización útil debe vincularse con un flujo de trabajo definido, su volumen, el alcance de la integración, el modelo de soporte y criterios de éxito medibles.
¿Una empresa debería contratar Presence o desarrollar su propio agente?
Conviene contratarlo cuando un flujo de voz o chat sujeto a muchas políticas necesita un despliegue gestionado y la empresa acepta a OpenAI como socio operativo con una participación profunda. Conviene desarrollar una solución propia cuando el agente diferencia el producto, el control de la arquitectura es estratégico, existen restricciones de despliegue inusuales o la portabilidad de modelos y la economía por unidad pesan más que la velocidad gestionada.
Si está decidiendo entre contratar un agente gestionado o controlar el sistema, delimite el flujo de trabajo y el riesgo antes de desarrollar.
3 sept 2026
Prefiera este sitio en Google
Marque omidsaffari.com como fuente preferida y Google lo destacará para usted en Top Stories, AI Overviews y AI Mode.
