Ta strona nie zawiera nowych zastrzeżeń — zbiera te, które i tak padają na poszczególnych stronach usług, bo rozproszone po sześciu miejscach były trudne do znalezienia akurat wtedy, gdy są najbardziej potrzebne: przed podpisaniem umowy. Przy każdej rzeczy, której nie zbudujemy, jest odesłanie do strony, na której opisujemy ją szerzej; warunki z drugiej sekcji pochodzą z dwóch stron wskazanych pod listą.
Czego nie zbudujemy
- Automatów do zimnych maili. Masowa wysyłka generowana przez AI to ryzyko prawne — zgody i przepisy o komunikacji elektronicznej — oraz reputacyjne, którego nie widać na dashboardzie: spalona domena i marka „spamera” zostają na długo po zakończeniu kampanii. Nie budujemy tego również na wyraźne życzenie. Szerzej przy AI w dziale sprzedaży.
- Systemów działających bez zatwierdzania od pierwszego dnia. Wszystko, co wychodzi do klientów albo zmienia stan systemów, startuje w trybie z akceptacją człowieka. Poluzowanie nadzoru to decyzja podejmowana na danych z pilotażu, nie założenie w ofercie — opisujemy to przy wdrożeniu agentów AI.
- Predykcji bez historii danych. Optymalizacja tras, przewidywanie awarii czy scoring szans sprzedażowych wymagają miesięcy spójnie opisanej historii. Jeżeli firma jej nie zbiera, uczciwa oferta zaczyna się od uporządkowania zbierania danych i mówi wprost, że efekt predykcyjny przyjdzie później — a nie sprzedaje projektu zbierania danych pod nazwą predykcji. Przykłady przy AI w firmie transportowej.
- Rozstrzygnięć, za które nikt nie odpowiada. System przygotowuje materiał — wycenę, dekret, kosztorys — ale decyzja i podpis zostają przy człowieku, który zna technologię i stawki. Oferta obiecująca „automatyczny kosztorys” obiecuje decyzje bez odpowiedzialnego za nie; rozwijamy to przy AI w firmie budowlanej.
- Porad prawnych. Rejestr systemów, dokumentacja, logowanie i opis przepływu danych — tak. Klasyfikacja systemu, podstawa prawna i ocena skutków należą do administratora i jego prawnika. Granicę opisujemy przy audycie gotowości na AI Act oraz na stronie o bezpieczeństwie i RODO.
Kiedy odradzamy projekt
Te warunki sprawdzamy w pierwszej fazie i jeżeli któryś jest spełniony, mówimy o tym od razu — zanim wystawimy fakturę za budowę.
- Proces nie jest ustabilizowany. Jeżeli pięć osób wykonuje go na pięć sposobów i żaden nie jest opisany, nie ma czego automatyzować. Najpierw trzeba uzgodnić proces, a to praca organizacyjna, nie informatyczna.
- Dane nie istnieją albo są nieosiągalne. Historia decyzji w cudzej głowie, w załącznikach do maili albo w systemie bez API to nie są dane, na których da się oprzeć wdrożenie w rozsądnym budżecie.
- Oszczędność nie pokrywa utrzymania. Każdy system AI ma koszt stały: model, monitorowanie, poprawki. Jeżeli proces zajmuje dwie godziny miesięcznie, prawie na pewno nie warto — i lepiej usłyszeć to na początku.
- Nie ma właściciela procesu. Bez osoby, która rozstrzyga, projekt zatrzyma się na pierwszym sporze o to, co jest błędem.
- Regulacje wykluczają dany scenariusz. Części zastosowań AI Act zakazuje wprost, a część wymaga przygotowania, którego koszt zmienia sens projektu.
- Wąskim gardłem nie jest praca, którą miałby przejąć system. Bywa, że sprawy nie stoją dlatego, że nikt ich nie przetwarza, tylko dlatego, że czekają na decyzję albo na formularz, którego nikt nie wypełnia. Automatyzacja przyspieszy wtedy fragment, który i tak nie był problemem.
- Reguły decyzji są niewypowiedziane. Proces bywa ustabilizowany — wszyscy robią to tak samo — a mimo to nikt nie potrafi powiedzieć, dlaczego jedna sprawa kończy się tak, a druga inaczej. Spisanie tych reguł to zadanie do wykonania przed projektem, nie w jego trakcie.
- Istnieje gotowe narzędzie, które to robi. Nie buduj tego, co możesz kupić w abonamencie — powiemy to również wtedy, gdy oznacza to brak zlecenia.
Pierwsze pięć warunków sprawdzamy w fazie pierwszej według metodyki wdrożenia, trzy ostatnie opisujemy przy automatyzacji AI. Jeżeli żaden nie jest spełniony, zwykle zaczynamy od jednego procesu dokumentowego — od czego konkretnie, opisuje strona wdrożenie AI w firmie.
Najczęstsze pytania
Czy odmawiacie zleceń?
Tak i zdarza się to regularnie. Najczęściej nie dlatego, że projekt jest technicznie niemożliwy, tylko dlatego, że policzony uczciwie się nie spina: proces zajmuje na tyle mało czasu, że oszczędność nie pokryje utrzymania systemu, albo wąskim gardłem jest decyzja, a nie praca, którą system miałby przejąć. Mówimy o tym w pierwszej fazie, zanim wystawimy fakturę za budowę — wolimy stracić zlecenie niż zbudować coś, co nie zwróci kosztów.
Dlaczego nie budujecie automatów do zimnych maili?
Z dwóch powodów, z których żaden nie jest światopoglądowy. Pierwszy to ryzyko prawne: masowa wysyłka wymaga zgód i podlega przepisom o komunikacji elektronicznej, a odpowiedzialność zostaje po stronie nadawcy. Drugi jest bardziej praktyczny i rzadziej wymieniany w ofertach: spalona domena i reputacja spamera zostają na długo po zakończeniu kampanii, a kosztu odbudowy nie widać na żadnym dashboardzie. Nie budujemy tego również wtedy, gdy klient prosi wprost.
Czy AI może podejmować decyzje bez udziału człowieka?
Technicznie tak, ale nie zaczynamy od tego i nie polecamy tego jako punktu wyjścia. Każde wdrożenie startuje w trybie, w którym system przygotowuje, a człowiek zatwierdza. Dopiero dane z takiego pilotażu — ile propozycji było poprawnych, jakie błędy się zdarzały i ile kosztowały — pozwalają świadomie zdecydować, które kategorie działań mogą iść dalej bez zatwierdzania. To decyzja podejmowana na liczbach, po pilotażu, a nie założenie przyjmowane w ofercie.
Czy doradzacie prawnie w sprawach AI Act i RODO?
Nie. Zajmujemy się stroną techniczną i organizacyjną: rejestrem systemów, dokumentacją, logowaniem, nadzorem człowieka i opisem przepływu danych, na którym ocena prawna może się oprzeć. Klasyfikacja systemu, podstawa prawna przetwarzania i ocena skutków to rozstrzygnięcia należące do administratora oraz jego prawnika lub inspektora ochrony danych. Nasza roboczo przydatna rola polega na tym, żeby system dało się zbudować zgodnie z tym rozstrzygnięciem, a nie odwrotnie.