Guía de implementación para administradores

Usa esta guía para planificar una implementación de ChatGPT Enterprise en los siguientes ámbitos de administración:

• Acceso al espacio de trabajo.
• Política de ejecución local para las capacidades incluidas en la aplicación de escritorio de ChatGPT, Codex CLI y la extensión de IDE.
• Codex cloud.
• Acceso a Platform API.
• Acceso a plugins y conectores.
• Permisos en los sistemas conectados.

Completa los pasos en orden para una implementación nueva o usa las páginas enlazadas para cambiar un ámbito.

Si administras una puerta de enlace de modelos para clientes locales de Codex, consulta Desplegar Codex a través de una puerta de enlace para la validación de la puerta de enlace, la distribución de credenciales y la entrega al cliente. Configura el acceso al espacio de trabajo por separado cuando tu despliegue utilice funciones del espacio de trabajo.

En la configuración del espacio de trabajo, Codex y Work Local combina el acceso local a Codex y Work en Permitir que los miembros usen Codex y Work localmente. Algunos espacios de trabajo ofrecen en su lugar secciones independientes de Codex Local y Work Local. En ese diseño, Permitir que los miembros usen Codex localmente controla Codex y Usar Work localmente controla Work. Activar una de ellas no activa la otra. Estas etiquetas identifican permisos del espacio de trabajo, no productos ni clientes distintos. Los permisos de los tokens y los límites de duración de las credenciales aparecen en una sección Tokens de acceso o en la sección de acceso local, según el espacio de trabajo. La configuración administrada es una capa de políticas independiente que puede restringir el comportamiento compatible del entorno de ejecución para las funciones incluidas en esos clientes. Esta guía indica la interfaz específica cuando el comportamiento o la disponibilidad difieren.

Para obtener una descripción general de los controles de acceso, consulta Roles y permisos del espacio de trabajo. Usa las guías del Centro de ayuda para conocer los procedimientos actuales del espacio de trabajo de ChatGPT y la documentación para desarrolladores enlazada para conocer el comportamiento de los entornos de ejecución locales y alojados.

Para obtener información sobre seguridad empresarial, privacidad y protecciones de ejecución, consulta Aprobaciones y seguridad de agentes y el documento técnico de seguridad de Codex.

Paso 1: Asigna responsables y elige una estrategia de implementación

Asigna un responsable a cada parte de la implementación:

• Acceso al espacio de trabajo: Membresía, puestos, roles y funciones compatibles del espacio de trabajo.
• Política de ejecución local: Aprobaciones, perfiles de permisos, acceso al sistema de archivos y a la red, y otros requisitos para los clientes locales compatibles.
• Codex cloud: Entornos alojados, conexiones con repositorios y política de ejecución en la nube.
• Sistemas conectados: Instalación de aplicaciones, cuentas y permisos del lado del proveedor.
• Informes y cumplimiento: Acceso a análisis, exportaciones de auditoría y tratamiento posterior de datos.

Decide si cada audiencia necesita las capacidades locales incluidas en la aplicación de escritorio ChatGPT, Codex CLI, la extensión de IDE, Codex cloud o una combinación. Trata el acceso a Platform API como un ámbito independiente de organización y proyecto cuando un flujo de trabajo use autenticación mediante API key.

Paso 2: Configura el acceso y la identidad del espacio de trabajo

Usa la membresía, los puestos, los grupos y los permisos RBAC compatibles del espacio de trabajo de ChatGPT para conceder a las audiencias previstas las funciones compatibles del espacio de trabajo. Verifica el acceso al cliente local y a Codex cloud según las indicaciones actuales del espacio de trabajo, en lugar de suponer que el mismo rol controla todas las superficies. Limita los roles de administración integrados a las personas que administran el espacio de trabajo.

Los controles y las etiquetas del espacio de trabajo cambian con el tiempo. Usa estas fuentes para consultar los procedimientos actuales:

• Gestionar miembros, tipos de puestos, roles y acceso
• Configurar el control de acceso basado en roles
• Gestionar la configuración del espacio de trabajo
• Grupos y aprovisionamiento
• Gestión del ciclo de vida de los usuarios
• Autenticación

Prueba el inicio de sesión y el acceso a las funciones con un miembro que tenga los permisos previstos. El acceso al espacio de trabajo no otorga acceso a repositorios, archivos ni acciones en un servicio conectado.

Configurar el acceso al equipo local con Work Cloud

Si tu despliegue incluye acceso al equipo local para Work o dots, revisa las políticas en Agent Security antes del despliegue. La migración de políticas y el acceso a las funciones son cambios independientes; el flujo de confirmación no exige crear políticas para habilitar el acceso. La política compatible de Global rige la orquestación en la nube cuando la política administrada está habilitada. Los requisitos de ejecución local y los controles de dispositivos rigen el equipo conectado. Los contenedores en la nube de Work y los equipos en la nube de dots usan su propia configuración y sus propios requisitos de ejecución. Sigue la guía Acceso al equipo local para Work Cloud y dots para conocer los requisitos de configuración y elegibilidad de cada uno.

Usa la API de políticas para administrar los ajustes de Global. Para administrar los ajustes de Local o Codex Cloud, usa la interfaz de Agent Security. Los flujos de trabajo existentes de la API de Global siguen disponibles después de la migración. Prueba tus scripts e integraciones de Terraform y confirma que las asignaciones y el orden de las políticas no hayan cambiado.

Comprueba la compatibilidad antes de habilitar la sincronización:

Política de red. Cuando estén disponibles las anulaciones por entorno, prueba las excepciones de experimental_network documentadas en Configuración administrada. Una restricción global puede seguir vigente aunque el entorno permita el acceso.

• Hooks empresariales. Cuando está habilitado para tu espacio de trabajo, el acceso al equipo local con Work Cloud admite hooks de MCP definidos por administradores que se ejecutan en el coordinador en la nube (orquestador) para los eventos de ciclo de vida y de herramientas compatibles. Los hooks de comandos y los hooks de la configuración local o de plugins no son compatibles con la orquestación en la nube, incluso cuando las herramientas se ejecutan localmente.

• Hooks no compatibles. Los hooks de comandos y los hooks de la configuración local o de plugins no son compatibles con la orquestación en la nube, incluso cuando las herramientas se ejecutan localmente. Cuando tanto la orquestación como la ejecución son locales, los hooks compatibles existentes siguen funcionando en los hilos exclusivamente locales de Work y Codex. Los administradores pueden seguir configurando hooks administrados compatibles en Agent Security para esos flujos de trabajo.

• Auditoría. Antes de depender de estos hooks, prueba la conexión de callback, confirma los eventos que recibe y comprueba cómo afectan los fallos a la tarea. Los hooks de MCP no proporcionan un registro de auditoría completo de Compliance API.

• Requisitos de datos. El acceso al equipo local con Work Cloud no ofrece una retención de datos estrictamente nula. La residencia de datos y la residencia de inferencia abarcan únicamente el contenido que cumple los requisitos y las cargas de trabajo, regiones y configuraciones compatibles. Enterprise Key Management (EKM) abarca el contenido almacenado compatible en los espacios de trabajo que cumplen los requisitos. Work no es compatible con la residencia de inferencia en los Emiratos Árabes Unidos. Si enforce_residency está habilitado en alguna política de la nube, Permitir el acceso al equipo local se deshabilita tanto para Work como para dots. Esta medida de protección no configura la residencia del espacio de trabajo ni deshabilita, por sí sola, Work Cloud o dots. Si tu organización requiere ZDR, no habilites esta función.

Como propietario del espacio de trabajo, revisa los permisos de Work para los usuarios o grupos previstos. Habilita Work Cloud y, a continuación, activa Permitir el acceso al equipo local. Usa las asignaciones de roles compatibles para conceder acceso. Consulta Roles y permisos del espacio de trabajo.

Paso 3: Configura los requisitos de ejecución local

Los requisitos locales restringen el comportamiento de ejecución cuando un usuario inicia una ejecución local compatible en la aplicación de escritorio de ChatGPT, Codex CLI o la extensión de IDE. Distribuye requirements.toml mediante un canal compatible de nube, dispositivo o sistema. Mantén esta política separada de los roles y grupos del espacio de trabajo de ChatGPT.

Usa perfiles de permisos para los clientes locales compatibles en lugar de crear nuevas implementaciones basadas en restricciones heredadas del modo sandbox. Por ejemplo:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Para deshabilitar Computer Use en las superficies compatibles de las funciones del navegador y del escritorio, restringe cada clave pública de función que participe en la experiencia:

[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false

Para consultar la lista oficial de claves, el comportamiento de distribución, la precedencia y más ejemplos, consulta Configuración administrada y la referencia de requirements.toml.

Paso 4: Estandariza la configuración del repositorio

Usa una configuración limitada al repositorio para compartir valores predeterminados, reglas y habilidades del proyecto sin duplicar la configuración para cada usuario. Incorpora la configuración en .codex o .agents según la ubicación documentada de la función:

La configuración del repositorio puede proporcionar valores predeterminados y flujos de trabajo reutilizables. No puede conceder acceso al espacio de trabajo, a modelos, a Platform API ni a sistemas conectados.

Paso 5: Configura Codex cloud

Codex cloud usa entornos alojados y repositorios de código fuente conectados.

Codex Cloud está desactivado de forma predeterminada en los espacios de trabajo Enterprise. Los ajustes existentes de Usar Codex en la nube se conservan desde Codex Cloud (Legacy): los espacios de trabajo que ya habilitaron Cloud conservan el acceso, y aquellos con Cloud deshabilitado siguen así hasta que un administrador lo habilite. El acceso sigue sujeto al despliegue y a las restricciones del espacio de trabajo correspondientes.

Planifica cada límite:

1. Concede a los usuarios previstos el permiso Usar Codex en la nube. Por separado, concede Administrar entornos del espacio de trabajo a las personas que crean y editan entornos compartidos del espacio de trabajo. Consulta la guía de roles del espacio de trabajo.
2. Instala y configura la integración compatible del sistema de código fuente.
3. Limita el acceso a repositorios en el sistema de código fuente a los repositorios que cada grupo de usuarios necesita.
4. Configura los entornos en la nube, los secretos, el acceso a Internet y los requisitos compatibles administrados en la nube para esos repositorios.
5. Configura flujos de trabajo alojados opcionales, como la revisión de código.
6. Prueba el acceso a las tareas con un miembro representativo y la administración de entornos con el administrador designado. Verifica los permisos de cada persona sobre el espacio de trabajo, los entornos y los repositorios.

Los entornos en la nube no heredan la política del dispositivo local, los ajustes de MDM ni el acceso a la red local. Revisa los requisitos compatibles administrados en la nube por separado de los requisitos instalados en el equipo de un usuario. Consulta Conectarse a servicios para obtener información sobre el acceso a destinos y Agent Security para saber cómo los requisitos del espacio de trabajo restringen los entornos en la nube.

Codex cloud respeta los permisos y las protecciones de los repositorios que expone el sistema de código fuente conectado. El acceso al espacio de trabajo no elude esos controles. Consulta Entornos en la nube para obtener orientación sobre la configuración y la ejecución.

Paso 6: Configura los plugins y las capacidades conectadas

Evalúa por separado la instalación de plugins, las habilidades incluidas, las capacidades respaldadas por conectores, las acciones de conectores y la autorización del sistema de origen. Deshabilitar una capacidad respaldada por un conector no necesariamente desinstala el plugin ni sus habilidades incluidas.

Antes de incluir un plugin o una habilidad en la implementación:

1. Confirma su origen, el responsable a cargo, la audiencia prevista y la fecha de revisión.
2. Revisa las habilidades incluidas, los conectores, los MCP servers, los hooks, y los datos y las acciones que requiere cada capacidad.
3. Pruébala con datos no sensibles y con el mínimo acceso que necesite.
4. Registra quién es responsable de la nueva revisión y la retirada.

Los plugins funcionan en Chat y Work en ChatGPT para la web, el escritorio y los dispositivos móviles, en Codex dentro de la aplicación de escritorio de ChatGPT y mediante el explorador de plugins de Codex CLI. No están disponibles en la extensión del IDE. ChatGPT y Codex comparten un único directorio público universal de plugins; los controles del espacio de trabajo determinan a cuáles de esos plugins pueden acceder los miembros.

Consulta Controles de plugins y Controles de habilidades para conocer el modelo completo.

Paso 7: Establece la gobernanza y la observabilidad

Elige la superficie de informes que corresponda a la pregunta:

• Usa Análisis del espacio de trabajo para consultar análisis interactivos del espacio de trabajo de ChatGPT y análisis de Codex.
• Usa la Analytics API para generar informes agregados mediante programación a través de Codex Analytics API.
• Usa la Compliance API para obtener registros de auditoría e investigación.
• Usa Límites de uso y controles de gasto de ChatGPT cuando la actividad de Codex dependiente del plan consuma créditos aptos del espacio de trabajo de ChatGPT.

Al crear una integración, usa las referencias de la API que requieren autenticación para consultar los requisitos de acceso, esquemas, campos, retención y comportamiento de las solicitudes vigentes.

Protege el ámbito de la integración:

• Almacena las API keys y otras credenciales de integración en el sistema de gestión de secretos de la organización.
• Limita el acceso a los sistemas posteriores y a los datos conservados a la audiencia aprobada.
• Protege los registros exportados de Compliance API de acuerdo con su sensibilidad y la política de retención de la organización, y prueba los flujos de trabajo de recopilación y eliminación con el contrato actual.

Paso 8: Verifica y mantén la implementación

Después de habilitar el acceso al equipo local con Work Cloud, crea una tarea nueva y continúa la conversación desde otro dispositivo compatible. Las tareas existentes no se migran y conservan su comportamiento original exclusivamente local o exclusivamente en la nube. Mantén el equipo en línea para los pasos que necesiten sus archivos o herramientas. Prueba una acción que la política deba permitir y otra que deba bloquear, y comprueba las aprobaciones y las restricciones del sistema de archivos y de red aplicables por separado para la ejecución local y en la nube. Prueba también a iniciar un turno nuevo mientras el equipo local no esté disponible. Una tarea que cumpla los requisitos puede continuar en un contenedor en la nube sin acceso a los archivos o las herramientas locales de ese equipo. Una tarea no puede pasar de la ejecución local a la nube durante un turno.

Registra los ajustes efectivos y el resultado de cada prueba. Si una restricción no funciona como se espera, resuelve el problema antes de que los usuarios dependan de ella. Sigue el comportamiento documentado para deshabilitar la sincronización. Trata la revocación del acceso, la interrupción de tareas y la retención de datos como acciones independientes.

Verifica cada ámbito aplicable con identidades representativas:

• Membresía, puesto y permisos de roles compatibles del espacio de trabajo de ChatGPT.
• Capacidades locales incluidas en la aplicación de escritorio de ChatGPT, Codex CLI y la extensión de IDE, incluidos el inicio de sesión y los requisitos de ejecución efectivos.
• Acceso a Codex cloud, configuración del entorno y permisos de repositorios.
• Acceso a la organización y al proyecto de Platform API para flujos de trabajo con API key.
• Instalación de plugins, habilidades incluidas, acceso a conectores y acciones compatibles.
• Autorización y acceso a datos en sistemas conectados.
• Acceso a análisis y cumplimiento para los administradores responsables.

Registra el responsable y la fuente actual del procedimiento para cada control. Este registro permite a los administradores actualizar los procedimientos cuando cambien la interfaz de usuario o las políticas sin cambiar el modelo de administración.

Tras la implementación inicial, revisa el acceso, las capacidades conectadas, el uso de créditos, los comentarios de soporte y los flujos de trabajo que realmente usan los equipos. Ajusta el alcance de la implementación y las indicaciones para administradores cuando cambien esas señales.

Si necesitas desactivar el acceso al equipo local con Work Cloud

Desactivar el acceso al equipo local con Work Cloud interrumpe los turnos que se estén ejecutando. Los usuarios pueden iniciar un turno nuevo en una conversación existente en la nube. Ese turno usa automáticamente Work Cloud sin acceso a los archivos locales. Indica a los usuarios que inicien un turno nuevo después de la interrupción y explica que los archivos locales dejarán de estar disponibles para el hilo en la nube.