Oprócz udziału w warsztacie uczestnicy otrzymują rozszerzony pakiet rozwojowy, dzięki któremu mogą od razu wykorzystać zdobytą wiedzę w praktyce:
• 30-dniowy instruktaż samodzielnego rozwoju kompetencji AI,
• dostęp do biblioteki gotowych promptów i szablonów pracy,
• indywidualne konsultacje eksperckie.

Program został zaprojektowany tak, aby uczestnik nie kończył szkolenia wyłącznie z wiedzą, ale z realnie wdrożonym sposobem pracy.

Warsztat 1. Przyspieszenie pracy z dokumentami z wykorzystaniem wielkich modeli językowych AI.

Warsztat dla pracowników działów finansowych, którzy codziennie pracują z długimi dokumentami: umowami, politykami, protokołami posiedzeń, sprawozdaniami i dokumentacją projektową.

Cel: Celem szkolenia jest wyposażenie uczestników w umiejętność samodzielnego budowania wyspecjalizowanych asystentów AI do pracy z dokumentami. Uczestnicy poznają mechanizm działania modeli językowych przy analizie tekstu, zasady projektowania system prompt, metody weryfikacji odpowiedzi oraz granice bezpieczeństwa w kontekście dokumentów o charakterze poufnym. Szkolenie kończy się zbudowaniem własnego, działającego asystenta dokumentowego gotowego do wdrożenia w środowisku zawodowym uczestnika.

I. Jak model językowy „czyta” dokument – od tekstu do odpowiedzi

Cel: Zrozumienie mechanizmu przetwarzania tekstu przez duże modele językowe i wynikających z niego możliwości oraz ograniczeń.

Opis przebiegu: Prowadzący wyjaśni, w jaki sposób model językowy analizuje dokument: mechanizm tokenizacji, rolę kontekstu, granice okna kontekstowego oraz różnicę między wyszukiwaniem słów kluczowych a rozumieniem semantycznym. Uczestnicy wykonują ćwiczenie porównawcze: to samo pytanie do tego samego dokumentu zadane bez kontekstu i z precyzyjnym kontekstem. Różnica w jakości odpowiedzi staje się materiałem do dyskusji o tym, co model faktycznie robi.

Rezultaty:
• Uczestnicy rozumieją, dlaczego AI nie „czyta” dokumentu w ludzkim sensie, ale przetwarza go statystycznie.
• Potrafią wskazać, kiedy model sprawdzi się w analizie dokumentu, a kiedy nie należy mu ufać.

II. Od pytania do asystenta – budowa pierwszego Claude Projecta

Cel: Praktyczna umiejętność zbudowania wyspecjalizowanego asystenta AI w środowisku Claude Projects.

Opis przebiegu: Uczestnicy samodzielnie tworzą pierwszego asystenta dokumentowego: definiują cel, załączają jeden dokument źródłowy, piszą krótki system prompt i testują asystenta trzema pytaniami. Prowadzący pokazuje w tle, jak rozwijać asystenta iteracyjnie, jak dobierać przykłady i jak unikać typowego błędu „asystenta od wszystkiego”. Ćwiczenie kończy się prezentacją kilku asystentów uczestników i krótką informacją zwrotną grupy.

Rezultaty:
• Uczestnicy potrafią samodzielnie zbudować asystenta AI od podstaw.
• Rozumieją zasadę „jeden asystent – jeden cel” i umieją ją stosować.

III. System prompt jako kontrakt z asystentem – struktura i dobre praktyki

Cel: Opanowanie struktury skutecznego system prompt opartej na frameworkach CLEAR i SPEC.

Opis przebiegu: Prowadzący omawia anatomię profesjonalnego system prompt: rola, kontekst, zakres, zakazy, format wyjścia, fallback responses. Uczestnicy rozbudowują asystenta zbudowanego w poprzednim bloku, dodając precyzyjne kryteria akceptacji odpowiedzi i jasne granice działania. Pracują w parach – jeden uczestnik buduje, drugi testuje granice i zadaje pytania spoza zakresu, sprawdzając, czy asystent zachowuje się zgodnie z założeniami.

Rezultaty:
• Uczestnicy potrafią skonstruować system prompt spełniający kryteria jakości zawodowej.
• Rozumieją, dlaczego ograniczenia i zakazy są równie ważne jak instrukcje pozytywne.

IV. Kontrola jakości – halucynacje i weryfikacja w dokumentach prawnych i finansowych

Cel: Zbudowanie praktycznej umiejętności wykrywania halucynacji i błędów AI w odpowiedziach dotyczących dokumentów o wysokiej stawce.

Opis przebiegu: Uczestnicy otrzymują pakiet sześciu odpowiedzi AI do tego samego dokumentu – część z nich zawiera subtelne halucynacje. Pracując w trójkach, w ciągu 15 minut mają wskazać, które odpowiedzi są poprawne, które wymagają zastrzeżenia, a które są błędne. Debriefing koncentruje się na tym, jakie błędy są najdroższe w kontekście pracy finansisty i jak projektować proces weryfikacji (Human-in-the-Loop) w codziennej pracy.

Rezultaty:
• Uczestnicy rozpoznają typowe wzorce halucynacji w dokumentach finansowych i prawnych.
• Potrafią zaprojektować własną procedurę weryfikacji odpowiedzi asystenta.

V. Projekt warsztatowy – zbudowanie własnego asystenta dokumentowego

Cel: Konsolidacja wiedzy warsztatu w formie gotowego do wdrożenia produktu pracy uczestnika.

Opis przebiegu: Każdy uczestnik buduje w pełni działającego asystenta dokumentowego dopasowanego do własnego stanowiska: analityk umów, asystent protokołów zarządu, auditor polityk wewnętrznych lub inny profil zgodny z jego pracą. Asystent ma komplet: system prompt, dokumenty źródłowe, checklistę weryfikacyjną, listę zakazanych zadań. Na koniec każdy uczestnik deklaruje jeden konkretny dokument z własnej pracy, do którego zastosuje asystenta w ciągu tygodnia następującego po warsztacie.

Rezultaty:
• Uczestnicy wynoszą z warsztatu gotowego, działającego asystenta dokumentowego.
• Mają zdefiniowany pierwszy przypadek użycia w swojej pracy zawodowej.

Warsztat 2. AI a Excel i obliczenia – Claude i Copilot w praktyce analityka.

Warsztat dla analityków finansowych, kontrolerów i księgowych pracujących na co dzień z arkuszami kalkulacyjnymi i modelami finansowymi.

Cel: Celem szkolenia jest nauczenie uczestników świadomego i bezpiecznego wykorzystania AI w pracy obliczeniowej – tam, gdzie błąd w liczbie może oznaczać błędną decyzję zarządczą. Uczestnicy poznają fundamentalną różnicę między Claude z narzędziem analitycznym a Copilotem zintegrowanym z Excelem, nauczą się wybierać właściwe narzędzie do zadania, a także zbudują praktyczne nawyki weryfikacji odpowiedzi AI w kontekście analizy wskaźnikowej i modelowania scenariuszowego.

I. Dlaczego AI źle liczy – granica arytmetyki w modelach językowych

Cel: Zbudowanie realistycznych oczekiwań wobec AI w zadaniach obliczeniowych.

Opis przebiegu: Prowadzący wyjaśnia, dlaczego duży model językowy natywnie nie jest kalkulatorem – przewiduje kolejny token na podstawie prawdopodobieństwa, a nie wykonuje operacji matematycznej. Uczestnicy wykonują ćwiczenie, w którym zadają Claude trzy coraz trudniejsze zadania liczbowe bez uruchomienia narzędzia analitycznego i obserwują, w którym momencie model zaczyna halucynować liczby. Następnie to samo zadanie uruchamiane jest z Analysis Tool – wynik jest natychmiast poprawny. Ćwiczenie ustanawia fundamentalne rozróżnienie: „LLM mówi o liczbach, narzędzie liczy liczby”.

Rezultaty:
• Uczestnicy wiedzą, kiedy AI daje realny wynik, a kiedy jedynie jego wiarygodną imitację.
• Potrafią świadomie włączać narzędzia obliczeniowe, zamiast polegać na natywnych odpowiedziach modelu.

II. Dwie drogi do wyniku – Copilot w Excelu vs. Claude z Analysis Tool

Cel: Porównanie dwóch podejść do analizy danych i wybór właściwego narzędzia dla konkretnego zadania.
Opis przebiegu: Uczestnicy otrzymują ten sam pakiet danych finansowych (bilans, rachunek zysków i strat, rachunek przepływów pieniężnych z trzech lat) i wykonują to samo zadanie analityczne w dwóch środowiskach: Copilot w Excelu oraz Claude z Analysis Tool. Porównują wyniki, czas wykonania, możliwość iteracji oraz jakość komentarza analitycznego. Na koniec mapują, która droga sprawdza się przy jakim typie zadania: ad-hoc analiza vs. model wielokrotnego użycia, dane wrażliwe vs. dane publiczne, zadanie jednorazowe vs. powtarzalne.

Rezultaty:
• Uczestnicy potrafią świadomie wybrać Claude lub Copilot dla konkretnego zadania analitycznego.
• Rozumieją granice obu narzędzi w kontekście bezpieczeństwa danych i jakości wyniku.

III. AI jako junior analityk – analiza wskaźnikowa sprawozdania

Cel: Praktyczne wykorzystanie AI do przyspieszenia analizy wskaźnikowej przy zachowaniu kontroli jakości.

Opis przebiegu: Każdy uczestnik otrzymuje sprawozdanie finansowe nieznanej spółki i zleca AI wygenerowanie pełnego zestawu wskaźników: rentowności, płynności, zadłużenia, sprawności operacyjnej, wraz z komentarzem analitycznym. Następnie wykonuje ręczną weryfikację trzech losowo wybranych wskaźników. Ćwiczenie kończy się dyskusją: które wskaźniki AI policzyło poprawnie, gdzie halucynowało, które błędy byłyby katastrofalne w komunikacji z zarządem, a które jedynie niewygodne.

Rezultaty:
• Uczestnicy potrafią wykorzystać AI jako asystenta analitycznego, zachowując rolę weryfikującego eksperta.
• Umieją zaprojektować procedurę kontroli jakości odpowiedzi AI dla analizy wskaźnikowej.

IV. Modelowanie scenariuszowe – delegowanie struktury, weryfikacja liczb

Cel: Opanowanie techniki delegowania AI pracy koncepcyjnej przy zachowaniu kontroli nad obliczeniami.

Opis przebiegu: Uczestnicy budują prosty model scenariuszowy dla hipotetycznej decyzji inwestycyjnej: trzy scenariusze (bazowy, optymistyczny, pesymistyczny), kluczowe zmienne i założenia. Claude generuje strukturę modelu, uczestnik przenosi ją do Excela, uruchamia i iteruje. Prowadzący wprowadza zasadę „deleguj wyniki, nie funkcje” – AI projektuje architekturę modelu, uczestnik zachowuje kontrolę nad logiką obliczeń i założeniami. Ćwiczenie pokazuje, gdzie kończy się użyteczność AI w modelowaniu i gdzie zaczyna niezastępowalna rola analityka.

Rezultaty:
• Uczestnicy potrafią wykorzystać AI do zaprojektowania architektury modelu finansowego.
• Rozumieją, które elementy modelu muszą pozostać pod pełną kontrolą człowieka.

V. Projekt warsztatowy – roboczy model finansowy z weryfikacją AI

Cel: Zbudowanie w trakcie warsztatu gotowego modelu analitycznego do zastosowania w pracy zawodowej uczestnika.

Opis przebiegu: Każdy uczestnik wybiera jeden realny problem analityczny ze swojej pracy – analiza odchyleń, prognoza cash flow, model marżowy, analiza rentowności produktu – i wykonuje go z wykorzystaniem AI według metodyki poznanej w warsztacie. Efektem pracy jest arkusz Excela z komentarzem analitycznym i checklistą weryfikacyjną. Na zamknięciu uczestnicy deklarują, który proces analityczny w swojej firmie przepiszą na nowy tryb pracy w najbliższym miesiącu.

Rezultaty:
• Uczestnicy wynoszą z warsztatu roboczy model finansowy gotowy do adaptacji.
• Mają zdefiniowany pierwszy proces analityczny do przeprojektowania z wykorzystaniem AI.

Warsztat 3. Budowa firmowej bazy wiedzy w oparciu o AI – ćwiczenia w RAG.

Warsztat dla osób odpowiedzialnych za dokumentację wewnętrzną, polityki, procedury i procesy wymagające dostępu do wiedzy specyficznej dla organizacji.

Cel szkolenia: Celem szkolenia jest nauczenie uczestników, jak wyposażyć asystenta AI w wiedzę, której publiczne modele nie posiadają – wiedzę o polityce rachunkowości własnej firmy, planie kont, procedurach, instrukcjach wewnętrznych, umowach typowych. Uczestnicy poznają mechanizm retrieval-augmented generation (RAG) w ujęciu praktycznym, porównają trzy dostępne ścieżki techniczne oraz zbudują własną firmową bazę wiedzy gotową do wdrożenia, z zachowaniem zasad poufności i zgodności regulacyjnej.

I. Granica wiedzy modelu – co AI wie, a czego nie wie o Twojej firmie

Cel: Zrozumienie fundamentalnej różnicy między wiedzą publiczną modelu a wiedzą specyficzną dla organizacji.

Opis przebiegu: Prowadzący wprowadza koncepcję granicy wiedzy modelu: AI zna polską ustawę o rachunkowości, ale nie zna polityki rachunkowości konkretnej firmy; zna standardy raportowania, ale nie zna konkretnych szablonów stosowanych w organizacji uczestnika. Uczestnicy wykonują ćwiczenie: formułują dziesięć pytań specyficznych dla swojej firmy, na które żadne publiczne AI nie zna odpowiedzi. Grupa wspólnie klasyfikuje typy tych pytań i identyfikuje wzorce: procedury, wartości graniczne, odpowiedzialności, terminy, odstępstwa.

Rezultaty:
• Uczestnicy rozumieją, gdzie leży granica między wiedzą publiczną a firmową.
• Potrafią zidentyfikować obszary, w których RAG przyniesie realną wartość biznesową.

II. Trzy ścieżki retrievala – Claude Projects, NotebookLM, custom RAG

Cel: Porównanie trzech dostępnych podejść do budowy asystenta z wiedzą firmową.

Opis przebiegu: Uczestnicy testują ten sam pakiet dokumentów firmowych (plan kont, polityka rachunkowości, instrukcja obiegu dokumentów) w trzech środowiskach: Claude Projects, Google NotebookLM oraz custom RAG zbudowany w ramach demonstracji prowadzącego. Porównują jakość odpowiedzi, precyzję cytowań, obsługę długich dokumentów, koszt utrzymania, poziom kontroli nad bezpieczeństwem danych. Debriefing kończy się matrycą decyzyjną: które rozwiązanie dla której organizacji i którego procesu.

Rezultaty:
• Uczestnicy potrafią wybrać odpowiednią ścieżkę techniczną dla potrzeb swojej firmy.
• Rozumieją kompromisy między prostotą wdrożenia, kosztem a poziomem kontroli.

III. Projektowanie asystenta firmowego – zasada „jeden asystent, jeden cel”

Cel: Opanowanie zasad projektowania skutecznego asystenta z bazą wiedzy.

Opis przebiegu: Uczestnicy w parach projektują asystenta firmowego dla konkretnego procesu: asystent zamknięcia miesiąca, asystent polityki rachunkowości, asystent procedur zakupowych. Budują go w Claude Projects w trzech iteracjach: wersja bazowa, wersja po testach, wersja po peer review. Prowadzący wprowadza antypattern „asystenta od wszystkiego” i pokazuje, dlaczego wyspecjalizowany asystent zawsze wygrywa jakością z uniwersalnym.

Rezultaty:
• Uczestnicy potrafią zaprojektować asystenta firmowego z precyzyjnie określonym zakresem.
• Rozumieją, dlaczego segmentacja wiedzy na wyspecjalizowane asystenty poprawia jakość odpowiedzi.

IV. Compliance i poufność – co może, a co nie może trafić do chmurowego modelu

Cel: Zbudowanie świadomości regulacyjnej i bezpieczeństwa danych w kontekście wdrożeń RAG.

Opis przebiegu: Prowadzący prezentuje studium przypadku: pracownik wrzucił do publicznego chatbota politykę wynagrodzeń zawierającą imiona i kwoty. Uczestnicy analizują kaskadę konsekwencji: RODO, tajemnica przedsiębiorstwa, obowiązki informacyjne, AI Act. Następnie tworzą wspólnie mapę ryzyk dla własnej firmy i decyzyjną matrycę: co wolno, co wymaga anonimizacji, co wymaga lokalnego modelu (np. Bielik), czego nie wolno nigdy.

Rezultaty:
• Uczestnicy znają granice bezpieczeństwa danych w pracy z modelami chmurowymi.
• Potrafią ocenić, które procesy wymagają rozwiązania on-premise lub suwerennego AI.

V. Projekt warsztatowy – firmowa baza wiedzy w Claude Projects

Cel: Zbudowanie funkcjonalnej firmowej bazy wiedzy gotowej do pilotażu w organizacji uczestnika.

Opis przebiegu: Każdy uczestnik identyfikuje jeden proces w swojej firmie, który wymaga dostępu do wiedzy firmowej, i buduje dla niego dedykowany Claude Project: od pięciu do siedmiu dokumentów, precyzyjny system prompt, testowe pytania, checklista weryfikacji. Na zamknięciu uczestnik przedstawia plan: które kolejne dokumenty doda, kto w organizacji będzie pierwszym testerem, jaki wskaźnik pozwoli ocenić wartość asystenta po trzydziestu dniach.

Rezultaty:
• Uczestnicy wynoszą z warsztatu działającą firmową bazę wiedzy z pierwszym przypadkiem użycia.
• Mają plan trzydziestodniowego pilotażu w swojej organizacji.

Warsztat 4. Zlecanie AI tworzenia automatyzacji w firmie – vibe-coding.

Warsztat dla osób gotowych przejść od korzystania z AI jako asystenta do korzystania z AI jako wykonawcy procesów – bez konieczności posiadania umiejętności programistycznych.

Cel: Celem szkolenia jest przekroczenie granicy między używaniem AI a zlecaniem AI realizacji konkretnych procesów w firmie. Uczestnicy poznają logikę automatyzacji opartych na AI, zbudują pierwszy workflow w środowisku n8n oraz doświadczą vibe-codingu – praktyki, w której osoba bez znajomości programowania zleca modelowi napisanie skryptu i sama go uruchamia. Szkolenie kończy się opracowaniem karty pilotażu automatyzacji dla konkretnego procesu w organizacji uczestnika.

I. Od asystenta do wykonawcy – czym różni się automatyzacja od konwersacji z AI

Cel: Zrozumienie fundamentalnej zmiany paradygmatu między AI konwersacyjnym a AI wykonawczym.

Opis przebiegu: Prowadzący wprowadza trzy poziomy dojrzałości pracy z AI: AI odpowiada (chatbot), AI asystuje (Claude Project), AI wykonuje (agent/workflow). Uczestnicy wspólnie mapują procesy ze swoich działów na te trzy poziomy i identyfikują, które z nich kwalifikują się do pełnej automatyzacji, które do wspomagania, a które powinny pozostać w pełni pod kontrolą człowieka. Krótki wykład wprowadza zasadę Pareto automatyzacji: dwadzieścia procent procesów zjada osiemdziesiąt procent czasu zespołu.

Rezultaty:
• Uczestnicy rozróżniają trzy poziomy dojrzałości pracy z AI i ich zastosowania.
• Potrafią ocenić, które procesy w ich dziale kwalifikują się do pełnej automatyzacji.

II. n8n w praktyce – workflow bez kodu jako narzędzie finansisty

Cel: Pierwsze praktyczne doświadczenie z platformą automatyzacyjną no-code w kontekście procesów finansowych.

Opis przebiegu: Prowadzący pokazuje na żywo działający workflow w n8n: formularz Google zbiera dane, AI klasyfikuje zgłoszenie, system wysyła skonstruowaną odpowiedź do właściciela procesu. Uczestnicy w parach mapują analogiczny proces z własnego działu – akceptacja faktur, obsługa zapytań od biznesu, klasyfikacja MPK – i rysują jego strukturę w notacji: trigger, kroki przetwarzania, punkty decyzyjne (w tym HITL), wyjście. Ćwiczenie kończy się prezentacją trzech najciekawszych propozycji przed grupą.

Rezultaty:
• Uczestnicy rozumieją logikę działania platform automatyzacyjnych no-code.
• Potrafią zaprojektować strukturę workflow dla konkretnego procesu w swojej firmie.

III. Vibe-coding – zlecenie modelowi napisania skryptu bez znajomości programowania

Cel: Doświadczenie pierwszej automatyzacji opartej na kodzie napisanym przez AI na zlecenie uczestnika.

Opis przebiegu: Każdy uczestnik wybiera proste, powtarzalne zadanie – przetworzenie folderu faktur PDF i wyciągnięcie kwot do pliku CSV, przekonwertowanie pliku Excela, porównanie dwóch list – i zleca Claude napisanie skryptu. Nie pisze żadnej linijki kodu. Opisuje efekt, uruchamia wynik, iteruje. Prowadzący wprowadza granice bezpieczeństwa vibe-codingu: czego nie wolno zlecać, jak weryfikować skrypt przed uruchomieniem na realnych danych, dlaczego zasada „działa u mnie” nie znaczy „działa u nas”.

Rezultaty:
• Uczestnicy wykonali pierwszą automatyzację opartą na kodzie wygenerowanym przez AI.
• Znają granice bezpieczeństwa vibe-codingu w środowisku firmowym.

IV. Karta pilotażu AI – od pomysłu do kontrolowanego wdrożenia

Cel: Opanowanie metodyki projektowania kontrolowanego pilotażu automatyzacji AI.

Opis przebiegu: Uczestnicy pracują nad własną kartą pilotażu według struktury: jeden proces, jeden właściciel biznesowy, jedno narzędzie, jedno kryterium sukcesu, jedna decyzja STOP/GO po trzydziestu dniach. Prowadzący omawia typowe błędy przy projektowaniu pilotażu: zbyt szeroki zakres, brak właściciela, brak kryterium sukcesu, brak momentu decyzji o kontynuacji. Każda karta kończy się peer review w parze i zapisem konkretnych działań na najbliższe dwa tygodnie.

Rezultaty:
• Uczestnicy potrafią zaprojektować kartę pilotażu AI spełniającą standardy zarządcze.
• Mają konkretny plan wdrożenia jednej automatyzacji w najbliższym miesiącu.

V. Projekt warsztatowy – plan dziewięćdziesięciodniowej transformacji własnego procesu

Cel: Zamknięcie programu czterech warsztatów przez zobowiązanie do konkretnej transformacji w pracy uczestnika.

Opis przebiegu: Uczestnicy syntezują wiedzę z całego cyklu czterech warsztatów w postaci dziewięćdziesięciodniowego planu: trzy działania do wykonania, dwa ryzyka do kontrolowania, jeden wskaźnik sukcesu do monitorowania. Plan obejmuje wszystkie cztery obszary: asystenci dokumentowi, analiza z AI, firmowa baza wiedzy, automatyzacje. Każdy uczestnik prezentuje swój plan grupie w sześćdziesięciu sekundach. Zamknięcie ma charakter kontraktu z samym sobą – dorosły uczy się, gdy widzi natychmiastowe zastosowanie.

Rezultaty:
• Uczestnicy wynoszą z cyklu konkretny, zmierzalny plan transformacji własnej pracy na najbliższe trzy miesiące.
• Mają zdefiniowane wskaźniki sukcesu, które pozwolą ocenić realną wartość przejścia przez program.

Online:
Warsztat 1 i 2: 2-3.07.2026
Warsztat 3 i 4: 16-17.07.2026