Acceso al equipo local para Work Cloud y dots

Work y dots pueden usar los archivos y las herramientas permitidos en un equipo conectado mientras la nube de OpenAI coordina la tarea. Habilite el acceso al equipo local por separado para cada función.

Comience por las indicaciones compartidas sobre políticas, compatibilidad y auditoría que aparecen a continuación y, después, siga las instrucciones de configuración y de uso de Work o dots para la función que vaya a habilitar.

Esta guía ayuda a los propietarios de espacios de trabajo empresariales a revisar los requisitos de las políticas y habilitar el acceso al equipo local para Work y dots. La disponibilidad depende de su espacio de trabajo y del despliegue.

Consulte Agent Security para conocer la configuración base de Global, las anulaciones por entorno y las listas de campos del orquestador y del ejecutor.

Ventajas del acceso al equipo local

Habilitar el acceso al equipo local en estas funciones ayuda a los equipos a continuar el trabajo desde distintos dispositivos. Los administradores pueden gestionar de forma centralizada los requisitos compatibles en Agent Security para la ejecución en un equipo local. Estos requisitos de ejecución no se aplican cuando Work usa un contenedor en la nube o un dot usa un equipo en la nube. La ejecución en la nube utiliza controles independientes para el acceso al navegador, el acceso a la red y el uso del equipo.

Work

• Continúe una misma conversación de Work desde distintos dispositivos. Comience en un equipo y, después, revise los resultados o dé instrucciones de seguimiento desde la web o la aplicación móvil. Las tareas que usan el acceso al equipo local con Work Cloud utilizan coordinación en la nube.

• Use recursos aprobados en su equipo. Una tarea que utilice esta función puede usar los archivos y las herramientas locales permitidos a través de un equipo conectado mientras usted sigue su desarrollo desde otro dispositivo. Mantenga ese equipo en línea y conectado para los pasos que lo necesiten.

• Administre los requisitos de ejecución local de forma centralizada. Establezca los requisitos empresariales compatibles en Agent Security para la ejecución local. Revise las políticas de Work Cloud por separado para la ejecución en la nube.

Dots

• Realice trabajo de ingeniería localmente. Investigue errores, implemente cambios y ejecute compilaciones con los repositorios locales, las herramientas de desarrollo y las habilidades permitidos.

• Coordine el trabajo de programación. Cree hilos locales de Work o Codex y controle los hilos locales existentes de Codex.

• Use aplicaciones de escritorio y el navegador local para las tareas compatibles, incluidas las que requieren iniciar sesión localmente cuando el navegador en la nube no puede completarlas.

Antes y después de habilitar el acceso al equipo local con Work Cloud

Una tarea consta de dos partes: coordinación y ejecución. La coordinación decide qué pasos seguir y mantiene la conversación en marcha. La ejecución es el trabajo que realiza una herramienta, como ejecutar un comando de shell. Esta función traslada la coordinación a la nube de OpenAI. No traslada todas las herramientas ni todos los archivos fuera del equipo.

Cómo configurar el acceso al equipo local

Revise su política en Agent Security

Dónde revisarla

Abra Consola de administración → Agent Security. Esta sección sustituye a Políticas y configuración. Su despliegue es independiente del acceso al equipo local para Work y dots.

• Ajustes de políticas: Revise la configuración base de Global y las anulaciones de Local. Mantenga los controles del orquestador, incluidas las aprobaciones y la búsqueda web, en Global; los entornos no pueden anularlos. Use los controles específicos de la interfaz cuando estén disponibles, incluidas las Políticas de aprobación permitidas y los Modos de búsqueda web permitidos, y TOML para los demás campos compatibles. Consulte los controles del orquestador y del ejecutor para saber dónde se aplica cada ajuste.

• Requisitos y valores predeterminados: Los requisitos establecen límites que los usuarios no pueden anular. Los valores predeterminados proporcionan valores iniciales dentro de esos límites y no pueden anular un requisito.

• Acceso a funciones: Use Configuración del espacio de trabajo → Permisos y roles. El acceso al equipo local se habilita de forma independiente para Work y para dots.

Qué se conserva

Cuando se migran las políticas heredadas en la nube que cumplen los requisitos, sus ajustes se trasladan a Global y se conservan las asignaciones y el orden de las políticas. Revise las políticas migradas en Agent Security y use la tabla siguiente para comprobar su configuración actual. Si automatiza las actualizaciones de políticas, revise también la última fila. Consulte Agent Security para obtener indicaciones sobre la migración.

Qué política tiene prioridad

Estas reglas se aplican a distintos niveles. Cada flecha siguiente va de mayor a menor prioridad.

• Entre políticas: Una política de mayor prioridad prevalece sobre otra de menor prioridad, incluso si esta última es más específica.

• Dentro de una política: Para los ajustes de ejecución compatibles, anulación por entorno → Global. Un entorno sin anulación hereda el ajuste de Global aplicable.

• Requisitos locales: Requisitos de MDM de macOS → campos heredados de managed_config.toml interpretados como requisitos → requisitos administrados desde la nube de Agent Security → requirements.toml del sistema. La capa de MDM se aplica en macOS; los valores predeterminados siguen reglas de configuración independientes.

Algunos requisitos tienen reglas de combinación específicas para cada campo. Consulte Configuración administrada y la Referencia de configuración para conocer el ámbito de las políticas, los campos compatibles y el ámbito de ejecución.

Cómo se aplica la política a Work y dots

El comportamiento compartido de Work y dots con acceso local abarca los siguientes ámbitos:

• Coordinación de tareas: Cuando la política administrada está habilitada, el servicio en la nube que coordina la tarea aplica los requisitos compatibles de Global en Agent Security, como los requisitos de aprobación y los modos de búsqueda web permitidos.

• Ejecución local: Cuando una herramienta se ejecuta en un equipo conectado, aplica los requisitos compatibles de ejecución local de Agent Security y las políticas de dispositivo aplicables, incluidas las distribuidas mediante MDM cuando sean compatibles. Pueden incluir restricciones del sistema de archivos y de la red. Solo se aplican los campos compatibles con el ejecutor local; configurar un campo en MDM o en requirements.toml local no garantiza que se aplique localmente.

• Ejecución en la nube: Los contenedores en la nube de Work y los equipos en la nube de dots usan controles de ejecución independientes. Las restricciones locales del sistema de archivos y de la red no se aplican automáticamente a estos entornos en la nube.

Para configurar las capacidades compartidas en la nube, vaya a Consola de administración → Permisos y roles → Capacidades del espacio de trabajo → Capacidades del equipo en la nube. Estos permisos abarcan tanto Work Cloud como dots. Revise Uso del navegador en la nube y Acceso a la red en la nube por separado; configurar uno no configura el otro. Las políticas de Global y las anulaciones de Codex Cloud no configuran estos permisos.

Compruebe la compatibilidad y los requisitos de datos

Revise los requisitos de acceso, la cobertura de datos y los controles en los que se basa su organización antes de habilitar cualquiera de las funciones. Compartir infraestructura no significa que Work y dots tengan la misma compatibilidad.

Revise los requisitos de acceso de Work y dots

• Work: La residencia se aplica únicamente al contenido que cumple los requisitos y a las cargas de trabajo, regiones y configuraciones compatibles. EKM cubre el contenido almacenado compatible en los espacios de trabajo que cumplen los requisitos. Confirme la cobertura de su flujo de trabajo en lugar de asumir que todos los pasos de acceso local o las integraciones conectadas están cubiertos. Work no es compatible con la residencia de inferencia en los EAU. Consulte Residencia de datos y residencia de inferencia y Seguridad de Work en la nube.

• Residencia de dots: Durante la beta de Enterprise, dots no admite la residencia de datos ni la residencia de inferencia. Los espacios de trabajo que cumplen los requisitos pueden optar por participar tras aceptar estas limitaciones; habilitar dots no hace que sus datos ni su procesamiento cumplan los requisitos de residencia.

• Exclusiones de dots: Dots no está disponible para espacios de trabajo FedRAMP, espacios de trabajo con EKM ni espacios de trabajo con la residencia de inferencia establecida en AE (EAU). Los espacios de trabajo HIPAA pueden participar si cumplen los demás requisitos de acceso.

Compruebe el tratamiento de datos y la medida de protección del acceso local

• Procesamiento en la nube: Work con acceso local y dots siguen usando coordinación en la nube. Las conversaciones, los resultados de las herramientas y el resto del contexto de la tarea no permanecen exclusivamente en el equipo conectado.

• Medida de protección de la residencia: Si alguna política en la nube habilita enforce_residency, Permitir acceso al equipo local deja de estar disponible tanto para Work como para dots. Esta medida no establece la residencia del espacio de trabajo ni, por sí sola, deshabilita Work Cloud o dots. Los espacios de trabajo que cumplen los requisitos pueden seguir optando por dots tras aceptar las limitaciones de residencia de la beta; el acceso local sigue bloqueado.

• Retención y acceso a los datos: Ninguna de las dos experiencias ofrece una retención de datos estrictamente nula. Zero Data Retention de la API es un control independiente de la API. Los compromisos de ausencia de revisión humana («Eyes-off») y los controles de supervisión de abusos también son distintos de la retención nula. Si un flujo de trabajo exige que no se conserve ningún dato, no lo habilite para estas experiencias.

Revise la cobertura de retención, eliminación y auditoría de los datos y las herramientas que realmente se utilizarán antes del despliegue. En Work, las conversaciones, el estado de ejecución alojado, los archivos y los datos de las aplicaciones conectadas pueden seguir ciclos de vida diferentes; eliminar una conversación no elimina todas las copias relacionadas.

Compruebe la compatibilidad de los hooks y la red

• Hooks empresariales compatibles: Cuando la política administrada y los hooks remotos están habilitados, Work Cloud con acceso local y dots usan hooks MCP remotos administrados por el administrador. El orquestador en la nube llama a su servicio MCP conectado en los eventos compatibles de tareas y herramientas. Configure los controladores mcp_tool en requirements.toml de Global. Work Cloud sin acceso local no usa estos hooks; estos hooks empresariales no están disponibles para cuentas personales.

• Work Cloud y dots con acceso local: Los controladores de comandos/shell, prompts y agentes; los hooks de la configuración local, de plugins o de directorios locales; los hooks con ámbito de entorno; y los hooks MCP SessionEnd no son compatibles con la orquestación en la nube, incluso cuando la tarea ejecuta herramientas en su equipo. Si su flujo de trabajo depende de uno de estos hooks, siga usando un flujo de trabajo exclusivamente local que lo admita hasta haber revisado una alternativa.

• Hilos exclusivamente locales en Work y Codex: Cuando tanto la orquestación como la ejecución son locales, los hooks compatibles existentes siguen funcionando. Los administradores pueden seguir configurando hooks administrados compatibles en Agent Security para este flujo de trabajo.

• Fallos y cobertura de auditoría: Pruebe la conectividad de las llamadas de retorno, los eventos necesarios y el comportamiento ante fallos. Una denegación explícita compatible puede bloquear una acción, pero un error, un tiempo de espera agotado o una respuesta mal formada en una llamada de retorno PreToolUse puede hacer que el hook falle sin bloquear la herramienta. Los hooks no proporcionan un registro de auditoría completo de la API de cumplimiento ni cubren todas las rutas internas de subagentes.

• Controles de red y aplicaciones: Verifique el campo, la vía de distribución y el entorno de ejecución en la Referencia de configuración. Los controles aplicados por aplicaciones o dispositivos pueden seguir vigentes cuando el orquestador en la nube no utiliza un ajuste. El entorno de ejecución en la nube no admite puertos de escucha HTTP/SOCKS administrados ni escuchas de proxy fuera de la interfaz de bucle local; la compatibilidad con las reglas de sockets depende de la ruta de ejecución. Revise la Precedencia de las políticas de red y los límites del entorno de ejecución y, después, pruebe las acciones permitidas y bloqueadas y la conectividad necesaria.

Si tiene preguntas sobre los archivos locales, la ejecución en la nube o la precedencia de las políticas, consulte las Preguntas frecuentes para administradores de Work, Seguridad local de Work y Seguridad de Work en la nube.

Habilite el acceso al equipo local

Conceda el acceso al equipo local por separado para Work y dots. Use los valores predeterminados del espacio de trabajo y los roles personalizados compatibles para conceder acceso a los usuarios o grupos previstos.

Antes del despliegue, revise las políticas y los requisitos de compatibilidad anteriores. Se recomienda revisar o crear políticas en Agent Security, pero el flujo de confirmación no exige crear políticas antes de habilitar el acceso. La migración de políticas no concede acceso al equipo local.

Work

1. Como propietario del espacio de trabajo, abra Configuración del espacio de trabajo > Permisos y roles.

2. Habilite Work Cloud para los usuarios previstos. Usar Codex localmente en la aplicación de escritorio de ChatGPT no es un requisito previo para esta función.

3. En Work Cloud, active Permitir acceso al equipo local. Revise el cuadro de diálogo de confirmación y, después, abra Agent Security para revisar o establecer políticas, o confirme para activar el acceso.

4. Pida a los usuarios que actualicen la aplicación de escritorio de ChatGPT a la versión 26.929 o posterior. La actualización es necesaria para que el acceso al equipo local con Work Cloud entre en vigor.

5. Pida a un miembro con los permisos previstos que seleccione Nube en el cuadro de redacción de la aplicación de escritorio e inicie una tarea nueva. Continúe la tarea desde otro dispositivo compatible y verifique el acceso a un archivo o una herramienta local aprobados mientras el equipo está conectado.

Dots

1. Como propietario del espacio de trabajo, abra Configuración del espacio de trabajo > Permisos y roles y habilite dots para los usuarios previstos, de acuerdo con los requisitos de acceso anteriores.

2. En Usar Dots, active Permitir acceso al equipo local. Revise el cuadro de diálogo de confirmación y, después, abra Agent Security para revisar o establecer políticas, o confirme para activar el acceso.

3. Pida a los usuarios que actualicen la aplicación de escritorio de ChatGPT a la versión 26.929 o posterior. La actualización es necesaria para que el acceso al equipo local entre en vigor.

4. Pida a los usuarios que abran los detalles de su dot en la aplicación de escritorio de ChatGPT y elijan Equipos. Busque Su equipo (o el nombre del equipo), seleccione Permitir y confirme con Permitir acceso.

5. Pida a un miembro con los permisos previstos y un equipo conectado que pruebe una tarea local con su dot.

Revise OpenTelemetry y la cobertura de auditoría

Para Work con acceso local y dots, distinga la telemetría de ejecución local de los registros de auditoría en la nube al revisar la cobertura de OpenTelemetry (OTel). Su ejecutor local puede seguir exportando los eventos de ejecución compatibles. Los eventos de orquestación en la nube no llegan a su recolector de OpenTelemetry existente.

Use la API de cumplimiento para los registros compatibles de la nube. Cambiar el endpoint del recolector no restablece los eventos de orquestación en la nube. Los registros de la API de cumplimiento no sustituyen todos los eventos del flujo anterior de OpenTelemetry.

Para dots, use la API de análisis para el uso y la API de cumplimiento para los registros de auditoría compatibles. Valide los registros que necesita su flujo de trabajo junto con la entrega al recolector local; los hooks MCP no sustituyen la cobertura de auditoría.

Consulte Seguridad de Work en la nube para conocer la cobertura de auditoría en la nube.

Experiencia del usuario final

Tanto para Work como para dots, los pasos locales requieren que el equipo correspondiente esté en línea y conectado, con la aplicación de escritorio de ChatGPT en ejecución y la sesión iniciada en la cuenta y el espacio de trabajo adecuados.

Work

• Tareas que cumplen los requisitos. Las nuevas tareas que cumplen los requisitos, iniciadas en la aplicación de escritorio de ChatGPT con Nube seleccionado, pueden usar el ejecutor local de ese equipo mientras esté conectado y el acceso local esté habilitado.

• Inicio de sesión. Use Iniciar sesión con ChatGPT en el espacio de trabajo previsto. Las API keys y los tokens de acceso de Codex no habilitan el acceso al equipo local con Work Cloud.

• Equipo no disponible. Si el equipo no está disponible cuando comienza un nuevo turno, una tarea existente que cumpla los requisitos puede continuar en un contenedor en la nube sin los archivos ni las herramientas locales de ese equipo. El contenedor no aplica los requisitos empresariales de la ejecución local. Una tarea no puede pasar de la ejecución local a la nube durante un turno.

• Acceso desactivado. Desactivar el acceso al equipo local con Work Cloud interrumpe los turnos que se están ejecutando. Los usuarios pueden iniciar un nuevo turno en una conversación existente en la nube; este usa Work Cloud sin acceso a los archivos locales.

• Chats y proyectos existentes. Las tareas creadas antes de habilitar esta función mantienen su modo original: exclusivamente local o en la nube sin acceso a archivos locales. Inicie una tarea nueva después de habilitar la función para usar el acceso al equipo local con Work Cloud.

• Ajuste Local/Nube. Para las empresas, el selector Local/Nube de la aplicación y su valor predeterminado no cambian en el lanzamiento. Las tareas que cumplen los requisitos con Nube seleccionado usan coordinación en la nube y el equipo conectado para los pasos locales.

Dots

• Conectar un equipo. Abra los detalles del dot en la aplicación de escritorio de ChatGPT y elija Equipos. Busque Su equipo (o el nombre del equipo), seleccione Permitir y confirme con Permitir acceso. El equipo queda disponible para las tareas locales compatibles.

• Equipo sin conexión. La autorización de acceso guardada se mantiene, pero el trabajo que necesita ese equipo no puede continuar mientras no esté disponible. Sin conexión no significa que se haya revocado el acceso.

• Eliminar el acceso. Elija Revocar acceso y confirme para eliminar la autorización del dot para ese equipo. Desconectado significa que se ha eliminado el acceso; es distinto de Sin conexión.

• Cambios de acceso del administrador. Si un administrador deshabilita el acceso al equipo local para dots, es posible que una tarea local ya autorizada aún esté terminando. No asuma que el comportamiento de Work de interrumpir inmediatamente los turnos en ejecución se aplica a dots.

• Tareas en ejecución. Una tarea local en ejecución no migra automáticamente a la nube. Los cambios de conexión pueden interrumpir el trabajo o recargar el entorno de ejecución. El dot puede continuar el trabajo posterior en su equipo en la nube, pero una tarea secundaria local que ya no tenga acceso no puede reanudarse en ese equipo ni se traslada automáticamente a la nube.