GitHub Models znika 30 lipca: plan migracji AI
GitHub Models zostanie wyłączony 30 lipca 2026. Sprawdź zakres zmiany i przeprowadź bezpieczną migrację API, modeli, testów i sekretów.
- AUTOR
- Karol Rapacz / CEO, Pentester (OSCP, PNPT)
- PUBLIKACJA
- 18 lipca 2026
- CZAS CZYTANIA
- 14 min czytania
- TEMAT
- AI w firmie
GitHub Models zostanie całkowicie wyłączony 30 lipca 2026 roku. Znikną playground, katalog modeli, inference API, endpointy BYOK i powiązany interfejs. Zmiana obejmuje również obecnych klientów z aktywnym użyciem. Dla aplikacji produkcyjnej nie jest to zwykła wymiana adresu URL — zmieniają się tożsamość, katalog modeli, limity, filtrowanie treści, obserwowalność i odpowiedzialność operacyjna.
Oficjalny komunikat GitHub podaje dwa testowe brownouty: 16 i 23 lipca. Pierwszy już minął, drugi jest ostatnią kontrolowaną okazją, aby zobaczyć, które procesy nie mają fallbacku. GitHub wskazuje Microsoft Foundry dla aplikacji wymagających dostępu do modeli oraz GitHub Copilot dla workflow bezpośrednio w GitHubie.
Co dokładnie przestanie działać
Po 30 lipca niedostępne będą:
- playground do ręcznego testowania promptów;
- katalog modeli i jego interfejs;
- inference API dla chat completion i powiązanych operacji;
- bring your own key (BYOK);
- endpointy i UI używane przez dotychczasowych klientów.
Dokumentacja REST API GitHub Models pokazuje, że aplikacje mogły korzystać z hosta models.github.ai, identyfikatorów w formacie publisher/model_name, tokenów GitHub z uprawnieniem models:read, streamingu i tool calls. Każdy z tych elementów może mieć inny odpowiednik u nowego dostawcy. Mechaniczne zastąpienie base URL nie wystarczy.
Najpierw odróżnij GitHub Models od GitHub Copilot
GitHub Models był platformą katalogu i inferencji dla własnych aplikacji oraz eksperymentów. GitHub Copilot jest produktem wspierającym tworzenie oprogramowania w edytorze, CLI i workflow GitHuba. Jeśli aplikacja backendowa wywołuje models.github.ai, migracja do Copilota zwykle nie jest odpowiednikiem jeden do jednego.
Zbuduj listę konsumentów na podstawie kodu, sekretów, proxy i rachunków. Szukaj:
- hosta
models.github.aii dawnych endpointów Azure inference; - scope
models:readw tokenach, GitHub Apps i workflow; - nazw modeli z ukośnikiem wydawcy;
- bibliotek klienta i zmiennych
GITHUB_TOKEN,GITHUB_MODELS_*; - notebooków, skryptów ewaluacyjnych, demo i testów CI;
- narzędzi BYOK i konfiguracji organizacji;
- dashboardów oraz alertów zależnych od kodów odpowiedzi GitHuba.
Nie ograniczaj wyszukiwania do repozytoriów aplikacji. Playground mógł stać się nieformalnym procesem biznesowym, a notebook analityka mógł używać produkcyjnych danych. Takie zależności należy wpisać do rejestru modeli i systemów AI.
Dlaczego migracja modelu zmienia zachowanie systemu
Nawet gdy nowy endpoint implementuje API zgodne ze stylem OpenAI, wynik może się różnić. Modele inaczej interpretują system prompt, JSON Schema, kolejność narzędzi, temperaturę i limity. Mogą mieć inne filtry bezpieczeństwa, format błędu, zakończenia, tokenizację oraz zasady przechowywania danych.
Zmiana platformy wpływa na co najmniej siedem kontraktów:
| Kontrakt | Co trzeba porównać |
|---|---|
| transport | base URL, TLS, proxy, streaming, timeout |
| uwierzytelnianie | PAT/GitHub App vs Entra ID lub API key |
| model | nazwa, wersja, kontekst, modalności i region |
| payload | wspierane pola, tool calls, response format |
| bezpieczeństwo | content filters, prywatność, retencja i DLP |
| operacje | limity, retry, quota, SLA i monitoring |
| jakość | poprawność, koszt, opóźnienie i regresje procesu |
Bez testów kontraktowych aplikacja może „działać” i jednocześnie zwracać inny JSON, pomijać tool call lub obcinać długi kontekst. Migrację trzeba traktować jak zmianę krytycznej zależności, nie aktualizację kosmetyczną.
Czy Microsoft Foundry jest automatycznym zamiennikiem
GitHub rekomenduje Microsoft Foundry, ale organizacja nadal musi sprawdzić dostępność konkretnego modelu, region, warunki dostawcy, filtrowanie oraz koszt. Dokumentacja endpointów Microsoft Foundry opisuje wdrożenia modeli, pojedynczy endpoint i możliwość uwierzytelniania bez klucza przez Microsoft Entra ID.
Foundry używa nazw wdrożeń. Wdrożenie wiąże model, wersję, typ pojemności, konfigurację filtrowania i limity. Ta nazwa jest kontraktem aplikacji, dlatego nie ustawiaj jej na niejednoznaczne latest. Zapisz model i wersję w konfiguracji oraz telemetrii.
Dokumentacja ostrzega również, że beta SDK Azure AI Inference zostanie wycofany 26 sierpnia 2026 roku i zaleca stabilne OpenAI/v1 API. Migracja z GitHub Models do starego, odchodzącego SDK stworzyłaby kolejną pilną migrację miesiąc później. Wybierz interfejs o potwierdzonym cyklu życia.
Plan migracji w sześciu etapach
Etap 1: inwentaryzacja i właściciele
Dla każdego klienta zapisz repozytorium, środowisko, właściciela, model, średni i szczytowy ruch, dane, narzędzia, wymagany region oraz skutek niedostępności. Oznacz aplikacje produkcyjne, eksperymenty i zasoby do usunięcia. Brak właściciela powinien zatrzymać automatyczną migrację i uruchomić decyzję o wycofaniu.
Etap 2: nowy kontrakt i adapter
Oddziel kod biznesowy od SDK dostawcy. Własny interfejs powinien przyjmować ustandaryzowane wiadomości, narzędzia, deadline, budżet i identyfikator zadania. Adapter tłumaczy je na endpoint GitHuba lub Foundry. Pozwala to uruchomić tryb dual-run i później zmienić dostawcę bez przepisywania całej aplikacji.
Jeżeli organizacja już używa LLM gateway, migracja może być zmianą routingu. Trzeba jednak sprawdzić, czy gateway nie ukrywa różnic w błędach oraz content filtering.
Etap 3: tożsamość i sekrety
GitHub Models używał tokenów GitHub. Foundry wspiera Entra ID oraz klucze. Microsoft rekomenduje uwierzytelnianie bezkluczowe dla produkcji, ponieważ umożliwia RBAC i eliminuje długowieczny sekret z aplikacji. Klucze zapewniają prostszy start, ale dokumentacja wskazuje, że dają szeroki dostęp do zasobu i wymagają rotacji.
Użyj managed identity lub workload identity tam, gdzie jest to możliwe. Przydziel minimalną rolę tylko do inferencji. Usuń stare PAT-y dopiero po zakończeniu obserwacji rollbacku, ale ustaw konkretną datę ich unieważnienia. Proces wspiera zarządzanie sekretami Vault/KMS.
Etap 4: testy kontraktowe i ewaluacyjne
Testy kontraktowe sprawdzają kody odpowiedzi, streaming, timeout, retry, JSON, tool calls i obsługę limitów. Testy ewaluacyjne sprawdzają znaczenie wyniku: fakty, format, odmowy, cytowania, bezpieczeństwo i koszt. Użyj reprezentatywnego zestawu z procesu ewaluacji LLM.
Nie testuj wyłącznie „hello world”. Dodaj długi kontekst, polskie znaki, duże narzędzia JSON Schema, równoległe wywołania, anulowanie streamu, odpowiedzi 429/5xx, brak uprawnień i niepoprawny model. Sprawdź, czy retry nie wykonuje ponownie nieodwracalnej akcji.
Etap 5: dual-run, canary i rollback
Najpierw wykonuj żądania do nowego endpointu w trybie shadow na danych, które wolno tam wysłać. Porównuj wynik bez prezentowania go użytkownikowi. Następnie skieruj mały procent odwracalnych zadań do nowej platformy. Zwiększaj udział dopiero po spełnieniu progów jakości, kosztu i błędów.
Rollback nie może zależeć od GitHub Models po 30 lipca. Przygotuj drugi wspierany endpoint albo degradację funkcji, na przykład kolejkę do ręcznej obsługi. Brownout 23 lipca wykorzystaj jako test ciągłości, ale nie czekaj z pierwszym sprawdzeniem do tej daty.
Etap 6: usunięcie starej zależności
Po stabilizacji usuń endpointy, tokeny models:read, konfigurację BYOK, nieużywane SDK, alerty i dokumentację GitHub Models. Zaktualizuj runbook, diagram przepływu danych, DPIA lub rejestr ryzyka, jeśli zmienia się dostawca albo region. Zachowaj raport porównawczy i decyzję właściciela.
Test bezpieczeństwa przed przełączeniem
Nowy endpoint powinien przejść minimalny zestaw kontroli:
- dane poufne są blokowane lub redagowane zgodnie z polityką;
- tenant i projekt są poprawnie rozdzielone;
- tożsamość workloadu nie może zarządzać wdrożeniami;
- logi nie przechowują sekretów, pełnych promptów i danych osobowych bez podstawy;
- tool calls podlegają allowliście oraz zatwierdzeniu dla akcji zapisu;
- prompt injection z dokumentu nie zmienia reguł systemowych;
- timeout i retry nie powodują podwójnych transakcji;
- model oraz filtr treści są przypięte do wersji;
- ruch wychodzący korzysta z kontrolowanego DNS, proxy i TLS.
Ogólny model zagrożeń zawiera przewodnik bezpieczeństwa AI w firmie. Migracja jest dobrym momentem, aby naprawić wcześniejsze skróty, zamiast odtwarzać je u nowego dostawcy.
Obserwowalność po migracji
Zapisuj identyfikator zadania, dostawcę, wdrożenie modelu, wersję promptu, tokeny, koszt, opóźnienie, liczbę retry, tool calls, decyzję approval i ocenę wyniku. Nie polegaj na dashboardzie dostawcy jako jedynym źródle. Potrzebujesz własnego śladu pozwalającego porównać okres przed i po migracji.
Ustal SLO dla sukcesu zadań, nie tylko dostępności HTTP. Endpoint może zwracać 200, a model generować niepoprawny format. Wzorce instrumentacji opisuje artykuł observability agentów AI z OpenTelemetry.
Alerty powinny obejmować wzrost 401/403, 429, 5xx, timeoutów, kosztu na sukces, odsetka eskalacji i naruszeń polityki. Osobno monitoruj nieoczekiwaną zmianę modelu oraz filtrowania treści.
Najczęstsze błędy migracji
Pierwszy to zmiana URL bez testu modelu. Drugi — przeniesienie produkcji na API key zapisany w zmiennej repozytorium, mimo dostępnej tożsamości workloadu. Trzeci — wybór SDK, które samo ma bliski termin wycofania. Czwarty — brak budżetu na różnice tokenizacji i cache. Piąty — zależność rollbacku od usługi, która za kilka dni przestanie istnieć.
Szósty błąd to pominięcie procesów „tymczasowych”. Notebook i skrypt CI mogą przestać działać w krytycznym momencie. Siódmy — brak aktualizacji bezpieczeństwa łańcucha dostaw AI, gdy migracja dodaje nowe SDK, obraz i uprawnienia.
Harmonogram do 30 lipca
| Termin | Rezultat |
|---|---|
| 18–20 lipca | pełna inwentaryzacja, właściciele i wybór celu |
| 21–22 lipca | adapter, tożsamość, wdrożenia i testy kontraktowe |
| 23 lipca | weryfikacja podczas brownoutu i test degradacji |
| 24–26 lipca | shadow traffic, ewaluacja i testy bezpieczeństwa |
| 27–28 lipca | canary produkcyjny oraz obserwacja |
| 29 lipca | pełne przełączenie i niezależny rollback |
| 30 lipca | usunięcie zależności, tokenów i BYOK |
Nie planuj podstawowego przełączenia na ostatni dzień. Problemy z limitem regionu, zatwierdzeniem modelu, RBAC i filtrowaniem mogą wymagać czasu oraz decyzji innych zespołów.
Test wyłączenia przed terminem
Przed 30 lipca wykonaj kontrolowany test, w którym stary endpoint jest niedostępny dla wybranej aplikacji. Sprawdź, czy ruch przechodzi do nowego wdrożenia, alert trafia do właściwego dyżuru, a fallback nie omija polityk bezpieczeństwa. Test powinien obejmować również 429, timeout, niezgodny format odpowiedzi i niedostępność regionu, nie tylko poprawne żądanie demonstracyjne.
Zapisz czas wykrycia, czas przełączenia, utracone zadania i sposób ich ponowienia. Jeżeli procedura wymaga ręcznej zmiany sekretu przez jedną osobę, nadal istnieje ryzyko operacyjne. Celem jest udowodnienie, że po wyłączeniu GitHub Models aplikacja zachowuje kontrolowaną degradację, a nie tylko działa w idealnym scenariuszu podczas testu integracyjnego.
Decyzja na dziś
Dowód zakończenia powinien zawierać listę dawnych konsumentów, nowy endpoint i model, wynik testów, datę unieważnienia tokenów oraz właściciela rollbacku. Dopiero taki pakiet pozwala wykazać, że organizacja nie pozostawiła ukrytej zależności od wyłączanej usługi.
Jeśli logi, kod lub sekrety pokazują użycie GitHub Models, wyznacz właściciela i środowisko docelowe natychmiast. Wykorzystaj 23 lipca jako chaos test, a nie pierwsze ostrzeżenie. Migracja jest zakończona dopiero wtedy, gdy aplikacja ma nowy wspierany endpoint, przechodzi ewaluacje, posiada obserwowalność i nie przechowuje starych tokenów.
Potrzebujesz bezpiecznie przełączyć firmowe aplikacje AI? Skontaktuj się z BreachRoad — ocenimy przepływ danych, tożsamości, gateway, narzędzia, testy regresji i fallback przed wyłączeniem GitHub Models.
