Seguridad local de ChatGPT Work

ChatGPT Work puede usar archivos, aplicaciones y sesiones del navegador aprobados en el equipo de un usuario para completar tareas locales. El acceso depende de los permisos del espacio de trabajo, el acceso que ya tenga la cuenta del usuario, los permisos del sistema operativo, las aprobaciones de aplicaciones y las políticas de dispositivos compatibles.

Para obtener una descripción general de los controles de seguridad, consulta el documento técnico de seguridad empresarial de ChatGPT Work.

Las capacidades locales dependen de la aplicación de escritorio y el sistema operativo compatibles, los derechos del espacio de trabajo, los permisos del rol, la política del dispositivo y el despliegue del producto.

Resumen de seguridad

• Los pasos locales se ejecutan a través de la aplicación de escritorio de ChatGPT. Con el acceso al equipo local con Work Cloud, la nube de OpenAI coordina la tarea mientras el equipo conectado ejecuta los pasos que lo requieren.

• Los controles disponibles de Work local y alojado dependen de la configuración y el despliegue del espacio de trabajo.

• El acceso a archivos, Computer Use, los navegadores y las aplicaciones conectadas utilizan permisos y aprobaciones diferentes.

• Un navegador o una aplicación donde ya se haya iniciado sesión en un sistema de la empresa puede exponer los permisos de esa cuenta existente.

• Las políticas compatibles para dispositivos administrados pueden restringir las funciones locales sin sustituir los controles de acceso del espacio de trabajo.

• Los datos de los espacios de trabajo Business, Enterprise y Edu procesados por los servicios de OpenAI cubiertos se cifran en tránsito y en reposo, y no se utilizan de forma predeterminada para entrenar modelos de OpenAI.

• Los archivos locales, el contexto de las tareas, los datos del navegador, los registros de sistemas conectados y los eventos de auditoría pueden estar sujetos a reglas diferentes de almacenamiento y retención.

Dónde se ejecutan las tareas locales

La ejecución local accede a los recursos aprobados a través de la aplicación de escritorio en el equipo del usuario. Cuando el acceso al equipo local con Work Cloud está habilitado, la nube de OpenAI coordina la tarea y llama al equipo conectado cuando un paso necesita ejecución local. El equipo debe estar en línea y conectado para realizar esos pasos.

El acceso al equipo local con Work Cloud se aplica únicamente a las tareas creadas después de habilitar la sincronización. Las tareas existentes, incluidas las de los proyectos, conservan su modo original: solo localmente o en la nube sin acceso a archivos locales. Inicia una nueva tarea para usar esta función.

Si el equipo no está disponible cuando comienza un nuevo turno, una tarea existente que cumpla los requisitos y use el acceso al equipo local con Work Cloud puede continuar en un contenedor en la nube. El contenedor en la nube no puede acceder a los archivos ni a las herramientas del equipo no disponible. Tampoco 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.

Los archivos locales pueden permanecer en el dispositivo, pero es posible que se envíen a los servicios de OpenAI fragmentos pertinentes de archivos, prompts, capturas de pantalla, contenido del navegador o resultados de herramientas para completar una tarea. La ejecución local no implica una inferencia del modelo sin conexión o exclusiva del dispositivo.

Acceso a archivos y dispositivos

Una tarea local puede trabajar con la información que el usuario proporcione o ponga a disposición, incluidos archivos compatibles, contenido de aplicaciones, sesiones del navegador y sistemas conectados autorizados. El acceso depende de los privilegios existentes del usuario y de los controles que rijan esa capacidad específica.

Conceder acceso local a Work no aprueba automáticamente todas las aplicaciones, no otorga derechos de administrador ni elude los permisos de la cuenta utilizada para acceder a otro sistema. Una conexión compartida aprobada puede tener privilegios diferentes de los de la cuenta personal del usuario.

Las lecturas directas de archivos, las ediciones de archivos y los comandos de shell siguen la configuración de aislamiento y aprobación de la tarea. Computer Use accede al contenido a través de una aplicación nativa aprobada, con los permisos de esa aplicación. Una restricción sobre el acceso directo a archivos no establece por sí sola la misma restricción sobre los archivos que la aplicación puede abrir.

Computer Use y aprobaciones de aplicaciones

Los permisos del espacio de trabajo determinan quién puede usar Work Local. Las políticas del administrador pueden restringir además qué aplicaciones nativas puede manejar Computer Use y si las aprobaciones de aplicaciones pueden guardarse para futuras sesiones. Los permisos del sistema operativo y las aprobaciones de aplicaciones requeridos siguen siendo necesarios. Cuando una tarea utiliza una aplicación o una cuenta con una sesión iniciada, los permisos de esa cuenta determinan qué información y acciones están disponibles.

Permitir una aplicación mediante una política del administrador no instala el plugin requerido, no concede permisos del sistema operativo ni aprueba una acción que todavía requiere revisión. Para consultar los controles compatibles y ejemplos de configuración, consulta Controles administrados del navegador y de Computer Use.

En macOS, Screen Recording permite que Computer Use vea el contenido de las aplicaciones, y Accessibility le permite hacer clic, escribir y navegar. Las tareas compatibles de macOS pueden ejecutarse en segundo plano. En Windows, Computer Use funciona en el escritorio activo y visible, y no puede ejecutarse en segundo plano mientras el usuario continúa utilizando esa misma sesión.

Los usuarios pueden detener una tarea en cualquier momento. Computer Use no puede aprobar solicitudes de seguridad del sistema operativo, autenticarse como administrador ni automatizar aplicaciones de terminal o el propio ChatGPT.

Dispositivos bloqueados

Las configuraciones de macOS compatibles pueden permitir, de forma opcional, que una tarea aprobada de Computer Use continúe después de que el Mac se bloquee. La disponibilidad depende de la versión de la aplicación, el despliegue de la función, los requisitos aplicables y el cumplimiento de las condiciones para el control remoto.

Al habilitar Locked Use, se instala un plugin de autorización de macOS que puede desbloquear temporalmente el Mac durante un turno activo y de confianza de Computer Use. ChatGPT cubre todas las pantallas durante el desbloqueo temporal. Si detecta actividad local del teclado o del dispositivo apuntador, vuelve a bloquear el Mac y pausa el desbloqueo automático hasta que el usuario lo desbloquee manualmente. Consulta Cómo funciona Locked Use.

Los administradores pueden impedir que los usuarios habiliten Locked Use en los Mac administrados. Este requisito no desactiva Locked Use si ya está habilitado. Computer Use en Windows requiere un escritorio activo y desbloqueado. Consulta Restricciones de Locked Use.

Sesiones del navegador e inicios de sesión existentes

Work Local no obtiene acceso automáticamente a todos los navegadores o cuentas de la empresa. El acceso depende del navegador utilizado, la cuenta con la sesión iniciada y las aprobaciones requeridas para esa experiencia de navegación.

Las políticas compatibles de Browser Use pueden restringir el acceso a sitios, las cargas, las descargas, el acceso al historial del navegador y el acceso completo a Chrome DevTools Protocol (CDP) para depurar el navegador. Los administradores también pueden restringir la revisión automática de aprobaciones, las aprobaciones guardadas y la duración de las aprobaciones de acceso a sitios. La aprobación de un usuario no puede anular la denegación de un administrador. Consulta Controles administrados del navegador.

Un navegador alojado en la nube está separado de los navegadores locales del usuario y no hereda automáticamente sus sesiones iniciadas. El inicio de sesión en sitios web a través del navegador en la nube no está disponible en los espacios de trabajo Enterprise o Edu.

Aplicaciones, plugins y cuentas conectadas

Una aplicación conectada puede proporcionar acceso a información o acciones de otro sistema. Un plugin puede utilizar una aplicación como herramienta subyacente. Hacer que un plugin esté disponible no habilita automáticamente la aplicación necesaria, no autoriza una cuenta ni permite todas las acciones.

Los valores predeterminados de plugins y aplicaciones dependen del plan y de si el espacio de trabajo es nuevo o existente. Los nuevos espacios de trabajo Enterprise y Edu comienzan con un conjunto seleccionado de aplicaciones habilitadas; esos valores predeterminados no cambian la configuración de los espacios de trabajo existentes ni se aplican a los espacios de trabajo Healthcare. En general, los nuevos plugins y aplicaciones están deshabilitados de forma predeterminada en Enterprise y Edu. Las aplicaciones de Business están habilitadas de forma predeterminada. Los administradores pueden cambiar la disponibilidad. Consulta los valores predeterminados actuales de plugins y aplicaciones y la descripción general de ChatGPT Work.

Antes de que una tarea utilice un sistema conectado, confirma que el espacio de trabajo permite la aplicación y cualquier plugin necesario, que la conexión está autorizada y que la cuenta conectada puede acceder a la información o acción solicitada. La configuración de solo lectura, las acciones permitidas y los requisitos de confirmación varían según la integración.

Los plugins que proporcionan funciones de navegador o de Computer Use requieren su propia revisión de disponibilidad e instalación. Hacer que un plugin esté disponible no anula las políticas administradas del navegador o de aplicaciones nativas, los permisos del sistema operativo ni las aprobaciones requeridas. Los plugins exclusivos de escritorio y las herramientas proporcionadas localmente pueden seguir distintas vías de instalación. Consulta Controles de plugins.

Conexiones personales y compartidas

Una conexión personal utiliza los permisos del usuario conectado en el sistema de origen. Una conexión compartida o propiedad de un agente utiliza los permisos de la cuenta conectada, que pueden ser más amplios que el acceso del propio usuario.

Limita las cuentas compartidas a los datos y las acciones necesarios, restringe quién puede utilizarlas y aplica los controles compatibles de acciones o confirmación. Los registros del sistema conectado siguen sujetos a los permisos y las políticas de retención de ese sistema.

Acceso de administradores y políticas de dispositivos administrados

Para el acceso al equipo local con Work Cloud, revisa tanto el permiso de sincronización del espacio de trabajo como los requisitos de Agent Security para la ejecución local.

Para la ejecución local, los requisitos de MDM y los requisitos heredados de dispositivos administrados tienen prioridad sobre Agent Security. El archivo de requisitos del sistema del dispositivo tiene menor prioridad que Agent Security. Dentro de una política determinada, las anulaciones de entorno específicas del sistema operativo tienen prioridad sobre las anulaciones de entorno para todos los sistemas operativos, seguidas de Global. Una política de mayor prioridad prevalece aunque una política de menor prioridad sea más específica. Algunos requisitos tienen reglas de combinación específicas de cada campo.

Usa la API de políticas para administrar la configuración de Global. Para administrar la configuración de Local o Codex Cloud, usa la interfaz de Agent Security. Los flujos de trabajo existentes de la API para 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.

Para Work con acceso local y dots, la política de Global compatible se aplica a través del orquestador compartido en la nube cuando la política administrada está habilitada. Los requisitos locales aplicables de requirements.toml rigen la ejecución en un equipo conectado. Los contenedores en la nube de Work y los equipos en la nube de dots utilizan su propia configuración y sus propios requisitos de ejecución, en lugar del paquete de entorno administrado que utilizan otros tipos de ejecutores. Las restricciones de ejecución local no se aplican automáticamente a estos equipos en la nube. Revisa los permisos de las capacidades en la nube y prueba la ejecución local y la ejecución en la nube por separado.

Antes de habilitar la sincronización, revisa estos requisitos:

• Políticas distribuidas únicamente mediante MDM. MDM distribuye las políticas a los dispositivos. Crea una configuración de referencia en Agent Security para los requisitos de ejecución local compatibles antes de habilitar la sincronización.

• 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 compatibles del ciclo de vida y de las herramientas. Los hooks de comandos y los hooks de la configuración local o de los 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 de Work y Codex que se ejecutan solo localmente. Los administradores pueden seguir configurando los hooks administrados compatibles en Agent Security para esos flujos de trabajo.

• Auditoría. Antes de depender de estos hooks, pruebe la conexión de devolución de llamada, confirme los eventos que recibe y compruebe cómo afectan los fallos a la tarea. Los hooks de MCP no proporcionan un registro de auditoría completo de la Compliance API.

Revise los controles de Work disponibles en Configuración del espacio de trabajo > Permisos y roles. Que Work local y alojado aparezcan como permisos distintos depende de la configuración del espacio de trabajo y del despliegue. Para obtener más orientación, consulte las Preguntas frecuentes para administradores de Work.

Habilita únicamente los entornos de ejecución aprobados para cada usuario o grupo y verifica el acceso efectivo después de realizar cambios.

Los permisos del espacio de trabajo determinan quién puede utilizar Work. Los administradores también pueden restringir las capacidades de escritorio compatibles mediante requisitos obligatorios definidos en requirements.toml. Según la implementación, estos requisitos pueden distribuirse mediante una configuración administrada por el espacio de trabajo, un archivo de configuración del sistema o herramientas compatibles de administración de dispositivos móviles de macOS.

Los usuarios individuales no pueden anular los requisitos obligatorios. En cambio, los valores predeterminados administrados establecen una configuración inicial que los usuarios quizá puedan cambiar. Ninguno de ellos sustituye los roles del espacio de trabajo ni los permisos del sistema operativo.

En los clientes locales que usan la ruta de configuración local existente, los requisitos administrados se cargan durante la carga de la configuración. Una actualización en segundo plano puede preparar los requisitos de la nube para una carga posterior, y los cambios de MDM de macOS se leen en el siguiente inicio del cliente. Reinicie y verifique el cliente local correspondiente después de cambiar una política local.

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. Ese turno usa automáticamente Work Cloud sin acceso a los archivos locales.

Este comportamiento de carga local no determina cuándo entra en vigor un cambio de política de la nube en una tarea en ejecución que usa el acceso al equipo local con Work Cloud. Verifique los controles efectivos de la tarea antes de depender de la actualización.

Estos son ejemplos de restricciones, no una lista de valores predeterminados activados. Omitir un requisito de una función mantiene vigentes los ajustes habituales del cliente, la plataforma, el despliegue y el usuario. Los indicadores de funciones de Browser Use, el panel del navegador integrado y Computer Use nativo son controles independientes. Compruebe cada vía de acceso al navegador por separado.

Los ajustes y métodos de distribución disponibles dependen del cliente, el sistema operativo, el espacio de trabajo y la configuración del despliegue. Compruebe las restricciones en un dispositivo administrado representativo. Para conocer los ajustes de políticas compatibles, ejemplos de configuración e instrucciones de configuración de MDM, consulte Configuración administrada.

Redes locales y recursos privados

Work Local puede acceder a información de la empresa a través de un navegador, una aplicación nativa, una aplicación conectada u otra herramienta compatible. Los controles de red se aplican de forma distinta a cada vía, y el acceso a una VPN corporativa no autoriza por sí solo a una tarea a usar un recurso interno.

Los requisitos de red administrados y las políticas de origen de Browser Use son comprobaciones independientes. Compruebe ambos en las versiones de la aplicación y los sistemas operativos de su despliegue antes de depender de una restricción de red para limitar Browser Use. Las comprobaciones de las políticas del navegador no significan que el tráfico del navegador pase por el proxy de red de comandos, y las políticas de Browser Use no regulan el tráfico de las aplicaciones nativas.

Los requisitos de red administrados bajo [experimental_network] son experimentales y pueden cambiar. La compatibilidad con Windows es limitada; prueba el cliente y el entorno exactos antes de aplicarlos a los usuarios de Windows. Las reglas de dominio por sí solas no activan el proxy administrado; se requiere experimental_network.enabled = true y este ajuste no anula un entorno aislado que mantenga deshabilitado el acceso a la red.

Revisa la conexión, la cuenta con la sesión iniciada, el destino y la acción que requiere el flujo de trabajo. Para obtener detalles de configuración y conocer las limitaciones de cada plataforma, consulta Requisitos de acceso a la red.

Tratamiento y retención de datos

En el acceso al equipo local con Work Cloud, la coordinación en la nube forma parte del flujo de trabajo incluso cuando un paso se ejecuta en el equipo. Revise los datos de la conversación y el contexto de la tarea por separado de los archivos locales que usa una herramienta. No deduzca que la ejecución local implica almacenamiento exclusivo en el dispositivo ni que se cargan todos los archivos de una carpeta.

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 solo abarcan el contenido elegible y las cargas de trabajo, regiones y configuraciones compatibles. Enterprise Key Management (EKM) abarca el contenido almacenado compatible en los espacios de trabajo elegibles. Work no es compatible con la residencia de inferencia en los Emiratos Árabes Unidos. Confirme la cobertura de almacenamiento, retención y auditoría del espacio de trabajo antes del despliegue. Si su organización requiere ZDR, no active esta función. Si enforce_residency está activado en cualquier política de la nube, Permitir el acceso al equipo local se desactiva tanto para Work como para dots. Esta medida de protección no configura la residencia del espacio de trabajo ni desactiva, por sí sola, Work Cloud o dots.

Aplica los controles de endpoint, acceso a archivos, proxy y prevención de pérdida de datos de tu organización al dispositivo y flujo de trabajo específicos. Confirma si esos controles pueden impedir que la información confidencial entre en la tarea antes del procesamiento. Los registros de auditoría y las exportaciones de cumplimiento ayudan con la supervisión y la investigación, pero no bloquean el procesamiento por sí solos.

El almacenamiento y la retención dependen de la categoría de información y de dónde se guarde.

En los espacios de trabajo Business, Enterprise y Edu compatibles, los datos empresariales procesados por los servicios de OpenAI cubiertos se cifran en tránsito y en reposo, y no se utilizan de forma predeterminada para entrenar o mejorar los modelos de OpenAI. Estas protecciones no implican que OpenAI controle todos los archivos del dispositivo, aplicaciones de terceros, perfiles del navegador o registros del sistema de origen.

No apliques un periodo de retención de conversaciones alojadas, cargas temporales o registros de cumplimiento a los registros locales sin confirmar que se aplica a la categoría de datos específica.

Visibilidad de auditoría y cumplimiento

Activar el acceso al equipo local con Work Cloud cambia lo que recibe su recopilador de OpenTelemetry (OTel) existente. Su ejecutor local puede seguir exportando los eventos de ejecución compatibles. Los eventos de orquestación en la nube no llegan a su recopilador de OpenTelemetry existente.

Use la Compliance API para los registros compatibles de la nube. Cambiar el punto de conexión del recopilador no restablece los eventos de orquestación en la nube. Los registros de la Compliance API no sustituyen todos los eventos del flujo anterior de OpenTelemetry. Consulte Revisar OpenTelemetry y la cobertura de auditoría.

Los informes disponibles dependen del plan del espacio de trabajo, la experiencia de producto, el evento, la aplicación conectada y la configuración implementada. Verifica la cobertura de Work Local antes de depender de una exportación del espacio de trabajo para responder a incidentes o realizar revisiones normativas.

En las versiones compatibles, Browser Use puede emitir eventos de OpenTelemetry para las comprobaciones de funciones, incluidas las de acceso a sitios, cargas y descargas. Estos eventos registran la decisión y su origen, con detalles de la política cuando están disponibles. El origen de la decisión puede ser desconocido. Cuando se configura la exportación, se envían al endpoint de OpenTelemetry del cliente junto con otros datos de telemetría del entorno de ejecución local.

Configure la exportación de OpenTelemetry por separado de los registros de la Compliance API. Estos eventos no constituyen un registro completo de todas las acciones del navegador o de las aplicaciones nativas. Consulte Configuración de OpenTelemetry.

Determina si los sistemas pertinentes registran la identidad de la tarea, los prompts y las respuestas compatibles, las llamadas a aplicaciones conectadas, las aprobaciones del navegador, las acciones de aplicaciones, la actividad de archivos locales o los eventos del endpoint. Los registros del sistema de origen y del dispositivo pueden ofrecer una visibilidad diferente de la de los registros del espacio de trabajo de ChatGPT.

OpenAI no almacena un registro completo independiente de las acciones de Chrome realizadas mediante la extensión. No des por sentado que todas las operaciones con archivos locales, capturas de pantalla, acciones del navegador, aprobaciones o actualizaciones externas aparecen en la Compliance API.

Empieza con una tarea aprobada

Verifique Work local en los dispositivos administrados que usan sus equipos. Ejecute una tarea aprobada, como comparar libros de cálculo financieros seleccionados. Confirme el acceso a Work de cada usuario y proporcione únicamente los archivos, las aplicaciones, las sesiones del navegador o las cuentas conectadas que requiera la tarea.

Compruebe que las acciones aprobadas funcionen, que las acciones restringidas se bloqueen y que los registros disponibles satisfagan sus necesidades de supervisión. Pida al usuario que revise los resultados y confirme que los cambios en los archivos o sistemas conectados se ajusten a lo solicitado.