La IA, en tu trabajo.

Qué cambia

GitHub anunció el 19 de octubre la disponibilidad general de operaciones GET y PATCH para consultar y modificar políticas de modelos de Copilot en cuatro ámbitos: empresa, equipos empresariales, aplicaciones de agentes y organización. El anuncio permite plantear una administración automatizada de esas decisiones. Anuncio de GitHub.

Para los responsables de proyecto, la cuestión práctica es cómo convertir una decisión sobre modelos en un cambio identificable: quién lo solicita, quién puede ejecutarlo y cómo se comprueba su efecto. Esa es la lectura editorial de Nexo.

Quién decide y qué sigue en vista previa

La guía contempla Copilot Business y Enterprise. La empresa puede habilitar, bloquear o delegar modelos. El modo predeterminado delega en organizaciones; el modo por equipos sigue en vista previa opcional y desactiva los controles de modelos de las organizaciones. Los equipos no pueden contradecir una habilitación o bloqueo empresarial; sus concesiones se acumulan cuando una persona pertenece a varios. En ese modo, las políticas de aplicaciones se controlan desde la empresa. Gestión de disponibilidad.

Permisos y límites de la API

En empresa, equipos y aplicaciones, GitHub documenta propietarios empresariales o permisos `read_enterprise_ai_controls` y `write_enterprise_ai_controls`. Los tokens OAuth y personales clásicos requieren `read:enterprise` para consultar y `admin:enterprise` para modificar; los tokens de GitHub Apps, «Enterprise AI controls» con lectura o escritura. Los estados devueltos para equipos y aplicaciones no determinan por sí solos el acceso individual. Referencia de controles empresariales.

En organizaciones, GET y PATCH están disponibles para propietarios si la organización es independiente o la empresa no usa el modo por equipos. Los tokens clásicos/OAuth requieren `admin:org` o `repo`; los granulares, «Administration» con escritura, incluso para GET. Se aplican las restricciones SAML/OAuth. Las políticas heredadas quedan bloqueadas. Sin política explícita efectiva, rige el valor empresarial predeterminado cuando existe; en su defecto, el organizativo, solo para modelos elegibles. PATCH es atómico: si un cambio falla, ninguno se guarda. Referencia para organizaciones.

Una revisión antes de automatizar

Nexo propone empezar por un inventario revisable. Para cada cambio, conviene registrar el ámbito, la necesidad del proyecto, el responsable y el estado anterior. Así, la automatización puede ejecutar una decisión ya entendida por quienes responden de ella.

Una secuencia de trabajo razonable sería:

• Consultar la configuración y describir el cambio solicitado sin modificarla todavía.
• Revisar quién tiene autoridad sobre ese ámbito y qué personas podrían verse afectadas.
• Acordar el cambio, conservar el estado anterior y definir cómo recuperarlo.
• Tras aplicarlo, volver a consultar y comprobar el acceso con usuarios representativos, registrando el resultado.

Ejemplo ficticio: dos equipos, dos necesidades

Supongamos que una empresa quiere evaluar un modelo adicional. Los equipos y las decisiones de esta tabla son inventados; ilustran una propuesta de revisión, no una configuración ejecutada ni resultados observados.

Qué aporta al gobierno del proyecto

En este ejemplo, la conversación útil empieza por las tareas y las responsabilidades. Una petición como «necesitamos otro modelo» se vuelve evaluable cuando concreta para qué trabajo, durante cuánto tiempo y con qué criterio se mantendría el acceso.

La conclusión editorial es que la API puede integrarse en ese proceso de revisión. El éxito de una petición técnica debe acompañarse de una comprobación del efecto esperado y de un registro comprensible para el equipo.