Entre el 26 de agosto y el 2 de septiembre de 2026, GitHub modificó varios mecanismos de gobernanza de Copilot: política global de disponibilidad de modelos, retirada de modelos seleccionados, consideración de las exclusiones de contenido en la aplicación y la CLI, y definición de un modelo predeterminado a nivel de empresa o equipo. Considerados por separado, estos cambios parecen ajustes de administración. Juntos, muestran que la elección de un modelo se convierte en un asunto de cartera, datos y continuidad operativa.
Para recordar: autorizar «Copilot» ya no basta. Una organización debe decidir qué modelos están disponibles, para qué equipos, sobre qué datos, con qué garantías y hasta qué fecha. Los valores heredados por defecto deben distinguirse de las decisiones explícitas, y cada retirada de modelo debe activar pruebas de no regresión.
1. Por qué los múltiples modelos cambian la gobernanza
Un asistente de código se percibía inicialmente como un producto relativamente homogéneo: una interfaz, un proveedor y una política central. Las plataformas ofrecen ahora varios modelos, a veces de editores distintos, con características diferentes de coste, rendimiento, licencia y tratamiento de datos.
El modelo interviene en contextos diversos: completado local, conversación, edición de varios archivos, agente autónomo, revisión de código o CLI. Una autorización adecuada para redactar una prueba no lo es necesariamente para un agente que explora un repositorio, ejecuta comandos y propone una pull request.
Esta diversidad aporta flexibilidad. Un equipo puede utilizar un modelo rápido para las interacciones habituales y uno más avanzado para una migración compleja. Pero también crea decisiones implícitas. Un nuevo modelo puede resultar accesible porque hereda una política global; un modelo favorito puede desaparecer; un ajuste de confidencialidad puede aplicarse en el IDE pero aún no en otra superficie.
Por tanto, la gobernanza debe abarcar la combinación modelo + funcionalidad + datos + equipo + versión, y no solo el nombre del producto.
2. Comprender los cuatro estados de política de GitHub
GitHub anunció el 26 de agosto la disponibilidad general de su política global para modelos Copilot, con un despliegue gradual hasta el 1 de septiembre. Los modelos de disponibilidad general que no se hubieran configurado explícitamente pueden seguir el estado de esta política.
La administración distingue cuatro situaciones: activado explícitamente, desactivado explícitamente, delegado a un equipo u organización y delegado a la política predeterminada. Este último valor es dinámico: si la política global cambia, todos los modelos que la siguen cambian con ella.
El matiz es esencial para la auditoría. Dos modelos visibles como disponibles pueden proceder de decisiones muy distintas. El primero fue evaluado y activado; el segundo apareció por herencia. Por ello hay que registrar el origen de la decisión y no considerar el estado efectivo como prueba de aprobación.
GitHub precisa que las elecciones explícitas se conservan. También indica que los modelos de pesos abiertos y los que no están cubiertos por su acuerdo de conservación de datos se desactivan por defecto en este mecanismo. Esta protección es un punto de partida, no una política completa: la organización debe seguir verificando las condiciones aplicables, las regiones, las funcionalidades y sus propios compromisos con los clientes.
Una buena práctica consiste en desactivar la activación automática en ámbitos sensibles y exigir una decisión explícita para cada modelo nuevo. En entornos menos críticos, la herencia puede seguir autorizada con una revisión automática y una notificación a los responsables.
3. Abordar la confidencialidad a nivel del contenido
El 2 de septiembre, GitHub anunció que la aplicación Copilot y Copilot CLI ya respetaban las políticas de exclusión de contenido configuradas a nivel de empresa, organización y repositorio para las ofertas Business y Enterprise. Los archivos excluidos no deben utilizarse como contexto en estos flujos de trabajo.
Esta función permite proteger secretos, código sujeto a restricciones contractuales, datos propietarios o directorios cuyo uso por un asistente no está autorizado. Sin embargo, no sustituye los controles de acceso. Un desarrollador o agente que puede leer un archivo sigue pudiendo copiarlo en otra superficie, resumirlo manualmente o exponerlo a una herramienta externa.
Por tanto, la exclusión debe formar parte de una estrategia más amplia: clasificación de repositorios, separación de secretos, reglas DLP, permisos mínimos y registro. También debe probarse en cada interfaz. No se debe suponer que una política anunciada para la aplicación y la CLI sea idéntica en todas las extensiones, integraciones o API.
Documente qué significa «excluido». La cuestión no es solo saber si el contenido entra en el prompt. Verifique las sugerencias, índices, cachés, registros, trazas de evaluación y posibles funciones de memoria. Los contratos y la documentación del editor siguen siendo la fuente de verdad.
Nuestro artículo sobre Zero Data Retention y Private Safety Processing detalla esta distinción entre conservación, entrenamiento, registro y controles de seguridad.
4. Preparar las obsolescencias como migraciones
El 31 de agosto, GitHub anunció la obsolescencia de varios modelos a partir del 1 de septiembre en la mayoría de las experiencias de Copilot. La lista incluía en particular versiones de Gemini, Claude y Raptor Mini, con alternativas sugeridas.
El plazo tan corto demuestra que el nombre de un modelo no debe codificarse de forma rígida sin una estrategia de sustitución. Un equipo que utiliza un modelo en instrucciones, automatizaciones, evaluaciones o ajustes empresariales puede sufrir una interrupción o un cambio silencioso de comportamiento.
Trate cada retirada como una migración de aplicación. Inventarie los usos, elija un candidato, repita las evaluaciones, mida la calidad y compruebe los costes. Los prompts pueden depender de un estilo de razonamiento, una ventana de contexto o un formato de salida. Sustituir un modelo por «el más parecido» no garantiza la equivalencia.
Añada una capa lógica entre el caso de uso y el nombre comercial. Por ejemplo, el perfil code-review-standard apunta a un modelo aprobado con una configuración determinada. El cambio de proveedor o de versión se realiza en el registro, sin modificar todos los flujos de trabajo.
Supervise los calendarios, pero prepare también la sustitución no planificada. Un modelo puede retirarse por motivos de seguridad, licencia o disponibilidad. Cada uso crítico debe disponer de una solución de respaldo probada y de un modo degradado explícito.
5. Definir modelos por equipo sin fragmentar la organización
El 2 de septiembre, GitHub anunció la posibilidad de definir un modelo predeterminado en los ajustes gestionados por la empresa, con valores distintos según los equipos, para la aplicación Copilot, la CLI y Visual Studio Code en las ofertas Business y Enterprise.
Esta granularidad es útil. Un equipo PHP puede priorizar un modelo eficiente en sus repositorios y tareas; un equipo de soporte puede buscar velocidad y coste; un equipo de seguridad puede exigir un modelo y una política más restrictivos.
El riesgo es la fragmentación. Si cada equipo elige sin un marco, la empresa deja de saber qué modelos procesan sus datos, las evaluaciones se multiplican y los incidentes se vuelven difíciles de reproducir.
Defina un catálogo breve. Dos o tres perfiles suelen cubrir la mayoría de las necesidades: interacción rápida, razonamiento complejo y contexto sensible. Los equipos solicitan una excepción cuando demuestran una necesidad medible. La excepción tiene un responsable, una fecha de vencimiento y un conjunto de evaluación.
El modelo predeterminado no es necesariamente el único autorizado. Representa la elección recomendada. La posibilidad de sustituirlo por el usuario depende del nivel de riesgo. En un repositorio público, la libertad puede ser amplia; en un producto regulado, el modelo y la superficie pueden imponerse.
6. Crear un registro de modelos y casos de uso
El registro constituye la fuente de verdad. Para cada modelo, conserve el proveedor, la versión, el estado de GitHub, las superficies disponibles, la política de datos, las regiones, el coste, la fecha de introducción, la fecha de revisión y el responsable interno.
Después relacione los casos de uso: completado, chat, agente, CLI, revisión, generación de pruebas o migración. Añada la clasificación de los datos, el nivel de autonomía, las herramientas accesibles, el modelo predeterminado y el modelo de respaldo.
Una línea de registro podría indicar: «revisión automática de repositorios internos no regulados; modelo A; solo sugerencias; contenido secreto excluido; aprobación humana obligatoria; evaluación mensual; respaldo al modelo B».
Este registro debe versionarse. Un archivo legible por máquina permite generar los ajustes gestionados, los cuadros de auditoría y las alertas de obsolescencia. Los cambios pasan por una pull request aprobada por los responsables de plataforma, seguridad y negocio cuando sea necesario.
Evite, sin embargo, convertir el registro en un catálogo teórico. Cada entrada activa debe corresponder a un uso observado. Los modelos no utilizados aumentan la superficie de gobernanza sin crear valor.
7. Probar la calidad, el coste y el riesgo antes de activar
Un benchmark general no basta para elegir un modelo de desarrollo. Construya un conjunto de evaluación a partir de tareas reales y anonimizadas: corrección específica, comprensión de un módulo, generación de pruebas, migración, revisión de seguridad y respeto de las convenciones.
Mida la tasa de éxito, los defectos introducidos, la calidad de la explicación, las llamadas a herramientas, el coste y la latencia. Verifique el comportamiento ante una instrucción presente en el repositorio, un archivo excluido, un secreto ficticio y una solicitud fuera de alcance.
Para los agentes, añada criterios de acción: ¿respeta la rama, los archivos autorizados, los comandos y los límites? El mejor modelo para generar código no es necesariamente el más controlable en un flujo de trabajo autónomo.
Repita el conjunto con cada nueva versión o cambio de superficie. Una actualización de GitHub puede modificar la orquestación alrededor del modelo, aunque el modelo siga siendo idéntico. Conserve los resultados y las configuraciones para explicar una evolución de calidad.
La activación sigue un despliegue gradual: equipo piloto, repositorios seleccionados, observación y después generalización. Los incidentes y los comentarios de los usuarios alimentan el registro y pueden llevar a volver al modelo anterior.
8. Establecer un ciclo trimestral de gobernanza
Cada trimestre, examine la lista de modelos disponibles, las decisiones heredadas, las exclusiones, los usos reales, los costes y las fechas de retirada anunciadas. Desactive los modelos no utilizados y renueve únicamente las excepciones justificadas.
Cada mes, supervise los changelogs de los proveedores y de GitHub. Un cambio material activa un análisis sin esperar a la revisión trimestral. La automatización puede abrir un ticket cuando un nombre del registro aparece en un anuncio de obsolescencia.
Antes de cada activación, exija una ficha breve: necesidad, datos, superficies, evaluación, coste, respaldo y responsable. Después de la activación, compruebe que los ajustes efectivos corresponden al registro. La diferencia entre la política declarada y la configuración real es un indicador prioritario.
Por último, comuníquese con los desarrolladores. Explique por qué ciertos modelos están disponibles, cómo informar de un problema y qué información nunca debe proporcionarse al asistente. Una gobernanza comprensible consigue mayor adhesión que una lista de restricciones sin contexto.
Conclusión
La multiplicación de modelos en GitHub Copilot aporta una capacidad útil de adaptación, pero transforma un ajuste de productividad en un sistema que hay que gobernar. Las políticas globales, las exclusiones de contenido, los valores por equipo y las obsolescencias deben tratarse conjuntamente.
Una organización sólida mantiene un registro versionado, explicita el origen de las decisiones, evalúa los modelos en sus tareas, prepara los reemplazos y verifica las protecciones de datos en cada superficie. Partitech acompaña el diseño de esta gobernanza, la automatización de los controles y la integración de Copilot en un enfoque DevSecOps medible.
Referencias verificadas el 3 de septiembre de 2026
- GitHub — «Global model policy generally available», 26 de agosto de 2026: https://github.blog/changelog/2026-08-26-global-model-policy-generally-available/
- GitHub — «Selected GitHub Copilot models deprecated», 31 de agosto de 2026: https://github.blog/changelog/2026-08-31-selected-github-copilot-models-deprecated/
- GitHub — «Content exclusions generally available in Copilot app and CLI», 2 de septiembre de 2026: https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli/
- GitHub — «Enterprise-managed settings support any default model», 2 de septiembre de 2026: https://github.blog/changelog/2026-09-02-enterprise-managed-settings-support-any-default-model/