Zanim zmienisz plan zatrudnienia w startupie pod wpływem benchmarku AI, rozpisz rzeczywiste zadania na danym stanowisku. Sprawdź, dla których masz przydatne wyniki badań, a pozostałe przetestuj we własnym procesie. Przed zatwierdzeniem lub anulowaniem wakatu zapisz, za co nadal muszą odpowiadać ludzie. Wynik modelu może pomóc w tej analizie; nie rozstrzygnie, ile osób potrzebuje twój zespół.

Wyobraź sobie, że chcesz zatrudnić kogoś do wdrażania klientów. Nowy model dobrze wypada w benchmarku, a podczas demonstracji tworzy imponujący dokument wdrożeniowy. Zespół pyta, czy wakat nadal jest potrzebny. Warto wtedy sprawdzić, czego w dokumencie nie widać: brakujących danych od klienta, sprzecznych zobowiązań, przekazywania spraw wewnątrz zespołu i osoby dostępnej do obsługi nietypowych przypadków.

[Mapa benchmarków Mercor, omawiana obecnie na Hacker News](https://news.ycombinator.com/item?id=50121179), daje aktualny punkt wyjścia do takiej rozmowy. Pokazuje, jaka część pracy wykonywanej w gospodarce pojawia się w wybranym zbiorze benchmarków AI. Jej wyniki uzasadniają sprawdzenie, co faktycznie zmierzono, zanim wynik modelu przełoży się na decyzję o zatrudnieniu.

## Co mówi zakres benchmarków AI?

Zakres benchmarku mówi, czy określone zadania znalazły się w ocenie. Nie mówi, czy model poprawnie wykonuje każde z nich, jak radzi sobie z twoimi narzędziami ani czy da się zautomatyzować całe stanowisko.

Pierwsza wersja [mapy gospodarki USA](https://www.mercor.com/research/labor-index/benchmark-map/) opracowanej przez Mercor obejmuje **29 wybranych benchmarków**. Wskazuje **924 uwzględnione zadania spośród 18 797**, korzystając z opisu **923 zawodów**. Według głównej definicji zadanie jest objęte benchmarkami, gdy przypisano do niego co najmniej pięć promptów. Jeden prompt może odpowiadać więcej niż jednemu zadaniu.

Najgłośniejszy szacunek mówi, że około **90% czasu pracy w USA** przypada na zadania słabo reprezentowane w tym indeksie lub zupełnie w nim nieobecne. Zawsze wyjaśniaj, czego dotyczy ta liczba. Opisuje ona wybrany zbiór benchmarków, z wagami opartymi na szacowanym czasie pracy. Nie oznacza, że AI nie radzi sobie z 90% pracy ani że 90% miejsc pracy jest bezpiecznych przed automatyzacją.

Ograniczenia są istotne. Mercor zaznacza, że zbiór jest niepełny i wstępny. Ogranicza liczbę benchmarków według grup zawodowych i pomija część tych, w których najbardziej zaawansowane modele osiągają już wyniki bliskie maksimum. Te decyzje mogą zaniżać szacowany zakres w stopniu, którego badacze nie potrafią określić. Traktuj mapę jako informację o brakach w pomiarach, a nie spis wszystkiego, co kiedykolwiek przetestowano.

Samo przypisywanie zadań również wymaga oceny. Mercor używa modelu językowego do łączenia promptów z zadaniami zawodowymi. Eksperci sprawdzili przypisania wskazane jako pierwszy wybór dla części zbioru APEX i zaakceptowali **76,7% z 1763 ocen**. Mapa uwzględnia także inne sugerowane przypisania, których ten przegląd nie ocenił w pełni. To przydatna kontrola, ale o określonym zakresie. [Metodologia Mercor](https://www.mercor.com/research/labor-index/benchmark-map/methodology/).

Niezależne badanie wskazuje na pokrewny problem. Wang i współautorzy przeanalizowali **43 benchmarki i 72 342 zadania**. Wykazali rozbieżność między rozwojem agentów, skupionym w dużej mierze na programowaniu, a rozkładem pracy wykonywanej przez ludzi. Korzystali z innej próby; ich badanie nie potwierdza niezależnie głównego szacunku Mercor. [How Well Does Agent Development Reflect Real-World Work?](https://arxiv.org/abs/2603.01203v2).

Dla planu zatrudnienia wynika z tego konkretne zadanie: ustalić, które części proponowanego stanowiska rzeczywiście mają odzwierciedlenie w dostępnych danych.

## Od jakich zadań zależy decyzja o zatrudnieniu?

Zacznij od pracy, którą trzeba wykonać, rytmu jej napływu i skutków jej niedokończenia. Sama nazwa stanowiska jest zbyt ogólna, by określić, co musiałby zmienić wynik AI.

Oficjalny [system opisu zawodów O*NET](https://www.onetcenter.org/overview.html) porządkuje informacje o zadaniach, czynnościach, umiejętnościach i innych cechach pracy. Może pomóc zauważyć pominięte obowiązki. Profile zawodów nie opiszą jednak dokładnie twojego startupu, gdzie jedna osoba może łączyć kilka funkcji i polegać na nieformalnym przekazywaniu spraw.

Poproś osoby wykonujące tę pracę o omówienie niedawnych przypadków: rutynowego, opóźnionego i takiego, który wymagał wyjątku. Odtwórz przebieg na podstawie istniejących zapisów. Ustal, kto dostarczył brakujące informacje, kto podjął decyzję i kto sprawdził, czy rezultat nadawał się do użycia.

Opisuj zadania jako działania, które można zaobserwować. „Wspieranie wdrażania klientów” daje niewiele do sprawdzenia. „Przygotowanie pakietu wdrożeniowego klienta na podstawie zatwierdzonych danych konta” określa dane wejściowe i wynik. „Rozwiązanie sprzeczności między podpisaną umową a notatkami na koncie” to inne zadanie, nawet jeśli oba należą do jednego stanowiska.

Uwzględnij koordynację. Gotowy szkic może nadal czekać na opiekuna konta, odpowiedź klienta lub zgodę na dostęp. Jeśli te zależności decydują o terminie zakończenia wdrożenia, pominięcie ich w wykazie zadań osłabi przydatność danych do decyzji o wakacie.

Oddziel też pracę potrzebną od tej, z której można zrezygnować. Test niepotrzebnego raportu nie określi zapotrzebowania na ludzi do obsługi rosnącej kolejki klientów. Uzgodnijcie wymagane rezultaty, zanim zaczniecie dyskutować, czy ma je dostarczyć człowiek, czy system.

Szerszą decyzję o zdolności zespołu do wykonania pracy opisuje nasz [poradnik planowania zatrudnienia](/blog/headcount-planning-humans-ai-agents-new-hr-role). Tutaj przygotowujesz jeden z jej elementów: jasny opis zadań, których wykonanie mogłoby zmienić twój plan.

## Przed testem AI połącz zadania z dostępnymi dowodami

Do każdego ważnego zadania przypisz rzeczywisty przypadek, kryterium akceptacji i dostępne dowody. To propozycja metody planowania, a nie procedura zweryfikowana w badaniu Mercor.

Poniższa tabela opisuje **hipotetyczną pracę przy wdrażaniu klientów**. Nie zawiera zaobserwowanych wyników, danych klientów ani branżowych celów wydajności. Pokazuje, czego trzeba się dowiedzieć przed zmianą planu zatrudnienia.

| Zadanie | Przypadek do uwzględnienia | Czego wymaga użyteczny rezultat | Jakie dane zebrać |
|---|---|---|---|
| Przygotowanie pakietu wdrożeniowego | Pełne, spójne dane konta | Potwierdzenie wymaganych faktów w zatwierdzonych zapisach | Brakujące fakty, błędne szczegóły i poprawki konieczne przed użyciem |
| Obsługa niepełnych danych | Brakuje wymaganej informacji o kliencie | Wykrycie braku i prośba o odpowiednie wyjaśnienie | Czy zauważono brak i kto go uzupełnił |
| Rozwiązanie sprzeczności | Notatki na koncie przeczą umowie | Zachowanie informacji o sprzeczności i przekazanie sprawy osobie z odpowiednimi uprawnieniami | Dostarczone dowody, jakość przekazania i pozostałe decyzje |
| Koordynacja przekazania sprawy | Kolejna odpowiedzialna osoba jest niedostępna | Jasny opis stanu sprawy i zastosowanie uzgodnionego rozwiązania zastępczego | Kto otrzymał pracę i czy przekazanie się zakończyło |
| Rozpoznanie granic działania | Prośba wykracza poza uprawnienia systemu | Zatrzymanie się na granicy i wyjaśnienie, co wymaga zgody | Czy podjęto próbę działania bez uprawnień lub wykonano takie działanie |

Dodaj kolumnę dla odpowiednich publicznych benchmarków. Zapisz podobieństwa i różnice: dane wejściowe, narzędzia, kontekst, długość zadania czy sposób oceniania. „Istnieje powiązany benchmark” to przydatne ustalenie. Nie dowodzi jednak, że przypadek przetestowano już w twoich warunkach.

Stosuj osobne stany: **„nieprzetestowane”**, **„przetestowane z nieakceptowalnym wynikiem”** i **„zaakceptowane w podanych warunkach”**. Nieprzetestowane przekazanie sprawy pozostaje niewiadomą. Nazwanie go porażką wykraczałoby poza dane; uznanie za sukces ukryłoby brak.

Wybierz kryterium akceptacji przed obejrzeniem wyników. Dla pakietu może to oznaczać, że każde wymagane stwierdzenie o faktach ma potwierdzenie w zatwierdzonym zapisie. Przy sprzeczności akceptowalnym wynikiem może być udokumentowane przekazanie sprawy, a nie ukończony pakiet. System, który prawidłowo się zatrzymuje, mógł wykonać właściwą pracę.

Nie komplikuj zbierania dowodów. Potrzebujesz dość szczegółów, by wyjaśnić decyzję, także istotne pominięcia. Mały początkowy zbiór może ujawnić problemy i pomóc zaplanować kolejny test, ale nie określi ogólnej skuteczności. Przywołane badania nie podają uniwersalnej liczby przypadków ani progu zaliczenia.

## Przetestuj proces, z którego naprawdę będziesz korzystać

Oceń proponowaną konfigurację z jej rzeczywistymi danymi wejściowymi, uprawnieniami, narzędziami i pomocą ludzi. Wyraźnie opisz warunki, żeby dobry wynik nie zyskał po cichu szerszego znaczenia.

Jeśli planowany proces obejmuje osobę sprawdzającą każdy pakiet, przetestuj taki układ. Jeśli zakłada dostęp do historii konta, zapewnij tylko dostęp, który rzeczywiście możesz zatwierdzić. Zapisuj pomoc współpracowników, również wyjaśnienia, których system ponownie potrzebowałby przy nieznanym przypadku.

Przygotuj przypadki z informacji, których masz prawo używać w wybranym środowisku. Usuń zbędne dane klienta, zachowując trudność, którą chcesz sprawdzić. Jeśli usunięcie kontekstu istotnie zmienia przykład, zapisz to ograniczenie zamiast przedstawiać przypadek jako pełne odtworzenie pracy.

Porównaj z obecnym procesem w porównywalnych warunkach. Pracownicy nie powinni dostawać najtrudniejszych przypadków, gdy proponowany system otrzymuje wyłącznie kompletne dane. Z kolei odebranie ludziom zwykłego wsparcia współpracowników i kontekstu może stworzyć sztuczny punkt odniesienia. Zapisz, co widziała każda strona i jaką pomoc otrzymała.

Badanie Mercor dotyczące księgowości pokazuje, dlaczego te warunki mają znaczenie. W [październikowym badaniu czterech uproszczonych scenariuszy zamknięcia miesiąca](https://www.mercor.com/blog/human-baselines-for-benchmarks-ai-now-outperforms-junior-accountants/) Mercor podaje, że czołowe modele osiągnęły lepsze wyniki niż 12 uczestniczących w badaniu licencjonowanych księgowych z uprawnieniami CPA. Ludzie pracowali w tym porównaniu bez wsparcia, więc nie wykazuje ono korzyści z pomocy AI. Mercor wyjaśnia też, że warunki wykluczały współpracowników, zgromadzony kontekst i część szerszych obowiązków. Dobry wynik w ograniczonym zadaniu może współistnieć z niepewnością co do całego stanowiska.

Przy wdrażaniu klientów sprawdzaj stan końcowy, nie tylko wygenerowany tekst. Czy pakiet nadawał się do użycia? Czy zdobyto brakujące dane? Czy sprzeczność trafiła do osoby z odpowiednimi uprawnieniami? Zachowaj przypadki nierozwiązane w terminie podjęcia decyzji wraz z przyczyną i wskazaniem kolejnej odpowiedzialnej osoby.

Jeśli zmienisz model, instrukcje lub dostępne narzędzia, oznacz nową konfigurację. Lepsze późniejsze wyniki opisują właśnie ją. Nie pozwalają ustalić, która zmiana przyniosła poprawę, ani nie dowodzą, że wcześniejsza konfiguracja zaliczyłaby teraz test.

Porównanie finansowe wymaga osobnej analizy. Nasz [poradnik kosztów pilotażu](/blog/ai-agent-pilot-cost-per-accepted-outcome) obejmuje oprogramowanie, ponowne próby, sprawdzanie wyników i niedokończoną pracę. Zachowaj te zapisy obok tabeli. Tabela odpowiada na pytanie, czy przetestowano pracę istotną dla wakatu; rejestr kosztów pokazuje, co pochłonęło jej wykonanie.

## Podejmij decyzję o zatrudnieniu w granicach wyników testu

Wyjaśnij na podstawie testu, co zmieniło się w twoim rozumieniu obciążenia pracą. Następnie zdecyduj, czy dane uzasadniają zatrudnienie, zmianę procesu czy kolejny ograniczony eksperyment.

Wróćmy do hipotetycznego zespołu wdrażającego klientów. Jeśli przygotowanie dokumentów staje się łatwiejsze, lecz niejednoznaczne przypadki nadal wymagają założyciela, dowiadujesz się czegoś o podziale pracy. Nowe stanowisko może wymagać umiejętności oceny sytuacji operacyjnej i uprawnień do rozstrzygania spraw. Taki wniosek zależałby od rzeczywistych wyników i obciążenia; nie wynika z przykładowej tabeli.

Przeanalizuj pozostałą pracę według osób i ich dostępności. Drobne oszczędności czasu rozproszone między kilkoma współpracownikami nie zapewniają automatycznie kogoś do obsługi kolejki klientów. Sprawa wymagająca rzadko dostępnego specjalisty może ograniczać tempo obsługi, nawet gdy przygotowanie dokumentów idzie sprawniej.

Uwzględnij też zapotrzebowanie. Test dzisiejszych przypadków nie określa, jak proces zachowa się przy większym wolumenie lub zmianie struktury klientów. Wakat planowany z myślą o wzroście wymaga jasno zapisanego założenia dotyczącego zapotrzebowania. Zapisz je obok obserwacji, aby czytelnik mógł odróżnić to, co się wydarzyło, od twoich oczekiwań.

Krótki zapis decyzji pozwala sprawdzić ten tok rozumowania:

1. **Decyzja:** Określ rozpatrywany wakat lub zakres pracy i termin podjęcia decyzji.
2. **Dowody:** Podaj linki do przetestowanych przypadków, konfiguracji, kryteriów akceptacji i zaobserwowanych wyników.
3. **Pozostała praca:** Wymień decyzje, wyjątki i przekazania spraw, którymi nadal muszą zajmować się ludzie.
4. **Ograniczenia:** Wskaż istotne warunki, których zabrakło lub których nie sprawdzono.
5. **Działanie:** Zatwierdź stanowisko, zmień jego zakres, zmień proces lub przeprowadź kolejny ograniczony test. Wskaż osobę odpowiedzialną i datę przeglądu.

Nie sprowadzaj tego zapisu do formalności uzasadniającej wcześniej podjętą decyzję. Określ, jakie dane skłoniłyby cię do zmiany zdania. Jeśli test może jedynie dostarczyć argumentu za anulowaniem wakatu, nie pozwala uczciwie ocenić potrzeby zatrudnienia.

Obiecujący wynik może uzasadniać węższy eksperyment przy równoległym prowadzeniu rekrutacji. Wynik nierozstrzygający może uzasadniać zebranie brakujących danych. Stały brak osoby odpowiedzialnej może wzmacniać argument za zatrudnieniem kogoś z właściwymi uprawnieniami. To różne możliwe decyzje, które wymagają różnych zobowiązań i dowodów.

Po zatwierdzeniu zatrudnienia zdefiniuj stanowisko na podstawie zadań, które nadal wymagają wykonania. Osobny poradnik o [stanowiskach ze wsparciem AI i rzeczywistą odpowiedzialnością](/blog/ai-assisted-roles-meaningful-work-decision-rights) opisuje ten następny krok. Dokument planowania powinien wyjaśniać, dlaczego stanowisko istnieje; opis stanowiska powinien mówić kandydatowi, za co będzie odpowiadać.

## Przenieś zatwierdzone stanowisko do Kit

Porównanie benchmarków i test wewnętrznego procesu zachowaj w dokumencie planowania. Kit może pomóc zorganizować rekrutację na zatwierdzone stanowisko, ale nie oferuje analizatora zakresu benchmarków, modelu planowania zatrudnienia ani środowiska do wewnętrznych testów AI.

Opisz rzeczywistą pracę w ogłoszeniu o pracę, a odpowiednie zadanie wyjaśnij w instrukcjach etapu widocznych dla kandydatów. Kit obsługuje próbki pracy związane ze stanowiskiem oraz etapy oceny zespołu. Dostosuj te etapy do zatwierdzonego stanowiska i jasno określ, co kandydaci powinni pokazać.

Osobom prowadzącym rekrutację przekaż konkretny opis: rezultaty, za które dana osoba odpowiada, decyzje, które może podejmować, i zadania, których eksperyment nie pozwolił rozwiązać. Publiczny benchmark pomógł zadać pytanie. Własne dowody wyznaczają granice odpowiedzi.

> [!CTA]
> **Masz zatwierdzone stanowisko do obsadzenia?** Zacznij od [szablonu procesu rekrutacji w Kit](/templates), a potem dostosuj etapy i instrukcje do pracy, której naprawdę potrzebuje twój zespół.