Każdy drugi CTO zadaje dziś to samo pytanie: „Od czego zacząć z AI, żeby to nie była kolejna wyrzucona inwestycja?" Odpowiedź nie leży w technologii. Leży w dyscyplinie pierwszych trzech miesięcy — w tym, co zmapujecie, czego odmówicie, komu dacie odpowiedzialność i jak zmierzycie wynik. Ten artykuł to rama decyzyjna na pierwsze 90 dni — nie techniczna instrukcja instalacji modelu.
Większość źródeł podaje, że 75–95 % projektów AI nie osiąga planowanej wartości biznesowej. Metodologia badań może wpływać na liczby, ale trend jest spójny: piloty powstają, kończą się po 3–6 miesiącach, wartość nie przychodzi. Przyczyna jest zazwyczaj ta sama — nie zła technologia, ale brak przygotowania przed pierwszym import openai.
Dni 1–30: Zmapujcie teren przed pierwszym kopnięciem łopaty
Inwentaryzacja use-case'ów, nie lista zakupów
Pierwszy miesiąc nie jest o wyborze technologii. Jest o zrozumieniu, gdzie firma traci czas i pieniądze na powtarzalnych zadaniach kognitywnych — czytaniu dokumentów, odpowiadaniu na te same pytania, ekstrakcji danych z formularzy, pisaniu standardowych raportów.
Szybki sposób: poproście 5–10 osób z różnych działów, żeby na kartce wypisały, co robią co tydzień powtarzalnie i co ich irytuje. Większość tego, co wpiszą, będzie kategorycznie różna od „chcemy chatbota". Pojawią się: ręczne przepisywanie e-maili od klientów do CRM, szukanie odpowiedzi w dokumentacji technicznej, przygotowywanie podkładów pod oferty cenowe, weryfikacja dokumentów dostawy.
Każdy use-case oceniajcie na dwóch osiach: częstotliwość (jak często się pojawia) i wartość (ile kosztuje jedno wykonanie — czas × stawka godzinowa × liczba powtórzeń miesięcznie). To nie jest ćwiczenie akademickie — to fundament pod rozmowę o ROI, którą będziecie mieć z zarządem za 60 dni.
Rozróżnienie: chatbot, copilot czy agent
Przed wyborem narzędzia rozróżnijcie, czego właściwie potrzebujecie. Chatbot, copilot i agent to różne wzorce architektoniczne o różnych kosztach i złożoności.
Chatbot odpowiada na pytania — odpowiedni do obsługi klienta lub wewnętrznego FAQ. Najprostszy we wdrożeniu, najniższe oczekiwania.
Copilot asystuje pracownikowi w jego narzędziu — w systemie MES, w ERP, w dokumentacji. Pracownik podejmuje decyzje, AI proponuje i przygotowuje. Typowy pierwszy krok dla firm przemysłowych.
Agent planuje, wywołuje narzędzia, wykonuje wieloetapowe akcje autonomicznie. Mocniejszy, ale wielokrotnie bardziej złożony — wymaga obsługi błędów, observability i starannego pilotażu. Nie do pierwszego projektu.
Dla 80 % firm w pierwszych 90 dniach właściwa odpowiedź brzmi: copilot nad wewnętrzną dokumentacją lub RAG nad firmową bazą wiedzy.
Dane: otwórzcie puszkę Pandory od razu
Projekt AI nie upada na modelach — upada na danych. W pierwszym miesiącu sprawdźcie:
- Gdzie są dokumenty, instrukcje, przepisy techniczne, zapisy serwisowe — i w jakim formacie (PDF, Word, tabele, bazy danych)?
- Kto ma dostęp? Czy wrażliwość danych jest zdefiniowana (RODO, tajemnica handlowa)?
- Jaka jest aktualność — czy dokumenty są na bieżąco, czy z 2018 roku?
Cisco AI Readiness Index podaje, że tylko ~34 % firm ocenia swoją gotowość danych jako wystarczającą. W praktyce oznacza to: skanowane archiwalne PDF-y, ręcznie kodowane arkusze Excel i dokumentacja istniejąca wyłącznie w głowach starych pracowników. To nie jest powód, żeby nie zaczynać — to powód, żeby zacząć od audytu danych, nie od modelu.
Dni 31–60: Pilotaż, który coś rozstrzyga
Wybór pierwszego use-case'u: ROI-pozytywny, nie najbardziej efektowny
Najczęstszy błąd: firma wybiera najbardziej ambitny use-case — „chcemy AI do przewidywania awarii linii produkcyjnej" — i pilotaż zatrzymuje się na niewystarczających danych historycznych, niejasnym kryterium sukcesu i braku eksperta domenowego w zespole.
Pierwszy use-case musi spełniać trzy warunki jednocześnie:
- 1.Mierzalna baseline — wiecie, ile godzin aktualnie kosztuje dane zadanie. Bez baseline nie ocenicie wyniku.
- 2.Ograniczony zakres — pilotaż mieści się w 4–6 tygodniach włącznie z ewaluacją. Im dłuższy pilotaż, tym niższe prawdopodobieństwo, że dotrze do końca.
- 3.Realny fundament danych — macie co najmniej 50–200 dokumentów lub transakcji, na których możecie testować pilotaż. Nie bazę danych z przyszłości.
Dobry pierwszy use-case dla firmy produkcyjnej: Q&A nad dokumentacją techniczną (RAG nad instrukcjami serwisowymi, certyfikatami, normami). Technicy szukają odpowiedzi na te same pytania dziesięć razy dziennie, dokumentów jest wystarczająco, a mierzalność jest oczywista (czas wyszukiwania odpowiedzi przed i po).
Architektura pilotażu: lokalnie czy w chmurze?
Dla firm z wrażliwymi dokumentami technicznymi lub obciążeniem regulacyjnym (przemysł maszynowy, chemiczny, medyczny) pierwsze pytanie brzmi: „Czy nasze dane mogą opuścić sieć?"
Jeśli nie — model lokalny (Ollama z Qwen 3 lub Mistral, działający na firmowym serwerze lub stacji roboczej) z lokalną bazą wektorową to właściwy wybór. Wydajność będzie niższa niż frontier cloud model, ale ryzyko compliance wynosi zero.
Jeśli tak — cloud API (Claude Sonnet, GPT, Gemini Flash) przez Azure OpenAI lub bezpośrednio przez API przynosi lepszą wydajność out-of-the-box przy niższym obciążeniu IT w fazie pilotażu.
Szczegółowe porównanie znajdziecie w artykule Lokalne LLM vs chmura, a także w dyskusji RAG vs fine-tuning — kiedy co.
Kryteria sukcesu przed startem pilotażu
Zdefiniujcie, co jest sukcesem, przed pilotażem. Nie po nim. Typowe metryki:
- Czas zaoszczędzony na zadanie — cel: -30 % lub konkretna liczba minut
- Dokładność odpowiedzi — cel: >85 % poprawnych odpowiedzi w ocenie eksperta domenowego (20–50 pytań testowych)
- Adopcja przez użytkowników — cel: >60 % członków zespołu korzysta z systemu co najmniej 3× w tygodniu po 4 tygodniach
- Wskaźnik błędów — cel: <5 % odpowiedzi zawierających faktycznie nieprawdziwą informację
Bez tych liczb pilotaż skończy się debatą „czy to działa?" zamiast danymi, które odpowiedzą tak albo nie.
Dni 61–90: Wyniki, decyzja, plan
Ewaluacja pilotażu: trzy pytania
Po 4–6 tygodniach pilotażu odpowiedzcie na trzy pytania:
1. Czy działa wystarczająco dobrze? Porównajcie z baseline sprzed pilotażu. Jeśli cel osiągnięty — kontynuujcie. Jeśli nie — dlaczego? Dane, prompt, integracja, czy był to zły wybór use-case'u?
2. Czy ludzie z tego korzystają? Technicznie działający system, którego nikt nie używa, nie ma wartości biznesowej. Adopcja w pierwszych tygodniach prognozuje długoterminowy wynik. Jeśli adopcja jest niska, sprawdźcie dlaczego — UI, zaufanie, szkolenie, czy system po prostu nie oszczędza czasu?
3. Gdzie jest największy opór? Każdy projekt AI napotka „to nie będzie działać". Zidentyfikujcie, skąd opór pochodzi — bezpieczeństwo IT (dane), średni management (kontrola), pracownicy (strach przed utratą pracy). Każde ma inną odpowiedź.
Kalkulacja ROI: prosta, ale rzetelna
Dla decydentów, którzy muszą obronić kontynuację, potrzebujecie liczb. Mierzenie ROI projektów AI to osobny temat, ale podstawowa rama:
- Oszczędność czasu: (liczba godzin/miesiąc zaoszczędzonych) × (stawka godzinowa pracownika) × 12 = roczna wartość
- Koszty projektu: infrastruktura + koszty API + czas inżyniera (pilotaż + produkcja)
- Okres zwrotu: koszty / miesięczna wartość = liczba miesięcy do zwrotu
Dla typowego RAG copilota przy 5–10 pracownikach technicznych, oszczędność 30–60 minut dziennie: roczna wartość jest mierzalna w dziesiątkach tysięcy euro przy środkowoeuropejskich stawkach. Koszty pilotażu są rzędu 10–30 razy niższe, jeśli dysponujecie istniejącą infrastrukturą i kilkoma dniami pracy inżynierskiej.
Build vs. buy: decyzja na 90. dzień
Po pilotażu macie wystarczająco danych na decyzję build vs. buy. Zasada z praktyki:
Kupcie (narzędzie SaaS, zintegrowany plugin), jeśli: use-case jest generyczny (obsługa klienta, podsumowywanie e-maili), nie ma krytycznej dyferencjacji i zespół nie ma pojemności AI engineeringowej.
Zbudujcie (własny pipeline RAG, własny agent), jeśli: dane są wrażliwe i nie mogą trafić do chmury, use-case jest domenowo specyficzny (normy maszynowe, wewnętrzne procesy), albo planujecie skalowanie na więcej use-case'ów, gdzie wspólne komponenty (embedding, wektorowa baza danych, orkiestracja) opłaca się współdzielić.
Połączcie — najczęściej właściwa odpowiedź w 2026: kupcie dla warstw commodity (model API, vector DB), budujcie dla „ostatniej mili" (prompty, logika retrieval, integracje, eval harness).
Czego unikać: pięć pułapek pierwszych 90 dni
1. Hype use-case bez baseline
„Chcemy predyktywne utrzymanie ruchu" albo „chcemy AI strategicznego analityka" — ambitne, wizualnie atrakcyjne, a przy bliższym spojrzeniu bez mierzalnej baseline, bez danych historycznych i bez eksperta domenowego w zespole. Takie projekty umierają w 3. miesiącu.
Zasada: jeśli nie macie baseline, macie aspirację, nie projekt.
2. Vendor lock-in w fazie pilotażu
Niektórzy dostawcy oferują „bezpłatny pilotaż" w zamian za zobowiązanie. Zanim podpiszecie, przetestujcie alternatywę — open-source stack (LangChain/LlamaIndex + Qdrant + model lokalny) potrafi zrealizować większość pilotaży bez zobowiązań. Vendor lock-in jest uzasadniony po walidacji use-case'u, nie przed nią.
3. Zespół AI bez eksperta domenowego
Inżynier AI potrafi zbudować pipeline. Nie potrafi ocenić, czy odpowiedź o obwodzie hydraulicznym jest poprawna. Bez technika lub technologa, który waliduje wyniki w pilotażu, nie macie podstawy do mierzenia dokładności. Ekspert domenowy to nie „nice to have" — to blocker.
4. Jeden pilotaż = strategia produkcyjna
Pilotaże potwierdzają zasadę, nie gotowość produkcyjną. Od pilotażu do produkcji potrzebujecie: audytu bezpieczeństwa (prompt injection, data egress), MLOps (monitoring, wersjonowanie promptów, eval regression) i change management (szkolenie użytkowników, SLA, ścieżka eskalacji gdy AI odpowie niepoprawnie).
5. Ignorowanie EU AI Act
Jeśli wasz use-case wchodzi w łańcuch decyzyjny mający wpływ na ludzi (rekrutacja, ocena, klasyfikacja ryzyka), od 2 sierpnia 2026 obowiązują wymagania EU AI Act dotyczące przejrzystości i klasyfikacji ryzyka. Compliance to nie tylko ćwiczenie prawnicze — wpływa na architekturę systemu (audit log, explainability, human oversight). Im wcześniej uwzględnicie to w projekcie, tym tańsza będzie zmiana.
Zespół: kogo potrzebujecie i kogo nie
Projekt AI to nie solo dyscyplina. System produkcyjny (nie tylko pilotaż) typowo wymaga kombinacji:
- Inżynier AI/ML — pipeline RAG, fine-tuning, orkiestracja agentów, eval
- Inżynier danych — pipeline danych, czyszczenie, wektorowa baza danych
- Ekspert domenowy — walidacja wyników, tworzenie zestawu eval
- Product owner — metryki sukcesu, priorytetyzacja use-case'ów, stakeholder management
- IT/bezpieczeństwo — data egress, dostępy, compliance
W fazie pilotażu pełna obsada nie jest konieczna. Inżynier AI + ekspert domenowy + product owner udźwigną pilotaż. MLOps i inżynier danych wchodzą do produkcji.
Ostrzeżenie: zespół poniżej 3 osób odpowiedzialnych za projekt AI jest ryzykowny nawet dla pilotażu. Jeden ubytek kluczowej osoby zatrzymuje cały projekt.
Zespół wewnętrzny vs. partner zewnętrzny zależy od strategii: jeśli AI to długoterminowa kompetencja firmy, budujcie wewnętrznie. Jeśli potrzebujecie szybko walidować 2–3 use-case'y i nie macie pojemności AI, zewnętrzny partner ze stałymi ramami projektowymi jest szybszy. Kombinacja — partner zewnętrzny pilotuje, zespół wewnętrzny przejmuje produkcję — to rozsądny model hybrydowy.
Pomiar po 90 dniach: cztery pytania do retrospektywy
Na koniec pierwszych 90 dni odpowiedzcie szczerze:
- 1.Czy pilotaż osiągnął kryteria sukcesu, które zdefiniowaliśmy przed jego startem? (Jeśli ich nie zdefiniowaliście — to samo w sobie jest lekcją.)
- 2.Czy potrafimy wskazać kolejne 2–3 use-case'y, gdzie ta sama infrastruktura przyniesie kolejną wartość? (Jeśli nie — ryzyko, że pilotujemy bez strategii.)
- 3.Czy projekt ma sponsora na poziomie zarządu, który potrafi sformułować wartość biznesową? (Projekty bez sponsora CEO/COO historycznie statystycznie znacznie częściej upadają niż te z nim.)
- 4.Czy wiemy, jak będzie wyglądał system w produkcji — monitoring, eval, cykl aktualizacji? (Jeśli nie — pilotaż jest proof-of-concept, nie fundament do skalowania.)
Te cztery pytania nie oceniają technologii. Oceniają gotowość organizacji — a ta decyduje o wyniku bardziej niż jakikolwiek model.
Najczęstsze pytania
Ile to wszystko kosztuje — pierwsze 90 dni?
Zależy od zakresu, ale orientacyjnie: pilotaż z RAG copilotem nad wewnętrzną dokumentacją, na cloud API, z partnerem zewnętrznym — rzędu kilku tysięcy euro za czas inżynierski plus niskie miesięczne koszty API (dla MŚP typowo dziesiątki do kilkuset euro przy typowym wolumenie). Wdrożenie lokalne (własny serwer, model open-weight) ma wyższy jednorazowy koszt wejścia, ale niższe koszty operacyjne.
Czy potrzebujemy własnego GPU?
Na etapie pilotażu zazwyczaj nie. Cloud API (Claude, Gemini Flash, GPT) lub Ollama na istniejącym firmowym serwerze ze zwykłym CPU udźwignie pilotaż. Własne GPU ma sens, gdy: dane nie mogą trafić do chmury, wolumen inferencji jest wysoki (tysiące zapytań dziennie) albo planujecie fine-tuning.
Co jeśli nasze dane nie są gotowe?
Nieprzygotowanie danych to nie blocker dla pilotażu — to parametr wejściowy. Pilotaż na 50 dobrze przygotowanych dokumentach jest lepszy niż pilotaż na 5 000 niskiej jakości. Zacznijcie od złotego zestawu 50–100 dokumentów, które ręcznie sprawdzicie. Skalowanie produkcyjne rozwiązujecie po walidacji use-case'u.
Jak wytłumaczyć pracownikom, że wdrażamy AI?
Bezpośrednio i konkretnie — nie „AI zajmie wasze stanowisko", ale „AI zajmie szukanie w instrukcjach, żebyście mieli więcej czasu na rozwiązywanie problemów". Zaangażujcie pracowników w pilotaż jako „ewaluatorów AI" — ich rola to testowanie i zgłaszanie błędów. Ownership pilotażu zmniejsza opór wobec produkcji.
Czy lepiej zacząć od jednego dużego projektu czy od kilku małych pilotaży?
Z praktyki: jeden dobrze wybrany pilotaż z jasnym ROI jest lepszy niż trzy równoległe eksperymenty. Równoległe pilotaże rozpraszają uwagę, obniżają jakość danych dla każdego z nich i utrudniają ewaluację. Skalujcie na więcej use-case'ów po pierwszym sukcesie — nie przed nim.
*MP Industrial Solutions pomaga firmom przejść przez pierwsze 90 dni w sposób ustrukturyzowany — od inwentaryzacji use-case'ów przez wybór architektury po definicję mierzalnych kryteriów sukcesu. Jeśli zastanawiacie się, od czego zacząć i chcecie uniknąć pilotaży, z których nic nie wynika, chętnie spotkamy się na bezpłatną konsultację wstępną.*