El cambio alcanza chat, edición, modos ask y agent, y completado de código. GitHub sugiere seis reemplazos, pero su activación automática depende de la configuración del administrador.

Seis retiros con una fecha común

GitHub retirará seis modelos de todas las experiencias de Copilot el 19 de octubre de 2026. El anuncio oficial, publicado el 18 de septiembre sin una hora visible, pide actualizar flujos e integraciones antes de esa fecha.

La lista exacta incluye Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini y Grok 4.5. GitHub recomienda estas migraciones:

| Modelo que se retira | Alternativa sugerida | | --- | --- | | Gemini 3.7 Flash | Gemini 3.8 Flash | | GPT-5.5 | GPT-5.6 Sol | | GPT-5.4 | GPT-5.6 Sol | | GPT-5.4 mini | GPT-5.6 Luna | | GPT-5 mini | GPT-5.6 Luna | | Grok 4.5 | Grok 4.6 |

La medida no queda limitada al selector de Copilot Chat. GitHub dice que alcanza Copilot Chat, las ediciones en línea, el modo *ask*, el modo *agent* y las sugerencias o completados de código. Por eso, un equipo puede verse afectado incluso si sus integrantes no eligen manualmente un modelo durante una conversación.

GitHub también aclara que no hace falta una acción para quitar los modelos después del retiro. Esa parte del cambio será automática. Lo que sí requiere atención es asegurar que las alternativas apropiadas estén habilitadas y que los flujos que dependían de un modelo específico funcionen como se espera.

La activación automática no es universal

Para clientes Copilot Business y Copilot Enterprise, las alternativas sugeridas se habilitan automáticamente bajo la configuración predeterminada de modelos, siempre que un administrador no haya desactivado el valor global ni bloqueado explícitamente el modelo. Si la organización apagó la habilitación predeterminada, el administrador deberá permitir cada alternativa mediante las políticas de modelos en la configuración de Copilot.

Ese matiz importa porque dos organizaciones con el mismo plan pueden llegar al 19 de octubre en situaciones diferentes. Una puede ver los reemplazos sin intervención y otra puede conservar políticas restrictivas que impidan su aparición. No alcanza con suponer que “GitHub hará la migración”: conviene revisar la configuración real del entorno.

Una alternativa sugerida tampoco es una promesa de equivalencia exacta. Los modelos pueden comportarse de forma distinta al completar código, interpretar instrucciones, usar herramientas o producir explicaciones. El anuncio establece una ruta recomendada, pero no asegura que el resultado, la latencia, el consumo o la calidad sean idénticos para cada repositorio y tarea.

Qué revisar antes del 19 de octubre

El primer paso es inventariar dónde aparece cada modelo. Revisá configuraciones del editor, instrucciones internas, documentación de incorporación, automatizaciones y cualquier integración que identifique un modelo por nombre. No limites la búsqueda al chat: el retiro cubre también ediciones, agentes y completado.

Después, verificá las políticas de la organización. En Copilot Business o Enterprise, confirmá si está activo el valor predeterminado global y si las alternativas fueron deshabilitadas de forma explícita. Si tu empresa restringe modelos por seguridad, cumplimiento o contrato, documentá quién puede aprobar el cambio. GitHub indica que los clientes Enterprise con dudas pueden contactar a su equipo de cuenta.

La migración debería probarse con tareas representativas, no solamente con una consulta genérica. Elegí ejemplos de los lenguajes, repositorios y niveles de riesgo que tu equipo usa de verdad: completar una función, explicar código heredado, proponer una refactorización, generar pruebas y ejecutar un flujo en modo agent. Compará exactitud, cambios innecesarios, citas de archivos y cumplimiento de instrucciones.

También conviene revisar los controles posteriores. Todo código sugerido por un asistente requiere pruebas, análisis estático y revisión humana según el riesgo. Si el nuevo modelo es más capaz, eso no elimina la posibilidad de errores. Si responde con mayor confianza, el equipo puede incluso necesitar reforzar la disciplina para no aceptar cambios sin inspección.

Un cambio operativo, no solo una actualización de catálogo

Las empresas suelen tratar el selector de modelos como una preferencia individual, pero Copilot ya participa en distintos puntos del ciclo de desarrollo. Cuando un modelo desaparece, pueden cambiar el estilo de las sugerencias, la forma de seguir instrucciones del repositorio o el desempeño en tareas largas. En modo agent, donde el sistema puede proponer y ejecutar varias acciones, una variación pequeña puede amplificarse a lo largo del flujo.

Por eso vale la pena registrar una línea base antes del corte. Guardá un conjunto reducido de tareas de evaluación y medí criterios útiles para tu organización: porcentaje de pruebas que pasan, archivos modificados sin necesidad, vulnerabilidades introducidas, tiempo de revisión y correcciones humanas. No necesitás construir un laboratorio complejo; una batería estable ayuda a distinguir una impresión subjetiva de un cambio repetible.

Los responsables de seguridad deberían confirmar además las políticas de uso de datos y los proveedores permitidos. La lista de retiros reúne modelos de Google, OpenAI y xAI, y las alternativas permanecen distribuidas entre esas familias. La recomendación técnica de GitHub no sustituye la aprobación interna de un proveedor o una versión.

Qué significa para equipos de Paraguay y América Latina

El anuncio no establece una condición específica para Paraguay. Su impacto depende de que una persona u organización use GitHub Copilot y tenga acceso a los modelos involucrados. Para equipos regionales que trabajan con clientes internacionales, el riesgo más inmediato es que una configuración administrada cambie el comportamiento de herramientas compartidas en medio de un proyecto.

Si administrás Copilot, avisá la fecha con anticipación y nombrá a una persona responsable de verificar políticas. Si sos usuario, preguntá qué reemplazo estará habilitado y evitá esperar al día del retiro para probarlo. En equipos pequeños, una hoja breve con modelo anterior, alternativa, casos probados y resultado puede ser suficiente.

También es una oportunidad para reducir dependencias frágiles. Las instrucciones de un repositorio deberían describir el resultado y los controles esperados, no asumir rasgos exclusivos de una versión concreta. Los flujos críticos necesitan pruebas automatizadas y puntos de aprobación que sigan funcionando aunque cambie el modelo.

Qué conviene observar ahora

La documentación de modelos compatibles es la referencia que conviene revisar hasta la fecha de corte, porque el catálogo puede seguir cambiando. Confirmá allí la disponibilidad y no des por hecho que una captura o una lista interna antigua sigue vigente.

El dato central es preciso: seis modelos salen el 19 de octubre y GitHub enumera seis sustituciones recomendadas. La tarea pendiente para cada organización es comprobar que sus políticas permitan esas alternativas y que su comportamiento sea aceptable en el trabajo real. El retiro será automático; una migración confiable no lo es.

Fuentes