La plataforma de agentes empresariales de OpenAI: lo que RevOps debe entender antes de que su equipo de Data Science empiece a construir

Su equipo de Data Science probablemente ya está entusiasmado. Posiblemente ya esté haciendo prototipos. Y si su empresa tiene una iniciativa de IA con cierto impulso, alguien casi con certeza ha mencionado construir agentes internos sobre la infraestructura de OpenAI.

Ese no es un mal instinto. Pero sí crea un problema de RevOps del que nadie está hablando todavía.

En febrero de 2026, TechCrunch informó que OpenAI lanzó "Frontier", una plataforma empresarial diseñada para empresas que quieren construir y gestionar sus propios agentes de IA usando los modelos subyacentes de OpenAI como motor. Como describió TechCrunch, la plataforma está construida alrededor de tratar a los agentes "como empleados humanos", con herramientas de gestión, supervisión y despliegue incluidas. Esto no es un nuevo modelo GPT. Es una capa de infraestructura que se asienta sobre los modelos, y está dirigida directamente a organizaciones que quieren dejar de comprar herramientas de IA prediseñadas y empezar a construir las suyas propias.

Esa distinción, plataforma versus modelo, es lo primero que RevOps necesita entender bien, porque cambia quién posee qué.

Plataforma vs. modelo: por qué RevOps debe preocuparse por la diferencia

Cuando su empresa compra acceso a un modelo de IA (GPT-4, Claude, Gemini), el modelo hace el razonamiento. Sus datos están en sus sistemas, y el modelo procesa las entradas que le da. El límite de seguridad es relativamente claro.

Una plataforma de agentes es diferente. Los agentes están diseñados para actuar: leer datos, tomar decisiones, realizar acciones y escribir los resultados en algún lugar. Se conectan a sistemas. Se autentican. Son persistentes. Y, fundamentalmente, los datos que necesitan para funcionar (estado del pipeline, registros de contactos, historial de negocios, señales de previsión) viven en el CRM que RevOps posee y es responsable.

Esto no es teórico. Cualquier agente orientado a los ingresos que valga la pena construir necesitará lecturas del CRM como línea base y probablemente escrituras del CRM para ser útil. Piense en lo que eso significa: un agente construido a medida sobre la plataforma Frontier de OpenAI, autorizado por alguien en su equipo de Data Science, podría estar actualizando etapas de oportunidades, escribiendo notas en registros de contactos o modificando categorías de previsión. Y RevOps puede que ni siquiera sepa que está ejecutándose.

Esa es la brecha de gobierno que necesita cerrar antes de que salga el primer agente.

La lista de verificación de preparación de datos de RevOps

Antes de que su organización construya cualquier cosa sobre una plataforma de agentes empresariales, ya sea Frontier de OpenAI, la infraestructura de agentes abierta de NVIDIA u otra, su casa de datos necesita estar en orden. Esto es lo que realmente importa:

1. La documentación del esquema está actualizada y es accesible. Los agentes consumen campos. Si su esquema de CRM tiene 14 variaciones de "etapa de negocio" porque cuatro equipos de ventas diferentes nombraron las cosas de forma diferente a lo largo de los últimos tres años, un agente replicará ese desorden a escala. Antes de conceder acceso programático a cualquier sistema, documente sus campos canónicos y aplíquelos.

2. Se han establecido líneas base de calidad de datos. Si su tasa de ganancia por segmento nunca ha sido confiable porque los representantes no actualizan las fechas de cierre de oportunidades, un agente entrenado para pronosticar sobre ese campo producirá malas predicciones con voz segura. Conozca el suelo de calidad de sus datos antes de que cualquier sistema empiece a consumirlos como verdad.

3. La autenticación de integración está revisada. ¿Quién tiene acceso API a su CRM actualmente? ¿Cuándo se auditó por última vez esa lista? Las plataformas de agentes añaden una nueva categoría de identidad del sistema, el propio agente, no solo el humano que lo configuró. Su modelo de autenticación de integración necesita tener esto en cuenta.

4. El acceso de escritura está explícitamente delimitado. Hay una diferencia significativa entre un agente que lee datos de pipeline y uno que los modifica. Los agentes de solo lectura son de menor riesgo. Los agentes con acceso de escritura a registros de contactos, etapas de negocio o campos personalizados necesitan aprobación explícita, alcance documentado y protocolos de reversión.

5. Sus políticas de retención de datos y privacidad cubren los sistemas automatizados. Si su empresa opera en Europa, los sistemas de IA que procesan datos personales de registros de contactos pueden activar obligaciones bajo el GDPR y la Ley de IA de la UE. Compruébelo antes de lanzar.

Las preguntas de gobierno que su organización necesita responder

La preparación de datos es el mínimo necesario. La conversación más difícil es el gobierno: quién tiene autoridad para aprobar qué, y qué ocurre cuando algo sale mal.

Estas son las preguntas que RevOps debe plantear antes de que cualquier agente entre en producción:

¿Quién aprueba el acceso de los agentes a las escrituras del CRM? Esto no debería ser una decisión solo de Data Science. Cualquier agente que modifique registros del CRM está, funcionalmente, modificando su pipeline. Eso es una decisión de RevOps y liderazgo de ventas. Establezca una ruta de aprobación ahora, no después del primer incidente.

¿Cuál es el rastro de auditoría? Si un agente actualiza 200 etapas de oportunidad el martes por la noche, ¿puede saber qué cambió, por qué, y revertirlo? La mayoría de los CRM tienen registros de auditoría a nivel de campo, pero no siempre están habilitados por defecto. Actívelos y pruebe el proceso de reversión antes de que ocurran escrituras automatizadas.

¿Cómo maneja los errores de los agentes? Los representantes humanos cometen errores en el CRM y ha construido procesos para detectarlos y corregirlos. Los errores de los agentes son diferentes: tienden a ser sistemáticos en lugar de aleatorios. Una regla mal configurada puede corromper muchos registros rápidamente. Su protocolo de manejo de errores para sistemas automatizados debería ser más estricto que para los humanos, no más permisivo.

¿Cuál es la ruta de escalada cuando un agente toma una acción que nadie pretendía? Esto ocurrirá. Siempre ocurre cuando la automatización toca sistemas en vivo. Defina la ruta de escalada, el responsable del incidente y el protocolo de comunicación antes de que ocurra.

¿Quién posee el mantenimiento continuo de la lógica del agente? Los agentes construidos hoy interactuarán con esquemas del CRM que cambian, pipelines que evolucionan y reglas de negocio que se actualizan. Alguien necesita ser propietario de la lógica y revisarla cuando las cosas cambien. "El equipo de Data Science lo construyó" no es una respuesta sostenible.

La pregunta de comprar vs. construir detrás de todo esto

Vale la pena dar un paso atrás y nombrar la decisión que el lanzamiento de Frontier realmente impone: su organización ahora tiene una elección real entre comprar agentes de IA (Salesforce Agentforce, HubSpot Breeze) y construirlos sobre infraestructura como la plataforma de OpenAI o el kit de herramientas de código abierto de NVIDIA.

El camino de comprar es de menor riesgo para empezar. Agentforce y Breeze ya están integrados con sus respectivos CRM. Las herramientas de gobierno existen. El proveedor se encarga del mantenimiento. Pero está restringido a lo que han construido.

El camino de construir ofrece más flexibilidad y potencialmente un mejor ajuste a sus flujos de trabajo específicos. Pero pone la carga de preparación de datos, el diseño del gobierno y el mantenimiento continuo directamente en su equipo.

Para la mayoría de las organizaciones de RevOps, la respuesta correcta ahora no es "construir todo desde cero". Es "entender la plataforma lo suficientemente bien como para gobernar lo que se construye sobre ella". Eso significa estar en la sala cuando Data Science está haciendo prototipos, no enterarse del agente después de que lleva seis semanas hablando con su CRM.

Si está pensando en su marco de gobierno del CRM de forma más amplia, esta decisión encaja en el mismo conjunto de preguntas que ya debería estar haciéndose sobre cualquier sistema con acceso al pipeline.

Qué hacer esta semana

Probablemente no puede detener a su equipo de Data Science de experimentar, y no debería querer hacerlo. Pero puede asegurarse de que esa experimentación ocurra dentro de una estructura que proteja la integridad de su pipeline.

Esta semana:

  • Pregunte directamente a su equipo de TI o Data Science: ¿está alguien actualmente haciendo prototipos o delimitando agentes contra nuestro CRM? Puede sorprenderle la respuesta.
  • Extraiga el registro de acceso API de su CRM e identifique cualquier integración o usuario del sistema que no reconozca. Cierre cualquier cosa que ya no esté activa.
  • Programe 30 minutos con quien lidera la administración de su CRM para redactar una política de una página: ¿qué necesita pasar un agente para obtener acceso de escritura a los datos del CRM de producción? Incluso un primer borrador aproximado es más de lo que tiene la mayoría de las organizaciones ahora mismo.
  • Identifique un único flujo de trabajo de bajo riesgo, quizás registrar actividades completadas o actualizar un campo personalizado basado en el engagement de correo, donde estaría dispuesto a hacer un piloto de un agente simple en un entorno controlado. Tener un caso de prueba real le da a su proceso de gobierno algo concreto con lo que trabajar.

La plataforma ya está ahí. Su equipo de Data Science ya tiene curiosidad al respecto. El rol de RevOps aquí no es ralentizar las cosas: es asegurarse de que cuando los agentes empiecen a ejecutarse en su infraestructura de ingresos, lo estén haciendo dentro de unas barreras de protección que usted diseñó.

Fuente: TechCrunch, 5 de febrero de 2026