Kiedy nie używać AI

Odrzucałem projekty AI

Presja na „robienie AI” prowadzi do złych decyzji. Zarządy tego żądają. Konkurencja to ogłasza. Dostawcy to sprzedają. A firmy budują projekty AI, które nigdy nie miały zadziałać - nie dlatego, że AI zawiodło, ale dlatego, że AI było złym narzędziem do zadania.

Najdroższy projekt AI to ten, którego nie potrzebowałeś.

Oto siedem scenariuszy, w których powiedziałem klientom, by nie budowali AI. Jeśli widzisz się w którymś, oszczędź pieniądze.

Scenariusz 1: To problem procesu

Zepsuty przepływ + AI = zautomatyzowana zepsutość na skalę.

Firma przyszła do mnie chcąc AI do predykcji odejść (churn). Ich dane CRM to bałagan - duplikaty, brakujące pola, niespójne formaty. Przedstawiciele wprowadzali dane inaczej. Niektórzy w ogóle nie wprowadzali.

AI tego nie naprawi. AI przewidziałoby odejścia na podstawie śmieciowych danych - pewnie mówiąc im, którzy klienci odejdą, na podstawie rekordów, które były błędne.

Prawdziwy problem: ich proces CRM był zepsuty. Napraw proces, wyczyść dane, przeszkol repów. Potem może rozważ AI. Nie przed.

Reguła: Jeśli twój proces jest zepsuty, AI automatyzuje to zepsucie. Napraw proces najpierw.

Scenariusz 2: Reguły działają lepiej

Jeśli potrafisz zapisać reguły, zapisz reguły. AI jest na decyzje zbyt złożone lub dynamiczne, by je zakodować.

Firma chciała AI do routingu zatwierdzania faktur. „Chcemy, by AI nauczyło się naszych reguł zatwierdzania”. Zapytałem: „Czy potraficie zapisać wasze reguły zatwierdzania?” Potrafili. Właściwie już to mieli - w dokumencie polityki.

Jeśli reguły mieszczą się w dokumencie, nie potrzebujesz AI. Potrzebujesz silnika reguł. Jest tańszy, szybszy, bardziej przejrzysty i 100% dokładny. AI dodaje złożoność, nieprzejrzystość i koszt bez żadnego pożytku.

Reguła: Jeśli mieści się w arkuszu lub dokumencie polityki, nie buduj sieci neuronowej.

Scenariusz 3: Twoje dane nie są gotowe

Rozproszone, niespójne, niekompletne dane = pewne błędne odpowiedzi.

Firma chciała systemu RAG dla wewnętrznej wiedzy. Ich dokumenty były rozrzucone po SharePoint, Google Drive, trzech różnych wiki i laptopach poszczególnych pracowników. Formaty od Worda przez PDF, przez Confluence, po odręczne notatki zeskanowane jako obrazy.

Czy AI mogło zadziałać na tych danych? Ostatecznie. Po miesiącach konsolidacji, czyszczenia i organizacji. Ale projekt AI nie był właściwym pierwszym krokiem - nim był projekt infrastruktury danych.

Test: Czy potrafisz opisać, gdzie żyją twoje dane, w jednym zdaniu? Jeśli odpowiedź to „to skomplikowane”, nie jesteś gotowy na AI. Jesteś gotowy na audyt danych.

Scenariusz 4: ROI nie uzasadnia

Koszty bieżące: compute, monitoring, utrzymanie, talenty. AI to nie jednorazowy zakup - to bieżący wydatek operacyjny.

Firma chciała AI do automatyzacji procesu kosztującego 20 tys. €/rok pracy ręcznej. System AI kosztowałby 80 tys. € budowy plus 15 tys. €/rok działania. Nawet gdyby działał perfekcyjnie, zwrot byłby w 8 lat - a systemy AI wymagają retrenowania, aktualizacji i utrzymania, co podbiłoby realny koszt.

Reguła: Zrób matematykę przed budową. Jeśli problem kosztuje 20 tys. €/rok, a AI 80 tys. € + 15 tys. €/rok, to zła inwestycja. Napraw proces ręcznie.

Scenariusz 5: Napędzane FOMO

„Konkurencja uruchomiła AI” to lęk, nie biznesowe uzasadnienie.

CEO zadzwonił do mnie, bo konkurencja ogłosiła funkcję AI. Chcieli ją dorównać. Zapytałem: „Co ta funkcja robi?” Nie wiedzieli. „Jak pomaga ich klientom?” Też nie wiedzieli. „Co zrobiłaby dla twoich klientów?” Cisza.

FOMO prowadzi do budowania funkcji, których nikt nie potrzebuje. Właściwe pytanie to nie „co oni robią?” lecz „jaki konkretny rezultat, którego dziś nie osiągamy, AI by umożliwił?”

Reguła: Jeśli motywacją jest „konkurencja to zrobiła”, nie buduj. Jeśli motywacją jest „mamy konkretny problem, który AI może rozwiązać”, rozważ.

Scenariusz 6: Twój zespół nie utrzyma

Budowa to 30% pracy. Uruchomienie i utrzymanie to 70%.

Firma chciała dedykowanego modelu do klasyfikacji dokumentów. Ich zespół inżynieryjny to dwie osoby - obie zajęte utrzymaniem istniejących systemów. Nikt nie miał czasu nauczyć się MLOps, monitorować dryfu modelu ani zajmować retrenowaniem.

Jeśli twój zespół nie potrafi debugować dryfu, aktualizować potoków danych ani utrzymać systemu po odejściu konsultanta, nie budujesz możliwości. Tworzysz stałą zależność od dostawcy.

Reguła: Jeśli nikt z twojego zespołu nie potrafi tego uruchomić po odejściu konsultanta, nie buduj. Albo zbuduj coś prostszego, co potrafią uruchomić.

Scenariusz 7: Ryzyko zgodności jest zbyt wysokie

Klasyfikacja ryzyka EU AI Act ma znaczenie. Niektóre przypadki użycia niosą ciężar zgodności, który może nie być wart wartości.

Firma chciała AI do automatycznej selekcji rekrutacyjnej - rankingu kandydatów przez analizę CV. Pod EU AI Act to prawdopodobnie system wysokiego ryzyka: decyzje kadrowe wymagają systemu zarządzania ryzykiem, zarządzania danymi, dokumentacji technicznej, oceny zgodności i bieżącego monitoringu.

Koszt zgodności (15-25% budżetu projektu) plus bieżące obciążenie dokumentacją uczyniły projekt nieekonomicznym dla 50-osobowej firmy.

Reguła: Znaj swoją kategorię ryzyka EU AI Act przed budową. Niektóre przypadki użycia są technicznie możliwe, ale ekonomicznie nierozsądne przez narzut zgodności.

Co robić zamiast

Zacznij od audytu. Audyt mówi ci:

• Czy twoje dane są gotowe
• Czy ROI uzasadnia inwestycję
• Czy twój zespół może utrzymać system
• Jakie są twoje wymogi zgodności
• Co zbudować najpierw (albo czy w ogóle budować)

Czasem odpowiedzią jest „jeszcze nie”. To nie porażka - to prawidłowa diagnoza. Najpierw zbuduj fundament. Dane, proces, zespół. Wtedy AI staje się możliwe.

Albo czasem odpowiedzią jest „w ogóle nie”. Też w porządku. Nie każdy problem potrzebuje AI. Niektóre problemy potrzebują lepszych procesów, czystszych danych lub prostszych narzędzi.

FAQ

Jak wiem, czy moje dane są gotowe? Czy potrafisz opisać, gdzie żyją, w jednym zdaniu? Czy są w jednym systemie, czy rozproszone na pięć? Czy są >95% kompletne? Jeśli nie potrafisz odpowiedzieć pewnie, potrzebujesz audytu danych przed projektem AI.

Czy możemy zbudować AI i naprawić dane później? Nie. Złe dane = autorytatywne błędne odpowiedzi. AI na złych danych nie produkuje wyników „mniej więcej dobrych” - produkuje pewne błędne wyniki, które wyglądają wiarygodnie. Napraw dane najpierw.

Co jeśli nasz zarząd żąda strategii AI? Pokaż im ten artykuł. Albo zarezerwuj audyt i przedstaw wnioski. Ocena oparta na danych jest bardziej przekonująca niż opinia konsultanta. „Oto co możemy zbudować, ile to kosztuje i co musimy naprawić najpierw” to strategia. „Powinniśmy robić AI” to nie jest.