Automatyzacje AI w praktyce: 6 projektów zbudowanych przez kursantów

Najłatwiej mówić o automatyzacji na przykładach, które brzmią efektownie: agent AI, workflow w n8n, własny system w Claude Code. Tyle że dopóki nie wiadomo, jaki konkretny problem taki system rozwiązuje, trudno ocenić, czy naprawdę ma sens.

Dlatego w tym artykule nie pokazujemy przykładowych projektów zrobionych „pod kurs”. Zebraliśmy sześć rozwiązań, które uczestnicy naszych programów stworzyli dla siebie i swojej pracy. Każde powstało w innej branży, bo każda z tych osób zaczynała od innego problemu.

Kamil chciał przestać ręcznie śledzić transakcje insiderów na giełdzie. Katarzyna stworzyła automatyzację, która wyszukuje atrakcje dla gości obiektów noclegowych, zamiast robić to ręcznie za każdym razem. Jan zna od podszewki pracę w supporcie i wiedział, ile czasu pochłania samo czytanie, porządkowanie i ocenianie zgłoszeń. Jarek zbudował własny system do organizowania wiedzy, zadań i decyzji. W firmie fotowoltaicznej powstał kalkulator wycen i system selekcji przetargów. Z kolei prawniczka bez wcześniejszego doświadczenia w programowaniu stworzyła system do pracy na 10 GB polskich ustaw.

To sześć zupełnie różnych projektów, ale warto przyjrzeć się im razem. Dobrze pokazują, jak wygląda automatyzacja wtedy, gdy nie zaczynasz od narzędzia, tylko od konkretnej pracy, której chcesz robić mniej, szybciej albo po prostu lepiej.

Giełda: z 15–20 minut dziennie do 8 sekund

„Osiem sekund. Tyle dziś trwa coś, co wcześniej zabierało mi piętnaście-dwadzieścia minut dziennie.”

Tak Kamil opisał na LinkedInie system, który zbudował dla siebie. Nie prosiliśmy go o opinię ani o przygotowanie case study. Po prostu uznał, że warto pokazać efekt swojej pracy, i podał konkretne liczby.

Kamil od dziesięciu lat zajmuje się audytem i zarządzaniem ryzykiem. Jednym z procesów, które wcześniej wykonywał ręcznie, było śledzenie transakcji insiderów, czyli m.in. zakupów i sprzedaży akcji dokonywanych przez prezesów oraz członków zarządów spółek.

Dla niego te informacje są istotne z prostego powodu:

„Prezes kupujący akcje za własne pieniądze wie o spółce więcej niż jakikolwiek analityk z zewnątrz.”

Same dane nie są ukryte. Spółki mają obowiązek publikować informacje o takich transakcjach zgodnie z art. 19 MAR. Problem pojawia się gdzie indziej: komunikaty o transakcjach trafiają do tego samego strumienia co wiele innych informacji giełdowych i są publikowane o różnych porach. Jeśli ktoś chce je regularnie śledzić, musi codziennie przeglądać komunikaty i wyłapywać z nich te, które rzeczywiście go interesują.

Kamil wcześniej poświęcał na to około 15–20 minut dziennie. Zamiast dalej robić to ręcznie, zbudował workflow w n8n składający się z 15 node'ów. Po zakończeniu sesji giełdowej system sam sprawdza, czy na GPW i NewConnect pojawiły się nowe transakcje osób zarządzających spółkami.

Przy projektowaniu automatyzacji Kamil wykorzystał zasady, które zna z audytu i zarządzania ryzykiem. Pierwsza dotyczy liczb.

„Model językowy odpowiada za język, nie za liczby. Parser jest w całości deterministyczny. Zero ryzyka, że AI zmyśli liczbę, na której ktoś oprze decyzję inwestycyjną.”

To oznacza, że model AI nie dostaje zadania obliczania ani interpretowania wartości liczbowych tam, gdzie pomyłka mogłaby mieć realne konsekwencje. Liczby obsługuje przewidywalny parser, a AI zajmuje się tym, do czego nadaje się lepiej, czyli pracą z językiem.

Druga zasada dotyczy raportowania.

„Cisza to zła forma raportowania. System wysyła maila nawet wtedy, gdy nie ma nowych transakcji, bo brak wiadomości i awaria wyglądają z zewnątrz identycznie.”

Gdyby system wysyłał wiadomość tylko po wykryciu transakcji, Kamil nie wiedziałby, czy brak maila oznacza spokojny dzień na rynku, czy awarię workflow. Dlatego raport przychodzi zawsze.

28 lipca system wykrył dziewięć nowych transakcji: osiem na GPW i jedną na NewConnect. Największa miała wartość 8,13 mln zł. Cały proces zajął osiem sekund, a utrzymanie automatyzacji kosztuje grosze miesięcznie.

Noclegi: gość dostaje podpowiedzi jeszcze przed przyjazdem

Katarzyna stworzyła automatyzację, która jest nieocenioną pomocą dla obiektów noclegowych. Już nie muszą wyszukiwać informacji, żeby odpowiadać na dziesiątki małych zapytań tygodniowo.

Goście chcą wiedzieć, co warto zobaczyć w okolicy, gdzie pojechać przy dobrej pogodzie, co można zrobić, kiedy pada, jakie wydarzenia odbywają się podczas ich pobytu albo jakie atrakcje będą odpowiednie dla konkretnego typu wyjazdu.

Każde z tych pytań jest rozsądne. Kłopot zaczyna się wtedy, gdy właściciel obiektu po raz kolejny wyszukuje podobne informacje, sprawdza pogodę, przekleja linki i układa z nich wiadomość dla następnej osoby.

Katarzyna postanowiła przenieść dużą część tej pracy do automatyzacji.

„Zero researchu. Zero kopiowania tych samych informacji. System działa w tle, zanim jeszcze wypijesz kawę.”

Zbudowany przez nią agent codziennie o 9:00 sprawdza kalendarz rezerwacji. Obecnie korzysta z danych z Hotresu, ale sama integracja została przygotowana tak, żeby można ją było podłączyć również do innego systemu rezerwacyjnego.

Jeżeli agent znajdzie rezerwację rozpoczynającą się za trzy dni, uruchamia kolejne kroki. Pobiera prognozę pogody z Open-Meteo, sprawdza aktualne wydarzenia turystyczne w okolicy i wybiera informacje pasujące do terminu pobytu. Rozpoznaje też język, w którym powinna powstać wiadomość, dzięki czemu może przygotować ją na przykład po polsku, czesku albo angielsku.

W jednym z przykładów system przygotował mail dla Anny, która planowała czterodniowy pobyt w połowie sierpnia. Wiadomość zawierała prognozę na konkretne dni oraz propozycje dla pary, która lubi spokojne zwiedzanie i chce unikać tłumów.

Do takiej wiadomości można również dołączyć ofertę samego obiektu, na przykład masaż, spa czy saunę. Dzięki temu automatyzacja nie tylko oszczędza czas potrzebny na przygotowanie rekomendacji, ale może też pomóc w sprzedaży dodatkowych usług.

Katarzyna celowo nie oddała jednak agentowi całego procesu. System przygotowuje wersję roboczą wiadomości w Gmailu, a następnie wysyła jej powiadomienie na Telegramie. To ona sprawdza treść i decyduje, czy mail może zostać wysłany.

Podobnie rozwiązano kwestię danych osobowych. Imiona i adresy e-mail są zamieniane na tokeny, zanim treść trafi do modelu AI. Dzięki temu agent może przygotować wiadomość na podstawie potrzebnych informacji, ale nie musi przetwarzać oryginalnych danych gościa.

Obsługa klienta: agent, który potrafi przekazać sprawę człowiekowi

Jan przez wiele lat pracował w zespołach supportu, więc dobrze zna proces obsługi zgłoszeń od środka.

„W obsłudze klienta duża część zgłoszeń jest powtarzalna, ale każde z nich nadal musi zostać przeczytane, sklasyfikowane i obsłużone przez człowieka. Przy większej liczbie zgłoszeń oznacza to dużo ręcznej pracy, dłuższy czas odpowiedzi i ryzyko, że pilne problemy nie zostaną odpowiednio szybko zauważone.”

Właśnie z tego problemu powstał Support Pilot.

System analizuje nowe zgłoszenie, rozpoznaje jego kategorię, określa priorytet, ocenia sentyment klienta i przygotowuje propozycję odpowiedzi. To jednak nie generowanie tekstu jest w tym projekcie najważniejsze.

Jan chciał przede wszystkim rozwiązać problem selekcji: które sprawy rzeczywiście mogą przejść dalej automatycznie, a które powinien zobaczyć człowiek?

Dlatego oddzielił generowanie odpowiedzi od warstwy decyzyjnej. Model nie dostaje po prostu polecenia „odpowiedz klientowi”. Najpierw ma ocenić konkretne elementy zgłoszenia i zwrócić wynik w ustalonym formacie. Dopiero na podstawie tych danych system decyduje, co zrobić dalej.

Jeśli sprawa jest krytyczna albo sam model ocenia swoją odpowiedź jako niepewną, zgłoszenie trafia do statusu „human review”. Wtedy automatyzacja nie próbuje na siłę doprowadzić procesu do końca, tylko przekazuje go człowiekowi.

W wersji demonstracyjnej Jan pokazał zgłoszenie dotyczące zawieszającej się aplikacji. Agent zaklasyfikował problem, nadał mu priorytet, określił sentyment klienta, streścił zgłoszenie i przygotował proponowaną odpowiedź. Podał również poziom pewności swojej oceny i rekomendację dotyczącą kolejnego kroku.

W tym przypadku uznał, że sprawę powinien przejąć pracownik supportu, ponieważ trzeba było dopytać klienta o dodatkowe szczegóły.

„Support Pilot nie zastępuje supportu. Pozwala supportowi skupić się na tym, co naprawdę wymaga człowieka.”

To dobrze pokazuje założenie całego projektu. Celem nie było usunięcie człowieka z obsługi klienta, tylko ograniczenie czasu, który zespół traci na czynności możliwe do wykonania wcześniej przez system.

Drugi mózg: własny system zamiast kolejnej aplikacji do notatek

Jarek na co dzień jest elektrykiem. Swój wpis na LinkedInie zaczął od zdania:

„Jestem elektrykiem. Przez ostatnie miesiące zbudowałem własny drugi mózg w Claude Code.”

Chodzi o system, który pomaga mu przechowywać informacje, porządkować projekty, wracać do wcześniejszych decyzji i regularnie podsumowywać własną pracę. Jarek nie zbudował go jednak w Notion ani Obsidianie. Oparł całość na plikach Markdown i Claude Code.

Jednym z głównych problemów przy zwykłej rozmowie z AI jest to, że kontekst łatwo się rozprasza między kolejnymi sesjami. Jarek chciał mieć środowisko, które będzie przechowywało najważniejsze informacje w uporządkowany sposób i pozwoli mu do nich regularnie wracać.

Dlatego folder core/ pełni w jego systemie funkcję długoterminowej pamięci. Znajdują się tam informacje o jego celach, projektach, kontaktach i innych obszarach, które powinny być dostępne również podczas kolejnych sesji.

Do tego stworzył 16 własnych komend uruchamiających retrospektywy tygodniowe, miesięczne, kwartalne i roczne. Nie musi za każdym razem przygotowywać pytań i zbierać materiałów od początku. Uruchamia odpowiednią komendę, a system korzysta z informacji, które zostały zapisane wcześniej.

W jego rozwiązaniu działa również sześciu wirtualnych mentorów AI. Każdy analizuje decyzje z nieco innej perspektywy, dzięki czemu Jarek może skonfrontować kilka sposobów patrzenia na ten sam problem, zanim sam zdecyduje, co zrobić.

Kolejna automatyzacja łączy wiadomość głosową na Telegramie, n8n i Asanę. Jarek może nagrać wiadomość głosową, n8n ją transkrybuje, a na podstawie treści w Asanie powstaje odpowiednie zadanie. Dzięki temu nie musi po rozmowie ze sobą samym jeszcze raz otwierać systemu zadań i przepisywać do niego tego, co właśnie powiedział.

Podczas jednej z sesji wykorzystał również to środowisko do zbudowania aplikacji mobilnej w React Native. Powstała aplikacja z pięcioma ekranami, która umożliwia m.in. śledzenie nawodnienia i nawyków, prowadzenie dziennika oraz obsługę powiadomień push.

„Kurs StormIT zmienił sposób, w jaki myślę o narzędziach. To nie jest projekt do portfolio. To moje codzienne środowisko pracy.”

W jego przypadku najważniejszy okazał się właśnie ten ostatni element. Nie chodziło o stworzenie projektu tylko po to, żeby przećwiczyć Claude Code. Jarek zbudował system pod własny sposób pracy, a później zaczął z niego normalnie korzystać.

Fotowoltaika: dane z formularza zamieniają się w gotową ofertę

Kolejny projekt powstał w firmie zajmującej się m.in. fotowoltaiką, magazynami energii i klimatyzacją.

Jej współwłaściciel skończył technikum informatyczne 25 lat wcześniej, ale od tamtego czasu nie programował. Nie zaczynał więc kursu z zamiarem powrotu do kodowania ani przebranżowienia się na programistę.

Chciał przede wszystkim rozumieć, jak działają nowe narzędzia, żeby móc świadomie wykorzystywać je w swojej firmie.

„Zastanawiałem się nad tym, rozmawiałem z prowadzącym. Chciałbym trochę wiedzieć, o co chodzi. Chciałbym to kontrolować i myślę, że jak poznam strukturę i mechanizmy, to znajdę też mnóstwo nowych opcji.”

Jednym z procesów, które nadawały się do usprawnienia, było przygotowywanie wycen instalacji PV.

W firmie powstał więc kalkulator, w którym handlowiec podaje potrzebne informacje, m.in. rodzaj falownika, typ instalacji i lokalizację. Te dane trafiają następnie do n8n, gdzie rozpoczyna się dalsza część procesu.

Na podstawie formularza system przygotowuje PDF z ofertą, wysyła wiadomość do klienta, przesyła właścicielowi firmy powiadomienie na Telegramie i zapisuje dane w arkuszu. Logika kalkulatora uwzględnia różne kategorie produktów, m.in. instalacje fotowoltaiczne, magazyny energii i klimatyzację.

Ważne jest też to, że nie pozostał to projekt szkoleniowy. Kalkulator działa obecnie w firmie i korzystają z niego handlowcy.

Później powstał jeszcze agregator przetargów. Tutaj problem był inny: nie każdemu ogłoszeniu warto poświęcać tyle samo czasu, ale ktoś musi je najpierw przejrzeć, żeby dojść do takiego wniosku.

System wykonuje więc wstępną selekcję. AI ocenia przetargi w skali od 1 do 5, biorąc pod uwagę wartość kontraktu, wymagania techniczne oraz odległość od siedziby firmy. Dzięki temu handlowcy mogą zacząć od tych ofert, które mają większą szansę być dla firmy interesujące, zamiast po kolei analizować wszystkie.

„Generalnie to ja zmierzam do tego, żeby jak najwięcej swojej pracy zautomatyzować, dojść do tego, że w sumie jest to tylko rozmowa, a reszta dzieje się już w tle sama.”

Co ważne, odzyskanego czasu nie chce przeznaczać na dokładanie sobie kolejnej pracy.

„Chciałbym mieć czas dla siebie, nie szukam tu kolejnych zleceń i jakiejś pracy dodatkowej.”

W tym przypadku automatyzacja ma więc bardzo konkretny cel: firma ma działać sprawniej, ale właściciel nie chce dzięki temu tylko zwiększać liczby zadań, które jest w stanie zmieścić w ciągu dnia. Chce po prostu mniej czasu poświęcać na pracę, którą może wykonać system.

Prawo: od braku doświadczenia z kodem do RAG-u na 10 GB ustaw

Ostatni projekt stworzyła prawniczka z wykształcenia, która zawodowo pracuje jako analityczka finansowa. Przed rozpoczęciem kursu nie miała doświadczenia programistycznego.

Nie zaczęła więc od rozbudowanego doświadczenia technicznego. W trakcie nauki po raz pierwszy napisała kod w Pythonie, a później wykorzystała go przy kolejnych projektach.

Jednym z nich był RAG oparty na około 10 GB polskich ustaw z Dziennika Ustaw. System korzysta z Bielika, czyli polskiego modelu językowego uruchamianego lokalnie. Dzięki temu dokumenty nie muszą być wysyłane do zewnętrznej chmury.

Największym problemem technicznym okazało się nie samo uruchomienie modelu, ale przygotowanie dokumentów w taki sposób, żeby system potrafił je później sensownie przeszukiwać. Długich aktów prawnych nie można po prostu wrzucić do jednego zbioru i liczyć na to, że model zawsze znajdzie właściwy fragment.

Dlatego potrzebny był odpowiedni chunking, czyli podział dokumentów na mniejsze części. Trzeba było zdecydować, gdzie taki fragment powinien się zaczynać i kończyć, żeby z jednej strony nie był zbyt duży, a z drugiej nie tracił potrzebnego kontekstu.

Poza systemem RAG powstała także analiza tonu dokumentów napisana w Pythonie oraz workflow, który przenosi notatki z Telegrama do Kalendarza Google.

Swoje podejście do nauki i kolejnych problemów podsumowała prostym zdaniem:

„Jak mamy powiesić firanki, to trzeba umyć okno.”

W praktyce oznaczało to, że kiedy po drodze pojawiała się rzecz, której jeszcze nie potrafiła zrobić, traktowała ją jako kolejny element potrzebny do osiągnięcia właściwego celu, a nie jako powód, żeby projekt odłożyć.

Sam cel również nie polegał na tym, żeby zostać programistką.

„Docelowo wolałabym być kimś, kto na wzór tego, co robiłam dotychczas, czyli analizy, bardziej doradzać, co można wdrożyć i współpracować z zespołem.”

Chodziło więc o połączenie tego, co już potrafiła zawodowo, z możliwością lepszego rozumienia narzędzi AI i automatyzacji. Dzięki temu może nie tylko analizować problem biznesowy, ale też lepiej oceniać, jakie rozwiązanie techniczne da się zastosować i jak powinno ono działać.

Co łączy te projekty?

Na poziomie technicznym niewiele. System do monitorowania GPW działa inaczej niż agent dla pensjonatu, ten z kolei rozwiązuje zupełnie inny problem niż RAG na ustawach czy kalkulator wycen dla firmy fotowoltaicznej.

Wspólny jest natomiast punkt wyjścia.

Każda z tych osób zaczęła od problemu, który naprawdę występował w jej pracy albo codziennym sposobie działania. Nie budowała automatyzacji tylko dlatego, że akurat nauczyła się nowego narzędzia i chciała znaleźć dla niego jakieś zastosowanie.

Kamil wiedział, że codziennie traci kilkanaście minut na przeglądanie danych giełdowych, które da się zebrać automatycznie. Katarzyna wiedziała, ile czasu obiekty noclegowe tracą na przygotowywanie podobnych informacji dla kolejnych gości. Jan znał skalę ręcznej pracy potrzebnej do wstępnej obsługi zgłoszeń. W firmie fotowoltaicznej czas zabierało przygotowywanie ofert i selekcja przetargów.

Najpierw był konkretny proces. Dopiero później pojawiało się pytanie, które jego elementy warto oddać automatyzacji.

Powtarza się jeszcze jedna rzecz: w kilku projektach ich autorzy świadomie zdecydowali, czego AI nie powinno robić samodzielnie.

U Kamila model językowy nie odpowiada za liczby, bo w tym miejscu potrzebny jest deterministyczny mechanizm. W automatyzacji Katarzyny agent przygotowuje mail, ale nie wysyła go bez akceptacji. U Jana system automatycznie przekazuje niepewne lub krytyczne zgłoszenia człowiekowi. Nawet Jarek, który wykorzystuje kilku mentorów AI do analizowania swoich decyzji, sam podejmuje ostateczną decyzję i określa kolejne działania.

To ważne, bo dobra automatyzacja nie musi oznaczać przekazania całego procesu AI. Czasem największą oszczędność daje przejęcie przez system tych etapów, które są powtarzalne, czasochłonne albo polegają głównie na zbieraniu i porządkowaniu informacji, podczas gdy człowiek zostaje tam, gdzie potrzebna jest odpowiedzialność, ocena sytuacji albo ostateczna decyzja.

I właśnie od tego najlepiej zacząć myślenie o własnym projekcie.

Nie od pytania, czy nauczyć się najpierw n8n, Claude Code czy agentów AI. Najpierw warto sprawdzić, co w Twojej pracy regularnie zabiera czas, mimo że za każdym razem przebiega podobnie. Dopiero wtedy można zdecydować, które narzędzie rzeczywiście pomoże ten problem rozwiązać.

Zobacz, jak zacząć swój projekt