WARSZTATY AI DLA ORGANIZACJI

Szkolenia z AI zwykle umierają na slajdzie „co to jest token” — postanowiłem, że u mnie każdy moduł zaczyna się od prawdziwego dokumentu firmy: dokumentacja przetargowa z załącznikami, raport z JIRA, notatki z daily, zdjęcie retro-boardu. Do każdego case'a przygotowałem gotowy input, system prompt jako checklistę i oczekiwany output, więc uczestnik nie ogląda demo — przechodzi proces, który następnego dnia powtórzy na własnych danych. Zbudowanie 17 takich case'ów wymagało więcej pracy niż niejeden projekt programistyczny, bo każdy musiał wytrzymać kontakt z realnym dokumentem, nie spreparowanym przykładem.

Osoba decyzyjna nie napisze ani linijki kodu i nie powinna musieć — a większość materiałów o AI zakłada odwrotnie. Przekładam LLM-y na język decyzji: capacity planning zamiast „context window”, pre-read na spotkanie decyzyjne zamiast „completion”, koszt złej decyzji zamiast kosztu tokena. Zero wymagań programistycznych to była twarda rama projektowa — wszystko, co pokazuję, musi działać z poziomu przeglądarki i gotowego promptu do wklejenia.

Część danych nie może opuścić infrastruktury — regulacja, umowa albo polityka bezpieczeństwa — i to nie jest przypis, tylko blokada wdrożenia. Poprowadziłem osobny wątek modeli lokalnych: LM Studio na maszynie uczestnika, dobór modelu do zadania, uczciwa rozmowa o tym, co lokalny model umie, a czego nie. Paradoksalnie ten moduł buduje najwięcej zaufania — pokazuje, że AI nie musi oznaczać wysyłania firmowych dokumentów w świat.

Prezentacja na 80+ slajdów nie mieści się w oknie kontekstowym modelu — w połowie decku Claude gubił stan i wypełnianie się sypało. Rozbiłem więc budowę na trzy komendy uruchamiane w osobnych czatach (init → fill × N → verify), a stan procesu wsadziłem do samego decku: ukryty slajd trzyma JSON w polu notatek, fill czyta go na starcie, wypełnia partię 25–30 slajdów, aktualizuje fazę i sam się zatrzymuje przy ~60% okna, prosząc o nowy czat — checkpoint/resume zamiast jednego przebiegu. Drugą pułapką był sam Master: nie ma pól na opisy kart, a kolejność ID shape'ów nie odpowiada wizualnej kolejności A/B/C — mechaniczne „i-ty shape = i-ta karta” wpisywałoby treść pod złą literę. Zbudowałem więc słowniczek 21 slajdów-reprezentantów z rolami shape'ów i ostrzeżeniami zaszytymi inline — fill musi czytać rolę, nie pozycję, a opisy, na które nie ma pól, jadą do notatek prowadzącego zamiast łamać geometrię OOXML.

Materiały szkoleniowe muszą spełniać ustawę o dostępności cyfrowej (WCAG 2.1 AA): zakaz kursywy, rozwijanie skrótów, słowniczek żargonu, powtarzany nagłówek tabeli, poprawne metadane językowe — a przy 323 plikach DOCX ręczna korekta jest nie do utrzymania. Zamiast checklisty dla człowieka napisałem konwerter Markdown→DOCX (8 skryptów, 1351 linii Pythona), który reguły dostępności wykonuje jako automatyczne transformacje OOXML: kursywa zamienia się w pogrubienie, skróty dostają rozwinięcia, słowniczek pojęć buduje się sam, tabele dostają w:tblHeader, dokument — firmowy motyw dokumentu i language=pl-PL. Zgodność regulacyjna przestała być etapem — jest właściwością generatora.