Struktura zespołu AI: pierwszy etat rozstrzyga o wszystkich następnych

Budujesz zespół AI i potrzebujesz kompetencji szybciej, niż pozwala rekrutacja? Poznaj nasze usługi Staff Augmentation.

Zobacz też: Staff augmentation AI/ML: jak skalować zespół oraz Koszt wdrożenia AI: od PoC do produkcji

Typowa polska organizacja, która postanowiła „zrobić coś z AI”, zaczyna od rekrutacji ML Engineera. Ogłoszenie wisi cztery miesiące, bo kandydatów o realnym doświadczeniu produkcyjnym jest niewielu, a ci, którzy są, wybierają między kilkoma ofertami. W końcu ktoś przychodzi, dostaje laptop, dostęp do kopii bazy sprzed kwartału i pytanie „co możemy zrobić z AI”.

Po trzech miesiącach ma działający prototyp na tej kopii. Po sześciu wciąż nie ma wdrożenia, bo okazało się, że dane produkcyjne wyglądają inaczej niż kopia, że identyfikatory klientów w dwóch systemach nie są tym samym identyfikatorem, że pole, na którym opierał się cały pomysł, jest wypełniane ręcznie przez dwie osoby z różnymi konwencjami, i że dostęp na żywo wymaga zgody zespołu, który utrzymuje system źródłowy i ma własne priorytety na dwa kwartały do przodu.

Po dziewięciu miesiącach ML Engineer odchodzi. W jego wypowiedzeniu nie ma słowa o pieniądzach.

Teza tego przewodnika brzmi i można się z nią spierać: struktura zespołu AI jest przede wszystkim kwestią uprawnień, a dopiero potem kompetencji, więc pierwszym etatem powinien być inżynier danych z formalnym mandatem do zmiany systemów źródłowych — nie ML Engineer i nie Data Scientist. Warstwa modelowania przestała być wąskim gardłem, bo kupuje się ją jako usługę i pierwsze użyteczne rozwiązanie powstaje na niej w kilka dni. Wąskim gardłem jest dostęp do danych i prawo do zmiany sposobu, w jaki te dane powstają — a to jest problem organizacyjny w technicznym przebraniu.

Kontrargument jest mocny i trzeba go postawić uczciwie: inżynier danych nie dowiezie efektu, który biznes zobaczy. Po sześciu miesiącach będzie miał uporządkowane przepływy i zero widocznych rezultatów, a zarząd, który finansował „projekt AI”, zobaczy projekt hurtowni danych pod inną nazwą i wycofa poparcie. Odpowiedź: widoczny efekt na danych demonstracyjnych dowozi się dziś w dwa tygodnie i to jest właśnie pułapka. Ten efekt nie przenosi się na produkcję i to jest mechanizm, w którym większość pilotaży AI umiera pomiędzy prototypem a wdrożeniem. Praktyczne rozwiązanie nie polega jednak na wyborze między jednym a drugim, tylko na kolejności i na tym, żeby pierwszy widoczny efekt był oparty na jednym, wąskim, realnym przepływie danych, a nie na kopii. Do tego potrzebny jest właśnie inżynier danych z mandatem, i to on umożliwia demonstrację, a nie ją opóźnia.

Co się faktycznie zmieniło, odkąd modele kupuje się jako usługę?

Jeszcze kilka lat temu zbudowanie użytecznego modelu dla większości zastosowań biznesowych wymagało zebrania zbioru uczącego, wytrenowania modelu i utrzymania infrastruktury treningowej. Zespół bez osoby, która to potrafi, nie miał czego wdrażać. Kolejność „najpierw ML Engineer” była wtedy poprawna.

Dziś dla przeważającej części zastosowań — klasyfikacja dokumentów, ekstrakcja pól, streszczanie, wstępna obsługa zapytań, dopasowywanie pozycji na listach — sensowny punkt startowy to gotowy model dostępny przez interfejs programistyczny. Zbudowanie na nim działającego rozwiązania nie wymaga wiedzy o trenowaniu, wymaga wiedzy o integracji, testowaniu i kosztach.

Konsekwencja dla struktury zespołu jest bezpośrednia i mało komfortowa dla branży: kompetencja, która przez dekadę była najdroższa i najbardziej pożądana, przesunęła się z pozycji krytycznej na pozycję ważną, ale nie pierwszą. Nie zniknęła — przy zastosowaniach specjalistycznych, przy dostrajaniu na własnych danych, przy wymaganiach dotyczących lokalnego uruchamiania modeli czy przy nietypowych typach danych jest niezastąpiona. Przestała natomiast być tym, od czego trzeba zacząć.

Warto zauważyć, że to jest ta sama zmiana, którą wcześniej przeszła infrastruktura. Kiedy serwerownia zamieniła się w usługę, kompetencja administratora sprzętu nie zniknęła, ale przestała być pierwszym etatem w zespole budującym system. Pierwszym etatem stał się ktoś, kto rozumiał, jak z usług złożyć całość. W AI ta rola nazywa się dziś inżynier danych, choć nazwa jest myląca, bo obowiązki są w połowie negocjacyjne.

Na czym dokładnie polega wąskie gardło danych w polskiej organizacji?

Cztery przeszkody powtarzają się na tyle regularnie, że warto je nazwać, bo każda wymaga innego rodzaju uprawnienia, a żadna nie wymaga wiedzy o modelach.

Dane są w systemie, którego nie kontrolujecie. ERP wdrożony przez zewnętrznego partnera, z umową serwisową, w której każda zmiana jest zleceniem. Uzyskanie strumienia danych na żywo to nie jest zadanie techniczne, tylko negocjacja handlowa i zmiana w umowie. Osoba bez mandatu nie ma czym negocjować.

Dane powstają ręcznie i niekonsekwentnie. Pole „kategoria zgłoszenia” wypełniane przez trzy osoby, każda po swojemu, bez słownika. Naprawa polega na zmianie sposobu pracy tych trzech osób, czyli na uzgodnieniu z ich przełożonym — znów uprawnienie, nie technika. Co ważne, to jest zwykle najtańsza możliwa poprawa jakości rozwiązania i prawie nigdy nie znajduje się w planie projektu AI.

Identyfikatory nie łączą się między systemami. Klient w systemie sprzedaży i klient w systemie rozliczeń to dwa różne rekordy bez trwałego powiązania. To akurat jest problem techniczny, ale jego rozwiązanie wymaga decyzji, który system jest źródłem prawdy — a to jest decyzja polityczna, którą trzeba komuś przypisać.

Nikt nie odpowiada za jakość danych. Nie ma osoby, do której idzie zgłoszenie „w tej tabeli od marca brakuje co dziesiątego rekordu”. W efekcie rozwiązanie oparte na modelu psuje się cicho, a diagnoza trwa tygodnie.

Wspólny mianownik czterech punktów: żaden z nich nie jest problemem uczenia maszynowego i żadnego nie rozwiąże osoba, której zakres obowiązków kończy się na granicy własnego zespołu.

Jak wygląda blokada w kalendarzu

Warto zobaczyć, jak te przeszkody rozkładają się w czasie, bo w opisie brzmią jak drobiazgi, a w kalendarzu zajmują kwartały.

Tydzień pierwszy: nowa osoba prosi o dostęp do danych produkcyjnych. Tydzień trzeci: dowiaduje się, że dostęp wymaga zgody właściciela systemu i opinii inspektora ochrony danych. Tydzień szósty: opinia jest pozytywna pod warunkiem pseudonimizacji dwóch pól, co wymaga zmiany po stronie systemu źródłowego. Tydzień siódmy: zmiana trafia do kolejki partnera serwisowego, wycena po dwóch tygodniach, realizacja w kwartale następnym. Tydzień dziesiąty: zespół decyduje się pracować na kopii, żeby nie stać. Tydzień dwudziesty czwarty: prototyp gotowy na kopii. Tydzień dwudziesty ósmy: pierwsze zderzenie z danymi produkcyjnymi ujawnia, że w kopii brakowało pola wypełnianego wyłącznie w nowym module, wdrożonym trzy miesiące wcześniej.

Nic w tym harmonogramie nie jest złą wolą i każdy pojedynczy krok jest uzasadniony. Suma jest jednak taka, że po pół roku nadal nie ma wdrożenia, a przyczyną nie była ani jakość modelu, ani kompetencje zatrudnionej osoby.

Ten sam harmonogram z mandatem wygląda inaczej w jednym miejscu — w tygodniu siódmym. Prawo do wystawienia wniosku poza kolejką, ograniczone do sześciu razy w roku, zamienia „kwartał następny” na „dwa tygodnie”. To jest cała różnica i całe uzasadnienie tezy tego przewodnika.

Dlaczego mandat waży więcej niż kompetencje?

To jest najbardziej kontrowersyjna część tezy, więc warto ją postawić precyzyjnie. Nie chodzi o to, że kompetencje są nieważne — chodzi o to, że przy tej samej osobie różnica między mandatem a jego brakiem daje różnicę w wyniku większą niż różnica między kandydatem dobrym a wybitnym.

Mandat oznacza cztery konkretne rzeczy i wszystkie cztery da się zapisać w dokumencie na jedną stronę. Prawo do wystąpienia o zmianę w systemie źródłowym z pominięciem zwykłej kolejki priorytetów, ograniczone liczbowo — na przykład do sześciu wniosków rocznie, żeby nie stało się to nadużyciem. Prawo do wglądu w dane produkcyjne w zakresie niezbędnym, z jasno opisanym trybem i ograniczeniami wynikającymi z ochrony danych osobowych. Prawo do zwołania spotkania z właścicielami procesów, w którym udział nie jest opcjonalny. I wskazanie osoby w zarządzie, która rozstrzyga spór o priorytety w ciągu tygodnia.

Bez tych czterech punktów zatrudniacie kogoś, kto będzie prosił. Osoba prosząca w organizacji, w której wszyscy mają własne cele kwartalne, dostanie odpowiedź „tak, oczywiście, w przyszłym kwartale” i to jest odpowiedź szczera, nie wymijająca.

Praktyczny test przed rozpoczęciem rekrutacji, zajmujący jedno popołudnie: napiszcie ten jednostronicowy dokument i przedstawcie go do podpisu. Jeżeli organizacja nie jest gotowa go podpisać, nie jest też gotowa na zespół AI i lepiej dowiedzieć się o tym przed czteromiesięczną rekrutacją niż po dziewięciu miesiącach pracy nowej osoby. Odmowa podpisu jest cenną informacją, a nie porażką — mówi, że wdrożenie nie ma jeszcze poparcia, którego wymaga.

Co zrobić, gdy mandatu zdobyć się nie da

Odmowa podpisu bywa ostateczna i wtedy pozostają trzy warianty, z których dwa są uczciwe.

Wariant pierwszy — zawęzić obszar do jednego systemu, który kontrolujecie. Jeżeli organizacja nie zgodzi się na mandat wobec całego krajobrazu systemów, można zapytać o mandat wobec jednego. Zwykle jest to system, którym opiekuje się wasz własny zespół. Zakres wdrożenia się zmniejsza, ale wdrożenie jest możliwe i buduje dowód, na podstawie którego drugi mandat bywa łatwiejszy do uzyskania. To jest wariant najlepszy z dostępnych.

Wariant drugi — przesunąć projekt na zastosowania oparte na danych, które i tak są dostępne. Dokumenty przychodzące, korespondencja, treści publiczne, dane, które organizacja już eksportuje na potrzeby raportowania. Zastosowania na tym materiale są mniej ambitne, ale nie wymagają zmian w systemach źródłowych i przez to nie wymagają mandatu. Uczciwie postawiony cel brzmi wtedy: budujemy zdolność i dowód, nie transformację.

Wariant trzeci — zacząć mimo wszystko, licząc na to, że problem rozwiąże się w trakcie. Ten wariant jest najczęściej wybierany i najczęściej kończy się opisanym wyżej harmonogramem z wypowiedzeniem w tygodniu trzydziestym ósmym. Nie polecam go, ale warto go nazwać, bo bywa wybierany nieświadomie — po prostu przez nieprzeprowadzenie rozmowy o mandacie w ogóle.

Rozróżnienie między wariantami jest w praktyce ważniejsze niż wybór między nimi. Organizacja, która świadomie wybrała wariant drugi i zakomunikowała jego ograniczenia, ma zdrowy projekt o skromnym zakresie. Organizacja, która wpadła w wariant trzeci, ma projekt z ambitnym zakresem i wbudowaną porażką, a różnicy nie widać przez pierwsze pół roku.

Kogo zatrudnić jako pierwszego, drugiego i trzeciego?

Kolejność poniżej sprawdza się w organizacjach, które zaczynają od zera i mają w perspektywie od jednego do trzech zastosowań. Uzasadnienie każdego kroku jest ważniejsze niż sama lista, bo pozwala ją świadomie zmienić.

Pierwszy: inżynier danych z mandatem. Doświadczenie w pracy z systemami źródłowymi, których nie kontroluje, jest w tym profilu ważniejsze od znajomości najnowszych narzędzi. Sygnał w rozmowie rekrutacyjnej: kandydat opowiada o negocjacjach z właścicielami systemów, o kompromisach i o tym, jak przekonał kogoś do zmiany. Kandydat, który mówi wyłącznie o narzędziach, ma inny profil i będzie potrzebny później.

Drugi: inżynier od wdrożenia i utrzymania. Osoba, która postawi warstwę udostępniania, monitorowanie jakości i kosztu, wersjonowanie oraz tryb wycofania zmiany. W wielu organizacjach ten etat da się w pierwszym roku pokryć osobą z istniejącego zespołu utrzymania, o ile dostanie na to realny czas — nie „dwadzieścia procent”, tylko wpisane dni.

Trzeci: zależnie od tego, gdzie boli. Jeżeli zastosowania są standardowe i działają na gotowych modelach, trzecim etatem powinien być kolejny inżynier danych, bo praca po tej stronie nie kończy się nigdy. Jeżeli pojawiła się potrzeba dostrajania modeli na własnych danych albo zastosowanie jest nietypowe — dopiero tu wchodzi ML Engineer i jest wtedy zatrudniany do konkretnego problemu, a nie „do AI”.

Rola, która nie jest etatem, ale musi mieć nazwisko od pierwszego dnia: właściciel zgodności i dokumentacji. Może to być część etatu osoby z obszaru ryzyka, prawnego albo zarządzania procesami. Nie powinien to być nikt z dwóch pierwszych etatów, bo ta praca zawsze przegra konkurencję z zadaniami inżynierskimi.

Rola, którą trzeba zapewnić z drugiej strony: właściciel procesu biznesowego z realnie przydzielonym czasem, rzędu jednego dnia w tygodniu. Bez niego zespół AI wybiera problemy do rozwiązania samodzielnie i wybiera je źle, bo wybiera te ciekawe.

Pierwsze dziewięćdziesiąt dni inżyniera danych

Kolejność zatrudniania proponowana w tym przewodniku ma sens tylko wtedy, gdy pierwsza osoba dostanie plan, który kończy się czymś widocznym. Bez tego zarzut o „hurtownię danych pod inną nazwą” jest trafny.

Dni 1–15: inwentaryzacja i jeden wybrany przepływ. Nie mapa wszystkich danych w firmie, tylko jeden proces, wskazany przez właściciela biznesowego, prześledzony od miejsca powstania danych do miejsca ich użycia. Produktem jest lista miejsc, w których dane powstają ręcznie, oraz lista przeszkód w dostępie z nazwiskami osób, które je zdejmą.

Dni 16–45: dostęp na żywo do jednego źródła. Wąsko, jedno źródło, jeden strumień, z monitorowaniem kompletności. To jest moment, w którym mandat jest zużywany po raz pierwszy i w którym okazuje się, czy istnieje naprawdę.

Dni 46–70: jakość u źródła. Uzgodnienie słownika dla dwóch, trzech pól wypełnianych ręcznie i wprowadzenie go w życie u osób, które je wypełniają. Najtańsza i najczęściej pomijana poprawa jakości w całym projekcie.

Dni 71–90: pierwsze zastosowanie na realnym strumieniu. Wąskie, oparte na gotowym modelu dostępnym jako usługa, obejmujące jeden fragment procesu — i działające na danych produkcyjnych, a nie na kopii.

Efekt po kwartale jest skromny w zakresie i mocny w charakterze: coś działa na prawdziwych danych. To jest zupełnie inna pozycja negocjacyjna wobec zarządu niż prototyp na kopii, choćby prototyp robił więcej.

Jakie kompetencje są dziś realnie deficytowe na polskim rynku?

Warto odróżnić deficyt rzeczywisty od deficytu pozornego, bo pierwszy wymaga pieniędzy albo augmentacji, a drugi wymaga tylko lepiej napisanego ogłoszenia.

Deficyt rzeczywisty — inżynierowie danych z doświadczeniem w środowiskach regulowanych i legacy. Osoby, które pracowały z systemami ERP, z bazami sprzed dekady, z danymi osobowymi i z partnerami serwisowymi. To jest wąska grupa, bo profil buduje się latami i jest niewidoczny w ogłoszeniach o pracę, które opisują wyłącznie narzędzia.

Deficyt rzeczywisty — osoby łączące rozumienie procesu biznesowego z techniczną wiarygodnością. Ktoś, kto usiądzie z księgowością i wyjdzie z opisem procesu, a potem usiądzie z inżynierem i przetłumaczy to na wymagania. Ten profil jest deficytowy w każdej dziedzinie, nie tylko w AI.

Deficyt pozorny — „specjalista od dużych modeli językowych”. Ogłoszenia opisują tę rolę jako rzadką, a wymagane umiejętności są w większości do nabycia w kilka tygodni przez dobrego inżyniera oprogramowania. Zatrudnianie na to osobnego, drogo wycenionego etatu jest zwykle błędem alokacji.

Deficyt pozorny — doktorat z uczenia maszynowego. Wartościowy przy pracy badawczej, rzadko krytyczny przy wdrożeniu opartym na gotowych modelach. Wymaganie go w ogłoszeniu zawęża pulę kandydatów i podnosi koszt bez proporcjonalnej korzyści.

Praktyczna konsekwencja: zanim podniesiecie widełki, sprawdźcie, czy nie szukacie profilu deficytowego pozornie. Zmiana treści ogłoszenia bywa tańsza niż zmiana budżetu o dwadzieścia procent.

Ile kosztuje zespół AI w Polsce i jak rozłożyć budżet?

Poniższe widełki to rzędy wielkości obserwowane na polskim rynku kontraktowym w pierwszej połowie 2026 roku, dla doświadczonych specjalistów, w modelu współpracy business-to-business. Traktujcie je jako punkt wyjścia do rozmowy, nie jako cennik — rozrzut między Warszawą a mniejszymi ośrodkami oraz między branżami jest istotny.

Inżynier danych z doświadczeniem w środowiskach produkcyjnych mieści się zwykle w przedziale od stu trzydziestu do stu dziewięćdziesięciu złotych za godzinę. Inżynier odpowiadający za wdrożenie i utrzymanie rozwiązań opartych na modelach — od stu pięćdziesięciu do dwustu dziesięciu. ML Engineer z realnym doświadczeniem produkcyjnym, nie tylko badawczym — od stu pięćdziesięciu do dwustu dwudziestu, przy czym górna granica dotyczy wąskich specjalizacji. Analityk danych — od stu dwudziestu do stu osiemdziesięciu.

Trzy uwagi, które mają większy wpływ na budżet niż same stawki.

Po pierwsze, koszt licencji i zużycia usług modelowych bywa niedoszacowany dwukrotnie, bo pilotaż liczy się na małym wolumenie. Zaplanujcie osobną pozycję i policzcie ją na realnym wolumenie rocznym, a nie na wolumenie pilotażu.

Po drugie, w zespołach mieszanych — część osób na umowie o pracę, część na kontrakcie — warto zwrócić uwagę na sposób organizacji pracy osób współpracujących w modelu business-to-business. Szczegółowe kierownictwo nad sposobem wykonania, sztywne godziny i imienne rozliczanie z indywidualnych wskaźników budują obraz podporządkowania, który bywa przedmiotem oceny przy kwalifikacji stosunku prawnego. To jest ryzyko organizacyjne, nie techniczne, ale materializuje się w budżecie.

Po trzecie, najdroższą pozycją w pierwszym roku bywa czas ludzi, których nie ma w budżecie projektu: właściciela procesu, zespołu utrzymującego system źródłowy, działu prawnego. Ten czas i tak zostanie zużyty. Lepiej wpisać go do planu, niż udawać, że projekt kosztuje tylko tyle, ile faktury.

Budżet pierwszego roku — struktura, nie kwota

Sama kwota jest mniej pouczająca niż jej rozkład, bo to rozkład ujawnia, czy plan jest realistyczny. Dla organizacji wchodzącej na poziom 1 z tabeli poniżej typowa struktura wygląda tak.

Około połowy budżetu to praca inżynierska po stronie danych — inżynier danych na pełny wymiar przez rok albo układ mieszany o równoważnym wolumenie. Około jednej piątej to praca wdrożeniowa i utrzymaniowa, często pokryta częściowo z istniejącego zespołu, ale wtedy trzeba ją wpisać jako koszt alternatywny, a nie jako zero. Około jednej dziesiątej to zużycie usług modelowych i licencje, przy czym ta pozycja rośnie po wdrożeniu, nie w trakcie budowy. Reszta, czyli mniej więcej jedna piąta, to praca, której nikt nie planuje: czas właściciela procesu, opinie prawne, uzgodnienia z partnerem serwisowym systemu źródłowego, dokumentacja.

Plan, w którym ostatnia pozycja wynosi zero, jest planem nierealistycznym — i jest to najczęstszy pojedynczy powód, dla którego projekty AI przekraczają budżet, mimo że stawki i zużycie usług zostały oszacowane poprawnie. Ta praca nie jest opcjonalna; jest jedynie niewidoczna w fakturach.

Warto też z góry rozstrzygnąć, kto płaci za zużycie usług modelowych po wdrożeniu. Jeżeli koszt zostaje w budżecie projektu, po roku pojawia się pozycja bez właściciela i pierwsze cięcie kosztów uderza w działające rozwiązanie. Jeżeli od początku obciąża jednostkę biznesową, która z rozwiązania korzysta, koszt ma właściciela, który go pilnuje — i to jest, nawiasem mówiąc, jedyny znany mechanizm powstrzymujący niekontrolowany wzrost tej pozycji przy większej liczbie zastosowań.

Jak dobrać skład zespołu do skali ambicji?

Poniższa tabela porządkuje cztery typowe poziomy. Warto ją czytać w poprzek: nie „jaki poziom chcemy osiągnąć”, tylko „na jakim jesteśmy i co jest najtańszym krokiem wyżej”.

Poziom	Co organizacja realnie robi	Minimalny skład	Rola, której najczęściej brakuje	Pierwszy krok wyżej
0 — eksperymenty	Pojedyncze osoby używają narzędzi AI we własnej pracy, bez wdrożenia	Brak zespołu; wystarczy polityka użycia i rejestr narzędzi	Nikt nie odpowiada za to, co gdzie wysyłane	Spisać rejestr używanych narzędzi i zasady dotyczące danych
1 — pierwszy proces	Jedno zastosowanie wspiera realny proces biznesowy	Inżynier danych z mandatem, inżynier wdrożeniowy, właściciel procesu na 1 dzień w tygodniu	Właściciel procesu z przydzielonym czasem	Podpisać mandat dla inżyniera danych
2 — kilka procesów	Trzy do pięciu zastosowań, wspólna warstwa udostępniania	4–6 osób, w tym nazwany właściciel zgodności	Właściciel zgodności i dokumentacji	Wydzielić wspólną warstwę integracyjną zamiast integracji per proces
3 — portfel	Powyżej dziesięciu zastosowań, część z dostrajaniem modeli	8–15 osób z podziałem na dane, wdrożenia i modelowanie	ML Engineer do konkretnych problemów, nie „do AI”	Wprowadzić rejestr systemów z rolą i klasą ryzyka dla każdego
4 — platforma	Wspólna platforma dla wielu jednostek biznesowych	Zespół platformowy plus zespoły produktowe korzystające z niego	Zarządzanie kosztem w podziale na jednostki	Rozliczać zużycie na jednostki biznesowe, inaczej koszt rośnie bez właściciela

Najczęstszy błąd widoczny w tej tabeli polega na próbie przeskoku z poziomu 0 na poziom 3 jedną rekrutacją. Organizacja zatrudnia ML Engineera z portfelem oczekiwań właściwym dla poziomu 3, podczas gdy realnie jest na poziomie 0 i brakuje jej wszystkiego, co poziomy 1 i 2 miały zbudować.

Kiedy budować własny zespół, a kiedy sięgnąć po augmentację?

Rozstrzyga jedno pytanie: czy kompetencja, o której mowa, będzie potrzebna za dwa lata w tym samym wymiarze.

Inżynieria danych zwykle będzie — praca po stronie źródeł nie kończy się po wdrożeniu, tylko przechodzi w utrzymanie i rozwój. To jest dobry kandydat na etat, nawet jeśli pierwsze miesiące trzeba pokryć z zewnątrz z powodu długości rekrutacji.

Kompetencje potrzebne punktowo — dostrajanie modelu, jednorazowa migracja danych, przygotowanie dokumentacji zgodności, przegląd architektury rozwiązania — rzadko uzasadniają etat. Zatrudnienie na stałe osoby do zadania, które zajmuje trzy miesiące, kończy się albo jej odejściem, albo wymyślaniem jej pracy, i drugi wariant jest gorszy.

Trzeci przypadek, najczęstszy w praktyce, to układ mieszany: etat na inżynierię danych, augmentacja na start i na szczyty. Sensowna proporcja w pierwszym roku to mniej więcej jedna osoba z zewnątrz na jedną wewnętrzną, z wyraźnym planem przekazania wiedzy. Przy czym plan przekazania wiedzy musi mieć zapisany produkt — działającą dokumentację i wspólnie przepracowane wdrożenie — bo „przekazanie wiedzy” bez produktu nie następuje.

Szerzej o kryteriach wyboru między tymi modelami pisaliśmy w tekście o strategicznej augmentacji zespołów IT.

Jak rekrutować, żeby rozmowa nie zamieniła się w quiz?

Rozmowa techniczna o AI ma silną skłonność do przekształcania się w sprawdzian ze znajomości nazw. To jest wygodne dla prowadzącego i bezużyteczne dla oceny, bo mierzy, co kandydat czytał w ostatnim kwartale.

Cztery pytania, które w naszej praktyce różnicują kandydatów lepiej.

„Opisz sytuację, w której dane okazały się inne, niż zakładałeś. Jak to wykryłeś?” Pytanie o wykrywanie, nie o naprawę. Kandydat z doświadczeniem produkcyjnym ma gotową odpowiedź, bo to jest jego codzienność.

„Musiałeś przekonać właściciela systemu, żeby coś w nim zmienił. Jak to wyglądało?” Odpowiedź „to nie było moje zadanie” nie dyskwalifikuje, ale wskazuje na profil bez mandatu.

„Co byś zrobił, gdyby model działał dobrze w testach i źle na produkcji?” Sprawdza sposób myślenia diagnostycznego. Odpowiedzi zaczynające się od zmiany modelu są słabsze niż te zaczynające się od porównania danych.

„Które twoje rozwiązanie zostało wyłączone i dlaczego?” Najlepsze pojedyncze pytanie w tym zestawie, bo nie ma społecznie poprawnej odpowiedzi, a każdy, kto wdrażał, ma taką historię.

Zadanie praktyczne, jeśli je stosujecie, powinno dotyczyć brudnych danych, a nie modelowania. Fragment realnego, zanonimizowanego zbioru z brakami, duplikatami i niekonsekwentnym formatem mówi o kandydacie więcej niż zadanie polegające na zbudowaniu klasyfikatora.

Warto też odwrócić kierunek rozmowy na kwadrans i pozwolić kandydatowi pytać. Osoby z doświadczeniem produkcyjnym pytają wtedy dokładnie o to, o czym jest ten przewodnik: kto jest właścicielem systemów źródłowych, jak wygląda droga do dostępu do danych produkcyjnych, kto rozstrzyga spory o priorytety i czy jest ktoś po stronie biznesu z przydzielonym czasem. Kandydat, który zadaje te pytania, przeszedł już przez opisany wyżej harmonogram i nie chce go powtarzać. Jest to zarazem najlepsza rekomendacja dla niego i najostrzejszy test dla was, bo odpowiedzi trzeba mieć przygotowane — a jeśli ich nie ma, to właśnie usłyszeliście, że nie jesteście gotowi na tę rekrutację.

Jak zatrzymać ludzi, gdy rynek płaci więcej?

Wynagrodzenie jest warunkiem koniecznym i przestaje działać jako narzędzie zatrzymywania powyżej poziomu rynkowego. Trzy rzeczy działają lepiej i wszystkie są tańsze.

Widoczny wpływ. Osoba, której rozwiązanie działa na produkcji i jest używane, zostaje dłużej niż osoba z lepszą stawką i trzema prototypami w szufladzie. To jest, nawiasem mówiąc, drugi argument za kolejnością zatrudniania z tego przewodnika: zespół, który wdraża, zatrzymuje ludzi lepiej niż zespół, który eksperymentuje.

Mandat. Ta sama rzecz, która decyduje o skuteczności, decyduje o satysfakcji. Ludzie odchodzą z organizacji, w których muszą prosić o wszystko.

Czas na naukę wpisany w kalendarz. Nie jako deklaracja, tylko jako wpisane dni. W dziedzinie zmieniającej się w tym tempie brak takiego czasu jest odbierany jako sygnał, że organizacja nie traktuje kompetencji poważnie. Warto przy okazji zauważyć, że rozporządzenie o sztucznej inteligencji nakłada obowiązek zapewnienia odpowiedniego poziomu kompetencji personelowi zajmującemu się systemami AI — więc ten czas i tak trzeba znaleźć, a lepiej zaplanować go jako korzyść niż odrabiać jako obowiązek.

Jakich błędów unikać przy budowie zespołu AI?

Pierwsza rekrutacja na ML Engineera bez rozwiązanego dostępu do danych. Główny wniosek tego tekstu i najczęstsza pojedyncza przyczyna dziewięciomiesięcznych projektów bez wdrożenia.

Zespół AI bez właściciela procesu po stronie biznesu. Kończy się wyborem ciekawych problemów zamiast kosztownych.

Odkładanie zgodności do momentu, w którym „będzie co dokumentować”. Rejestr systemów prowadzony od pierwszego wdrożenia kosztuje godzinę na wdrożenie. Odtworzony po trzech wdrożeniach kosztuje tygodnie i jest niepełny.

Mierzenie zespołu liczbą modeli albo liczbą pilotaży. Obie miary rosną najszybciej wtedy, gdy nic nie wchodzi na produkcję. Mierzcie liczbę procesów, w których rozwiązanie działa i jest używane co najmniej trzy miesiące.

Trzech analityków i pół inżyniera. Proporcja, która daje organizację zdolną do produkowania prezentacji.

Traktowanie augmentacji jako sposobu na uniknięcie decyzji organizacyjnych. Osoba z zewnątrz bez mandatu napotka dokładnie te same cztery przeszkody i napotka je szybciej, bo ma mniej kredytu zaufania w organizacji.

Jak ARDURA Consulting pomaga zbudować zespół AI?

Nasza rola zaczyna się zwykle wcześniej, niż klienci się spodziewają — nie od dostarczenia ML Engineera, tylko od sprawdzenia, czy dostęp do danych jest rozwiązany, i od pomocy w napisaniu jednostronicowego mandatu, który to umożliwi. Ta rozmowa bywa krótka i czasem kończy się rekomendacją, żeby wstrzymać rekrutację o kwartał. Jest to tańsze niż jej alternatywa.

Kompetencje udostępniamy w modelu Staff Augmentation i Time & Materials: inżynierów danych i inżynierów wdrożeniowych na okres, w którym własna rekrutacja jeszcze trwa, oraz specjalistów punktowo — do dostrajania modeli, do przygotowania dokumentacji zgodności albo do przeglądu rozwiązania przed wejściem na produkcję. Standardowy układ pierwszego roku to jedna osoba z zewnątrz obok jednej wewnętrznej, z zapisanym produktem przekazania wiedzy.

Najtańszy krok, który możecie wykonać w tym tygodniu bez niczyjej pomocy: napiszcie jednostronicowy mandat dla przyszłego pierwszego etatu i przedstawcie go do podpisu. Reakcja organizacji na ten dokument powie wam o gotowości do wdrożenia AI więcej niż jakikolwiek audyt dojrzałości.

Skontaktuj się z nami, jeśli chcesz omówić skład zespołu przy konkretnym zastosowaniu.