Nyhet

GitHub Copilot rullar ut global modellpolicy: kontrollera vilka modeller som öppnas

En modell som ingen administratör har valt kan snart bli tillgänglig genom arv. För Copilot Business och Enterprise behöver du därför jämföra den effektiva modellistan före och efter utrullningen — inte bara leta efter nya uttryckliga beslut.

27 aug 2026

En stor profil uppbyggd av ljusa noder ser mot en person framför fyra gröna ljuspelare i ett mörkt rum.
Ett grönt slutläge visar inte om åtkomsten valts uttryckligt eller ärvts från standardpolicyn.

Kort sagt

GitHub började den 26 augusti gradvis verkställa en global standardpolicy för allmänt tillgängliga Copilot-modeller och anger att utrullningen fortsätter till den 1 september 2026. Tidigare okonfigurerade modeller kan då börja följa standardpolicyn. Exportera eller skriv av modellernas nuvarande lägen, skilj uttryckliga val från delegerade och kontrollera sedan samma vy igen när policyn har nått din enterprise eller organisation.

Det nya är arvet, inte ännu ett modellsläpp

GitHubs ändring gäller Copilot Business och Copilot Enterprise. Policyn Default availability for released models bestämmer om allmänt tillgängliga modeller utan ett uttryckligt administratörsbeslut ska vara aktiverade eller avstängda. När verkställandet når din organisation får sådana modeller läget Delegate to default policy. Är standardpolicyn aktiverad blir de tillgängliga för användarna; är den avstängd blir de inte det.

Det här är skilt från GitHubs separata modellavvecklingar. Där handlar arbetet om att ersätta namn som slutar fungera; här handlar det om att en tidigare neutral rad kan börja ärva ett levande standardbeslut. Om du också har modeller med stoppdatum finns den inventeringen i vår nyhet om de sex Copilot-modellerna som pensioneras den 1 september. Blanda inte de två listorna: en pensionerad modell räddas inte av policyn, och en nyöppnad modell är inte samma sak som en ersättare du har godkänt.

Utrullningen har inget gemensamt klockslag

GitHub säger att verkställandet rullas ut gradvis till den 1 september och träder i kraft vid olika tidpunkter för olika enterprises. Ett prov den 27 augusti kan därför visa det gamla läget hos en kund och det nya hos en annan. Behandla datumet som ett kontrollfönster och notera klockslag, enterprise och organisation för varje avläsning.

Inventera de fyra tillstånden

Efter utrullningen beskriver GitHub fyra lägen för en modell: uttryckligen aktiverad, uttryckligen avstängd, delegerad till organisationer eller enterprise-team och appar, samt delegerad till standardpolicyn. Det avgörande revisionsfältet är alltså inte bara ”på” eller ”av”, utan vem som äger beslutet. GitHub bevarar uttryckliga val; det är raderna utan ett sådant beslut som byter beteende.

Modell. Skriv det exakta namnet från vyn, en rad per modell.
Visat läge. Kopiera hela statusen, särskilt vilken nivå den delegerar till.
Effektiv åtkomst. Notera om en användare i målgruppen faktiskt kan välja modellen.
Beslutsägare och motiv. Ange vem som får ändra raden och länka till ditt godkännande eller din riskbedömning.

Ta den första avläsningen innan du ändrar något. I enterprisevyn går sökvägen enligt GitHubs dokumentation via AI controls, Copilot och Configure models. En skärmbild kan fungera som råbevis, men en tabell är bättre för diffen. Använd exempelvis kolumnerna model, displayed_state, effective_for_test_user, checked_at och decision_owner. Det gör ett ärvt läge synligt även när slutresultatet fortfarande råkar vara ”aktiverad”.

Kontrollera båda nivåerna

I GitHubs vanliga organisationsläge kan enterpriseägaren delegera en modell till organisationer. Organisationsägaren väljer då aktiverad eller avstängd; lämnas modellen okonfigurerad följer den organisationens egen standardpolicy. Läs därför enterprise- och organisationsraden tillsammans. En skärmbild som bara visar att enterprise har delegerat säger inte vilken åtkomst användaren får.

Enterprise-team är ett separat förhandsläge. Där avaktiveras organisationsinställningarna och teamens åtkomst läggs ovanpå enterprisebaslinjen. Ett team kan få ytterligare modeller, men kan inte slå på en modell som har stängts av på enterprisenivå. Skriv vilket kontrolläge din enterprise använder i inventeringen; annars går det inte att tolka samma ord, exempelvis ”delegerad”, på rätt nivå.

Gör ett före/efter-prov med samma identitet

  1. Välj en testanvändare vars enterprise, organisation och eventuella enterprise-team är kända.
  2. Dokumentera samtliga modellrader och standardpolicyn utan att ändra dem.
  3. Kontrollera vilka modeller samma användare ser i samma Copilot-klient.
  4. Upprepa efter att utrullningen nått miljön och jämför både status och faktisk modellväljare.

Undantagen ska inte smugglas in i en komplett lista

Standardpolicyn omfattar inte varje modell. GitHubs dokumentation undantar bland annat modeller före allmän tillgänglighet, öppenviktsmodeller och modeller som inte täcks av GitHubs avtal om datalagring. Om enterprisen har begränsat utbudet till modeller som följer krav på data residency eller FedRAMP undantas också modeller som inte uppfyller dessa krav. Kontrollera kategorierna mot den aktuella dokumentationen i stället för att kopiera dagens exempel till en permanent tillåtelselista.

Den praktiska fallgropen är att tolka ”inte automatiskt aktiverad” som ”uttryckligen förbjuden”. Det är två olika tillstånd och ska ha olika rader i beslutsloggen. Om en modell ska vara blockerad av säkerhets-, kostnads- eller kvalitetsskäl, sätt ett uttryckligt avstängt läge. GitHub säger att sådana explicita val bevaras när standardpolicyn verkställs.

Sätt en stoppregel för oavsiktlig åtkomst

Gör diffen till ett beslut, inte bara dokumentation. För varje nytillgänglig modell ska det finnas en beslutsägare och ett av tre utfall: godkänn åtkomsten uttryckligen, stäng av modellen uttryckligen eller tidsbegränsa granskningen med en ansvarig och ett datum. Lämna inte en känslig modell i delegerat läge bara för att den råkade vara avstängd när skärmbilden togs — Delegate to default policy följer senare ändringar av standardinställningen.

Om en ny modell godkänns behöver den fortfarande provas mot teamets faktiska arbetsflöde. Använd samma indata, verktygsbehörigheter och godkäntkriterier före och efter bytet. Vår guide om att kontraktstesta AI-integrationen innan modellen uppdateras visar hur du gör resultatet reproducerbart. För system där modellnamn ligger hårdkodade finns också guiden om reservmodell och abstraktionslager.

Före: spara standardpolicyn och alla modellstatusar med tid och scope.
Efter: markera varje rad som ändrats till delegerad och verifiera samma testanvändare.
Beslut: gör känsliga tillåtelser eller blockeringar uttryckliga så att de inte följer en framtida standardändring.
Bevis: spara diffen tillsammans med ansvarig, motiv och nästa granskningsdatum.

Källor

Uppgifterna kontrollerades mot GitHubs primärkällor den 27 augusti 2026. Modellutbud och policygränssnitt kan ändras; kontrollera därför den aktuella dokumentationen och den effektiva åtkomsten i din egen miljö.

Relaterad förändring
Sex Copilot-modeller försvinner 1 september