martes, 27 de octubre de 2026
PortadaGitHubNoticia y análisis

GitHub abre la API de políticas de modelos de Copilot: automatizar no evita las herencias

GitHub permite leer y cambiar por API qué modelos admite Copilot en empresa, equipos, aplicaciones y organizaciones. La clave es resolver la herencia.

Una API distribuye políticas de modelos de Copilot entre empresa, equipos, aplicaciones y organizaciones conectadas.
Ilustración editorial generada con IA; representa la jerarquía de políticas y no reproduce la interfaz de GitHub.

GitHub ya permite consultar y modificar mediante REST las políticas que deciden qué modelos puede usar Copilot. Los endpoints están disponibles para empresas, equipos empresariales, aplicaciones empresariales y organizaciones. La automatización facilita mantener una regla; no elimina la necesidad de entender qué nivel manda.

El anuncio de GitHub declara disponibilidad general para operaciones GET y PATCH. Las rutas separan cuatro ámbitos: empresa, equipo, aplicación y organización. En modo de organización, la empresa puede delegar el control; en modo de equipos empresariales, puede delegarlo a equipos y aplicaciones.

Leer antes de cambiar

Una automatización segura debería empezar con GET, conservar la respuesta y comparar el estado deseado con el efectivo. Un PATCH directo basado en una plantilla antigua puede reactivar un modelo que un nivel superior había restringido o borrar una excepción válida.

Ámbito Ruta anunciada Riesgo operativo
Empresa /enterprises/{enterprise}/copilot/model-policies Cambio amplio no previsto
Equipo /enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies Confundir herencia con excepción
Aplicación /enterprises/{enterprise}/copilot/apps/model-policies Afectar integraciones distintas
Organización /orgs/{org}/copilot/model-policies Sobrescribir una delegación

El inventario importa cuando un modelo desaparece

La API llega el mismo día en que GitHub retiró seis modelos de la mayoría de experiencias de Copilot. Texploto ya explicó esa retirada en la URL publicada en septiembre; repetirla como noticia nueva sería duplicar intención. La novedad aquí es administrativa: poder detectar y corregir políticas por código.

Una comprobación útil puede registrar para cada ámbito el modelo permitido, el origen de la decisión y la fecha. Si un modelo deja de estar disponible, el informe debe distinguir «prohibido por política» de «retirado del producto»; ambos producen una ausencia en el selector, pero exigen respuestas diferentes.

Una automatización responsable conserva reversión

  1. Exportar el estado actual y resolver la jerarquía aplicable.
  2. Calcular un diff legible por personas antes del PATCH.
  3. Limitar el token a la administración necesaria y registrar quién aprobó el cambio.
  4. Volver a leer la política y comprobar el selector en una cuenta afectada.

GitHub no aporta en el anuncio una prueba independiente ni ejemplos completos de respuesta. El nivel de evidencia es documentación primaria. Texploto no ha llamado a estos endpoints; el flujo anterior es análisis operativo de su alcance, no una experiencia de uso.

Estas políticas también acotan los modelos entre los que puede elegir Auto. La guía de Efficiency, Balance e Intelligence muestra cómo comparar coste por tarea resuelta y registrar el modelo efectivo; elegir Intelligence no habilita un modelo excluido por el administrador.

Transparencia: artículo elaborado con asistencia de IA a partir de las fuentes enlazadas. No se ha ejecutado la API descrita.