For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navegación principal
Theme

Seguridad local de ChatGPT Work

Revisa la ejecución local, el acceso al dispositivo y al navegador, las políticas administradas, el manejo de datos y las limitaciones de auditoría de ChatGPT Work

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

Para conocer los controles de seguridad, consulta el informe técnico sobre seguridad empresarial de ChatGPT Work.

Las funciones locales dependen de la app de escritorio compatible, el sistema operativo, las funciones habilitadas para el espacio de trabajo, los permisos del rol, la política del dispositivo y la etapa de lanzamiento del producto.

Resumen de seguridad

  • Los pasos locales se ejecutan a través de la app de escritorio de ChatGPT. Con el acceso a la computadora local desde Work en la nube, la nube de OpenAI coordina la tarea y la computadora conectada ejecuta los pasos que requieren ejecución local.

  • Los controles disponibles para Work local y Work alojado dependen de la configuración del espacio de trabajo y de la etapa de lanzamiento.

  • El acceso a archivos, el Uso de la computadora, los navegadores y las apps conectadas tienen distintos permisos y requisitos de aprobación.

  • Si ya hay una sesión iniciada en un sistema de la empresa desde un navegador o una aplicación, la tarea puede acceder al sistema con los permisos de esa cuenta.

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

  • Los datos de los espacios de trabajo Business, Enterprise y Edu que procesan los servicios de OpenAI cubiertos se cifran en tránsito y en reposo. De forma predeterminada, no se usan 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 distintas reglas de almacenamiento y retención.

Dónde se ejecutan las tareas locales

Durante la ejecución local, la tarea accede a los recursos aprobados a través de la app de escritorio en la computadora del usuario. Cuando está habilitado el acceso a la computadora local desde Work en la nube, la nube de OpenAI coordina la tarea y recurre a la computadora conectada cuando un paso requiere ejecución local. Para ejecutar esos pasos, la computadora debe estar en línea y conectada.

Los requisitos del dispositivo se aplican a la ejecución local. Si un nuevo turno se ejecuta en un contenedor en la nube mientras la computadora está sin conexión, el contenedor aplica sus propias políticas y no puede acceder a los archivos ni a las herramientas locales. Consulta Cómo continuar una tarea de Work en otro dispositivo.

Los archivos locales pueden permanecer en el dispositivo, pero para completar una tarea se pueden enviar a los servicios de OpenAI fragmentos relevantes de archivos, prompts, capturas de pantalla, contenido del navegador o resultados de herramientas. La ejecución local no implica que la inferencia del modelo se realice sin conexión o exclusivamente en el dispositivo.

Archivos y acceso al dispositivo

Una tarea local puede trabajar con la información que el usuario proporciona o pone a su disposición, incluidos archivos compatibles, contenido de aplicaciones, sesiones de navegador y sistemas conectados autorizados. El acceso depende de los privilegios que ya tiene el usuario y de los controles que rigen esa función específica.

Otorgar acceso local a Work no aprueba automáticamente todas las aplicaciones, no otorga derechos de administrador ni permite eludir los permisos de la cuenta que se usa para acceder a otro sistema. Una conexión compartida aprobada puede tener privilegios distintos de los de la cuenta personal del usuario.

La lectura directa de archivos, la edición de archivos y los comandos de shell se rigen por la configuración del sandbox y de las aprobaciones de la tarea. El Uso de la computadora accede al contenido a través de una aplicación nativa aprobada y con los permisos de esa aplicación. Restringir el acceso directo a archivos no impone por sí solo la misma restricción a los archivos que la aplicación puede abrir.

Uso de la computadora y aprobaciones de aplicaciones

Los permisos del espacio de trabajo determinan quién puede usar Work local. Las políticas de los administradores pueden restringir aún más qué aplicaciones nativas puede controlar el Uso de la computadora y si se pueden guardar las aprobaciones de aplicaciones para sesiones futuras. Los permisos obligatorios del sistema operativo y las aprobaciones de aplicaciones siguen siendo necesarios. Cuando una tarea usa una aplicación o una cuenta con una sesión iniciada, los permisos de la cuenta determinan a qué información puede acceder y qué acciones puede realizar.

Permitir una aplicación mediante una política de administración no instala el complemento necesario, no otorga permisos del sistema operativo ni aprueba acciones que aún requieren revisión. Para conocer los controles compatibles y ver ejemplos de configuración, consulta Controles administrados del navegador y del Uso de la computadora.

En macOS, el permiso de grabación de pantalla permite que el Uso de la computadora vea el contenido de las aplicaciones, y el de accesibilidad le permite hacer clic, escribir y navegar. Las tareas compatibles en macOS pueden ejecutarse en segundo plano. En Windows, el Uso de la computadora opera en el escritorio activo y visible, y no puede ejecutarse en segundo plano mientras el usuario sigue usando esa misma sesión.

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

Dispositivos bloqueados

En las configuraciones de macOS compatibles, puedes permitir que una tarea aprobada de Uso de la computadora continúe después de que se bloquee la Mac. La disponibilidad depende de la versión de la app, la etapa de lanzamiento de la función, los requisitos aplicables y el cumplimiento de las condiciones para el control remoto.

Al habilitar el uso con la computadora bloqueada, se instala un complemento de autorización de macOS que puede desbloquear temporalmente la Mac durante un turno activo y de confianza del Uso de la computadora. ChatGPT oculta el contenido de todas las pantallas durante el desbloqueo temporal. Si detecta actividad local del teclado o del puntero, vuelve a bloquear la Mac y pausa el desbloqueo automático hasta que el usuario la desbloquee manualmente. Consulta Cómo funciona el uso con la computadora bloqueada.

Los administradores pueden impedir que los usuarios habiliten el uso con la computadora bloqueada en las Mac administradas. Este requisito no desactiva la función si ya está habilitada. En Windows, el Uso de la computadora requiere un escritorio activo y desbloqueado. Consulta Restricciones de uso con la computadora bloqueada.

Sesiones de navegador y cuentas con sesión iniciada

Work local no obtiene acceso automático a todos los navegadores ni a todas las cuentas de la empresa. El acceso depende del navegador que se use, de la cuenta con la que se haya iniciado sesión y de las aprobaciones que se requieran para esa modalidad de uso del navegador.

Modalidad de acceso al navegador Sesión y límites de seguridad
Navegador integrado de la app de escritorio Usa un perfil distinto del que el usuario utiliza en su navegador habitual. Los usuarios pueden iniciar sesión en ese perfil. En los clientes compatibles, las políticas administradas de la función Navegador restringen el acceso del agente a los sitios y las funciones del navegador que puede usar. El navegador integrado no puede automatizar la carga de archivos.
Extensión de Chrome Puede interactuar con pestañas existentes y cuentas con sesión iniciada si se aprueban la extensión y el acceso a los sitios web. En los clientes compatibles, las mismas políticas administradas de la función Navegador se aplican a las acciones que el agente realiza mediante la extensión.
Control del navegador mediante el Uso de la computadora Controla el navegador como una aplicación nativa aprobada y puede usar cuentas con sesión iniciada. Las políticas de la función Navegador que regulan el acceso a sitios y las funciones disponibles no se aplican a esta modalidad. Siguen vigentes las políticas para aplicaciones nativas, los permisos del sistema operativo, las aprobaciones de aplicaciones y los permisos de la cuenta con sesión iniciada.

Las políticas compatibles de la función Navegador pueden restringir el acceso a sitios, las cargas, las descargas, el acceso al historial de navegación 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 vigencia 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.

El navegador alojado en la nube es independiente de los navegadores locales del usuario y no hereda automáticamente las sesiones iniciadas en ellos. En los espacios de trabajo Enterprise o Edu, no se puede iniciar sesión en sitios web desde el navegador en la nube.

Apps, complementos y cuentas conectadas

Una app conectada puede dar acceso a información o acciones en otro sistema. Un complemento puede usar una app como herramienta subyacente. Poner un complemento a disposición de los usuarios no habilita automáticamente la app necesaria, no autoriza una cuenta ni permite todas las acciones.

La configuración predeterminada de los complementos y las apps depende del plan y de si el espacio de trabajo es nuevo o ya existe. Los nuevos espacios de trabajo Enterprise y Edu comienzan con un conjunto seleccionado de apps habilitadas. Estos valores predeterminados no modifican la configuración de los espacios de trabajo existentes ni se aplican a los espacios de trabajo Healthcare. En general, los complementos y las apps nuevos están deshabilitados de forma predeterminada en Enterprise y Edu. En Business, las apps están habilitadas de forma predeterminada. Los administradores pueden cambiar su disponibilidad. Consulta la configuración predeterminada actual de complementos y apps y la descripción general de ChatGPT Work.

Antes de que una tarea use un sistema conectado, confirma que el espacio de trabajo permita la app y los complementos necesarios, que la conexión esté autorizada y que la cuenta conectada pueda acceder a la información solicitada o realizar la acción requerida. La configuración de solo lectura, las acciones permitidas y los requisitos de confirmación varían según la integración.

La disponibilidad y la instalación de los complementos que ofrecen funciones de navegador o de Uso de la computadora requieren una revisión por separado. Poner un complemento a disposición de los usuarios no anula las políticas administradas del navegador o de las aplicaciones nativas, los permisos del sistema operativo ni las aprobaciones requeridas. Los complementos exclusivos de la app de escritorio y las herramientas disponibles localmente pueden tener distintos métodos de instalación. Consulta Controles de complementos.

Conexiones personales y compartidas

Una conexión personal usa los permisos que tiene el usuario conectado en el sistema de origen. Una conexión compartida o que pertenece a un agente usa los permisos de la cuenta conectada, que pueden ser más amplios que los del usuario.

Limita el acceso de las cuentas compartidas a los datos y las acciones necesarios, restringe quién puede usarlas y aplica los controles de acción o confirmación compatibles. 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 para dispositivos administrados

Para el acceso a la computadora local desde Work en la nube, revisa tanto el permiso de sincronización del espacio de trabajo como los requisitos de seguridad de agentes para la ejecución local.

En la ejecución local, los requisitos de MDM y los requisitos heredados para dispositivos administrados tienen prioridad sobre los de seguridad de agentes. El archivo de requisitos del sistema del dispositivo tiene menor prioridad que la seguridad de agentes. Dentro de una misma política, los valores que se definen para un entorno y un sistema operativo específicos tienen prioridad sobre los que se definen para ese entorno en todos los sistemas operativos. La configuración global tiene la prioridad más baja. Prevalece la política de mayor prioridad, incluso si una de menor prioridad es más específica. Algunos requisitos tienen reglas de combinación específicas para cada campo.

Usa la API de políticas para administrar la configuración global. Para administrar la configuración local o de Codex Cloud, usa la interfaz de seguridad de agentes. Los flujos de trabajo existentes que usan la API para la configuración 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 sigan siendo los mismos.

Para Work con acceso local y para dots, la política 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 una computadora conectada. Los contenedores de Work en la nube y las computadoras de dots en la nube usan su propia configuración y sus propios requisitos de ejecución, en lugar del paquete de entorno administrado que usan otros tipos de ejecutores. Las restricciones de ejecución local no se aplican automáticamente a estas computadoras en la nube. Revisa los permisos de las funciones en la nube y prueba por separado la ejecución local y la ejecución en la nube.

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

  • Políticas distribuidas solo mediante MDM. MDM distribuye las políticas a los dispositivos. Antes de habilitar la sincronización, establece en la configuración de seguridad de agentes una política base para los requisitos de ejecución local compatibles.

  • Hooks empresariales. Si un flujo de trabajo que se ejecuta solo de forma local depende de scripts o de hooks de complementos, comprueba qué hooks admite el orquestador en la nube antes de habilitar el acceso a la computadora local. Prueba los eventos necesarios y revisa la cobertura de auditoría.

Revisa los controles de Work disponibles en Configuración del espacio de trabajo > Permisos y roles. La configuración del espacio de trabajo y la etapa de lanzamiento determinan si Work local y Work alojado aparecen como permisos distintos. Para obtener más información, consulta las preguntas frecuentes de los administradores de Work.

Habilita solo los entornos de ejecución aprobados para cada usuario o grupo y verifica qué acceso tienen después de hacer cambios.

Los permisos del espacio de trabajo determinan quién puede usar Work. Los administradores también pueden restringir las funciones de escritorio compatibles mediante requisitos obligatorios definidos en requirements.toml. Según la implementación, estos requisitos se pueden distribuir mediante la configuración administrada del espacio de trabajo, un archivo de configuración a nivel del sistema o herramientas compatibles de administración de dispositivos móviles para macOS.

Los usuarios no pueden anular los requisitos obligatorios. En cambio, los valores predeterminados administrados establecen una configuración inicial que los usuarios podrían modificar. Ninguno de estos mecanismos reemplaza los roles del espacio de trabajo ni los permisos del sistema operativo.

En los clientes locales que usan el mecanismo de configuración local existente, los requisitos administrados se cargan junto con la configuración. Una actualización en segundo plano puede preparar los requisitos de la nube para que se carguen más adelante. En macOS, el cliente lee los cambios de MDM la próxima vez que se inicia. Después de cambiar una política local, reinicia el cliente local correspondiente y verifica su configuración.

La forma en que se carga la configuración local no determina cuándo surte efecto un cambio de política en la nube para una tarea en curso que usa el acceso a la computadora local desde Work en la nube. Antes de confiar en la actualización, verifica qué controles se aplican a la tarea.

Configuración administrada Objetivo de seguridad
features.computer_use = false Deshabilita las funciones nativas del Uso de la computadora.
allow_appshots = false Impide la captura de Appshots en los clientes compatibles.
features.in_app_browser = false Deshabilita el navegador integrado de la app de escritorio.
features.browser_use = false Deshabilita las funciones compatibles de Navegador. La función Navegador externo tiene su propio indicador.
features.browser_use_external = false Deshabilita el uso de la función Navegador por parte del agente a través de extensiones de navegador compatibles.
features.apps = false o features.plugins = false Restringe las aplicaciones conectadas o los complementos compatibles.
computer_use.allow_locked_computer_use = false Impide que los usuarios habiliten el uso con la computadora bloqueada en las Mac administradas. Si ya está habilitado, seguirá activo.

Estos ejemplos muestran restricciones y no enumeran las funciones habilitadas de forma predeterminada. Si omites un requisito para una función, siguen vigentes la configuración habitual del cliente, de la plataforma y del usuario, así como las condiciones del lanzamiento. Los indicadores de la función Navegador, el panel del navegador integrado y el Uso de la computadora mediante aplicaciones nativas tienen controles independientes. Comprueba cada modalidad de acceso al navegador por separado.

Los ajustes y los métodos de distribución disponibles dependen del cliente, el sistema operativo, el espacio de trabajo y la configuración de la implementación. Comprueba las restricciones en un dispositivo administrado representativo. Para conocer los ajustes de políticas compatibles, ver ejemplos de configuración y consultar las instrucciones de configuración de MDM, visita 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 app conectada u otra herramienta compatible. Los controles de red se aplican de manera distinta en cada caso. 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 la función Navegador se verifican por separado. Comprueba ambos en las versiones de la app y los sistemas operativos de tu implementación antes de confiar en una restricción de red para limitar la función Navegador. Que se comprueben las políticas del navegador no implica que su tráfico pase por el proxy de red para comandos. Las políticas de la función Navegador tampoco rigen el tráfico de las aplicaciones nativas.

Los requisitos de red administrados en [experimental_network] son experimentales y pueden cambiar. La compatibilidad con Windows es limitada. Prueba el cliente y el entorno específicos antes de aplicar estos requisitos a 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 la restricción de un sandbox que mantiene deshabilitado el acceso a la red.

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

Manejo y retención de datos

Con el acceso a la computadora local desde Work en la nube, la coordinación en la nube forma parte del flujo de trabajo incluso cuando un paso se ejecuta en la computadora. Revisa los datos de la conversación y el contexto de la tarea por separado de los archivos locales que usa una herramienta. No supongas que la ejecución local implica que los datos se almacenan únicamente en el dispositivo o que se cargan todos los archivos de una carpeta.

El acceso a la computadora local desde Work en la nube no ofrece retención cero de datos en sentido estricto. La residencia de datos y la residencia de inferencia solo cubren el contenido que cumple los requisitos y las cargas de trabajo, regiones y configuraciones compatibles. La administración de claves empresariales (EKM) cubre el contenido almacenado compatible en los espacios de trabajo que cumplen los requisitos. Work no admite la residencia de inferencia en los Emiratos Árabes Unidos. Antes de la implementación, confirma qué cubren el almacenamiento, la retención y la auditoría del espacio de trabajo. Si tu organización requiere retención cero de datos (ZDR), no habilites esta función. Si enforce_residency está habilitado en alguna política en la nube, Permitir el acceso a la computadora local queda deshabilitado 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 en la nube o dots.

Aplica al dispositivo y al flujo de trabajo específicos los controles de tu organización para dispositivos finales, acceso a archivos, proxy y prevención de pérdida de datos. Confirma si estos controles pueden impedir que se incorpore información confidencial a la tarea antes de procesarla. Los registros de auditoría y las exportaciones de cumplimiento ayudan a monitorear e investigar la actividad, pero por sí solos no bloquean el procesamiento.

El almacenamiento y la retención dependen del tipo de información y de dónde se guarde.

Categoría de información Qué revisar
Registros locales de conversaciones Cómo la app de escritorio almacena, elimina, respalda o comparte los registros locales. No supongas que la configuración de retención de las conversaciones alojadas se aplica a todos los elementos guardados localmente.
Archivos locales y resultados generados El almacenamiento del dispositivo, la política para dispositivos finales, las cargas autorizadas por el usuario, el contenido compartido externamente y las copias guardadas por separado.
Prompts, fragmentos de archivos y contexto de las aplicaciones El contenido que se proporciona a un modelo o servicio, los términos aplicables al espacio de trabajo y el recorrido real de los datos en el flujo de trabajo.
Voz y Appshots La entrada del micrófono, las capturas de la ventana en primer plano, el texto accesible de las aplicaciones, el almacenamiento local de la sesión y cualquier contenido enviado como contexto de la tarea.
Datos del navegador El perfil de navegador utilizado, las sesiones iniciadas, el historial de navegación, las descargas, las aprobaciones de sitios web y el contenido de la tarea que se haya guardado por separado.
Registros de sistemas conectados Los permisos y la retención del sistema de origen, la identidad de la cuenta conectada y cualquier información guardada por separado en la conversación o en otro destino.
Registros de cumplimiento y actividad Qué eventos de Work local están disponibles en el espacio de trabajo, cuál es la integración compatible y qué política de retención aplica el sistema receptor.

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

Antes de aplicar a los registros locales un período de retención definido para conversaciones alojadas, cargas temporales o registros de cumplimiento, confirma que corresponda a la categoría de datos específica.

Visibilidad para auditoría y cumplimiento

Habilitar el acceso a la computadora local desde Work en la nube cambia los eventos que recibe tu recopilador de OpenTelemetry (OTel) actual. El 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 acceder a los registros compatibles de la nube. Cambiar el punto de acceso del recopilador no restablece la recepción de eventos de orquestación en la nube. Los registros de la API de Cumplimiento no reemplazan todos los eventos del flujo anterior de OpenTelemetry. Consulta Revisar OpenTelemetry y la cobertura de auditoría.

Los informes disponibles dependen del plan del espacio de trabajo, la modalidad de uso del producto, el evento, la aplicación conectada y la configuración implementada. Verifica la cobertura de Work local antes de basarte en una exportación del espacio de trabajo para responder a un incidente o realizar una revisión regulatoria.

En las versiones compatibles, la función Navegador puede emitir eventos de OpenTelemetry cuando comprueba si se permite usar una función, como acceder a sitios, cargar archivos o descargarlos. Estos eventos registran la decisión y su origen, junto con los detalles de la política cuando están disponibles. El origen de la decisión puede ser desconocido. Cuando se configura la exportación, los eventos se envían al punto de acceso de OpenTelemetry del cliente junto con los demás datos de telemetría del entorno de ejecución local.

Configura la exportación de OpenTelemetry por separado de los registros de la API de Cumplimiento. Estos eventos no proporcionan un registro completo de todas las acciones del navegador o de las aplicaciones nativas. Consulta Configuración de OpenTelemetry.

Determina si los sistemas correspondientes registran la identidad de la tarea, los prompts y las respuestas compatibles, las llamadas a apps conectadas, las aprobaciones del navegador, las acciones de las aplicaciones, la actividad en archivos locales o los eventos de los dispositivos finales. Los registros de los sistemas de origen y de los dispositivos pueden mostrar información distinta de la que aparece en los registros del espacio de trabajo de ChatGPT.

OpenAI no almacena por separado un registro completo de las acciones realizadas en Chrome a través de la extensión. No supongas que todas las operaciones con archivos locales, capturas de pantalla, acciones del navegador, aprobaciones o actualizaciones externas aparecen en la API de Cumplimiento.

Empieza con una tarea aprobada

Verifica el funcionamiento de Work local en los dispositivos administrados que usan tus equipos. Ejecuta una tarea aprobada, como comparar libros de cálculo financieros seleccionados. Confirma que cada usuario tenga acceso a Work y proporciona únicamente los archivos, las aplicaciones, las sesiones de navegador o las cuentas conectadas que requiere la tarea.

Comprueba que las acciones aprobadas se puedan realizar, que las acciones restringidas se bloqueen y que los registros disponibles cubran tus necesidades de monitoreo. Pide al usuario que revise los resultados y confirme que los cambios en los archivos o sistemas conectados correspondan a lo solicitado.