Gdy firma decyduje się wdrożyć AI, pierwszy odruch jest zwykle taki sam: zatrudnijmy data scientista. Ten odruch jest zrozumiały — data scientist to ikoniczna rola ery AI. W praktyce jednak właśnie ten nabór bywa pierwszym błędem, który spowalnia lub zatrzymuje projekt.
Właściwy skład zespołu zależy od tego, co konkretnie budujesz: system RAG nad dokumentami firmowymi różni się od predykcyjnego modelu anomalii na linii produkcyjnej, który różni się od autonomicznego agenta w obsłudze klienta. Każdy z tych projektów wymaga innego zestawu ludzi — a niektóre z nich w ogóle nie potrzebują wewnętrznego zespołu.
Dlaczego data scientist nie jest pierwszą odpowiedzią
Data scientist tradycyjnie koncentruje się na eksploracyjnej analizie danych, modelowaniu statystycznym i eksperymentowaniu. Są wartościowi tam, gdzie nie wiesz, czego szukasz w danych — w analityce predykcyjnej, przy wykrywaniu wzorców w danych historycznych, przy testach A/B.
Większość projektów AI, których firmy faktycznie potrzebują, nie dotyczy jednak odkrywania wzorców. To integracje systemowe: LLM podłączony do dokumentacji firmowej, agent weryfikujący zamówienia w ERP, automatyzacja triażu e-maili. Tutaj potrzebujesz kogoś, kto potrafi zbudować oprogramowanie produkcyjne — nie analizę eksploracyjną.
W praktyce wygląda to tak: firma zatrudnia data scientista, ten robi ładne eksperymenty w notatniku Jupyter, wyniki wyglądają obiecująco. Potem pojawia się pytanie: „kiedy wdrożymy to na produkcję?" — i zapada cisza. Data scientist nie jest inżynierem oprogramowania, nie zna Dockera, CI/CD, projektowania API ani monitorowania systemu produkcyjnego. Projekt utyka w fazie prototypu.
Role, których naprawdę potrzebujesz
ML / AI engineer — trzon zespołu
To rola, którą większość firm lekceważy, a która jest kluczowa dla produkcyjnego AI. ML/AI engineer łączy dwie kompetencje: rozumie modele (fine-tuning, embedding, inference, prompt engineering) i potrafi opakować te możliwości w solidne oprogramowanie (API, systemy kolejkowe, monitoring, testowanie).
W praktyce: inżynier ML skonfiguruje pipeline RAG z wyszukiwaniem hybrydowym, dobierze właściwy model embeddingów, nastawi retrieval i udostępni wynik jako produkcyjne API z obserwowalnością. Data scientist zrobiłby pierwszy krok; inżynier oprogramowania bez kontekstu ML zrobiłby ostatni. ML/AI engineer poradzi sobie z oboma.
Dla firm budujących z modelami frontier przez API (Claude, GPT, Gemini) rola inżyniera ML/AI jest jeszcze ważniejsza — chodzi tu mniej o trenowanie, a więcej o orkiestrację, prompt engineering, tool calling i integracje. Więcej o tym, co wpływa na koszty i niezawodność, w artykule Koszty agenta AI na produkcji.
Ekspert domenowy — bez niego projekt nigdzie nie zmierza
To rola, którą firmy najczęściej pomijają, a jej brak jest drugim najczęstszym powodem niepowodzeń (po niskiej jakości danych).
Ekspert domenowy to ktoś, kto głęboko rozumie proces, który automatyzujesz. W praktyce jest to doświadczony operator, kierownik działu, technik lub specjalista w danej dziedzinie. Ta osoba nie wie nic o LLM, ale wie dokładnie: - Które odpowiedzi są poprawne, a które tylko wyglądają poprawnie - Gdzie są przypadki brzegowe, wyjątki i sytuacje, w których system zawodzi - Jak wygląda „dobry wynik" z perspektywy biznesu — nie z perspektywy metryki accuracy
Bez eksperta domenowego inżynier ML optymalizuje metrykę, nie realną wartość. Efektem jest system, który świetnie prezentuje się na demo, a na produkcji w kółko powtarza te same błędy.
Ekspert domenowy nie musi być pełnoetatowym członkiem zespołu. Wystarczy 4–8 godzin tygodniowo na przeglądanie wyników, kalibrację oceny i cykle informacji zwrotnej.
Inżynier danych — tylko gdy masz problem z danymi
Jeśli twój projekt AI zależy od pipeline'ów danych — czyszczenie, transformacja, streaming zdarzeń z maszyn, integracja wielu źródeł — potrzebujesz inżyniera danych. Ten profil buduje infrastrukturę, która niezawodnie dostarcza dane do AI.
Jeśli jednak budujesz RAG nad istniejącymi dokumentami lub agenta wywołującego istniejące API, inżynier danych nie jest krytyczny w pierwszej fazie. Nie przeceniaj potrzeby tej roli — wprowadź ją wtedy, gdy faktycznie rozwiązujesz problem z danymi, a nie profilaktycznie.
Inżynier MLOps — od pewnej skali
MLOps obejmuje wdrażanie modeli, monitoring dryftu, zarządzanie wersjami, pipeline retrainingu. To krytyczna rola, ale dopiero wtedy, gdy masz modele na produkcji, które wymagają utrzymania i aktualizacji.
Przy pierwszych projektach tę funkcję zazwyczaj pełni samodzielnie inżynier ML — posiadanie dedykowanego specjalisty MLOps jest zbędne, dopóki nie ma czym zarządzać. Wprowadź go wtedy, gdy zarządzasz więcej niż 3–5 modelami produkcyjnymi lub obsługujesz cykle retrainingu.
Product owner — niedoceniana, lecz niezbędna rola
Każdy projekt AI potrzebuje kogoś, kto odpowiada za to, jaki problem rozwiązujesz i jak mierzysz sukces. Bez tej roli inżynier ML/AI optymalizuje technicznie interesujące rzeczy, a nie wartość biznesową.
Product owner (lub AI product manager) definiuje metryki sukcesu przed startem, priorytetyzuje przypadki użycia według ROI i pośredniczy w komunikacji między zespołem technicznym a interesariuszami. Ta rola może być obsadzona przez wewnętrznego project managera z wystarczającym rozumieniem technicznym — nie musi to być specjalista AI.
Minimalny funkcjonalny zespół dla pierwszego projektu
Z praktyki — dla typowego pierwszego produkcyjnego projektu AI (system RAG, agent, integracja LLM):
- 1× ML/AI engineer (pełny etat podczas wdrożenia)
- 1× ekspert domenowy (niepełny etat, 4–8 h/tydzień)
- 1× product owner / osoba odpowiedzialna po stronie biznesu (niepełny etat, 2–4 h/tydzień)
To minimalny funkcjonalny zespół. Mniej niż trzy osoby w tym składzie to konfiguracja ryzykowna — albo brakuje kompetencji technicznych, albo brakuje powiązania z realnym kontekstem biznesowym.
Przy bardziej złożonym projekcie (system multi-agentowy, fine-tuning własnego modelu, integracja z wieloma systemami) rozszerz skład o inżyniera danych i specjalistę MLOps. O tym, kiedy sensowny jest fine-tuning modelu, piszemy w artykule RAG vs fine-tuning — jak decydować.
Zespół wewnętrzny vs. partner — kiedy co
To pytanie, które firmy zadają za późno — zazwyczaj dopiero wtedy, gdy proces rekrutacji utknął lub projekt się zablokował.
Buduj wewnętrzny zespół, gdy: - AI jest rdzeniem twojego produktu lub kluczową przewagą konkurencyjną (nie wsparciem istniejącego procesu) - Masz długoterminowy horyzont inwestycji (12+ miesięcy) i stabilny produkt do rozbudowy o AI - Potrzebujesz pełnej kontroli nad danymi, modelami i pipeline'em (środowisko regulowane, systemy krytyczne pod RODO) - Planujesz szybko iterować w krótkich cyklach — zewnętrznie zarządzany zespół jest w tym wolniejszy
Zaangażuj zewnętrznego partnera, gdy: - Realizujesz pierwszy lub drugi projekt AI i nie masz jeszcze wewnętrznych kompetencji - Potrzebujesz szybkiego rezultatu (3–6 miesięcy) — rekrutacja i onboarding wewnętrznego zespołu trwa zazwyczaj 4–9 miesięcy - Przypadek użycia jest dobrze zdefiniowany i po wdrożeniu wymaga tylko utrzymania, nie aktywnego rozwoju - Chcesz transferu wiedzy — dobry partner nie tylko dostarczy rozwiązanie, ale nauczy wewnętrzny zespół, jak z nim pracować
O wyborze między własną implementacją a gotowym rozwiązaniem pisaliśmy dokładniej w artykule Build vs buy rozwiązanie AI.
Model hybrydowy sprawdza się dobrze: zewnętrzny partner dostarcza pierwszy projekt, wewnętrzny zespół uczy się i przejmuje odpowiedzialność za utrzymanie i rozwój. Kluczowe jest, by partner aktywnie wspierał ten transfer — nie tylko dostarczył i odszedł.
Częste błędy przy budowaniu zespołu
Szukasz „eksperta AI" — i nie możesz go znaleźć
Ogólny ekspert AI nie istnieje. Każdy naprawdę doświadczony specjalista ma specjalizację: inference i serving, fine-tuning, orkiestracja agentów, architektura RAG. Szukaj kogoś z konkretną relewancją do twojego przypadku użycia — nie uniwersalnego geniusza.
Niedoceniasz czasu eksperta domenowego
Firmy zwykle planują „kilka godzin miesięcznie na konsultacje". W praktyce dobry projekt AI wymaga regularnego, konsekwentnego zaangażowania eksperta domenowego — nie jednorazowego kickoffu na początku i sign-off na końcu.
Mylisz eksperymentowanie z kompetencją produkcyjną
Kandydat, który pokazuje ci imponujące prototypy w notatniku Colab, niekoniecznie ma doświadczenie z wdrożeniem produkcyjnym. Pytaj o konkretne przykłady: Co dokładnie wdrożyłeś na produkcję? Jak obsługiwałeś monitoring? Jak reagowałeś na regresję jakości? Odpowiedzi na te pytania odróżnią eksperymentatora od inżyniera.
Skalujesz zanim zwalidowałeś przypadek użycia
Widzimy to regularnie: firma zatrudnia cały zespół (3–5 osób), kupuje infrastrukturę GPU i po sześciu miesiącach odkrywa, że przypadek użycia nie był wystarczająco wartościowy na wdrożenie produkcyjne. Najpierw waliduj z minimalnym zespołem i zewnętrznym rozwiązaniem; scale-up przyjdzie wtedy, gdy wiesz, co działa.
Sygnały ostrzegawcze — zespół ma zły skład
Z praktyki — czerwone flagi, które widzimy u klientów:
- Projekt utknął w fazie prototypu dłużej niż 3 miesiące — zazwyczaj brakuje inżyniera ML/AI z doświadczeniem produkcyjnym lub product ownera, który zdefiniowałby kryteria wyjścia
- System „nie działa w praktyce" mimo dobrych benchmarków — brakuje eksperta domenowego w cyklu oceny
- Zespół nie potrafi odpowiedzieć na pytanie „jak mierzycie sukces" — brakuje product ownera lub metryki są zdefiniowane czysto technicznie (accuracy, F1) bez powiązania z biznesem
- Rekrutacja trwa 6+ miesięcy bez efektu — profil jest zbyt ogólny lub oczekiwania płacowe nie odpowiadają rynkowi; rozważ zewnętrznego partnera dla pierwszej fazy
Jak postępować, gdy zaczynasz
Jeśli budujesz pierwszy projekt AI i nie masz wewnętrznego zespołu, zalecamy:
- 1.Zdefiniuj przypadek użycia i metryki sukcesu przed jakąkolwiek rekrutacją — bez tego kroku nie wiesz, kogo szukasz
- 2.Zidentyfikuj eksperta domenowego wewnętrznie — to rola, której nie możesz kupić z zewnątrz
- 3.Rozważ zewnętrznego partnera dla pierwszej fazy — szybszy start, niższe ryzyko, możliwość transferu wiedzy
- 4.Rekrutację inżyniera ML/AI rozpocznij równolegle z pilotem — zespół będzie gotowy przejąć projekt we właściwym czasie
Więcej o tym, jak ustrukturyzować pierwsze 90 dni projektu AI, znajdziesz w artykule Jak zacząć z AI w firmie.
Najczęstsze pytania
Czy do projektu AI z LLM potrzebuję data scientista?
W większości przypadków nie — przynajmniej nie jako rolę główną. Data scientist jest wartościowy przy analizie eksploracyjnej i modelowaniu statystycznym. Projekty oparte na LLM (RAG, agenty, integracje) potrzebują przede wszystkim inżyniera ML/AI, który rozumie zarówno modele, jak i oprogramowanie produkcyjne. Data scientist może uzupełniać zespół później — na przykład przy ewaluacji lub analizie wyników.
Ile osób minimum potrzeba do produkcyjnego projektu AI?
Z praktyki: minimum to trzy role — ML/AI engineer (pełny etat), ekspert domenowy (niepełny etat) i product owner / osoba odpowiedzialna po stronie biznesu (niepełny etat). Zespół złożony z jednej osoby lub bez eksperta domenowego ma znacznie wyższe ryzyko niepowodzenia lub utknięcia w fazie prototypu.
Czy lepiej zatrudnić zespół czy skorzystać z zewnętrznego partnera?
Zależy od twojego horyzontu i od tego, na jakim etapie jesteś. Przy pierwszym projekcie rekomendujemy zewnętrznego partnera lub model hybrydowy — jest szybszy i ogranicza ryzyko kosztownej rekrutacji przed walidacją przypadku użycia. Wewnętrzny zespół ma sens, gdy AI jest rdzeniem twojego produktu i masz długoterminowy horyzont inwestycji.
Jak rozpoznać, że kandydat ma doświadczenie produkcyjne, a nie tylko prototypowe?
Pytaj o konkretne wdrożenia: Co dokładnie działało na produkcji? Jaki był wolumen danych lub użytkowników? Jak obsługiwałeś monitoring i stany błędów? Jak reagowałeś, gdy jakość się pogorszyła? Prototypiści odpowiadają ogólnie; inżynierowie produkcyjni opisują konkretne decyzje i kompromisy.
Czy ekspert domenowy musi rozumieć AI?
Nie — i nie jest to nawet pożądane. Ekspert domenowy musi rozumieć proces, który automatyzujesz: umieć ocenić, czy wynik jest poprawny, identyfikować przypadki brzegowe i definiować, co oznacza „dobry wynik" z perspektywy biznesu. Wiedza techniczna z zakresu AI nie jest tu wymagana.
*Jeśli zastanawiasz się nad składem zespołu do projektu AI lub rozważasz, co budować wewnętrznie, a co powierzyć partnerowi, chętnie umówimy się na bezpłatną konsultację. Pomożemy ocenić, jakich ról faktycznie potrzebujesz — i kiedy zewnętrzna współpraca jest bardziej opłacalna niż rekrutacja.*