ChatGPT y Codex ya corren en Bedrock en GovCloud. La guía no autoriza su carga de trabajo

Para una agencia federal o un contratista de defensa, la primera pregunta sobre una herramienta de IA para programar rara vez es “¿es buena?”. Es “¿a dónde va el prompt?”. El prompt de un desarrollador puede contener código fuente, nombres de sistemas y datos que no pueden salir de un perímetro aprobado. Hasta que haya una respuesta limpia, la herramienta se queda fuera de la lista de aprobados.

AWS publicó una de esas respuestas el 30 de octubre: una configuración que dirige la inferencia de modelos desde la aplicación de escritorio de ChatGPT, incluido su modo Work para tareas de varios pasos, y desde el agente de programación Codex, hacia Amazon Bedrock en AWS GovCloud (US), usando la Responses API en la región US-West.

Qué hace la configuración

La configuración tiene tres partes, y cada una es un control conocido, no uno nuevo.

Identidad. El inicio de sesión funciona solo en modo API. La aplicación se autentica con una clave de API de Bedrock o mediante la cadena de credenciales del SDK de AWS, que incluye el inicio de sesión único a través de IAM Identity Center. En este modo, gobiernan el acceso la identidad y las políticas de dispositivo de AWS, no los roles habituales del espacio de trabajo de ChatGPT.

Configuración bajo gestión. Dos archivos controlan la aplicación: un archivo de usuario y un archivo de administrador que fija los requisitos. Ambos deben estar en su sitio antes del primer arranque, lo que implica distribuirla mediante la gestión de dispositivos y no desarrollador por desarrollador.

Red. La aplicación queda restringida al endpoint aprobado de Bedrock, con el resto de conexiones externas desactivadas. AWS afirma que se admite la retención cero de datos, es decir, que AWS no escribe los prompts ni las respuestas en almacenamiento duradero ni los comparte con los proveedores de modelos.

El precio es por token, sin licencias por puesto, lo que traslada la conversación de compras de licencias a consumo. La aplicación funciona en Windows, Linux y macOS, con integraciones de IDE para VS Code, JetBrains y Xcode.

Qué no resuelve

AWS es inusualmente directo sobre los límites, y esos límites son lo importante.

No autoriza nada. La publicación afirma que usar GovCloud y seguir la guía no autoriza por sí mismo una carga de trabajo. La organización sigue siendo responsable de su revisión de seguridad y de autorización. Que GovCloud sea un entorno acreditado no hace que toda configuración de servicio dentro de él esté aprobada para un sistema concreto.

Cambiar un endpoint no es soporte. AWS señala que apuntar la aplicación a otra URL no demuestra que la configuración esté soportada. Los equipos deben confirmar la versión de escritorio soportada, el modelo y la región aprobados, y mantener esa combinación bajo control de cambios. Una actualización de escritorio que altere el comportamiento de red es un cambio en el perímetro.

Las funciones desactivadas son parte del trato. Restringir la aplicación a un solo endpoint implica que las funciones que llaman a otros servicios quedan apagadas. Ese es el objetivo, y conviene explicarlo a los desarrolladores antes del despliegue, o los primeros tickets de soporte pedirán excepciones.

Tres decisiones que pasan al equipo de plataforma

La arquitectura convierte la adopción de IA para programar en decisiones que un equipo de plataforma ya sabe tomar.

1. Qué endpoint es el perímetro. Un endpoint de inferencia aprobado, impuesto por política de red y configuración de dispositivo, sustituye a una lista de dominios de proveedores que hay que permitir.
2. Qué identidad lo llama. Conviene preferir la ruta de SSO a las claves de API estáticas, para que el acceso quede ligado a una persona, sea revocable y se registre en el mismo lugar que el resto de la actividad en la nube.
3. Quién aprueba los cambios de configuración. El archivo de administrador es ahora un artefacto de seguridad. Versiónelo, revise los cambios y registre qué versión ejecuta cada dispositivo.

Es la misma lección que sacamos cuando los mismos modelos de Claude llegaron a través de Azure y AWS con perímetros distintos: la vía de entrega es una decisión de gobernanza, a menudo mayor que el modelo. También añade un eslabón a la cadena de suministro de modelos que toda organización regulada debería mapear. Aquí el fabricante del modelo, el operador de nube y el proveedor de la aplicación cliente controlan cada uno una parte de la ruta.

Para los compradores regulados fuera del gobierno, el patrón se traslada tal cual. Un banco o una farmacéutica que ya tenga aprobada una región de nube, por ejemplo AWS Europe (Spain), puede aplicar los mismos tres controles, aunque antes tendrá que comprobar si los modelos y las API que necesita se ofrecen en esa región. La guía da la configuración. La autorización, como dice AWS, sigue siendo trabajo del cliente.