Copilot Auto nie oznacza zatwierdzenia jednego modelu przed każdym zapytaniem. W domyślnym trybie Auto Copilot sam dobiera model do zapytania, a w Cowork robi to z puli modeli dopuszczonych przez organizację. Microsoft opisuje Auto jako mechanizm, który przy każdym zapytaniu waży dokładność, szybkość i koszt, dobierając model i poziom rozumowania bez konieczności wyboru po stronie użytkownika. Nie oznacza to braku kontroli: administrator decyduje o dopuszczonych rodzinach modeli, użytkownik może w niektórych miejscach wybrać model ręcznie, Cowork pokazuje, który model wygenerował odpowiedź, a dzienniki audytu zapisują dostawcę modelu. Zmienia się jednak pytanie o walidację. Sprawdzenie jednego modelu nie jest sprawdzeniem procesu, w którym model może się różnić między kolejnymi zapytaniami.
Najważniejsze wnioski dla decydenta
✓ W trybie Auto firma zatwierdza produkt i pulę modeli, a nie model użyty w konkretnym zapytaniu.
✓ Kontrola działa na trzech poziomach: organizacja (dopuszczone modele), użytkownik (Auto albo konkretny model, gdzie interfejs na to pozwala), router (wybór w ramach puli).
✓ Identyfikowalność jest częściowa i zależy od powierzchni: Cowork pokazuje oznaczenie modelu, dzienniki audytu zawsze zapisują dostawcę, a zapis nazwy modelu zależy od scenariusza.
✓ Dla procesów, w których wynik wymaga walidacji, rozsądniej testować cały proces na dopuszczonej puli albo ustalić konkretny model, niż zakładać, że wynik testu jednego modelu przenosi się na Auto.
Co robi tryb Auto w Copilocie?
Auto to domyślny tryb Copilota, w którym system sam wybiera model do zapytania. Dokumentacja Copilot Chat mówi: „By default, Copilot uses a real-time router to adjust the underlying model it uses based on your prompt”, a strona o licencji na użytkownika dodaje, że Auto przy każdym zapytaniu waży dokładność, szybkość i koszt, dobierając model i poziom rozumowania.
Obok Auto Copilot Chat ma tryby „Quick response”, w którym priorytetem jest szybkość, oraz „Think deeper”, w którym używa modelu z głębszym rozumowaniem do pytań złożonych. Użytkownik wybiera je w selektorze w prawym górnym rogu interfejsu. Domyślnie jednak działa Auto, a więc w typowym użyciu to router, a nie człowiek, decyduje, który model obsłuży zapytanie.
Dla użytkownika to wygoda: nie musi znać różnic między modelami. Dla organizacji to zmiana w przedmiocie zatwierdzenia. Przy narzędziu z jednym modelem można było powiedzieć, że firma sprawdziła i dopuściła model X. Przy routerze firma dopuszcza produkt, który w ramach określonych zasad sam wybiera model do każdego zapytania.
Kto decyduje o modelu: organizacja, użytkownik czy router?
Decyzja o modelu jest rozłożona na trzy poziomy, a wynik zależy od całego systemu. Organizacja ustala, jakie modele są dostępne, użytkownik wybiera tryb albo konkretny model tam, gdzie interfejs na to pozwala, a router w trybie Auto wybiera model z dostępnej puli dla danego zapytania.
| Poziom | Co może się zmieniać | Kto decyduje | Źródło |
|---|---|---|---|
| Pula dostępnych modeli | skład puli wraz z ofertą dostawcy i konfiguracją organizacji | Microsoft i administrator | Learn, modele w Cowork (14.09.2026) |
| Tryb pracy | Auto, konkretny model albo tryb odpowiedzi | użytkownik, w granicach interfejsu | Learn, Copilot Chat (10.09.2026); Learn, modele w Cowork |
| Model dla konkretnego zapytania w Auto | dynamicznie, zapytanie po zapytaniu | router Copilota | Learn, Copilot Chat; Learn, licencja na użytkownika (25.09.2026) |
| Wynik | zależny od modelu, polecenia, kontekstu i narzędzi | cały system | interpretacja autora |
Tabela porządkuje poziomy decyzji na podstawie dokumentacji Microsoft Learn. Nie jest pomiarem.
Najwięcej szczegółów Microsoft podaje dla Cowork. Dokumentacja mówi: „When you select Auto, Cowork picks the model based on the models enabled by your organization”. Administrator może wyłączyć rodzinę modeli Anthropic w centrum administracyjnym, przy czym ustawienie działa dla całej dzierżawy i nie da się nim przyznać tych modeli tylko części użytkowników. Użytkownik może też wybrać konkretny model, a Cowork pamięta ten wybór na danym urządzeniu do czasu zmiany. W politykach wydatków dla Cowork działa dodatkowo profil modelu, czyli zestaw dostawców i modeli dostępnych w ramach polityki.
Dla Copilot Chat dokumentacja opisuje router i selektor trybów, ale w moim odczycie nie opisuje kontroli administratora nad modelami w tym samym zakresie co dla Cowork. Tam, gdzie opis kontroli jest skąpy, nie wnioskuję z milczenia, że kontroli nie ma, tylko że nie dotarłem do jej opisu.
Czy da się ustalić, który model odpowiedział?
Częściowo, i zależy to od miejsca. Cowork pokazuje w rozmowie oznaczenie modelu: „Cowork shows a model badge in the conversation so you can see which model produced a response”. Dzienniki audytu Microsoft Purview zapisują w każdym scenariuszu Microsoft 365 Copilot dostawcę modelu, natomiast zapis jego nazwy zależy od scenariusza.
Dokumentacja Purview mówi o tym w dwóch miejscach. Opis pola ModelTransparencyDetails podaje, że ModelProviderName występuje we wszystkich scenariuszach Microsoft 365 Copilot, a ModelName i ModelVersion są w tych scenariuszach niedostępne. W innym miejscu ta sama strona podaje, że dzienniki dla Microsoft Copilot i Copilot Chat zawierają dostawcę i nazwę modelu, a jako przykład pokazuje sytuację, w której użytkownik wybrał konkretny model zamiast Auto. Dla zapytań obsłużonych w trybie Auto dokumentacja wprost nie rozstrzyga, czy nazwa modelu zawsze trafi do dziennika.
Dzienniki te powstają w ramach Audit (Standard), więc przy włączonym audycie nie wymagają osobnej konfiguracji. Dla interfejsu Copilot Chat nie dotarłem do opisu, czy pokazuje on, który model wygenerował odpowiedź w trybie Auto.
Wniosek praktyczny: firma ma narzędzia do częściowej identyfikacji modelu, ale przed oparciem na nich procedury warto sprawdzić we własnej dzierżawie, co faktycznie trafia do dziennika dla zapytań w trybie Auto. To jest test, który administrator może wykonać w kilka minut, a który rozstrzyga więcej niż lektura dokumentacji.
Dlaczego walidacja jednego modelu nie jest walidacją procesu?
Bo w trybie Auto proces nie ma jednego modelu. Jeżeli firma sprawdziła jakość odpowiedzi na próbce zadań przy jednym modelu, wynik nie przenosi się automatycznie na sytuację, w której router dla podobnych zadań wybiera różne modele z puli, a sama pula zmienia się wraz z ofertą dostawców.
W finansach walidacja dotyczy procesu i jego wyników, a nie tylko pojedynczego komponentu. Jeśli w procesie zmienia się komponent, a proces wciąż ma dawać wynik w akceptowalnych granicach, test musi obejmować zakres zmienności tego komponentu. Tryb Auto wprowadza właśnie taką zmienność: nie w czasie, jak aktualizacja produktu, lecz w bieżącym działaniu, między kolejnymi zapytaniami.
Pula też nie stoi w miejscu. Strona Microsoftu o modelach w Cowork z 14 września 2026 wymienia siedem modeli trzech generacji. W dzienniku zmian API OpenAI między wydaniem GPT-6 Astra (3 września) a GPT-6.1 Sol (29 września) minęło niecałe cztery tygodnie. Nie każda nowa wersja trafia od razu do Copilota, ale tempo wydań pokazuje, że skład puli należy traktować jako zmienny.
Przykład hipotetyczny: dział kontrolingu w firmie produkcyjnej używa Copilota do przygotowania komentarza do odchyleń budżetowych. Przed wdrożeniem zespół sprawdził na dwudziestu przykładach, że odpowiedzi poprawnie odwołują się do liczb z arkusza. Test odbył się w trybie Auto, ale nikt nie zapisał, które modele obsłużyły zapytania. Po kilku miesiącach pula się zmienia, a wynik testu nie mówi, czy nadal obowiązuje.
Co firma może faktycznie testować i dokumentować?
Firma może dokumentować decyzje na każdym z trzech poziomów i sprawdzać wynik procesu, a nie tylko model. W praktyce oznacza to kilka czynności, które mieszczą się w zwykłym ładzie korporacyjnym wokół narzędzi IT.
- Pula dopuszczonych modeli: zapisać, które rodziny modeli organizacja dopuszcza, kto o tym zdecydował i kiedy; w Cowork także profil modelu w polityce wydatków.
- Procesy krytyczne: tam, gdzie wynik podlega walidacji (na przykład komentarz do wyników finansowych albo analiza umowy), rozważyć pracę na konkretnym modelu zamiast Auto, jeśli interfejs na to pozwala, i zapisać ten wybór w instrukcji procesu.
- Testy na puli, nie na modelu: próbkę zadań kontrolnych uruchamiać okresowo w tych samych warunkach, w jakich proces działa naprawdę, i zapisywać dostawcę oraz, jeśli jest dostępna, nazwę modelu z dziennika audytu.
- Sprawdzenie dzienników: jednorazowo ustalić we własnej dzierżawie, jakie pola
ModelTransparencyDetailspojawiają się dla zapytań w Auto. - Przegląd przy zmianie puli: traktować dodanie modelu do puli jako zdarzenie wymagające ponownego uruchomienia testów kontrolnych dla procesów krytycznych.
W kancelarii czy biurze rachunkowym, gdzie odpowiedź trafia do klienta, ten zestaw daje odpowiedź na pytanie, które klient albo audytor może zadać: jakim narzędziem i w jakich warunkach powstał dokument. W firmie produkcyjnej, gdzie Copilot wspiera wewnętrzne analizy, wystarczy zwykle lżejsza wersja: zapis dopuszczonej puli i okresowy test na próbce.
Czy numer najnowszego modelu ma tu znaczenie?
Mniejsze, niż sugerują doniesienia o premierach. Najnowszy model dostawcy nie musi być dostępny w firmie: Google udostępnił Gemini 4 Argon 30 września 2026 najpierw wybranej grupie obrońców cyberbezpieczeństwa w programie Fairwind, zapowiadając szersze udostępnienie później. A w trybie Auto firma i tak nie wybiera wersji dla każdego zapytania.
Dla decyzji wdrożeniowej ważniejsze od numeru wersji są trzy pytania: jakie modele są w puli dopuszczonej przez organizację, jak firma dowie się o zmianie tej puli i czy jej procedura walidacji obejmuje tę zmianę. O tym, jak model może zniknąć z narzędzia, w tym gdy dostawca narzędzia zmienia model bazowy pod tą samą nazwą produktu, pisałem w tekście o trzech drogach wycofania modelu AI.
Kiedy ta analiza ma mniejsze znaczenie
- Gdy Copilot służy do zadań, których wynik każdorazowo sprawdza człowiek i które nie trafiają do klienta ani do sprawozdań, zmienność modelu ma ograniczone znaczenie praktyczne.
- Gdy organizacja korzysta wyłącznie z powierzchni, w której użytkownicy pracują na konkretnym, wybranym modelu, problem routera dotyczy jej w mniejszym stopniu.
- Dokumentacja Microsoftu zmienia się szybko; opis kontroli, oznaczeń i pól audytu może w dniu lektury wyglądać inaczej niż w dniu pisania.
Czego ten tekst nie twierdzi
- Nie twierdzi, że firma nie wie, który model odpowiedział: Cowork pokazuje oznaczenie modelu, a dzienniki audytu zapisują dostawcę.
- Nie twierdzi, że model zmienia się bez decyzji firmy: router wybiera z puli, o której decyduje organizacja.
- Nie twierdzi, że tryb Auto daje gorsze wyniki niż wybór ręczny; nie dotarłem do pomiaru, który by to rozstrzygał.
Podsumowanie
Tryb Auto w Microsoft 365 Copilot przesuwa przedmiot zatwierdzenia. Firma nie dopuszcza już jednego modelu, tylko produkt, który w ramach puli dopuszczonej przez organizację sam dobiera model do każdego zapytania, ważąc dokładność, szybkość i koszt. Kontrola istnieje na trzech poziomach: organizacji, użytkownika i routera, a identyfikowalność jest częściowa: Cowork pokazuje oznaczenie modelu, dzienniki audytu zawsze zapisują dostawcę, zapis nazwy modelu zależy od scenariusza. Dla większości codziennych zadań to wystarcza. Dla procesów, w których wynik trzeba walidować, zmienia się jednak sposób pracy: test jednego modelu nie zastępuje testu procesu, a skład puli jest zmienny i ostatnie tygodnie pokazują, jak szybko pojawiają się nowe wersje. Rozsądna praktyka to zapis dopuszczonej puli z właścicielem decyzji, praca na konkretnym modelu tam, gdzie wynik podlega walidacji, okresowe testy kontrolne z zapisem danych z dziennika audytu oraz ponowne testy przy każdej zmianie puli.
O autorze
Remigiusz Pruszczak: ekspert GenAI i trener AI. Od 17 lat prowadzi szkolenia, a od 2025 roku również z generatywnej AI, między innymi dla banków, instytucji finansowych, kancelarii oraz firm z sektorów regulowanych i produkcji. Szkolenia realizuje we współpracy z EY Academy of Business Polska, Warszawskim Instytutem Bankowości, Bankowym Ośrodkiem Doradztwa i Edukacji oraz CFA Society Poland. Więcej na stronie „O mnie”.
Źródła
- Microsoft, „Microsoft Copilot Chat overview”, Microsoft Learn, aktualizacja 10.09.2026. https://learn.microsoft.com/en-us/copilot/overview
- Microsoft, „User subscription license and usage-based billing for Microsoft 365 Copilot”, Microsoft Learn, aktualizacja 25.09.2026. https://learn.microsoft.com/en-us/microsoft-365/copilot/user-subscription-license-usage-based-billing
- Microsoft, „Models in Copilot Cowork”, Microsoft Learn, aktualizacja 14.09.2026. https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-models
- Microsoft, „Managing AI experiences enabled by usage-based billing”, Microsoft Learn, aktualizacja 02.10.2026. https://learn.microsoft.com/en-us/microsoft-365/copilot/usage-based-billing-manage-copilot-credits
- Microsoft, „Audit logs for Copilot and AI applications”, Microsoft Purview, Microsoft Learn, aktualizacja 26.08.2026. https://learn.microsoft.com/en-us/purview/audit-copilot
- OpenAI, „API changelog”, wpisy z 03.09.2026 i 29.09.2026. https://developers.openai.com/api/docs/changelog
- Google, „Gemini 4 Argon”, blog Google, 30.09.2026. https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/
