Copilot rozdziela użycie BYOK: jak czytać raport zespołu

W zespole pada pytanie: ile właściwie korzystamy z AI? Ktoś pokazuje wykres Copilota, ktoś dopisuje rachunek za własny klucz do modelu, a ktoś przypomina o modelu uruchamianym lokalnie. Nagle proste pytanie ma trzy odpowiedzi i żadnego właściciela. Ja zaczynam wtedy od ustalenia, co dokładnie obejmuje każda liczba. Dopiero później otwieram arkusz. Excel cierpliwie zsumuje nawet rzeczy, których nigdy nie należało dodawać.

GitHub ogłosił 3 listopada 2026 r. rozróżnienie BYOK w API metryk Copilota. BYOK oznacza korzystanie z własnego klucza dostawcy; lokalny wariant obejmuje także lokalne modele. Osobno raportowane są modele skonfigurowane przez administratora. Opisuję stan na 6 listopada 2026 r. Dla osoby prowadzącej zespół analityczny to dobry moment na uporządkowanie raportu użycia narzędzi.

Co zobaczysz w nowych danych

Lokalne BYOK ustawia użytkownik w swoim kliencie i rozpoznasz je między innymi po used_local_byok oraz totals_by_local_byok. Modele skonfigurowane przez administratora w GitHubie oznacza is_custom_enterprise_model. Nowe przekroje mieszczą się w istniejących sumach. Telemetria klienta może zaniżać lokalne BYOK, a starsze dni nie dostają wstecznie pola is_custom_enterprise_model.

Mój wniosek organizacyjny jest prosty: do raportu dopisuję sposób obsługi żądania, zamiast grupować wszystko wyłącznie według nazwy modelu. Przy każdym porównaniu zostawiam miejsce na brak danych. Puste pole z października opisuję jako niedostępny przekrój, bez dopisywania zera. Zespół powinien wiedzieć, od kiedy konkretny podział nadaje się do obserwowania zmian.

Wyobraź sobie analityczkę, która jednego dnia poprawia SQL, a następnego dokumentuje model danych. Przed rozmową o wyborze narzędzia proszę ją o przypisanie obu zadań do użytego środowiska. Interesuje mnie droga wykonania pracy i jej rezultat. Samo hasło „używałam tego samego modelu” zostawia za dużo miejsca na różne interpretacje.

Ustal zakres, zanim porównasz zespoły

Dokumentacja API opisuje raporty dzienne i obejmujące ostatnie 28 dni. Ich dostępność wymaga włączonej polityki metryk i właściwych uprawnień. Dlatego wyznaczam osobę odpowiedzialną za pobranie raportu i zapisanie jego okresu. Na spotkanie przynosimy tę samą wersję danych, zamiast porównywać dwa zrzuty ekranu zrobione w różnych dniach.

GitHub wyjaśnia różnice między raportami: znaczenie mają zakres, okno czasu i opóźnienie telemetrii. Metryki IDE mogą potrzebować dwóch pełnych dni UTC po zakończeniu danego dnia. Raport zespołu powstaje przez połączenie danych użytkowników z ich przynależnością do zespołów. Z tego powodu przy każdym zestawieniu zapisuję datę pobrania oraz definicję grupy.

Wybierz na początek jedną grupę zajmującą się podobną pracą. Ja zestawiam przygotowanie cyklicznych analiz z przygotowaniem cyklicznych analiz. Osobno opisuję tydzień, w którym zespół budował nowy projekt. Przy każdej zmianie składu grupy zostawiam adnotację. Dzięki temu dyskusja o spadku aktywności zaczyna się od sprawdzenia kontekstu, zanim ktoś zamówi kolejne szkolenie z promptowania.

Osobną regułę zapisuję dla analityka pracującego przy kilku projektach. W przeglądzie konkretnego raportu przypisuję jego pracę do zadania, które właśnie oceniamy. W zestawieniu całej organizacji pilnuję, żeby tej samej aktywności nie przypisać ponownie tylko dlatego, że człowiek należy do dwóch zespołów. Właściciel raportowania zatwierdza tę regułę przed prezentacją wyników. Inaczej każdy dział pokaże własny sukces, a suma przestanie opisywać cokolwiek rzeczywistego.

Oddziel użycie od rozliczenia

W arkuszu przeglądu utrzymuję trzy części: aktywność, dokumenty rozliczeniowe i efekty pracy. W pierwszej zapisuję źródło metryki. W drugiej wskazuję, skąd pochodzi kwota i jakiego okresu dotyczy. W trzeciej opisuję odebrany rezultat. Każda część ma własne kryterium kompletności. Pusta kwota oznacza zadanie do wyjaśnienia z właścicielem rozliczenia, a nie darmową pracę narzędzia.

Przy lokalnym modelu proszę o opis przyjętego sposobu liczenia infrastruktury. Przy zewnętrznym dostawcy o wskazanie właściwego zestawienia użycia. Przy wspólnym koncie o regułę podziału między projekty. Nie mnożę liczby żądań przez wymyśloną średnią cenę. Wolę raport z nazwanym brakiem niż elegancki wykres oparty na kwocie wyciągniętej z kapelusza.

Uzgadniam również, kto poprawia błędne przypisanie. Osoba przygotowująca analizę zna zadanie, administrator zna konfigurację, a właściciel rozliczenia zna dokument kosztowy. Każda z tych osób potwierdza swój fragment. Gdy odpowiedzialność trafia do jednego ogólnego pola „IT”, po miesiącu sam raport zaczyna wymagać projektu wdrożeniowego. Naprawdę da się prościej.

Przy porównaniu dwóch okresów zachowuję tę samą regułę podziału. Jeżeli ją zmieniam, opisuję datę i powód zmiany obok wykresu. Przeniesienie wspólnego kosztu do konkretnego projektu traktuję jako zmianę sposobu raportowania. Osobno sprawdzam, czy zmieniła się sama praca. Dzięki temu mogę wyjaśnić różnicę bez przypisywania jej automatycznie nowemu modelowi albo lepszym umiejętnościom zespołu.

Wybierz jeden rezultat do oceny

Weźmy cotygodniowe podsumowanie sprzedaży przygotowywane z pomocą Copilota. Za rezultat uznaję raport zaakceptowany według uzgodnionych kryteriów: właściwego okresu, poprawnych definicji oraz zgodności sum ze źródłem. Zapisuję czas przygotowania i czas poprawek oddzielnie. Obok umieszczam rodzaj wykorzystanej pomocy: przygotowanie zapytania, dokumentację albo sprawdzenie logiki. To mój proponowany sposób oceny procesu.

Takie kryteria ustalam przed zbieraniem wyników. Inaczej łatwo wybrać po fakcie akurat tę liczbę, która wygląda najlepiej. Polecam zacząć od briefu zamiast rozbudowanego prompta. W briefie wskazujesz decyzję biznesową i warunek odbioru. Tutaj dokładam do niego źródło metryk oraz osobę, która potwierdzi, że rezultat rzeczywiście nadaje się do użycia.

GitHub w opisie interpretacji metryk zwraca uwagę, że porównania grup pokazują zależności, bez dowodu przyczynowego wpływu AI. Ja uzupełniam je przeglądem konkretnych zadań. Sprawdzam, czy zespół pracował na podobnych danych, z podobnym terminem i tym samym kryterium jakości. Dopiero taki kontekst pozwala mi sensownie rozmawiać o rozszerzeniu zastosowania.

Karta przeglądu do skopiowania

Poniższą kartę przygotowałem do jednego procesu analitycznego. Wklej ją do zadania w Linearze albo dokumentacji projektu i wypełnij przed najbliższym przeglądem. Nawiasy zastąp konkretnymi ustaleniami. Zapisuj odnośniki do zestawień w miejscu dostępnym właściwym osobom; karta ma prowadzić do dowodów, bez gromadzenia kluczy API czy treści prywatnych rozmów.

PRZEGLĄD UŻYCIA AI W PROCESIE
Proces: cotygodniowe podsumowanie sprzedaży
Okres danych i data pobrania: [...]
Grupa osób oraz zmiany jej składu: [...]
Właściciel przeglądu: [...]

AKTYWNOŚĆ
Źródło raportu i zakres objętych nim narzędzi: [...]
Sposób rozdzielenia BYOK i pozostałego użycia: [...]
Przekroje zawarte już w sumach, których nie dodajemy: [...]
Brakujące dane i sposób ich oznaczenia: [...]

ROZLICZENIE
Właściciel oraz źródło zestawienia każdego dostawcy: [...]
Przyjęta reguła przypisania kosztu do procesu: [...]
Pozycje niewyjaśnione, osoba odpowiedzialna, termin: [...]

REZULTAT
Link do odebranego raportu i kryteriów poprawności: [...]
Czas przygotowania / czas poprawek: [...]
Co poprawiamy w następnym przebiegu: [...]
Decyzja: utrzymujemy zakres / rozszerzamy / wracamy do poprawy
Osoba podejmująca decyzję i termin przeglądu: [...]

Na pierwszym spotkaniu przejdź przez jeden zakończony raport. Ustal, które pola potraficie wypełnić z istniejących źródeł, a które wymagają dodatkowego zapisu podczas pracy. Ja nie zaczynam od budowania nowego dashboardu. Najpierw chcę zobaczyć, czy dwie osoby, korzystając z tej samej karty, dochodzą do zgodnego opisu tego samego zadania.

Jaką decyzję podejmuję po przeglądzie

Jeżeli rezultat spełnia kryteria, a sposób jego przygotowania jest zrozumiały, wybieram kolejny podobny proces do pilotażu. Gdy większość wysiłku pochłaniają poprawki definicji, porządkuję brief. Gdy brakuje danych o użyciu, poprawiam opis pomiaru. Każdy z tych wyników prowadzi do innego działania. Sam wzrost aktywności zostawiam jako obserwację.

W kolejnym okresie wracam do zapisanej decyzji. Sprawdzam, czy poprawa briefu ograniczyła wskazany problem i czy rozszerzony zakres nadal mieści się w możliwościach zespołu. Wybieram do rozmowy także zadanie zatrzymane albo odrzucone. Taki przypadek pokazuje, gdzie kończy się przydatność obecnego sposobu pracy, i daje konkretny temat do poprawy przed dalszym wdrożeniem.

To łączy się z czwartym tygodniem Analizy z AI i doborem skali rozwiązania. Nowy przekrój w metrykach pomaga lepiej nazwać to, co już robisz. Użyj go do sprawdzenia jednego procesu, ustalenia odpowiedzialności i podjęcia następnej decyzji. Na początek wystarczy jedna wypełniona karta oraz jeden raport, za którego jakością ktoś potrafi stanąć.