Acceso a la computadora local para Work en la nube y los dots

El modo Work y los dots pueden usar los archivos y las herramientas permitidos en una computadora conectada mientras la nube de OpenAI coordina la tarea. Habilita el acceso a la computadora local por separado para cada función.

Primero, revisa las indicaciones sobre políticas, compatibilidad y auditoría que comparten ambas funciones. Luego, sigue las instrucciones de configuración y uso de Work o de los dots según la función que quieras 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 a la computadora local para Work y los dots. La disponibilidad depende de tu espacio de trabajo y de la etapa de implementación.

Consulta Seguridad de agentes para conocer la configuración base de Global, los ajustes que pueden prevalecer en cada entorno y las listas de campos del orquestador y del ejecutor.

Ventajas del acceso a la computadora local

Al habilitar el acceso a la computadora local en estas funciones, los equipos pueden continuar su trabajo desde distintos dispositivos. Los administradores pueden gestionar de forma centralizada en Seguridad de agentes los requisitos compatibles con la ejecución en una computadora local. Estos requisitos de ejecución no se aplican cuando Work usa un contenedor en la nube o un dot usa una computadora en la nube. La ejecución en la nube tiene controles independientes para el acceso al navegador, el acceso a la red y el uso de la computadora.

Work

Los miembros pueden continuar sus tareas de Work desde distintos dispositivos y usar recursos locales aprobados a través de una computadora conectada. Los administradores pueden gestionar los requisitos de ejecución local en Seguridad de agentes y revisar por separado la ejecución en la nube.

dots

• Realiza tareas de ingeniería en tu computadora. Investiga errores, implementa cambios y ejecuta compilaciones con los repositorios locales, las herramientas de desarrollo y las habilidades que estén permitidos.

• Coordina tareas de programación. Crea hilos locales de Work o Codex y controla los hilos locales de Codex existentes.

• Usa las apps 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 a la computadora local con Work en la nube

Una tarea consta de dos partes: coordinación y ejecución. La coordinación determina los pasos que se deben seguir y permite que la conversación avance. La ejecución es el trabajo que realiza una herramienta, como ejecutar un comando de shell. Con esta función, la coordinación pasa a la nube de OpenAI. Eso no implica trasladar todas las herramientas y los archivos fuera de la computadora.

Cómo configurar el acceso a la computadora local

Revisa tu política en Seguridad de agentes

Dónde revisarla

Abre Consola de administración → Seguridad de agentes. Esta sección reemplaza a Políticas y configuración. Su implementación es independiente de la del acceso a la computadora local para Work y los dots.

• Configuración de políticas: revisa la configuración base de Global y los ajustes de Local que prevalezcan sobre ella. Mantén los controles del orquestador, incluidas las aprobaciones y la búsqueda web, en Global. Los entornos no pueden modificar esos controles. Usa los controles específicos de la interfaz cuando estén disponibles, entre ellos Políticas de aprobación permitidas y Modos de búsqueda web permitidos. Usa TOML para los demás campos compatibles. Consulta 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 modificar. Los valores predeterminados proporcionan valores iniciales dentro de esos límites y no pueden prevalecer sobre un requisito.

• Acceso a las funciones: ve a Consola de administración → Permisos. Debes habilitar el acceso a la computadora local por separado para Work y para los dots.

Qué se conserva al migrar

Cuando se migran las políticas heredadas de la nube que cumplen los requisitos, sus ajustes pasan a Global y se conservan las asignaciones de políticas y su orden. Revisa las políticas migradas en Seguridad de agentes y usa la siguiente tabla para comprobar tu configuración actual. Si automatizas las actualizaciones de políticas, revisa también la última fila. Consulta las indicaciones para la migración en Seguridad de agentes.

Qué política tiene prioridad

Estas reglas se aplican en distintos niveles. Las flechas indican el orden 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, el orden de prioridad es el siguiente: ajuste específico del entorno → Global. Si un entorno no tiene un ajuste propio, hereda el ajuste de Global que corresponda.

• Requisitos locales: requisitos de MDM en macOS → campos heredados de managed_config.toml que se interpretan como requisitos → requisitos de Seguridad de agentes administrados desde la nube → archivo 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. Consulta Configuración administrada y la Referencia de configuración para conocer el alcance de las políticas, los campos compatibles y el alcance de la ejecución.

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

Cuando Work y los dots tienen acceso local, las políticas se aplican de la misma manera en los siguientes ámbitos:

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

• Ejecución local: cuando una herramienta se ejecuta en una computadora conectada, hace cumplir los requisitos de Seguridad de agentes compatibles con la ejecución local y las políticas aplicables al dispositivo, incluidas las distribuidas mediante MDM cuando se admite ese método. 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 el archivo requirements.toml local no garantiza que se haga cumplir localmente.

• Ejecución en la nube: los contenedores de Work en la nube y las computadoras en la nube de los 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.

Comprueba la compatibilidad y los requisitos relativos a los datos

Antes de habilitar cualquiera de las dos funciones, revisa los requisitos de elegibilidad, qué datos están cubiertos y los controles de los que depende tu organización. Aunque Work y los dots comparten infraestructura, las funciones y configuraciones que admiten pueden variar.

Revisa los requisitos de elegibilidad para Work y los dots

• Work: la residencia se aplica solo 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. Confirma la cobertura de tu flujo de trabajo. No des por hecho que abarca todos los pasos con acceso local ni todas las integraciones conectadas. Work no es compatible con la residencia de inferencia en los Emiratos Árabes Unidos (EAU). Consulta Residencia de datos y residencia de inferencia y Seguridad de Work en la nube.

• Residencia para los dots: durante la beta de Enterprise, los dots no admiten la residencia de datos ni la residencia de inferencia. Los espacios de trabajo que cumplen los requisitos pueden habilitar los dots tras reconocer esas limitaciones. Habilitarlos no hace que sus datos ni su procesamiento cumplan los requisitos de residencia.

• Exclusiones para los dots: los dots no están disponibles en espacios de trabajo de FedRAMP, en espacios de trabajo con EKM ni en aquellos que tienen la residencia de inferencia configurada en AE (EAU). Los espacios de trabajo sujetos a HIPAA pueden participar si cumplen los demás requisitos de elegibilidad.

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

• Procesamiento en la nube: la nube sigue coordinando las tareas de Work con acceso local y las de los dots. Las conversaciones, los resultados de las herramientas y el resto del contexto de la tarea no permanecen exclusivamente en la computadora conectada.

• Protección de la residencia: si alguna política de la nube habilita enforce_residency, la opción Permitir el acceso a la computadora local deja de estar disponible tanto para Work como para los dots. Esta medida no establece la residencia del espacio de trabajo ni deshabilita por sí sola Work en la nube o los dots. Los espacios de trabajo que cumplen los requisitos aún pueden habilitar los dots tras reconocer 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 retención cero de datos en sentido estricto. La retención cero de datos de la API es un control independiente de la API. Los compromisos de “no revisión humana” y los controles de monitoreo de abusos también son distintos de la retención cero. Si un flujo de trabajo exige que no se retengan datos, no lo habilites para estas experiencias.

Antes de la implementación, revisa la retención, la eliminación y la cobertura de auditoría para los datos y las herramientas que se usarán. En Work, las conversaciones, el estado de la ejecución alojada, los archivos y los datos de las apps conectadas pueden tener ciclos de vida distintos. Eliminar una conversación no elimina todas las copias relacionadas.

Comprueba la compatibilidad de los hooks y la red

• Compatibilidad de los hooks: antes de habilitar el acceso local, revisa los avisos de compatibilidad que aparezcan en la configuración del espacio de trabajo y en Seguridad de agentes. Compara los hooks que necesita tu flujo de trabajo con los hooks compatibles con la orquestación en la nube. Si el flujo depende de un hook de comando local o de un hook de un complemento, sigue ejecutándolo solo de forma local.

• Fallos y cobertura de auditoría: prueba la conexión para las llamadas de retorno y los eventos necesarios. Comprueba cómo se comporta la herramienta si una llamada de retorno falla o si se agota el tiempo de espera. Si falla un hook PreToolUse, es posible que la herramienta se ejecute de todos modos. Los hooks no cubren todas las rutas internas de ejecución de los subagentes. Revisa por separado los registros de auditoría disponibles.

• Controles de red y de apps: comprueba el campo, el mecanismo de distribución y el entorno de ejecución en la Referencia de configuración. Los controles que aplica una app o un dispositivo pueden seguir vigentes aunque el orquestador en la nube no use un ajuste. El entorno de ejecución en la nube no admite puertos de escucha HTTP/SOCKS administrados ni servicios de escucha de proxy en direcciones que no sean de loopback. La compatibilidad con las reglas de sockets depende de la ruta de ejecución. Revisa Prioridad de las políticas de red y límites del entorno de ejecución y luego prueba las acciones permitidas, las bloqueadas y la conectividad necesaria.

Si tienes preguntas sobre los archivos locales, la ejecución en la nube o la prioridad de las políticas, consulta las preguntas frecuentes para administradores de Work, la seguridad de Work en modo local y la seguridad de Work en la nube.

Habilita el acceso a la computadora local

Concede acceso a la computadora local por separado para Work y para los dots. Usa los valores predeterminados del espacio de trabajo y los roles personalizados compatibles para conceder acceso a los usuarios o grupos previstos.

Antes de la implementación, revisa las políticas y los requisitos de compatibilidad anteriores. Se recomienda revisar o crear políticas en Seguridad de agentes, aunque el proceso de confirmación permite habilitar el acceso sin crear políticas primero. La migración de políticas no concede acceso a la computadora local.

Work

1. Como propietario del espacio de trabajo, abre Consola de administración > Permisos.

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

3. En Work en la nube, activa Permitir el acceso a la computadora local. Revisa el cuadro de confirmación. Luego, abre Seguridad de agentes para revisar o configurar las políticas, o confirma para activar el acceso.

4. Pide a los usuarios que actualicen la app de escritorio de ChatGPT a la versión 26.929 o posterior. Se requiere esta actualización para que el acceso a la computadora local con Work en la nube surta efecto.

5. Pide a un miembro con los permisos previstos que seleccione Nube en el editor de la app de escritorio e inicie una tarea nueva. Continúa la tarea desde otro dispositivo compatible y comprueba que se pueda acceder a un archivo o una herramienta local aprobados mientras la computadora está conectada.

dots

1. Como propietario del espacio de trabajo, abre Consola de administración > Permisos y habilita los dots para los usuarios previstos, de acuerdo con los requisitos de elegibilidad anteriores.

2. En Usar dots, activa Permitir el acceso a la computadora local. Revisa el cuadro de confirmación. Luego, abre Seguridad de agentes para revisar o configurar las políticas, o confirma para activar el acceso.

3. Pide a los usuarios que actualicen la app de escritorio de ChatGPT a la versión 26.929 o posterior. Se requiere esta actualización para que el acceso a la computadora local surta efecto.

4. Pide a los usuarios que conecten su computadora siguiendo los pasos para usuarios de dots que aparecen más adelante.

5. Pide a un miembro con los permisos previstos y una computadora conectada que pruebe una tarea local con su dot.

Revisa la cobertura de OpenTelemetry y de auditoría

Al revisar la cobertura de OpenTelemetry (OTel) para Work con acceso local y para los dots, distingue la telemetría de ejecución local de los registros de auditoría en la nube. Tu ejecutor local puede seguir exportando los eventos de ejecución compatibles. Los eventos de orquestación en la nube no llegan a tu recopilador de OpenTelemetry actual.

Usa la API de Cumplimiento para obtener los registros disponibles de la nube. Cambiar el punto de acceso del recopilador no restablece la recepción de los eventos de orquestación en la nube. Los registros de la API de Cumplimiento no reemplazan todos los eventos del flujo anterior de OpenTelemetry.

Para los dots, usa la API de análisis para consultar los datos de uso y la API de Cumplimiento para obtener los registros de auditoría disponibles. Comprueba tanto los registros que necesita tu flujo de trabajo como la entrega de eventos al recopilador local. Los hooks de MCP no sustituyen la cobertura de auditoría.

Consulta la cobertura de auditoría en la nube en Seguridad de Work en la nube.

Experiencia del usuario final

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

Work

Los miembros deben iniciar sesión con ChatGPT en el espacio de trabajo correspondiente. Las claves de API y los tokens de acceso de Codex no permiten habilitar esta función. Comparte la guía Continuar las tareas de Work desde distintos dispositivos para que los miembros sepan cómo iniciar una tarea que cumpla los requisitos y continuarla cuando la computadora esté sin conexión. Antes de deshabilitar la función, revisa las instrucciones para revertir el cambio.

dots

• Conecta una computadora. Abre los detalles del dot en la app de escritorio de ChatGPT y elige Computadoras. Busca Tu computadora (o el nombre de la computadora), selecciona Permitir y confirma con Permitir acceso. La computadora quedará disponible para las tareas locales compatibles.

• Computadora sin conexión. El permiso de acceso se conserva, pero el trabajo que requiere esa computadora no puede continuar mientras no esté disponible. El estado Sin conexión no indica que se haya revocado el acceso.

• Retira el acceso. Elige Revocar acceso y confirma para retirar el permiso del dot para esa computadora. El estado Desconectada indica que se retiró el acceso y es distinto del estado Sin conexión.

• Cambios de acceso por parte de un administrador. Si un administrador deshabilita el acceso a la computadora local para los dots, es posible que una tarea local ya autorizada aún esté terminando. No des por hecho que los turnos en curso de los dots se interrumpen de inmediato como sucede en Work.

• Tareas en curso. Una tarea local en curso no se traslada automáticamente a la nube. Los cambios en la conexión pueden interrumpir el trabajo o hacer que se vuelva a cargar el entorno de ejecución. El dot puede continuar el trabajo posterior en su computadora en la nube, pero una subtarea local que ya no tiene acceso no puede reanudarse en la computadora local ni se traslada automáticamente a la nube.