Mała firma nie potrzebuje strategii AI. Potrzebuje dwóch, najwyżej trzech miejsc, w których coś realnie przestaje zjadać czas ludzi, i pewności, że po kwartale da się to policzyć. AI w małej firmie najczęściej rozbija się nie o wybór modelu. Rozbija się o dane rozsypane po skrzynkach, brak integracji i o to, że po stronie klienta nikt tak naprawdę nie odpowiada za proces.
Od 2006 roku w Web Systems budujemy aplikacje, integracje i automatyzacje, a od kilku lat także wdrożenia aplikacji AI oparte na modelach językowych. Wniosek z tych wdrożeń jest nudny: zwraca się to, co jest powtarzalne, mierzalne, ma znany wolumen i opiera się na danych, które już siedzą w systemie. Poniżej trzy zastosowania, które ten warunek spełniają. Plus to, co je psuje, kiedy zabierze się do nich bez planu.
Spis treści
Kiedy AI w małej firmie zwraca się szybko, a kiedy zostaje kosztem
Test opłacalności jest prosty. Proces musi być wykonywany codziennie, mieć przewidywalny kształt wejścia i akceptowalny próg błędu. Jeśli pomyłka oznacza tylko tyle, że ktoś to potem poprawi – ryzyko jest do udźwignięcia. Jeśli oznacza zobowiązanie wobec klienta albo błąd księgowy, dokładasz kontrolę, a kontrola zjada część oszczędności.
Sygnały ostrzegawcze widać zwykle na pierwszym spotkaniu. Dane leżą w prywatnych skrzynkach i arkuszach, nie ma jednego źródła prawdy, a sam proces zmienia się co miesiąc, bo zależy od nawyków konkretnej osoby. No i wtedy najpierw porządkujemy przepływ, a model dokładamy później.
Koszt wdrożenia to nie licencja. Składają się na niego integracje i wywalczenie dostępu do danych, inferencja rosnąca liniowo z wolumenem, testy jakości, utrzymanie promptów oraz rezerwa na regresję po zmianie modelu. Dlatego pilot prowadzimy na danych produkcyjnych, nie na ładnie wybranych przykładach. Tylko brudne wejście pokazuje prawdziwą skuteczność. Najczęstszy błąd? Start od zastosowania najbardziej efektownego zamiast najbardziej powtarzalnego.
Zastosowanie pierwsze: obsługa powtarzalnych zapytań i wstępna kwalifikacja
Nie chodzi o chatbota, który zastępuje człowieka. Chodzi o warstwę segregującą przychodzące wiadomości: rozpoznaje temat, wyciąga dane potrzebne do wyceny, przypisuje sprawę do właściwej osoby i przygotowuje szkic odpowiedzi. Człowiek zatwierdza albo poprawia, zamiast pisać po raz setny to samo.
Decyzja, która przesądza o jakości, dotyczy źródła wiedzy. Model ma odpowiadać wyłącznie na podstawie firmowej bazy dokumentów, cenników i regulaminów. Nie z własnej pamięci. Tylko przy takim ograniczeniu da się kontrolować treść i wyjaśnić, skąd wzięło się konkretne zdanie.
Do tego obowiązkowa ścieżka eskalacji i jawne przyznawanie się systemu, że nie wie. Halucynacja w odpowiedzi handlowej albo reklamacyjnej to nie wpadka wizerunkowa. To potencjalne zobowiązanie, którego ktoś potem dochodzi. O zwrocie decydują dwie rzeczy: skrócony czas pierwszej odpowiedzi i odciążenie osoby, która dotąd przepisywała te same akapity w kółko.
Zastosowanie drugie: przetwarzanie dokumentów i ekstrakcja danych
Faktury, zamówienia, specyfikacje, protokoły odbioru, umowy. Wejście nieustrukturyzowane, wyjście w postaci konkretnych pól trafiających do systemu. Tutaj zwrot bywa najszybszy, bo praca ręczna jest widoczna gołym okiem, a jej koszt policzalny w godzinach, których nikt nie lubi. Szerzej opisaliśmy to przy okazji automatycznego przetwarzania faktur.
Wymóg techniczny jest jeden i bezdyskusyjny: aplikacja waliduje schemat wyjścia, zamiast ufać temu, co zwrócił model. Do tego przypadki graniczne, które zawsze się pojawiają – skan zrobiony telefonem pod kątem, załącznik w obcym języku, dokument w układzie, którego nikt nie przewidział. Zapis automatyczny obejmuje wyłącznie wyniki powyżej progu pewności, reszta idzie do kolejki weryfikacji.
Wdrożenie ekstrakcji nadaje się na produkcję, gdy ma komplet elementów:
- Jedno źródło dokumentów zamiast trzech skrzynek i dysku sieciowego
- Jawny schemat wyjścia z typami pól i polami wymaganymi
- Walidację po stronie aplikacji, odrzucającą odpowiedzi niezgodne ze schematem
- Próg pewności i kolejkę do ręcznego sprawdzenia poniżej niego
- Log wejścia i wyjścia pozwalający odtworzyć każdą decyzję
- Ścieżkę poprawiania błędów dostępną dla użytkownika, nie dla programisty
Zastosowanie trzecie: automatyzacja przepływu między systemami, których nikt nie połączył
Typowa mała firma ma sklep, program księgowy, CRM i skrzynkę pocztową. Dane wędrują między nimi przez człowieka i schowek systemowy. A każde takie przepisanie to okazja do literówki w numerze konta albo w indeksie towaru.
Model sprawdza się tu jako tłumacz między formatami i jako decydent w tych kilku punktach, gdzie zwykły warunek nie wystarcza, bo opis produktu bywa napisany prozą. Cała reszta przepływu zostaje zwykłym, deterministycznym kodem. Odwrotna kolejność, czyli budowanie całej automatyzacji na modelu, daje system, którego nie da się ani zdiagnozować, ani powtórzyć.
Sprawy integracyjne zwykle zajmują więcej czasu niż sama warstwa AI: limity API dostawcy, idempotencja przy ponowieniach, kolejka zamiast wywołań synchronicznych, zdefiniowane zachowanie przy niedostępności usługi. Nudne? Bardzo. Ale realny zwrot bierze się z zaniku błędów przepisywania i ich skutków, nie z samych zaoszczędzonych minut.
Dane, bezpieczeństwo i to, o co klienci pytają za późno
Pierwsze pytanie brzmi zawsze tak samo: co właściwie wychodzi poza firmę. Odpowiedzią jest minimalizacja zakresu przesyłanych danych, anonimizacja tam, gdzie identyfikator nie jest potrzebny do zadania, umowa powierzenia przetwarzania i świadomy wybór regionu, w którym dostawca przetwarza treść.
Model uruchamiany lokalnie ma sens przy naprawdę wrażliwych danych albo przy stałym, wysokim wolumenie. Przy kilkudziesięciu dokumentach dziennie to zwykle koszt infrastruktury i utrzymania bez uzasadnienia. Niezależnie od wariantu obowiązuje rozdzielenie uprawnień: warstwa AI dostaje dostęp dokładnie do tych danych, których wymaga proces. Nie do całej bazy przez konto administratora.
Prompt injection przez treść dokumentu albo wiadomości od klienta to wektor spotykany w praktyce, nie akademicka ciekawostka. Widziałem to na żywo. Treść z zewnątrz traktujemy jak dane, nigdy jak instrukcję. Logowanie decyzji zamyka temat – bez niego nie odtworzysz, dlaczego system odpowiedział tak, a nie inaczej.
Utrzymanie: dlaczego wdrożenie AI nie kończy się odbiorem
Model, na którym zbudowano rozwiązanie, kiedyś zostanie wycofany albo zaktualizowany. Zachowanie systemu przesunie się wtedy bez jednej zmiany w kodzie po stronie klienta, a objawy będą subtelne: nieco inne formatowanie pola, inna interpretacja niejasnego zapisu w umowie. Nikt tego nie zauważy od razu.
Jedyna obrona przed taką cichą regresją to zestaw przypadków testowych zbudowany na prawdziwych dokumentach i wiadomościach, uruchamiany po każdej zmianie. Równie ważna jest osoba po stronie firmy, która ogląda kolejkę weryfikacji i zgłasza błędy. Bez niej system przestaje być korygowany i po kilku miesiącach zespół po prostu przestaje mu ufać.
Zużycie na jednostkę procesu mierzcie od pierwszego dnia, bo wzrost wolumenu potrafi wywrócić cały rachunek opłacalności. Dojrzałe wdrożenie poznaje się po jednym: można je wyłączyć i wrócić do pracy ręcznej bez paraliżu firmy.
Od czego zacząć w przyszłym kwartale
Wybierzcie jeden proces: ten o największym wolumenie i najniższym koszcie pomyłki. Trzy naraz kończą się trzema pilotami bez właściciela. Miarę ustalcie przed startem, żeby po kwartale odpowiedzieć na pytanie o zwrot liczbą, a nie wrażeniem.
Przygotowanie danych i dostępów zwykle zajmuje więcej czasu niż podłączenie modelu. I to jest normalne. Jeśli planujecie MVP, integrację, automatyzację, wdrożenie AI albo budowę dedykowanego oprogramowania na bazie istniejącego systemu, zapraszamy do kontaktu. Zaczniemy od rozmowy o procesie, nie o technologii.
