Mnożnik jest tu bezlitosny: jeden zatwierdzony materiał globalny razy liczba rynków, języków, grup odbiorców, kanałów i formatów. Przy czym każdy wariant musi nadal nieść wszystkie elementy obowiązkowe — informacje bezpieczeństwa, równowagę przekazu, odnośniki do charakterystyki produktu i kody zadań. To nie jest zadanie, które można oddać generatorowi treści i sprawdzić wyrywkowo.

Odpowiadałem za architekturę techniczną rozwiązania. Zaprojektowałem ją wokół jednego środowiska Azure Container Apps, obejmującego aplikację frontendową, API, UI dla HITL oraz samych agentów.

Sam przepływ jest wieloetapowy. Zadania adaptacyjne wykonują się równolegle, korzystając z dynamicznych baz wiedzy opisujących markę, kanał i rynek. Po wygenerowaniu materiał przechodzi przez warstwę walidacji i krytyki z iteracją — model ocenia i poprawia własny wynik, zanim cokolwiek trafi do człowieka. Dopiero potem wchodzi przegląd z udziałem recenzenta, który może wprowadzić poprawki poleceniem w języku naturalnym. Osobnym, niełatwym wymaganiem była izolacja między markami: pełne oddzielenie kontekstu i danych, zrealizowane przez wydzielone kontenery, kontrolę dostępu opartą na rolach i prywatne punkty końcowe.

Technologie: Azure Container Apps, Python, agenci LLM, Azure AI Search, zewnętrzne API generatywne

Wartość demo polegała na pokazaniu zwielokrotnienia liczby wariantów przy zachowaniu elementów obowiązkowych i wyjściu w postaci plików warstwowych, edytowalnych, a nie zamkniętych artefaktów wygenerowanych przez model.

W treściach regulowanych warstwa walidacji jest ważniejsza od warstwy generującej. Model, który tworzy dwadzieścia wariantów, jest tani. Model, który potrafi udowodnić, że wszystkie dwadzieścia niesie komplet wymaganych elementów, jest tym, za co klient faktycznie płaci.

Potrzebny był fundament pozwalający zespołom budować agentów bez powtarzania tej samej pracy: wspólne uwierzytelnianie, wspólny routing do modeli, wspólna obserwowalność i jasne granice odpowiedzialności między agentem, narzędziem a danymi.

Zaprojektowałem platformę opartą o wzorzec backend-for-frontend. Aplikacja SPA nigdy nie przechowuje tokenów, sesja żyje po stronie backendu, a dostęp do modeli prowadzi przez jedno proxy z limitami i rozliczaniem kosztów w podziale na zespoły. Agenci są budowani w LangGraph i wystawiani przez ustandaryzowane protokoły, dzięki czemu jeden agent może być narzędziem dla drugiego bez pisania integracji od zera. Całość działa na Azure Container Apps, z infrastrukturą opisaną deklaratywnie i pełnym śladem wykonania zbieranym w Langfuse.

Technologie: Python, LangGraph, FastAPI, Azure Container Apps, Entra ID, LiteLLM, Langfuse, Docker, Terraform.

Nowy agent startuje z gotowym uwierzytelnianiem, obserwowalnością i politykami bezpieczeństwa, zamiast budować je od podstaw. Koszt inferencji stał się mierzalny i przypisany do konkretnego zespołu, a nie do jednej wspólnej faktury na koniec miesiąca.

Najdroższym elementem platformy agentowej nie jest model. Są nim granice: kto ma dostęp do jakich danych, kto ponosi koszt i kto odpowiada za treść odpowiedzi. Jeżeli nie rozstrzygnie się tego w architekturze, orkiestrator jedynie rozprowadzi ten problem na większą powierzchnię.

Zakres obejmował całość: przygotowanie przed wydarzeniem, dwudniowe warsztaty stacjonarne, dziesięć zdalnych sesji mentoringowych w trakcie dwutygodniowego sprintu prototypowania oraz udział w finałowej prezentacji. Byłem odpowiedzialny za projekt merytoryczny programu, przygotowanie wszystkich materiałów i prowadzenie warsztatów na miejscu, a następnie za mentoring zespołów. Uczestnikami było około pięćdziesięciu osób z ról biznesowych, nie technicznych — z obszarów HR, sprzedaży, łańcucha dostaw, produkcji i rozwoju produktu, z kilku krajów regionu.

Problem, który trzeba było rozwiązać zanim zaczął się hackathon

Hackathony AI dla osób nietechnicznych mają jedną charakterystyczną przypadłość: kończą się zestawem pomysłów na chatbota. Uczestnik, który zna AI wyłącznie z asystenta w przeglądarce, będzie proponował warianty tego, co zna. Efektem jest dzień dobrej energii i portfel koncepcji, których nikt nie sfinansuje, bo żadna nie została połączona z konkretnym procesem, konkretnym użytkownikiem i konkretną liczbą.

Drugi problem to rozrzut wiedzy. W sali siedzą obok siebie ludzie, dla których GenAI to codzienne narzędzie, i tacy, którzy nie używali go nigdy. Warsztat prowadzony na uśrednionym poziomie zanudzi jednych i zgubi drugich.

Rozwiązanie

Przed wydarzeniem przygotowałem kwestionariusz oceny wiedzy o AI, GenAI, agentach, RAG, gotowości danych i odpowiedzialnym stosowaniu AI. Wypełniło go czterdzieści osób na pięćdziesiąt cztery, a wyniki posłużyły mi do skalibrowania modułu wprowadzającego — przygotowałem materiał z nadmiarem, żeby mieć co przycinać, zamiast improwizować w trakcie. Ten sam kwestionariusz, w wersji powtórzonej po wydarzeniu, pozwolił zmierzyć faktyczny przyrost wiedzy, a nie tylko zadowolenie uczestników.

Program został zbudowany według jasnej logiki. Dzień pierwszy to inspiracja i nauka: wspólny słownik pojęć, przegląd realnych zastosowań AI w branży FMCG i w operacjach, praktyczny tutorial promptowania, zasady bezpiecznego i zgodnego z regulacjami korzystania z narzędzi oraz — co uważam za najważniejszy moduł całego dnia — sesja o tym, jak przejść od generycznego pomysłu na chatbota do rozwiązania powiązanego z wartością biznesową, zmianą procesu i konkretnym użytkownikiem. Domknąłem to blokiem o adopcji i fazie RUN, bo zespoły z reguły kończą myślenie na dniu wdrożenia.

Dzień drugi to warsztat pracy własnej zespołów: kwestionowanie ambicji pomysłu, ramowanie problemu, mapa beneficjentów, projekt koncepcji rozwiązania, reality check dotyczący danych i wykonalności, przygotowanie makiety lub przykładowego wyniku oraz szkielet pitcha. Mentorzy i wyznaczeni przez klienta AI Champions mieli w tym dniu jedną wyraźną zasadę: nie rozwiązują problemów biznesowych za zespoły i nie podsuwają rozwiązań. Naprawadzają celnymi pytaniami.

Narzędziowo oparliśmy program o wewnętrzne, agentyczne rozwiazanie Lingaro, uruchomione jako dedykowana instancja na naszej infrastrukturze, z osobnymi kluczami dostępowymi dla pięciu zespołów. Przygotowałem dwa szablony pracy: jeden do indywidualnego kształtowania pomysłu przed pracą zespołową, drugi jako główny szablon prowadzący zespół od wybranego kierunku do udokumentowanej koncepcji. Narzędzie nie generuje pomysłów za uczestników — zadaje pytania, które zadałby dobry facylitator: kto dokładnie skorzysta, jakie dowody potwierdzają problem, co musi być prawdą, żeby to zadziałało, jakie dane są potrzebne i jak wyglądałby wiarygodny MVP. Przy okazji zapisuje tok myślenia zespołu i zamienia go w ustrukturyzowaną, porównywalną dokumentację.

Osobnym zadaniem było uporządkowanie kryteriów oceny. W poprzedniej edycji każde wyzwanie biznesowe miało odrębne zasady, co uniemożliwiało porównywanie zespołów między sobą. Przygotowałem jednen, wspólny arkusz ocen, obejmujący dopasowanie strategiczne, wartość dla użytkownika i biznesu, wykonalność, sensowność zastosowania AI oraz gotowość do przejścia poza pilotaż, z dodatkową premią za siłę narracji. Do arkusza dopisałem reguły pomocne dla sędziów,np. która że premii za prezentację nie wolno używać do kompensowania słabej treści. Kryteria zamieniłem następnie w dedykowany szablon w naszym agentycznym rozwiązaniu, którr dzięki temu potrafiło wygenerować zestaw prawdopodobnych pytań od jury na podstawie materiałów zespołu i pomóc się przygotować do ostatecznej prezentacji.

Efekt

Pięć koncepcji gotowych do prototypowania, z udokumentowanym problemem, beneficjentami, założeniami co do danych, hipotezą wartości i planem MVP. Łączna pula wartości zidentyfikowana przez zespoły przekroczyła 6 mln EUR rocznie — w wariancie kierunkowym, wymagającym walidacji po stronie klienta, co konsekwentnie komunikowaliśmy, żeby nikt nie pomylił projekcji z potwierdzoną oszczędnością.

Zwycięski projekt wyszedł z obszaru łańcucha dostaw i produkcji: platforma decyzyjna dla zakładów produkcyjnych, przewidująca odchylenia procesu, optymalizująca parametry pracy dla danej partii, podpowiadająca operatorom działania korygujące i ucząca się z kolejnych cykli. Zespół zaadresował nim realne straty — wydajność fermentacji poniżej celu, zmienność uzysku, utracone partie i czas reakcji na odchylenie sięgający dobę. Uważam to za najlepszy przykład tego, co chciałem osiągnąć programem: AI wpływająca bezpośrednio na wskaźniki operacyjne i rentowność produkcji, a nie kolejne usprawnienie pracy biurowej.

Satysfakcja uczestników wyniosła 4,5 na 5, a NPS po dniu otwierającym przekroczył +70.

Czego się nauczyłem

Po pierwsze, kwestionariusz przed wydarzeniem był najtańszym elementem programu i jednym z najbardziej wartościowych. Kilka godzin pracy dało mi konkretną wiedzę o tym, co przyciąć, a co rozwinąć — zamiast zgadywania na sali.

Po drugie, gotowość techniczna po stronie klienta to ryzyko, które trzeba testować, a nie deklarować. Drugiego dnia okazało się, że firewall przepuszcza do narzędzia wyłącznie pliki markdown i CSV, blokując PDF-y i obrazy. Lokalny zespół IT odblokował to w trakcie, ale kilkadziesiąt minut pracy zespołów zostało straconych. Przy kolejnych edycjach test end-to-end z udziałem IT klienta wchodzi do zakresu obowiązkowo.

Po trzecie, jestem mocno zorientowany na pracę i przy planowaniu drugiego dnia nie zaplanowałem żadnych aktywności rozluźniających. Zwrócili mi na to uwagę koledzy z zespołu i mieli rację — dołożone ćwiczenia przełamujące rytm wyraźnie poprawiły energię grupy po przerwie obiadowej. Warsztat to nie tylko agenda merytoryczna.

Na koniec kwestia, która w tego typu wydarzeniach bywa pomijana: dane. Po finale klient otrzymał komplet materiałów wejściowych i wyjściowych wytworzonych w narzędziu, a instancja została wyłączona i skasowana wraz z potwierdzeniem, że nie zostały na niej żadne pliki. Warto mieć to zaplanowane od początku, a nie ustalać po fakcie.

Zadanie, które sobie postawiłem, brzmiało: przełożyć akt prawny na decyzje podejmowane przez programistę w piątek po południu. Czy ten commit zmienia klasę ryzyka systemu? Czy ten model wymaga dokumentacji technicznej? Czy to jeszcze wsparcie decyzji, czy już decyzja automatyczna?

Przygotowałem praktyczny przewodnik dla inżynierów — nie wykład prawniczy, lecz ścieżkę decyzyjną z checklistami i jasno wyznaczonym momentem eskalacji do prawnika. Do tego narzędzie wstępnej oceny poziomu ryzyka wpięte w moment rozpoczęcia projektu oraz zestaw zasad dotyczących oznaczania treści generowanych przez AI i zachowania śladu audytowego. Materiał dostarczyłem w formie szkolenia dla społeczności deweloperskiej, współtworzonego z zespołem prawnym i compliance.

Efektem jest przeniesienie oceny ryzyka z kategorii dokumentu tworzonego po fakcie do kategorii standardowego kroku uruchamiającego projekt. Zespoły wiedzą, kiedy mogą działać samodzielnie, a kiedy muszą podnieść rękę.

„Nie wiedziałem” nie jest linią obrony, tylko przyznaniem się. Zgodność da się zoperacjonalizować wyłącznie wtedy, gdy jej koszt dla pojedynczego inżyniera spadnie do kilku minut.

Standardowa odpowiedź na ten problem brzmi: zainstalujcie GPS. Jest kosztowna, wymaga zgody właścicieli wynajmowanej floty i nie obejmie przewoźników, którzy jutro dołączą do sieci. Postawiłem więc pytanie inaczej: skoro kierowca i tak ma telefon, a ręczne dzwonienie działa — tylko nie skaluje się — to co się stanie, jeśli zeskalujemy samo dzwonienie?

Zaprojektowałem rozwiązanie, w którym agent głosowy automatycznie dzwoni do kierowców na trasie i zbiera aktualizację pozycji oraz przewidywanego czasu przyjazdu. Telefony są wyzwalane cyklicznie, według konfigurowalnej reguły, a dodatkowo wtedy, gdy dane śledzenia są nieaktualne lub ich brakuje. Agent prowadzi rozmowę zarówno po angielsku, jak i w języku filipińskim — co w tym kontekście nie jest opcją, tylko warunkiem, żeby kierowca w ogóle odebrał i odpowiedział sensownie. Zebrane dane — pozostały dystans i szacowany czas — trafiają automatycznie do systemu, bez udziału dyspozytora. Warstwa wyznaczania tras oparta jest na usłudze mapowej z routingiem uwzględniającym czas i specyfikę pojazdów ciężarowych, co pozwala porównać deklarację kierowcy z realistycznym oszacowaniem i wykryć ryzyko opóźnienia.

Kluczowa zaleta tego podejścia jest organizacyjna, nie techniczna. Wymagania wobec kierowcy zewnętrznego przewoźnika sprowadzają się do dwóch: mieć naładowany telefon z zasięgiem i odebrać połączenie. Nie trzeba negocjować montażu sprzętu w cudzych pojazdach ani wdrażać aplikacji w firmach, nad którymi nie ma się kontroli. To samo rozwiązanie działa dla floty własnej i obcej.

Zakres rozwiązania objął panel administracyjny do zarządzania kierowcami, centrami dystrybucyjnymi, pojazdami i trasami, wizualizację tras i pojazdów na mapie, silnik reguł biznesowych konfigurowalnych również w języku naturalnym, detekcję ryzyka opóźnienia oraz konfigurowalny wyzwalacz połączeń cyklicznych. Świadomie zostawiłem poza zakresem integrację z systemami ERP i GPS, uwierzytelnianie korporacyjne oraz rozpoznawanie tablic rejestracyjnych z kamer — to są rozszerzenia mające sens dopiero po potwierdzeniu, że sam mechanizm działa.

Technologie: Python, ElevenLabs (agent konwersacyjny), Twilio, HERE Maps (routing dla pojazdów ciężarowych z uwzględnieniem czasu), Azure, PostgreSQL, Azure Static Web Apps.

Zbudowałem działające demo i przedstawiłem je klientowi, a następnie przygotowałem strukturę podziału prac oraz plan czterotygodniowego wdrożenia dowodu koncepcji — od warsztatu dotyczącego polityki AI i konfiguracji środowiska, przez integracje i logikę wyzwalania połączeń, po strojenie agenta głosowego i testy akceptacyjne. Klient potwierdził, że rozwiązanie bezpośrednio adresuje problem ręcznego obdzwaniania dużej liczby kierowców, szczególnie w przypadku floty zewnętrznej.

Wniosek, który uważam za najciekawszy w tym projekcie: najtańsze rozwiązanie problemu widoczności nie polegało na dołożeniu czujników, tylko na zauważeniu, że czujnik już tam jest — siedzi w kieszeni kierowcy i mówi po filipińsku. Rozmowa telefoniczna przestała być wąskim gardłem w momencie, w którym jej koszt krańcowy spadł do pomijalnego poziomu.

Naturalne pytanie jest z definicji wieloznaczne. „Sprzedaż w zeszłym kwartale” oznacza co innego w finansach, co innego w łańcuchu dostaw, a w każdym rynku może mieć jeszcze odrębną definicję lokalną. Model językowy chętnie wygeneruje SQL dla każdego z tych pytań, w tym dla tego źle zrozumianego, i zrobi to z jednakową pewnością siebie.

Punktem ciężkości rozwiązania nie był zatem model, lecz warstwa semantyczna: jedno źródło prawdy dla metryk, joinów, synonimów i wariantów rynkowych. Routing i orkiestracja działają nad nią, a nie zamiast niej. Dołożyliśmy zestaw kontroli: tożsamość użytkownika przenoszona do zapytania, bezpieczeństwo na poziomie wierszy i kolumn, rozróżnienie w odpowiedzi między faktem, wyliczeniem, prognozą i symulacją, a także progi pewności, poniżej których system świadomie odmawia odpowiedzi zamiast zgadywać.

Byłem odpowiedzialny za architekturę rozwiązania oraz za odpowiedzi na pytania architektoniczne stawiane przez architektów klienta — w tym za wyznaczenie granic zastosowania, czyli wskazanie przypadków, w których wzorzec konwersacyjny nie jest właściwym narzędziem i należy sięgnąć po inne.

Odmowa odpowiedzi jest tu funkcją, nie awarią. Każda zwrócona liczba ma pochodzenie, wersję modelu i ślad w logach.

Routing nie zastąpi semantyki. Jeżeli definicje metryk i warianty rynkowe nie są rozstrzygnięte w warstwie semantycznej, orkiestrator jedynie rozprowadzi tę niejednoznaczność po większej liczbie interfejsów.

Klasyczny RAG oparty o embeddingi radzi sobie dobrze z pytaniami ogólnymi i zawodzi dokładnie tam, gdzie jest najważniejszy: na nazwach własnych leków, jednostkach dawkowania i relacjach między substancjami. W tej dziedzinie halucynacja nie jest usterką kosmetyczną.

Uporządkowałem wiedzę farmaceutyczną w dedykowaną taksonomię łączącą wiele źródeł danych. Dołożyliśmy wyspecjalizowane rozpoznawanie encji dla terminów medycznych i nazw leków, a retrieval oparliśmy na grafie — model językowy dostaje kontekst wynikający z relacji między bytami, a nie z podobieństwa tekstu. Odpowiedź jest generowana warstwowo i zawsze z cytowaniem źródła, a każde wywołanie modelu jest śledzone w Langfuse, co daje pełną audytowalność rozwiązania.

Osobnym, istotnym obszarem mojej pracy była rama oceny jakości: definicja metryk zrozumiałych dla nietechnicznego interesariusza i kategoryzacja typów błędów. Oceniona trafność odpowiedzi wyniosła około 95%, a w obszarach krytycznych — dawkowanie i przeciwwskazania — około 99%.

Technologie: Python, Azure, LangGraph, Cosmos DB z API Gremlin, Langfuse.

Zanim zacznie się mierzyć halucynacje, trzeba zdefiniować, czym jest odpowiedź poprawna. Zbudowanie ramy oceny okazało się trudniejsze niż zbudowanie samego retrievalu.

Trudność nie polega na tym, że produktów jest dużo. Polega na tym, że ten sam produkt u dwóch dostawców ma inną nazwę, inną jednostkę miary i inną strukturę opisu, a część atrybutów istotnych dla porównania — jak gramatura porcji — w ogóle nie występuje jako pole w danych, tylko siedzi w tekście opisu.

Podejście, które przyjąłem, opiera się na warstwowym dopasowaniu. Najpierw katalog jest dzielony na porównywalne kubełki: częściowo według hierarchii obecnych w danych, częściowo według atrybutów wywnioskowanych przez model z opisu tekstowego. Wołowina to jedna kategoria, ale w jej obrębie liczy się już wielkość opakowania i gramatura — a te trzeba wydobyć z tekstu. Dopiero wewnątrz kubełka działa wyszukiwanie semantyczne oparte na embeddingach, zestawione z porównaniem atrybutów i opatrzone oceną pewności oraz wyjaśnieniem, dlaczego dwa produkty uznano za odpowiedniki. Reguły biznesowe — na przykład zakaz mieszania produktów bio z nie-bio — działają zarówno jako zdefiniowane ograniczenia, jak i jako doprecyzowania wydawane w języku naturalnym. Osobny moduł wydobywa jednostki miary z nazw produktów podejściem hybrydowym, łączącym reguły heurystyczne z modelem językowym tam, gdzie heurystyka zawodzi, i normalizuje ceny do porównywalnej ceny za jednostkę. Na końcu wchodzi solver MILP, który na podstawie uploadowanego planu popytu rekomenduje optymalny miks dostawców z uwzględnieniem minimalnych wielkości zamówienia, czasu dostawy i kosztów transportu.

Prototyp demonstrujący pełny przepływ — od wczytania katalogu, przez wyszukiwanie semantyczne i dopasowanie z wyjaśnieniem, po wykrywanie oszczędności i zoptymalizowany plan zakupowy — zbudowałem w tydzień. To zmieniło trajektorię całej rozmowy z klientem: przestaliśmy dyskutować, czy to zadziała, a zaczęliśmy rozmawiać o tym, jak szybko można to wdrożyć i o ile taniej.

Technologie: Python, embeddingi, wyszukiwanie wektorowe, LLM, MILP (OR-Tools / PuLP), Azure.

Uczestniczyłem w kształtowaniu podejścia technicznego i wycenie prac. Wniosek, który zapamiętałem: działający prototyp jest mocniejszym argumentem handlowym niż najlepiej przygotowana prezentacja, a koszt jego zbudowania dzięki AI Assisted Coding bywa niższy niż koszt jej przygotowania.

Celem było ustandaryzowanie pracy z AI w wytwarzaniu oprogramowania bez spowalniania zespołów i bez zamieniania standardu w dokument, którego nikt nie czyta.

Współtworzyłem firmowe standardy programowania w Pythonie oparte na trzech filarach. Pierwszy to skonteneryzowane środowiska deweloperskie — identyczne u każdego programisty, a także dla agenta kodującego, co eliminuje całą klasę problemów typu „u mnie działa”. Drugi to zarządzanie kontekstem dla asystentów, żeby model pracował na tej samej wiedzy o projekcie co człowiek. Trzeci to automatyczne bramki jakości w CI/CD zamiast ręcznego pilnowania zasad podczas code review.

Osobnym elementem było ujednolicenie nazewnictwa struktury repozytoriów. Wydaje się banalne, dopóki nie okaże się, że folder „infrastructure” oznacza coś zupełnie innego dla architekta pracującego w modelu heksagonalnym, a coś innego dla inżyniera DevOps — i że ta kolizja semantyczna myli nie tylko ludzi, ale też agentów kodujących.

Praktyczne znaczy sprawne, a nie niedbałe. Mnóstwo zysku z AI w kodzie bierze się nie z szybszego pisania, lecz z tego, że nie trzeba pisać rzeczy, które już były rozwiązane.

Kod z PoC nie jest produktem. Do tego każdy rynek wnosi własne wymagania, a źródła danych migrują w trakcie trwania rolloutu. Wdrażanie sekwencyjne, rynek po rynku, nie mieściło się w żadnym realnym kalendarzu.

Zbudowaliśmy framework techniczny pozwalający prowadzić rollouty równolegle, partiami po trzy do sześciu rynków. Do architektury danych klienta weszły nowe komponenty: biblioteka wejścia i wyjścia danych, rejestr modeli MLflow oraz skalowanie orkiestracji w Azure Data Factory. Wyprodukcjonalizowane zostały cztery moduły ML wraz z licznymi personalizacjami rynkowymi: mikrosegmentacja klientów, rekomendacja asortymentu, potencjał wartości klienta i rekomendowana częstotliwość wizyt handlowych.

Rezultaty: czas wdrożenia pojedynczego rynku spadł z dwóch miesięcy do około półtora tygodnia, koszt przetwarzania zmniejszył się o 50%, a czas przetwarzania o 40%.

Technologie: Azure, Databricks, Python, MLflow, Azure Data Factory.

Przyspieszenie rzędu trzy do pięciu razy nie wzięło się z lepszych modeli. Wzięło się stąd, że personalizacja rynkowa dostała własne, wyraźnie odgraniczone miejsce w strukturze kodu.