Pół roku temu Zarząd zatwierdził projekt strategii AI. Slajdy wyglądały dobrze. Mapa drogowa była szczegółowa. Ramy governance miały własny dokument. Honorarium było znaczące.
Dziś pilotaże nadal działają tylko na środowiskach testowych. Na produkcji nie działa nic. Biznes case ze slajdu 47 się nie zmaterializował. Konsultanci są już przy kolejnym kliencie; Tobie został stustronicowy dokument i brak działających systemów.
To nie jest wyjątkowy przypadek. Ten sam wzorzec widać w wielu dużych organizacjach. Standardowe wyjaśnienia — technologia „nie była gotowa”, dane były „brudne”, „zawiodło zarządzanie zmianą” — opisują objawy, nie przyczynę.
Pierwotny problem jest strukturalny. I zaczyna się od tego, kogo zatrudniasz i jak definiujesz zlecenie.
Luka integracyjna#
Projekty AI w dużych organizacjach przechodzą przez pięć warstw: Strategia → Governance → Proces → Architektura → Technologia.
Tradycyjny consulting działa głównie w dwóch pierwszych. Zespoły inżynierskie żyją w dwóch ostatnich. Środkowa warstwa często nie ma właściciela.
Strategia AI mówi: „zautomatyzować obsługę zapytań klientów”. Ale ktoś musi zdecydować:
Które typy spraw przejmuje system, a które zawsze eskaluje do człowieka? (Proces)
Co się dzieje przy niskiej pewności modelu i jak wygląda ścieżka eskalacji? (Governance-as-Code)
Czy architektura faktycznie udźwignie decyzje w czasie zbliżonym do rzeczywistego przy realnych wolumenach i ile będzie nas kosztował prąd? (Architektura)
Jak dokładnie wpiąć nadzór człowieka w istniejące workflow? (Model operacyjny)
Dokument strategiczny rzadko odpowiada na te pytania, bo osoby, które go tworzą, pracują zbyt daleko od wdrożeń, żeby je postawić. Inżynierów, którzy mogliby odpowiedzieć, często nie ma przy stole, kiedy powstaje koncepcja.
To w tej luce między slajdem a systemem ginie większość strategii AI.
Paradoks „drogiego juniora”#
Problemem nie jest brak zdolnych ludzi w dużych firmach doradczych. Problemem jest to, czego realnie wymaga praca z AI.
Skuteczne wdrożenie wymaga głębokiego doświadczenia interdyscyplinarnego:
Kogoś, kto potrafi rozmawiać z Zarządem o P&L i alokacji kapitału.
Kto rozumie wymagania AI Act, przepisy sektorowe i ich przecięcie z RODO.
Kto potrafi przeprojektować przepływy pracy pod współpracę człowiek–AI, a nie tylko narysować nowy organigram.
Kto umie ocenić, czy proponowana architektura dowiezie wymagany SLA i poziom kontroli.
Kto widział jak systemy produkcyjne się wywracają i musiał je naprawiać.
Taki profil nie powstaje w jednym dziale. To efekt doświadczenia, które prowadzi przez delivery technologiczne, doradztwo i odpowiedzialność operacyjną.
Duże firmy budują zespoły funkcjami: osobno strategia, osobno technologia, osobno zmiana. Każdy optymalizuje swój fragment. Przekazywanie pałeczki między nimi dokłada opóźnienia i utratę informacji. Rzadko ktoś ma realną odpowiedzialność za całą ścieżkę: od zasady do działającej kontroli.
„Drogi junior” nie odnosi się do wieku, tylko do liczby warstw, po których ktoś potrafi poruszać się bez tłumacza. Partner, który nigdy nie odpowiadał za utrzymanie systemu produkcyjnego, jest juniorem na warstwie architektury i operacji. Inżynier ML, który nigdy nie rozmawiał z audytorem ani komitetem ryzyka, jest juniorem na warstwie governance i biznesu. Liczy się seniority integracyjne — a ono jest rzadkie.
Jeżeli płacisz stawki seniorskie osobom, które realnie operują w jednej warstwie, to kupujesz drogiego juniora.
Proces jest produktem#
Korporacyjne AI często opisuje się jako problem „pozyskania technologii”. W praktyce to przede wszystkim problem zaprojektowania procesu.
AI nie naprawia złych procesów, tylko ujawnia ich problemy. Dołożenie LLM-a do nieefektywnego workflow wzmacnia to, co już w nim jest:
Model halucynuje, bo korpus danych jest niespójny, a nikt nie zdefiniował hierarchii źródeł.
Chatbot nie radzi sobie z nietypowymi sprawami, bo ścieżki wyjątków nigdy nie zostały opisane.
„Automatyzacja” podnosi obciążenie pracowników, bo granica między tym, co robi maszyna, a tym, co robi człowiek, nie jest zdefiniowana — więc ludzie weryfikują wszystkie decyzję i odtwarzają pracę ręcznie.
W klasycznych systemach IT dało się czasem zautomatyzować słaby proces, licząc na sztywną logikę, która ukryje niespójności. Systemy probabilistyczne zachowują się inaczej. Testują przypadki brzegowe.
Projektowanie granicy człowiek–AI to więc zasadniczy element projektu, nie kosmetyka:
Kto decyduje, kiedy wynik modelu przyjmujemy bez zmian?
Jaka jest ścieżka awaryjna dla niskiej pewności lub przypadków spoza rozkładu?
Jak wyjątki są kierowane, logowane i przeglądane?
Gdzie jest próg przekazania do decyzji człowieka, i jak chronisz czas ludzi, którzy je podejmują?
Tradycyjny consulting oddaje to w postaci slajdu z „docelowym modelem operacyjnym”. Użyteczne doradztwo AI opisuje konkretne przepływy: próg pewności, dokładną ścieżkę eskalacji, pola logów, o które zapyta audytor.
Jeśli Twoja strategia AI nie schodzi do tego poziomu, nie jest jeszcze planem wdrożenia.
Prosty test dla doradców#
Zanim podpiszesz kolejną umowę doradczą w AI, zadaj kandydatom trzy pytania.
1. „Opisz projekt AI, przy którym pracowałeś, który nie dowiózł na produkcji. Co konkretnie się zepsuło?”
Szukasz konkretnego projektu, jasnego trybu awarii i tego, co zmieniono po fakcie. Odpowiedzi typu „problemy po stronie klienta” zwykle oznaczają dystans do delivery.
2. „Jak zaprojektował(a)byś interwencję człowieka w przypadku predykcji o niskiej pewności w krytycznym use case?”
Dobra odpowiedź dotyczy workflow, progów, UX, logowania i odpowiedzialności — nie tylko „dodamy krok akceptacji”.
3. „Kiedy wybrał(a)byś Human‑in‑the‑Loop, a kiedy Human‑on‑the‑Loop — i dlaczego?”
HITL oznacza, że decyzję podejmuje człowiek przy wsparciu AI. HOTL — że system działa samodzielnie, a człowiek nadzoruje. Wybór zależy od ryzyka, odwracalności decyzji i wymogów regulacyjnych. Jeśli doradca nie potrafi tego przełożyć na praktykę, nie ma jeszcze w ręku warstwy governance.
Ogólnikowe albo czysto teoretyczne odpowiedzi w tych trzech obszarach są sygnałem. Najpewniej rozmawiasz ze strategiem albo technologiem — nie z integratorem.
Briefing#
Modele wnioskujące a zużycie energii#
Badanie AI Energy Score porównało zużycie energii przez kilkadziesiąt modeli. Średnio modele z włączonym „reasoningiem” zużywały około 100 razy więcej energii na ten sam zestaw zapytań niż uproszczone warianty.
W skrajnym przypadku kompaktowe wersje modeli (Deepseek R1, Phi-4 Microsoftu) potrzebowały około 20-50 Wh przy wyłączonym wnioskowaniu i ponad 7-13 kWh na 1000 promptów przy włączonym.
Różnica wynika z dłuższych łańcuchów generowania i większej liczby operacji na token.
Wniosek operacyjny: kierowanie wszystkiego przez „najmądrzejszy model” to decyzja kosztowa i pojemnościowa, nie tylko jakościowa. Kluczowe pytanie brzmi nie „czy używać AI?”, tylko „jaka klasa modelu jest adekwatna do tego zadania?”. Proste podsumowania, retrieval i klasyfikacje powinny lądować na mniejszych, tańszych modelach. Ciężkie wnioskowanie rezerwujesz tam, gdzie faktycznie zmienia wynik.
Cele sprzedażowe kontra rzeczywistość#
Relacje m.in. Ars Technica o wewnętrznych celach Microsoftu wskazują, że w części jednostek cele sprzedaży oprogramowania AI zostały obniżone mniej więcej o połowę po serii nieudanych kwartałów. Produkty takie jak Azure AI Foundry nie rosną w tempie sugerowanym w przekazach marketingowych. Infrastruktura istnieje. Nacisk handlowy jest silny. A mimo to firmy nie kupują licencji technologii.
Przyczyny leżą moim zdaniem w kilku miejscach. Po pierwsze jest to kolejny sygnał, że głównym ograniczeniem nie jest dostępność modeli czy platform — bez odpowiedniego przeprojektowania procesów, integracji z istniejącymi systemami licencje nie będą wykorzystane. Po drugie — konkurencja na rynku jest coraz większa a Microsoft nie jest postrzegany jako lider branży AI.
ROI, weryfikacja i koszt „sprawdzania maszyny”#
Dane IBM mówiące o tym, że zaledwie około jedna czwarta inicjatyw AI realizuje zakładany ROI a 16% firm z sukcesem skaluje zastosowania AI, pokrywają się z tym, co dziś widzą zarządy. Niewielka część programów skaluje się globalnie; wiele utknęło w wiecznej fazie „pilota”.
Znaczna część kosztu siedzi w weryfikacji. Seniorzy spędzają czas na sprawdzaniu wyników AI, ponieważ procesy nie zostały przekonstruowane pod znany poziom błędu modelu. Płacisz za model i za dodatkowy nadzór.
Dopóki nie przeprojektujesz procesów tak, by ograniczyć lub lepiej ukierunkować wysiłek weryfikacyjny, zysk z „automatyzacji” jest pozorny. Koszt przesuwa się z jednej linijki budżetu na drugą — zwykle w stronę najdroższych ludzi.
Pytanie na poniedziałek#
Przed kolejnym wydatkiem na AI warto zadać jedno pytanie:
„Kto jest odpowiedzialny za przełożenie strategii na ograniczenia techniczne i z powrotem na biznes case — i czy ta osoba realnie obejmuje wszystkie pięć warstw?”
Jeśli ta praca wpada w szczelinę między zespołami — jeśli „ludzie od strategii” i „ludzie od delivery” rzadko siedzą w jednym pokoju roboczym — właśnie tam leży ryzyko.
Brakuje roli, która potrafi płynnie przechodzić między salą zarządu a pipeline’em wdrożeniowym i odpowiada za obie strony: narrację i system. Bez niej kupujesz drogich juniorów w każdej warstwie i dziwisz się, że nic nie wychodzi na produkcję.
Do następnego razu, Krzysztof