El 26 de agosto de 2026 cambiará la forma en la que GitHub Copilot gestiona los modelos de IA no configurados. Analizamos las opciones Enabled everywhere, Disabled everywhere y Let organizations decide, y por qué esta configuración debería formar parte de la estrategia de gobernanza de IA de cualquier empresa.
Cuando hablamos de GitHub Copilot, solemos centrarnos en la productividad, la generación de código o en comparar qué modelo de inteligencia artificial responde mejor.
¿GPT, Claude, Gemini o algún modelo especializado en programación?
Sin embargo, desde una perspectiva de arquitectura empresarial, seguridad, cumplimiento y gobernanza de IA, existe una pregunta mucho más importante:
¿Qué ocurre cuando GitHub incorpora un nuevo modelo de IA y nadie en la organización lo ha revisado todavía?
El próximo 26 de agosto de 2026, GitHub cambiará la forma en la que se gestiona la disponibilidad de los modelos de IA no configurados en GitHub Copilot Business y GitHub Copilot Enterprise.
A partir de esa fecha, los nuevos modelos generalmente disponibles (GA) y los modelos GA existentes que continúen sin una configuración explícita heredarán la política denominada:
Default availability for released models
En otras palabras: en GitHub Copilot, no configurar un modelo también será una decisión de gobierno.
El riesgo que muchas organizaciones todavía no están viendo
La evolución de los modelos de inteligencia artificial es cada vez más rápida.
Constantemente aparecen nuevas versiones de GPT, Claude o Gemini, modelos especializados en desarrollo de software, modelos optimizados para razonamiento, modelos con diferentes costes, capacidades y políticas de tratamiento de datos, así como nuevas opciones de selección automática de modelos.
Esto plantea una cuestión relevante para cualquier empresa que utilice GitHub Copilot:
¿Queremos que cada nuevo modelo esté disponible automáticamente para nuestros desarrolladores o preferimos revisarlo antes de permitir su uso?
No existe una única respuesta correcta.
Una startup puede priorizar la velocidad de adopción. Una entidad financiera, una administración pública o una empresa de un sector regulado probablemente necesitará aplicar controles preventivos.
El problema no es utilizar nuevos modelos.
El problema es hacerlo sin saber quién los ha autorizado, con qué criterios y bajo qué políticas de seguridad y cumplimiento.
Cómo funciona Default availability for released models
La política Default availability for released models controla qué sucede con los modelos GA que no hayan sido configurados explícitamente.
Actualmente, los administradores ya pueden establecer esta política, aunque su comportamiento automático comenzará a aplicarse el 26 de agosto de 2026.
Desde ese momento:
- Los nuevos modelos GA se considerarán inicialmente no configurados.
- Los modelos GA existentes que sigan sin configuración también heredarán la política.
- En la interfaz aparecerán identificados como inherits default.
- Los modelos habilitados o deshabilitados explícitamente mantendrán su configuración.
En el nivel Enterprise, GitHub ofrece tres opciones de gobierno.
Opción 1: Enabled everywhere
Máxima velocidad de adopción
Con Enabled everywhere, los modelos GA nuevos o existentes que permanezcan sin configurar heredarán automáticamente el estado habilitado.
Las organizaciones no podrán anular esta política desde su propio nivel.
Ventajas
- Acceso rápido a nuevos modelos de GitHub Copilot.
- Menor carga administrativa.
- Los desarrolladores pueden probar nuevas capacidades sin esperar una aprobación manual.
- Mayor velocidad de innovación y experimentación.
Riesgos
- Menor control preventivo.
- Los modelos podrían estar disponibles antes de completar una evaluación interna.
- La revisión de seguridad, coste o cumplimiento podría realizarse después de la activación.
- Puede no ser adecuada para organizaciones con requisitos regulatorios estrictos.
Es una opción orientada a la agilidad, pero necesita acompañarse de monitorización, auditoría y un proceso rápido de revisión posterior.
Opción 2: Disabled everywhere
Máximo control preventivo
Con Disabled everywhere, los modelos GA que no hayan sido configurados explícitamente permanecerán deshabilitados.
Esto significa que un nuevo modelo no podrá utilizarse hasta que un administrador lo revise y permita de forma expresa.
Ventajas
- Control previo sobre los modelos disponibles.
- Menor riesgo de adopción no evaluada.
- Facilita la aplicación de procesos de seguridad y cumplimiento.
- Adecuada para sectores regulados o entornos con políticas estrictas.
Inconvenientes
- Mayor carga administrativa.
- Posibles retrasos en la adopción de nuevas capacidades.
- Riesgo de generar burocracia si no existe un proceso de aprobación ágil.
- Los desarrolladores pueden quedarse temporalmente sin acceso a modelos útiles.
Esta opción no debería significar simplemente «bloquear por defecto».
Debería ir acompañada de un proceso claro para evaluar y aprobar nuevos modelos en un plazo razonable.
Opción 3: Let organizations decide
Un modelo de gobierno federado
Con Let organizations decide, el Enterprise delega en cada organización la decisión sobre la disponibilidad por defecto de los modelos.
Esto permite aplicar políticas diferentes según el contexto, el nivel de riesgo o las necesidades de cada área.
Por ejemplo:
- Una organización de ingeniería podría permitir nuevos modelos con mayor rapidez.
- Finanzas podría exigir una evaluación previa.
- Un área que gestione datos sensibles podría mantenerlos deshabilitados por defecto.
- Un equipo de innovación podría utilizarlos inicialmente dentro de un entorno controlado.
Para grandes empresas con múltiples unidades de negocio, esta suele ser una alternativa flexible porque combina una estrategia corporativa común con autonomía local.
Sin embargo, existe un matiz importante: los usuarios que reciben GitHub Copilot directamente desde el Enterprise, y no mediante una organización, no están cubiertos por Let organizations decide.
Para ellos existe una configuración independiente denominada Policies for enterprise-assigned users.
No debemos confundir la política general con la configuración de cada modelo
GitHub Copilot permite gobernar los modelos desde dos capas relacionadas, pero diferentes.
1. Política de disponibilidad por defecto
Default availability for released models establece qué sucede con los modelos GA que continúan sin configurar.
Sus opciones en el nivel Enterprise son:
- Enabled everywhere
- Disabled everywhere
- Let organizations decide
2. Configuración individual de cada modelo
Además, cada modelo concreto puede tener uno de estos estados en el Enterprise:
- Enabled: disponible para todos.
- Disabled: bloqueado explícitamente para todos.
- Optional: puede habilitarse para organizaciones o equipos específicos.
Cuando un modelo se configura como Optional, cada organización puede decidir si lo habilita o lo deshabilita.
Si una organización no toma ninguna decisión sobre ese modelo, heredará su política Default availability for released models.
Esta combinación permite crear una estrategia mucho más granular:
- Una base común de modelos aprobados para toda la empresa.
- Modelos bloqueados por razones de seguridad o cumplimiento.
- Modelos opcionales para determinadas organizaciones.
- Diferentes niveles de acceso según las necesidades del negocio.
¿Qué modelos no se habilitan automáticamente?
La política no significa que cualquier modelo publicado por GitHub pueda activarse automáticamente.
GitHub excluye de la habilitación automática:
- Modelos deshabilitados explícitamente.
- Modelos que todavía se encuentren en fase Pre-GA.
- Determinados modelos open weight.
- Modelos no cubiertos por el acuerdo de retención de datos de GitHub.
- Modelos incompatibles con las restricciones de residencia de datos o FedRAMP establecidas por el Enterprise.
En su documentación actual, GitHub menciona como ejemplos de modelos open weight excluidos a DeepSeek y Kimi K2.7 Code.
Esta lista puede evolucionar a medida que cambie el catálogo de GitHub Copilot.
Estas exclusiones aportan una capa adicional de protección, pero no sustituyen el proceso interno de evaluación de cada organización.
La conversación real no es GPT contra Claude
Muchas conversaciones sobre GitHub Copilot siguen centrándose únicamente en:
- ¿Qué modelo genera mejor código?
- ¿Cuál razona mejor?
- ¿Cuál responde más rápido?
- ¿Cuál tiene más contexto?
Todas estas preguntas son relevantes, pero para arquitectos, CISOs, responsables de plataforma y equipos de cumplimiento hay otras mucho más importantes:
- ¿Quién puede aprobar un nuevo modelo?
- ¿Qué criterios deben evaluarse antes de habilitarlo?
- ¿Qué datos pueden enviarse al proveedor?
- ¿Qué políticas de retención y residencia de datos se aplican?
- ¿Cuál es el impacto económico del modelo?
- ¿Cómo se auditan los cambios de configuración?
- ¿Qué áreas pueden experimentar y cuáles necesitan aprobación previa?
- ¿Quién revisa periódicamente los modelos que continúan habilitados?
Eso es AI Governance aplicada al desarrollo de software.
Qué deberían hacer las empresas antes del 26 de agosto de 2026
Las organizaciones que utilicen GitHub Copilot Business o GitHub Copilot Enterprise deberían realizar, al menos, estas acciones:
- Revisar la política Default availability for released models.
- Identificar qué modelos continúan sin configuración explícita.
- Decidir si la postura corporativa será abierta, restrictiva o federada.
- Definir quién puede aprobar o bloquear modelos.
- Establecer criterios de seguridad, privacidad, coste y cumplimiento.
- Documentar excepciones para organizaciones o equipos concretos.
- Revisar los permisos de quienes pueden modificar las políticas.
- Utilizar el registro de auditoría para controlar cambios y evitar desviaciones.
GitHub también recomienda revisar periódicamente quién tiene acceso a estas políticas y utilizar los registros de auditoría para detectar cambios o posibles desviaciones en la postura de gobierno.
Gobernar la IA no significa frenar la innovación
Una buena estrategia de gobernanza no debería convertirse en una barrera para los desarrolladores.
Tampoco debería consistir en habilitar automáticamente cada novedad sin realizar ninguna evaluación.
El objetivo es encontrar un equilibrio entre innovación, autonomía, seguridad, cumplimiento y control.
Porque gobernar los modelos de IA no consiste únicamente en decidir cuáles se permiten o se bloquean.
Consiste en saber quién toma esa decisión, con qué criterios, para qué usuarios y bajo qué nivel de riesgo.
Y con el crecimiento del catálogo de modelos de GitHub Copilot, esta conversación dejará de ser opcional para convertirse en una capacidad estratégica dentro de cualquier organización que adopte inteligencia artificial en el ciclo de desarrollo.
#GitHubCopilot #AIGovernance #GitHub #ArtificialIntelligence #Cybersecurity #CloudArchitecture #SoftwareDevelopment #EnterpriseAI #Compliance #DeveloperExperience