Powered by Protopia

Virtual data center: jak odciążyć własne data center maszynami w Azure

Łukasz Kałużny, Mikołaj Szczerbicki — Wed, 22 Jul 2026 00:00:00 GMT

TL;DR

Gdy lokalnemu data center brakuje zasobów, a koszt jego rozbudowy jest niepewny, możesz je odciążyć, przenosząc część maszyn wirtualnych do Azure. Virtual data center to wystandaryzowana, współdzielona przestrzeń w Azure, w której maszyny powstają z szablonów spełniających te same wymagania co w Twoim data center. Prawdopodobnie dużo zyskasz na środowiskach developerskich i testowych: gdy wyłączają się automatycznie poza godzinami pracy, płacisz za ich moc obliczeniową tylko wtedy, gdy działają.

Kluczowe wnioski

Virtual data center traktuje Azure jako przestrzeń na maszyny wirtualne (IaaS), a nie na usługi PaaS czy SaaS.
Systemy dzielisz według ryzyka biznesowego: do Azure trafiają mniej krytyczne, a krytyczne zostają w lokalnym data center.
Maszyny działające całą dobę możesz objąć savings planem albo rezerwacją, zależnie od potrzeb. Licencje Windows Server i SQL Server z aktywnym Software Assurance możesz, zależnie od ich typu, wykorzystać w chmurze dzięki Azure Hybrid Benefit.
Ustal, jak reagować na przewymiarowane maszyny: alert do właściciela, który sam je zmniejsza, albo agresywniejszy wariant, w którym platforma zmienia ich rozmiar automatycznie lub po wcześniejszej informacji.
Istniejące maszyny przeniesiesz przez Azure Migrate, co wymaga przestoju, albo odtworzysz z backupu w Azure, jeśli Twoje narzędzie to obsługuje i masz na to licencję.
Pierwszy krok to warsztaty: wymagania, koncepcja sieci i sprawdzenie, czy firma ma już Azure.

Wersja do czytania

Czym jest virtual data center

Rozmówcy zwracają uwagę, że oferty na rozbudowę lokalnego data center są ważne krótko, a ceny w niektórych miejscach mocno urosły. Problemem bywa też termin: to, czy rozbudowa zdąży w bieżącym roku, zależy od wielkości zamówienia.

Virtual data center to wystandaryzowana landing zone w Azure, w której maszyny wirtualne powstają automatycznie na współdzielonych subskrypcjach. Maszyny współdzielą zasoby subskrypcji w jednym miejscu, zamiast być rozrzucone, co ma dać lepszy efekt kosztowy. Zespół nie ustala przy każdej maszynie usługi i grupy zasobów. Dostaje proste wytyczne, jak dodać kolejną maszynę albo przenieść ją z lokalnego data center.

Platforma odwzorowuje wymagania, które stosujesz lokalnie, także te z polityk bezpieczeństwa. Składa się z kilku warstw:

zestaw subskrypcji w formie landing zone,
sieć odpowiadająca lokalnej segmentacji, czyli podziałowi na VLAN-y i strefy,
governance: polityki bezpieczeństwa, tagi, budżety i alerty,
infrastructure as code (skrypty albo Terraform, zależnie od preferencji) i szablony maszyn, które instalują te same agenty co lokalnie, np. do skanowania, DLP albo monitoringu,
tożsamość: model nadawania dostępów,
backup: natywny Azure Backup, Veeam (preferowany przez Protopię) albo narzędzie innego dostawcy, którego już używasz, jeśli wspiera Azure.

Platformę można też połączyć z systemem ticketowym. Zespoły zamawiają wtedy maszyny same, przez formularze (self-service).

Schemat: architektura virtual data center.

Które systemy przenieść do chmury

Do virtual data center przenosisz systemy mniej krytyczne: aplikacje mniej ważne biznesowo, aplikacje backoffice’owe i środowiska nieprodukcyjne, czyli developerskie i testowe. Chmura jest w tym scenariuszu dodatkowym źródłem mocy obliczeniowej, które zwalnia zasoby w lokalnym data center.

Kryterium wyboru jest ryzyko biznesowe. Łukasz Kałużny: „Nie migrujemy wszystkiego, tylko to, co nam być może przeszkadza albo mogłoby bezpiecznie biznesowo, bez dużego ryzyka zwolnić zasoby lokalne.”

Jak dobrać mechanizm cenowy do maszyny

Za dysk płacisz osobno, także gdy maszyna jest wyłączona. Kwoty w tej sekcji dotyczą mocy obliczeniowej i dysku nie obejmują.

Mechanizmy obniżania kosztu maszyn wirtualnych w Azure
Mechanizm	Dla jakich maszyn	Oszczędność lub efekt
Automatyczne wyłączanie poza godzinami pracy (maszyna działa np. w godzinach 8–18)	Nieprodukcyjne: developerskie, testowe	71% względem cennika
Savings plan albo rezerwacja	Niekrytyczne, działające 24 godziny na dobę	45–61%, zależnie od konfiguracji
Azure Hybrid Benefit	Windows Server i SQL Server z aktywną umową Software Assurance	Licencję kupioną do środowiska lokalnego można wykorzystać w chmurze, w zakresie zależnym od jej typu

Maszyna włączona tylko w godzinach pracy działa około 210 godzin miesięcznie zamiast średnio 730. Łukasz Kałużny: „Mamy bardzo błędne przekonanie, że to musi chodzić 24 godziny na dobę.”

Przykład z cennika: moc obliczeniowa popularnej maszyny z procesorem Intel albo AMD kosztuje około 160–170 USD miesięcznie. Z automatycznym wyłączaniem jej koszt spada do 46–51 USD.

Schemat: który mechanizm cenowy dla której maszyny.

Jak pilnować kosztów po uruchomieniu

Kosztów pilnują dwie warstwy, wbudowane w platformę od pierwszego dnia. Pierwsza to standardowe mechanizmy FinOps w Azure: budżety i Azure Advisor. Druga to zestaw alertów i skryptów, który Protopia dokłada do platformy. Skrypty cyklicznie wyszukują niewykorzystane i przewymiarowane zasoby.

Rozmówcy często spotykają maszyny wzięte na zapas, z niewykorzystanym CPU. W łagodniejszym wariancie reakcji alert trafia do właściciela maszyny, który sam ją zmniejsza. W agresywniejszym wariancie, jeśli organizacja się na niego zgodzi, platforma regularnie sprawdza metryki zużycia, np. co tydzień. Potem zmienia rozmiar maszyn automatycznie albo po wcześniejszej informacji, zgodnie z przyjętą polityką.

Przykładowa polityka: maszyna dostaje 2 rdzenie zamiast 4, a pamięć RAM zostaje bez zmian. Dla jednej maszyny działającej całą dobę koszt spada ze 177 do 117 USD.

Jak przenieść istniejące maszyny

Nowe systemy stawiasz skryptami i szablonami od razu po zbudowaniu platformy. Istniejące maszyny przenosisz na jeden z dwóch sposobów:

Azure Migrate ocenia maszyny z VMware, Hyper-V i innych platform, a potem je konwertuje i przenosi. Migracja wymaga przestoju, bo maszynę trzeba przesłać.
Narzędzie do backupu, które integruje się z Azure, np. Veeam, odtwarza maszynę z istniejącego backupu bezpośrednio w virtual data center. Narzędzie musi wspierać ten scenariusz, a Ty musisz mieć na niego licencję. Taka migracja jest szybsza albo, zależnie od podejścia, przebiega bez przerwy w działaniu.

Schemat: dwie drogi migracji istniejących maszyn.

Jak wygląda wdrożenie i ile trwa

Protopia szacuje budowę działającej platformy na 4–8 tygodni.

Etapy budowy platformy:

Rozeznanie (discovery) na warsztatach: czy firma ma już Azure, jak wygląda koncepcja sieci, jakie są wymagania i jakie podejście wybrać.
Projekt: dostosowanie wystandaryzowanego infrastructure as code Protopii do potrzeb firmy.
Setup i konfiguracja, czyli główna faza: subskrypcja, sieć, testy skryptów i szablonów maszyn oraz wdrożenie opisanych wyżej warstw governance, tożsamości i backupu.

Po tych etapach stawiasz na platformie nowe maszyny wirtualne. Migracje to osobny etap.

Pilotażowe migracje pierwszych maszyn.
Po udanych pilotażach migracja mniej krytycznych systemów na większą skalę.

Wdrożenie AI w SDLC: standard procesu, pomiar i pilot

Łukasz Kałużny, Mikołaj Szczerbicki — Wed, 01 Jul 2026 00:00:00 GMT

TL;DR

Twoje zespoły korzystają już z narzędzi AI i poza kosztami nie widać efektu, albo właśnie decydujesz, w których procesach najpierw wdrożyć AI i jak mierzyć sukces. Zysk z AI widać dopiero po przeprojektowaniu cyklu wytwarzania oprogramowania: specyfikacji przed kodem, wspólnego standardu pracy z agentem i automatycznego feedbacku, sprawdzonych w pilocie na prawdziwej aplikacji. Zmierz stan przed pilotem, bo dopiero porównanie z nim pokaże, czy skalować, czy najpierw poprawić fundamenty.

Kluczowe wnioski

Przyspieszenie tylko jednego etapu zapycha proces w innym miejscu, dlatego standaryzujesz cały cykl wytwarzania: specyfikację przed kodem, pracę z agentem, skille, dokumentację w repozytorium i automatyczną pętlę feedbacku, a narzędzia wybierasz na końcu.
Wdrożenie zaczyna się od przeglądu gotowości procesu: CI/CD, kadencji wydań, testowalności i automatyzacji wdrożeń.
Pilot najlepiej prowadzi zespół, który zgłosił się sam, na aplikacji, którą naprawdę rozwija i utrzymuje.
Pomiar przed pilotem to diagnostyka bez konkretnych celów: mierzysz dostarczanie, flow i jakość, a nie tokeny, linie kodu czy procent kodu z AI.
Pilot może pokazać wąskie gardło poza AI, na przykład kolejkę na akceptacji, i to też jest wynik: proces zostaje zmierzony i poprawiony.
Skalowanie nie musi objąć całej organizacji: zależnie od wielkości firmy i krytyczności czasem wystarczy jej część albo kilka zespołów developerskich.

Wersja do czytania

Samo narzędzie nie wystarcza

Rozmówcy słyszą to z rynku i przy wymianie doświadczeń: samo rozdanie zespołom narzędzi takich jak GitHub Copilot, Codex od OpenAI czy Claude Code od Anthropic nie pokazuje realnego przyspieszenia pracy, a jedyny widoczny efekt to koszty.

U klientów bardzo często widzą, że AI trafia do procesów niemierzonych i nieustandaryzowanych. Spotykają przy tym dwie sytuacje. W pierwszej firma wciąż ustala, w których procesach najpierw wdrożyć AI i jak mierzyć sukces. W drugiej developerzy sami zaczynają używać AI, a manager się na to zgadza. Wtedy pojawiają się wykupione, droższe i podobno bezpieczniejsze wersje aplikacji czatowych, a obok własne interfejsy podpięte do API. Nic z tego nie jest ustandaryzowane i w pewnym momencie organizacja widzi, że nie ma efektu ani zysku.

Przyspieszenie jednego etapu zapycha proces w innym miejscu

SDLC (software development life cycle), po polsku cykl wytwarzania oprogramowania, to cała droga od zebrania potrzeby biznesowej do działającego, wdrożonego oprogramowania. SDLC nie jest więc tym samym co pisanie kodu.

Raporty z firm, które skupiły się na samym pisaniu kodu, mówią o przyrostach rzędu 4–5%, czasami mniej, zależnie od tego, gdzie pytać. W niektórych bardzo małych organizacjach słychać o dużo wyższych liczbach, bo nie mają one narzutów organizacyjnych. W małym produkcie, na przykład niewielkim SaaS-ie, developer potrafi w ciągu dnia napisać zmianę, przetestować ją i wdrożyć. W dużych organizacjach, z którymi pracuje Protopia, bardzo często nie ma takiej możliwości.

Łukasz Kałużny: „jeżeli przyspieszymy tylko 1 etap, to realnie w którymś miejscu gdzieś to się zapcha”

Dlatego wdrażając AI w SDLC, standaryzujesz cały proces.

Zysk z AI przychodzi dopiero po przeprojektowaniu procesu

W 1987 roku noblista Solow stwierdził, że komputery widać już wszędzie, ale nigdzie nie widać z nich wzrostu wartości. Na zwrot z inwestycji w komputery organizacje czekały około 15 lat. Przy silniku elektrycznym w fabrykach trwało to około 40 lat, bo procesy musiały się dostosować do nowej technologii.

AI idzie tą samą drogą: zysk będzie widać dopiero po przeprojektowaniu procesu i podejścia, razem z dojrzałością organizacji. Cykl zwrotu będzie prawdopodobnie dużo szybszy niż przy komputerach czy silniku elektrycznym.

Jeśli chcesz ten zwrot kontrolować, musisz go zmierzyć, czyli ocenić stan przed udoskonaleniem procesu i po nim. Co mierzyć i w których punktach, planujesz przed startem wdrożenia, także etapowego.

Wdrożenie wychodzi od obecnego procesu i rozwija go ewolucyjnie: dostosowuje to, co istnieje, do pracy z narzędziami AI. Celem jest powtarzalny, skalowalny efekt dla całej organizacji. Czasem może wystarczyć sukces jednego zespołu, ale wtedy trzeba sprawdzić, czy da się go potem powielić.

Raport DORA (DevOps Research and Assessment) z 2025 roku opisuje AI jako wzmacniacz, który podnosi dojrzałe zespoły i nasila dysfunkcje słabych.

Standard obejmuje specyfikację, pracę z agentem i pętlę feedbacku

Spec Driven Development to metoda, w której zespół powtarzalnie zbiera wymagania, generuje z nich specyfikację, potem plan pracy agenta nad daną funkcją i dopiero na końcu kod. To przeciwieństwo vibe codingu. Podstawą są otwarte standardy, takie jak GitHub Spec Kit czy OpenSpec, albo lżejsza wersja przygotowana dla konkretnej organizacji.

Celem jest jeden spójny standard pracy z agentem w repozytoriach organizacji. Zespół dostaje bazę, którą wykorzysta ponownie w nowym projekcie albo w projekcie objętym standardem.

Skille to zestawy komend i promptów, które mówią agentowi, jak coś zrobić. Bywają globalne dla firmy, na przykład „zrób mi review wymagań zgodnie z globalną polityką”, albo projektowe. Jeden z popularnych skilli, które Protopia wdraża u klientów, analizuje zgłoszenie błędu z produkcji, żeby szybciej go zlokalizować.

Dokumentacja trafia do repozytorium z kodem, jest aktualizowana i czytelna zarówno dla agenta, jak i dla człowieka.

Harness i guardrails to całe otoczenie agenta, które daje mu krótką pętlę feedbacku. Tak jak developer korzysta z testów jednostkowych, agent dostaje automatyczne formatowanie, lintowanie i testowanie, blokady i bramki jakości. W niektórych miejscach bramką jest pokrycie testami albo cognitive complexity (cognitive load), czyli miara tego, jak trudno zrozumieć kod i jak bardzo jest złożony. Metryki dobierasz tak, żeby kod dało się w przyszłości łatwiej usunąć lub utrzymać, i wpinasz je automatycznie. Dzięki temu agent jak najszybciej dostaje feedback i pracuje w kierunku, który wyznaczasz.

Narzędzia wybierasz na końcu, bo wiele z tych praktyk przenosi się między modelami i narzędziami. Narzędzia zmieniają się obecnie co kwartał, a według niektórych mody nawet co miesiąc. Dlatego dobierasz je razem z modelami pod swój stos technologiczny i wymagania compliance.

Standard obejmuje cały SDLC. Wymagania obsługuje Spec Driven Development. Kod, testy i review obsługują narzędzia agenta razem ze Spec Driven Development. Utrzymanie opiera się na testach integracyjnych i jednostkowych, które działają lokalnie i w CI/CD.

Schemat: standard pracy z agentem obejmuje cały cykl wytwarzania, a nie samo pisanie kodu

Wdrożenie zaczyna się od oceny gotowości i wyboru zespołu pilotażowego

Pierwszy krok to ocena obecnego stanu i gotowości. Sprawdza, czy proces jest gotowy na AI, i z góry zakłada, że trzeba go będzie dostosować. Pokazuje, jak wygląda Twój standard SDLC i czy już na papierze nie ma wąskich gardeł: jak działają CI/CD i serwery buildów, jaka jest kadencja wydań i czy firma ma to ustandaryzowane. Obejmuje też higienę testowalności i częstotliwość wdrożeń. Jeśli częste wdrożenia nie są potrzebne, sprawdza, czy przynajmniej są zautomatyzowane.

Ocena odwołuje się do podejścia DevOps i jego pętli feedbacku. Branża cyklicznie wraca do tego podejścia.

Drugi krok to wybór pilota: jednego lub dwóch zespołów, systemów, modułów albo aplikacji. Najlepsze są zespoły, które zgłoszą się same, bo pilot wymaga zaangażowania całego zespołu. Zespół pilotażowy ma być aktywny w testach, a potem nieść rozwiązanie dalej w organizacji jako jego ewangelista.

Schemat: kroki wdrożenia AI w SDLC, od oceny gotowości do porównania z baseline

Pomiar stanu przed pilotem jest diagnostyką bez konkretnych celów

Trzeci krok to pomiar stanu przed pilotem, bez KPI. Przy KPI pojawia się ryzyko malowania trawy na zielono i grania pod wskaźnik. Pomiar jest diagnostyką: pokazuje wąskie gardło i miejsce, od którego zacząć, żeby przyspieszyć z głową.

Nie mierzysz wskaźników pozornych: zużytych tokenów, wygenerowanych linii kodu, liczby pull requestów ani procentu kodu wygenerowanego przez AI.

Łukasz Kałużny: „To nie jest produktywność i nie sprowadzimy tego wszystkiego do jednej liczby, tylko to będzie ocena wielowymiarowa.”

Pomiar ma 3 poziomy, albo 2,5, zależnie od sposobu liczenia. Celem całego pomiaru jest szybsze albo stabilniejsze dostarczanie.

Trzy poziomy pomiaru przed pilotem i po nim
Poziom	Co pokazuje	Jak mierzysz
Dostarczanie	Czy dowozisz szybciej i stabilniej	4 metryki DORA: jak często wdrażasz, jak często wprowadzasz zmianę, odsetek nieudanych wdrożeń, czas przywracania po awarii
Flow	Czas całego procesu	Od wejścia prośby o funkcję lub zmianę, na przykład nowy ekran, do oddania jej na produkcji
Jakość	Czy podejście agentowe pogorszyło jakość, poprawiło ją, czy utrzymało stabilnie (u dojrzałego zespołu)	Sposób ustalasz z Protopią dla swojego przypadku, na przykład liczbę zgłoszonych błędów

Pilot działa na prawdziwej aplikacji i kończy się porównaniem ze stanem przed

Czwarty krok to pilot z wybranym zespołem lub zespołami na realnym produkcie. Na start Protopia wspiera go mentoringiem i konsultacjami przez 1–2 cykle wdrożeń na produkcję, a długość dostosowuje do sprintu, żeby przejść i przetestować całą ścieżkę od początku do końca. Gdy całość jest skonfigurowana, podejście może zacząć działać po 1–2 sprintach.

Pilot odbywa się na prawdziwej aplikacji, którą zespół rozwija i utrzymuje, a nie na wymyślonych przypadkach testowanych z boku.

Po pilocie porównujesz jego dane z wcześniej zebranym stanem przed (baseline) i sprawdzasz, czy coś ruszyło do przodu. Musisz liczyć się z tym, że nie ruszy. W badaniach pojawia się na przykład obserwacja, że w bardzo dojrzałych zespołach nie było znacznego przyspieszenia. Wszystko wskazuje na to, że im lepiej zespół działa teraz, tym mniejszy będzie przyrost wydajności.

Pilot może też pokazać miejsca do poprawy, które nie zależą od AI, choćby procesy akceptacji. Na przykład zespół szybciej wytwarza i testuje zmiany po swojej stronie, a kolejka zapycha się na akceptacji, bo ktoś nie nadąża z testowaniem. Na początku to bardzo pożądany scenariusz: wtedy zastanawiasz się, jak ten etap przyspieszyć lub poprawić. Jeśli tam, gdzie AI miało pomóc, przyrost okaże się niewielki, możliwe, że ostatecznie nie zdecydujesz się na AI w tym miejscu. Sukcesem jest wtedy to, że proces został zmierzony i poprawiony w innej części.

Wynik pilota decyduje o skalowaniu i jego zasięgu

Po porównaniu masz dwie drogi. Jeśli nie akceptujesz poprawy, nie skalujesz: diagnozujesz ograniczenia i być może wracasz do fundamentów. Sprawdzasz, które procesy w organizacji blokują zmianę, gdzie są wąskie gardła, czy problem nie leży w konfiguracji pilota i jak wyglądały review, testy i observability w tym obszarze. Jeśli akceptujesz poprawę, to, co się sprawdziło, zamieniasz w standardy, szablony i definition of done.

Schemat: wynik pilota decyduje, czy skalujesz, czy wracasz do fundamentów

Być może rollout na całą organizację nie jest potrzebny. Czasem, w zależności od wielkości firmy i krytyczności, wystarczy jej część albo kilka zespołów developerskich. Aktualizujesz standard, a dla projektów, które są gotowe i chętne go przyjąć, przygotowujesz plan adopcji.

Jednym ze sposobów skalowania są ambasadorzy: wybrane osoby z zespołów przechodzą osobne warsztaty dla ambasadorów, a potem na co dzień pokazują w swoich zespołach, jak proces ma wyglądać. Zespoły, które przyjmują standard, dostają merytoryczne wsparcie: doraźne konsultacje i mentoring.

Standard wyznacza ogólny kierunek i najważniejsze wytyczne. Każdy projekt i tak trzeba na koniec doszlifować, więc w zespole zawsze zostaje trochę pracy, żeby z niego skorzystać.

Asystent AI w dużej firmie: dostęp do systemów, bazy wiedzy i tickety

Marek Grabarz, Szymon Warda — Wed, 10 Jun 2026 00:00:00 GMT

TL;DR

Planujesz asystenta AI, który w dużej firmie ma odpowiadać na pytania z baz wiedzy w SharePoincie i ServiceNow, korzystać z danych w SAP i zakładać tickety w ServiceNow. Najwięcej pracy zajmie wtedy dostęp do tych systemów: asystent powinien czytać tylko wybrane źródła i działać na uprawnieniach zalogowanego użytkownika, poza które generalnie nie wyjdzie nawet po udanym prompt injection. Ukryte reguły formularzy asystent dostaje jako zwykły tekst, więc obsłuży wiele typów ticketów bez przepisywania frontendu.

Kluczowe wnioski

Zanim zespół zacznie implementację, musi wiedzieć, które systemy mają API, co to API daje i jakie licencje oraz limity je ograniczają.
Asystent powinien odpytywać systemy tokenem zalogowanego użytkownika, bo service account i impersonacja przez nagłówek pozwalają po udanym prompt injection wyciągnąć cudze dane.
Jeśli system wymaga impersonacji, dodaje ją API Gateway na podstawie tożsamości odczytanej z tokenu.
Źródła wiedzy trzeba zawęzić i oczyścić: integracja z całym SharePointem pokazuje za dużo, a surowy HTML i ikonki z bazy wiedzy zużywają tokeny.
Reguły ukryte w formularzach ticketów agent dostaje z custom API jako zwykłe zdania, które może edytować właściciel tematu, na przykład dział HR.
Zespół potrzebuje ludzi z długim doświadczeniem w integracjach i bezpieczeństwie, którzy umieją też przeprowadzić integrację przez rozmowy z wieloma interesariuszami.

Wersja do czytania

Najwięcej pracy wymaga dotarcia do systemów i ich API

Marek Grabarz: „na koniec dnia okazuje się, że 90% problemów albo raczej pracy polega na tym, żeby jednak się przebić przez te wszystkie bariery i żeby zrobić tę integrację w sposób taki, powiedziałbym, od początku do końca”

Dlatego projekt zaczyna się od discovery: z jakimi systemami asystent się integruje, czy mają API, co to za API i jaki zakres wiedzy dają. Asystent łączy się z systemami przez API, bez interfejsu użytkownika, więc API trzeba najpierw znaleźć i poznać jego możliwości.

Istniejące systemy często są utrzymywane pod kątem frontendu. Na przykład zespół bazy wiedzy w ServiceNow dba o aktualność treści i ma opisany sposób jej tworzenia, ale pytania o dostęp od strony API nikt wcześniej nie zadawał, więc nikt nie zna odpowiedzi. Zespoły utrzymaniowe rozproszone po krajach Azji, Ameryki i Europy też tego nie wiedzą.

API często jest dostępne wybiórczo: to, czy istnieje, zależy od wdrożonych modułów i planów licencyjnych. API poszczególnych modułów mogą się od siebie całkowicie różnić. Może się też okazać, że API nie ma wcale albo obsługuje tylko service account lub impersonację.

Discovery obejmuje też licencje, warunki dostępu i rate limity, które trzeba potem obsłużyć w architekturze systemu. Jedna z integracji w projekcie prowadzi do SAP. Nagranie powstało na samym początku maja 2026. Chwilę wcześniej SAP ogłosił, że użycie jego API przez agentów AI będzie rozliczane albo zabronione, i analiza skutków jeszcze trwała. Rozmówcy przypuszczają, że SAP chce w ten sposób zmusić wszystkich do używania własnego asystenta Joule.

Service account pozwala wyciągnąć przez asystenta cudze dane

Service account ma bardzo ograniczone zastosowanie, gdy dostęp asystenta trzeba zawęzić. W opisanym projekcie dostęp był jednym z pierwszych problemów. W większości organizacji intuicyjnym wyborem jest konto techniczne z dostępem administracyjnym do systemu źródłowego, na przykład SAP. Asystent pobiera nim dane jednego pracownika, a potem dowolnego innego.

Takie konto jest bardzo łatwo zmanipulować. Wystarczy skuteczny prompt injection po stronie chatbota, żeby przekonać asystenta do podania na przykład danych prezesa firmy: jego planów, a może też pensji i benefitów.

Impersonacja to dopisanie do zapytania konta technicznego identyfikatora albo imienia i nazwiska użytkownika, na przykład w nagłówku lub w query string. Nadal łatwo ją zmanipulować, więc może wbudować podatność w integrację i odsłonić dane wrażliwe.

Asystent odpytuje systemy tokenem zalogowanego użytkownika

Asystent powinien korzystać z prawdziwego tokenu użytkownika i jego uprawnień w systemie docelowym. Delegated access to model oparty na delegowanych przepływach OAuth: użytkownik loguje się sam, dostaje access token reprezentujący go wobec systemu docelowego, a asystent odpytuje system tym tokenem. Asystent generalnie nie wychodzi wtedy poza uprawnienia użytkownika. Nie odtwarza RBAC (Role-Based Access Control) i nie ogranicza dostępu system promptami ani parametrami: korzysta z pełnych uprawnień, ale tylko tych, które ma zalogowana osoba.

Ten model wymaga federacji tożsamości, a do jej zaprojektowania potrzeba wiedzy z kilku dziedzin. SAP, SAP SuccessFactors i każda inna duża platforma w organizacji mają własną tożsamość użytkownika. Federacja sprawia, że użytkownik agenta nie dostaje okna logowania do każdego systemu, z którego asystent korzysta. SAP może też oczekiwać zupełnie innej tożsamości. Wtedy między Microsoft Entra ID a systemem źródłowym potrzebna jest federacja po SAML, a jej konfiguracja w dużych organizacjach nie zawsze jest prosta.

Jeśli dostęp ma być impersonowany, potrzebny jest API Gateway, który tłumaczy jeden model na drugi. Asystent dochodzi do bramy z delegated access. Brama odczytuje tożsamość użytkownika z tokenu, a tej ścieżki nie da się oszukać. Dopiero potem brama dodaje impersonację wewnątrz systemu według własnej, deterministycznej logiki.

Schemat: service account, delegated access i impersonacja przez API Gateway

Asystent czyta tylko wybrane site’y SharePointa

Podłączenie SharePointa do asystenta to trzy zadania: wyodrębnić wiedzę, którą asystent ma pokazywać, ograniczyć to, co widzi, i obronić się przed wstrzykiwaniem złej treści. SharePoint Online łączy się przez Microsoft Graph API i technicznie to działa. Rozmówcy widzą jednak, że klienci mają tendencję do włączania integracji dla całego SharePointa. Asystent dostaje wtedy dostęp do wielu site’ów, także tych, których nie powinien czytać, nawet przy delegated access.

Użytkownik ma dostęp do site’ów swoich projektów. Mogą to być też site’y, na których ktoś kiedyś włączył publiczny dostęp, wrzucił bardzo wrażliwe dane i o tym zapomniał. Dostęp istniał wcześniej, ale człowiek nie przegląda site’ów jeden po drugim, chyba że robi to celowo. Asystent syntetyzuje wszystko, co znajdzie, więc pytanie o budżety może pokazać projekty, do których użytkownik w teorii nie miał dostępu. W opisanym projekcie asystent czyta tylko wybrane, moderowane site’y z wiedzą o HR.

Content poisoning to wstrzykiwanie złej treści do źródeł, które czyta asystent. Osoba z prawem zapisu do takiego site’u może wygenerować, na przykład LLM-em, poprawnie wyglądającą procedurę HR, według której należy jej się Porsche jako benefit służbowy, a asystent zacznie to podawać w odpowiedziach. Może też podmienić formularz do zgłaszania nieprawidłowości czy mobbingu na własny i zbierać zgłoszenia, także poza organizacją.

Graph API działa tylko z SharePoint Online. SharePoint on-premises, który też często się spotyka, wymaga scrapingu i bazy wektorowej, a delegated access tam nie zadziała. Cała treść wybranego site’u trafia wtedy do bazy jako wektory.

Treść z bazy wiedzy ServiceNow trzeba oczyścić przed modelem

W opisanym projekcie większość wiedzy leżała w bazach wiedzy, które działy HR zbudowały w ServiceNow. Artykuły powstają w edytorze WYSIWYG, podobnym do dawnego Pajączka, więc API zwraca je jako HTML ze stylami inline, divami i zagnieżdżonymi tabelami. Wczytanie takiej treści bez wyodrębnienia tekstu zwiększyło zużycie tokenów 5 razy i może skończyć się poważną halucynacją.

Konwersja HTML na Markdown albo zwykły tekst wydaje się problemem rozwiązanym. Artykuły często zawierają jednak obrazy, diagramy, załączniki i linki do artykułów w SharePoincie. Agent, który pobiera tylko tekst, nie wie na przykład, jaki przepływ procedury pokazuje dołączony obrazek. Model musi więc być multimodalny i obsługiwać obrazy, tekst, PDF-y i pliki Word, a pobieranie tych elementów trzeba zorkiestrować.

Dołączanie wszystkich obrazów do kontekstu rodzi inne problemy. Ktoś z zespołu redakcyjnego zamiast punktorów wstawiał ikonki z zielonym checkboxem albo czerwonym krzyżykiem. Pobrany artykuł miał 20 załączników graficznych, z których 19, a może wszystkie, nic nie wnosiły: były ikonkami albo paskiem z logo firmy na dole strony. Potrzebne są listy wyjątków, które blokują pobieranie takich załączników, na przykład na poziomie API, integracji albo instrukcji agenta. Bez nich rośnie zużycie tokenów.

Schemat: jak asystent zawęża i oczyszcza źródła wiedzy

Wyszukiwanie w bazie wiedzy wymaga reguł opisanych przez biznes

Wyszukiwanie w bazie wiedzy potrzebuje priorytetów, bo obok procedur globalnych istnieją lokalne. Pracownik z Polski, który pyta o urlop, chce odpowiedzi według polskiego prawa, a nie według globalnej polityki. ServiceNow wyszukuje przez API po słowach kluczowych: zapytanie „company car” nie znajdzie polskiej procedury, w której stoi „samochód służbowy”, więc takie różnice trzeba opisać. Trudniejsze są przypadki zagnieżdżone, na przykład pracownik HR z dostępem do wszystkiego albo przełożony, który ma ludzi w pięciu lokalizacjach i pyta, ile urlopu ma jego pracownik z Francji. Uprawnienia i zapytanie trzeba wtedy odpowiednio zorkiestrować.

Samo wyszukiwanie nie daje stuprocentowej pewności, że odpowiedź jest poprawna. Potrzebne jest rozumienie tekstu. Sposób przeszukiwania i streszczania bazy wiedzy trzeba opisać w user stories, które przygotowują biznes i analitycy.

Reguły formularzy ticketów agent dostaje z custom API

Celem projektu jest mniejsza liczba ticketów, więc asystent najpierw odpowiada z baz wiedzy. Gdy nie umie pomóc, przechodzi do ticketu. Jeśli użytkownik od początku mówi, że jest chory i chce zgłosić ticket, asystent od razu zaczyna zgłoszenie.

Ticket w ServiceNow to zwykle formularz z listami rozwijanymi, w którym wybór jednej opcji pokazuje kolejne pola. Typów ticketów jest dużo. Marek Grabarz: „My staramy się, ja już to zresztą powtarzałem, orchestrate, do not replicate. Czyli staramy się zorkiestrować przeprowadzanie takiego ticketu, a niekoniecznie każdy typ ticketów.” Agent pobiera kategorie, dopasowuje kategorię do prośby użytkownika, pobiera typy ticketów w tej kategorii, a potem szablon: pola, ich typy i informację, czy są wymagane.

To nie wystarcza, bo dużo logiki siedzi w formularzu ticketu w ServiceNow, a nie w backendzie: walidatory, lookupy do tabel (na przykład City ID) i zależności między polami. ServiceNow odwołuje się do tabel przez identyfikatory SYS_ID, osobne dla tabeli krajów, użytkowników i każdej innej, i to jest duży problem. Nawet gdyby te zależności były w API, agent by ich nie zrozumiał, bo nikt ich nie opisał. Dokumentacji nie ma: formularze ticketów wyklikała 10 lat temu zewnętrzna firma, a osoby z HR wiedzą mniej więcej, jak działają.

Przykład: w tickecie z prośbą o szkolenie szkolenie nie może się odbyć wcześniej niż za 2 tygodnie. Tej reguły nie ma w encji API, jest tylko w logice formularza. Zespół rozwiązał to przez custom API pośrodku, które w locie dokłada do pól ticketu, zwłaszcza dynamicznych, nowe właściwości: reguły walidacji, opisy i zależności. Agent ma w instrukcji pobrać szablon, sprawdzić, które pola są wymagane, i przeczytać reguły opisowe oraz walidacyjne. Reguły są zapisane zwykłym zdaniem, bez JSON Logic, na przykład: jeśli w polu A zaznaczono daną wartość, to pole B jest wymagane.

LLM doskonale radzi sobie z tekstem, który nie jest technicznym żargonem ani regułą typu IF this then THAT. Opis może też edytować właściciel tematu, na przykład dział HR. Źródłem reguł dla custom API może być załącznik albo inny zestaw informacji, a API stosuje pola, walidacje i opisy w locie jako elementy tekstowe. Zespół nie przepisuje frontendu ani nie opisuje w prompcie każdego kroku, a agent dostaje potrzebne informacje dynamicznie.

Schemat: reguły formularza ticketu przez custom API

Zespół potrzebuje doświadczenia w integracjach i umiejętności miękkich

Wyzwania takiego projektu leżą przede wszystkim w integracjach, bezpieczeństwie i uwierzytelnianiu. Zespół potrzebuje ludzi z długim doświadczeniem w IT, którzy rozumieją uwierzytelnianie i autoryzację, działanie i wywoływanie API, sieć, protokoły i bezpieczny dostęp do API przez sieć.

Integracja to też spotkania z wieloma interesariuszami: ludźmi od sieci i właścicielami platform. Czasem trzeba naciskać na support, żeby wydobyć informacje, a może też eskalować sprawę do dostawcy systemu. Taka praca wymaga przywództwa, umiejętności miękkich i tłumaczenia potrzeb na język różnych zespołów.

Utrzymanie agenta wymaga automatycznych testów odpowiedzi

Eval strategy to automatyczna ocena odpowiedzi agenta względem odpowiedzi oczekiwanej, przygotowanej na podstawie business case’ów i customer stories. Prace nad nią trwają. Mechanizmy oparte na LLM i bez LLM automatycznie uruchamiają zestaw przypadków użycia i oceniają, czy agent odpowiedział z sensem i rzetelnie oraz czy był proaktywny i miły, czy szorstki i niepomocny.

Asystent AI dla ponad 60 tys. pracowników: HR, integracje i wdrożenie etapami

Marek Grabarz, Mikołaj Szczerbicki — Wed, 20 May 2026 00:00:00 GMT

TL;DR

Gdy pracownicy dużej firmy nie wiedzą, w którym systemie HR szukać odpowiedzi ani jaki ticket założyć, asystent AI może być jednym punktem wejścia do tych systemów. Z tego wdrożenia w globalnej firmie farmaceutycznej dowiesz się, jak zawęzić pierwszy zakres, kiedy asystent ma odesłać użytkownika do formularza, dlaczego najwięcej pracy pochłaniają integracje i tożsamość oraz jak mierzyć efekt, gdy asystent trafia do kolejnych grup pracowników.

Kluczowe wnioski

Projekt ruszył, bo HR przyszedł do IT z problemem: pracownicy gubili się w rozproszonych systemach kadrowych.
Asystent zna kraj, rolę i umowę użytkownika, a logika procesów zostaje w systemach źródłowych.
Zakres rośnie etapami: najpierw odpowiedzi z baz wiedzy, potem pomoc w ticketach i plany roczne.
Najbardziej złożone tickety asystent świadomie odsyła do formularza i od pierwszego kontaktu mówi, czego nie obsługuje.
Najwięcej pracy pochłaniają tożsamość, integracje i identyfikacja API. Pierwsza przeszkoda: asystent może widzieć tylko dane, do których użytkownik ma prawo w systemie źródłowym.
Wdrożenie obejmuje coraz większe grupy pracowników, a efekt mierzy się liczbą ticketów, powrotami użytkowników i feedbackiem.

Wersja do czytania

Projekt zaczął się od problemu HR z rozproszonymi systemami

Asystent powstał z inicjatywy działu HR dużej globalnej firmy farmaceutycznej, która działa w kilkudziesięciu krajach. Sprawy kadrowe są w tej firmie rozproszone po wielu systemach, na przykład po bazach wiedzy, systemach wypłat i benefitów. Pracownicy nie wiedzieli, do którego systemu się zwrócić, co w nim znajdą i co mogą w nim zrobić.

HR chciał ograniczyć złożoność tego układu i postawił sprawę jasno: jeśli IT tego nie zrobi, HR znajdzie sposób i rozwiąże problem samodzielnie.

Rozmówcy dość często widzą u klientów odwrotną sytuację. Zarząd albo dyrektor mówi „potrzebujemy AI”, a IT zastanawia się, co może zrobić, i zwykle zaczyna od własnych baz wiedzy zamiast od discovery z biznesem. Stąd bierze się opinia, którą słychać na rynku: 90% wdrożeń AI kończy się porażką, bo nie przynosi żadnej wartości.

Gdy do wdrożenia dołączył zespół Protopii, projekt był już dość dobrze opisany, miał sponsora i opiekunów biznesowych, a w firmie działała platforma AI. Klient uznał, że potrzebuje kogoś z zewnątrz, kto widział już wdrożenia agentowe: w tych systemach doświadczenie można mieć rok, dwa lata, a problemy z kontekstem czy halucynacje prędzej czy później się pojawią.

Asystent wie, kim jest użytkownik

W tym projekcie asystent to frontend z chatbotem, który zna kontekst użytkownika i ułatwia mu procesy HR. Nazwa „asystent” odróżnia go od agenta, rozumianego jako autonomiczny element, który w tle łączy i automatyzuje procesy. Od klasycznego chatbota bez kontekstu różni go to, że wie, w jakim kraju pracuje użytkownik, w jakiej roli i na jakiej umowie: o pracę czy B2B. Od tego zależy, co ta osoba może zrobić w sprawach HR.

Asystent integruje się z systemami, które działają w korporacji od lat, na przykład z systemem ticketów HR. Przez tickety idą między innymi urlop macierzyński lub chorobowy, prośba o szkolenie, zmiana roli i przeniesienie pracownika. Wokół nich jest ogromna i rozproszona baza wiedzy (KB): część procedur jest lokalna, część globalna. Stąd pytania w rodzaju: czy menedżer, który ma pracowników w trzech różnych miejscach, ma dostęp do wszystkich KB, czy tylko do części z nich.

Zakres rośnie etapami według roadmapy

Asystent obejmuje kolejne obszary jeden po drugim, bo roadmapa produktu nie próbuje wrzucić wszystkiego naraz. Klient ma wiele systemów, więc zakres na start trzeba było zawęzić.

Na początek poszła integracja z bazami wiedzy, prawdopodobnie najpilniejsza potrzeba: asystent miał odpowiadać w kontekście użytkownika. Pytania brzmią na przykład: ile mam dni urlopu, czy przysługuje mi dany benefit, czy mogę dostać samochód służbowy. Użytkownik nie przeszukuje baz ręcznie. Asystent sięga do tych systemów i składa z nich odpowiedź w języku, w którym padło pytanie.

Drugi obszar to tickety. Asystent najpierw próbuje rozwiązać sprawę na podstawie KB. Gdy użytkownik dalej nie wie, co zrobić, albo wie już, że musi zgłosić ticket, asystent proponuje, że wypełni z nim właściwy ticket i wskaże, gdzie on jest. Typów ticketów jest dużo.

Trzeci obszar to plany roczne pracowników. Pracownik razem z menedżerem i asystentem formułuje plan z celami SMART i go weryfikuje. Dalsza roadmapa jest szeroka, na razie to zamiary: learning, rekrutacje, rozwój pracownika i awanse wewnątrz organizacji. Docelowo asystent ma być centralnym punktem wejścia, który spina systemy HR w całość.

Rozmówcy widzą, że klienci oczekują superagenta, który od pierwszego dnia na produkcji rozwiąże wszystkie problemy. Z doświadczenia wiedzą, że to nie działa. W tym projekcie praca jest iteracyjna, podzielona na zadania i osobnych agentów.

Asystent mówi wprost, czego nie obsługuje

Asystent od pierwszego kontaktu deklaruje, co jest możliwe, a co nie. Rozmówcy widzą, że klienci często boją się mówić, co agent umie, a czego nie umie. Tutaj przy każdym kolejnym wydaniu MVP organizacja robi duże spotkanie typu town hall i ogłasza pierwszym użytkownikom, co asystent potrafi.

Część typów ticketów ma złożone formularze z dynamicznymi, rozwijanymi menu i zbyt wiele zależności. Zespół zdecydował, że asystent ich nie obsługuje. Dla użytkownika efektywniej jest, gdy asystent mówi, że w tej sprawie nie pomoże, i daje link do formularza, który użytkownik wypełnia sam. Dzięki temu zespół unika halucynacji. W ticketach zadziałała zasada Pareto:

Marek Grabarz: „90% funkcjonalności jesteśmy w stanie ogarnąć w 10% wysiłku i odwrotnie.”

Schemat: kiedy asystent odsyła do formularza

Asystent łączy systemy, a procesy zostają w źródle

Asystent orkiestruje procesy i nie musi ich powielać. Gdy proces jest bardzo złożony i zamknięty w systemie źródłowym, zespół opisuje go asystentowi ogólnie, bez instrukcji krok po kroku, a całe „mięso” procesu zostaje po stronie systemu.

Istniejące systemy, takie jak SAP czy SharePoint, nie integrują się w oczywisty sposób. Trzeba ustalić, jak się z nimi łączyć, gdzie są zespoły utrzymaniowe i gdzie w organizacji jest wiedza o systemach docelowych.

Przykładem problemu niskopoziomowego jest dostęp delegowany. Jeśli systemem jest na przykład SAP, użytkownik widzi w nim własne cele roczne i e-learning, a przełożony także dane i deklaracje swoich pracowników. Asystent może widzieć tylko te dane, do których dany użytkownik ma prawo, więc musi odwzorować role i uprawnienia z systemu źródłowego (RBAC). To była pierwsza ściana, którą zespół musiał pokonać z klientem.

Marek Grabarz: „Większość pracy to jest wokół tożsamości, wokół integracji, wokół identyfikacji tych API.”

Schemat: asystent jako punkt wejścia do systemów HR

Wdrożenie obejmuje coraz większe grupy użytkowników

Etap nazwany pierwszym rejsem pilotażowym to produkcja z ograniczonym zasięgiem. W chwili nagrania korzystało z niej ponad 1000 aktywnych, unikalnych użytkowników.

Prawdopodobnie dzień przed nagraniem zespół dostał zgodę na wejście na produkcję z pełnym zakresem opisanym wyżej. To nadal nie jest pełny rollout: kolejny etap obejmuje 10% pracowników, czyli tysiące osób. Docelowo, prawdopodobnie na początku lipca, asystent ma trafić do wszystkich krajów i wszystkich pracowników. W chwili nagrania nie było widać dużych przeszkód dla tego planu.

Schemat: etapy wdrożenia asystenta

Sukces mierzą tickety, powroty użytkowników i feedback

Pierwsza miara to liczba ticketów, zwłaszcza user requestów, czyli pytań do HR w rodzaju „jak mam zrobić to czy tamto”. Asystent ma rozwiązać sprawę już na etapie bazy wiedzy, żeby nie kończyła się ticketem, a pracownicy HR nie odpowiadali na takie pytania na czatach. Zespół śledzi zmiany w liczbie ticketów i ich typach. Druga miara to powroty: czy użytkownicy chętnie wracają do asystenta. Trzecia to odpowiedź na pytanie, czy asystent naprawdę rozwiązuje problemy.

Do tego służy feedback wbudowany w platformę i w asystenta, mierzony w dwóch wymiarach: biznesowym i technicznym. Użytkownik ocenia, czy sesja rozwiązała jego problem i czy stało się to szybko, czy po wielu pytaniach i krokach. Z feedbacku zespół ustala przyczynę: problem po stronie asystenta, niezrozumienie, jak asystent działa, albo braki w bazach wiedzy. Bazy wiedzy na bieżąco poprawia osobny zespół, bo bywają w nich stare albo niepoprawne wersje treści. Błędy się zdarzają, ale dużo feedbacku brzmi: świetnie, tylko dodajcie kolejne funkcje.

Gdy pojawiają się błędy, zespół korzysta z platformy monitoringu z tracingiem. Na etapie pilotażu można wydobyć całą treść czatu, kontekst wywołań i wywołane funkcje, a identyfikator sesji zostaje zachowany. Po pilotażu śledzenie na produkcji będzie węższe, bo asystent obsługuje wrażliwe dane HR, czasem o wypłatach, czasem o zdrowiu.

Koszt to projekt i tokeny, a część korzyści trudno zmierzyć

Koszt rozwiązania agentowego to suma wielu pozycji, w tym kosztu projektu i tokenów, które zużywa cały system. Korzyści można próbować mierzyć efektywnością organizacji i zadowoleniem użytkowników, ale wielu takich procesów nie da się przeliczyć na pieniądze.

W dużej organizacji nie zawsze wiadomo, gdzie jest właściwy ticket i który trzeba założyć. To tak zwana wiedza plemienna. Na przykład analityk finansowy ze sprawą kadrową, zamiast czekać dniami, pisać maile i zagadywać kogoś na Microsoft Teams, może szybko załatwić ją z asystentem i wrócić do swojej pracy. Taki nieprzerwany czas pracy to korzyść, którą trudno zmierzyć.

FinOps to proces, nie narzędzie

Szymon Warda, Mikołaj Szczerbicki — Wed, 29 Apr 2026 00:00:00 GMT

TL;DR

Koszty chmury rozchodzą się po subskrypcjach dostawców, licencjach i kolejnych wersjach tych samych usług, a Ty chcesz nad nimi zapanować bez dokładania pracy zespołom. FinOps jest w tym ujęciu stałym procesem w organizacji: najpierw daje widoczność kosztów, potem wprowadza wspólne zasady, automatyzacje i monitoring, a oszczędności przychodzą jako skutek uboczny. Wdrożenie przebiega fazami: widoczność, optymalizacja, a potem utrzymanie procesu, które organizacja prowadzi już sama.

Kluczowe wnioski

Koszty ukrywa rozdrobnienie: zasoby dostawców bez budżetów i alertów, licencje na osobnej fakturze i wiele wersji tej samej usługi, z których każda wymaga własnych polityk.
Ani kolejne narzędzie, ani prośba do zespołów o cięcia nie dają trwałego efektu, bo narzędzie bywa ignorowane, a ścięte koszty wracają.
Proces zaczyna się od przeglądu dostawców i własnych zasobów, a potem dokłada spójne budżety, automatyczne polityki, zachęty dla zespołów i monitoring, którego wnioski wracają do pierwszych dokumentów.
W pierwszej fazie wdrożenia klient głównie daje dostępy i wyznacza osoby kontaktowe.
W drugiej fazie oszczędność z optymalizacji zestawia się z kosztem zmiany po stronie dostawcy, bo ten koszt czasem przewyższa zysk.
Faza utrzymania nigdy się nie kończy: organizacja sama podtrzymuje kulturę FinOps.

Wersja do czytania

FinOps to proces, który daje widoczność kosztów

FinOps to proces w organizacji, który daje przewidywalność i wgląd w koszty chmury. Przy okazji podnosi governance i compliance, a oszczędności są jego skutkiem ubocznym. FinOps nie jest jednorazową kontrolą, narzędziem zainstalowanym w CI/CD ani przeglądem kosztów raz na 3 miesiące. Rozmówcy często widzą odwrotną kolejność: firma wprowadza kontrole raz na rok albo raz na kwartał i od razu chce zbić koszty. To tak nie zadziała.

Dzięki widoczności organizacja wie, na co wydaje, łatwiej kontroluje koszty, ma mniej typów zasobów i łatwiej je przegląda. Niższy rachunek za chmurę nie może przy tym wynikać z dodatkowej pracy ludzi.

Szymon Warda: „Bo nie chodzi, żeby wydawać mniej. Chodzi, żeby wydawać rozsądniej.” Z reguły rozsądniejsze wydatki są też niższe.

Koszty uciekają w rozproszonych zasobach i długim ogonie systemów

Koszty rozchodzą się tam, gdzie każdy dostawca, region albo dział ma własne, słabo wykorzystane zasoby. Opis pochodzi z pracy z jednym klientem, ale rozmówcy widzą tę sytuację w bardzo wielu organizacjach, w różnym stopniu i w różnych obszarach.

Typowy układ to wiele subskrypcji i kont, na których dostawcy wgrywają oprogramowanie i niejako wydają nie swoje pieniądze. Luźniejsza kontrola nie jest zła sama w sobie: daje zwinność i skraca czas dostarczenia, a organizacje często nie wiedzą, jak zrobić to inaczej. W takim układzie nie ma jednak rezerwacji, kontroli budżetów, alertów, prognoz ani zasad, z jakich zasobów korzystać. Część zasobów można scentralizować: częstsze ponowne użycie ułatwia kontrolę, zmniejsza pracę ludzi i poprawia compliance.

Osobny problem to licencje oprogramowania. U tego klienta nikt ich nie kontrolował, a potrafią kosztować sporo w dolarach. Licencje często łatwo przeoczyć, bo trafiają na inną fakturę, a w niektórych organizacjach to koszt bardzo znaczący.

Ukryty koszt tworzą również powtarzalne rozwiązania, które nieco się od siebie różnią. Przykład: jedna usługa istnieje w sześciu wersjach, a każda potrzebuje polityk backupu, bezpieczeństwa i sieci. Ten koszt rośnie, bo każdą wersję trzeba zabezpieczyć i utrzymywać. Każdy system wdrożony przez dostawcę wydłuża długi ogon kosztów, a dział IT musi mieć tyle osób, ile wymagają utrzymywane systemy. Taki model nie skaluje się dobrze.

Godziny też się sumują. Przez lata trzy godziny tu, dwie tam i cztery gdzie indziej mogą złożyć się na przykład na dwa, trzy etaty. Późniejsze odzyskanie tego czasu jest drogie, bo oszczędzanie czterech godzin tygodniowo opłaca się średnio. Może lepiej nie dopuścić, by te cztery godziny w ogóle powstały, i zostać na przykład przy 20 minutach. Dlatego FinOps pilnuje też przyszłych kosztów: organizacja widzi, jak będą wyglądać i jak się rozłożą.

Ani zakup narzędzia, ani cięcia w zespołach nie dają trwałych oszczędności

Zakup narzędzia albo licencji do FinOps nie naprawi problemów, a mimo to rozmówcy często widzą tę drogę. Łatwiej ulec marketingowi, który obiecuje, że produkt je usunie. Szymon Warda: „magiczny proszek nigdy jeszcze nikogo nie uzdrowił”

Nowe narzędzie trafia do zespołu, który już utrzymuje wiele produktów. Nie wiadomo, czy zostanie dobrze skonfigurowane, czy będzie działać i czy ludzie zechcą z niego korzystać. W najgorszym razie może stać się kolejną przeszkodą, w najlepszym kolejnym ignorowanym narzędziem, które podnosi koszt.

Zestaw best practices to lepszy kierunek, bo dotyczy zachowań. Organizacja musi jednak stworzyć warunki, w których ludzie chcą je wdrożyć, mają na to czas i wiedzą, jak je zastosować.

Prośba do wszystkich zespołów, by same znalazły zbędne zasoby i ścięły koszty, to pułapka, którą rozmówcy bardzo często widzą. Po pół roku koszty potrafią wrócić, i to większe, jak w efekcie jojo, bo przerzucono je na ludzi, płacono błędnie albo oszczędności miały tylko dobrze wyglądać w Excelu w odpowiednim kwartale. Nawet 8 godzin w miesiącu na każdy zespół składa się w skali organizacji na dość spory budżet.

Sporo oszczędności i widoczności musi powstać na poziomie organizacji. Protopia proponuje zrobić tę pracę raz, centralnie, i dać zespołom automatyzację oraz gotowe procesy zamiast codziennego porannego przeglądu tabelki na liście zadań. Pit of success to układ, w którym poprawne rzeczy robi się łatwo, tanio i prosto. Zespoły oddają część pracy, a jeśli działają tak, jak uzgodniono w całej organizacji, mają łatwiej i taniej. Wtedy nie trzeba walczyć z organizacją, bo optymalne zachowanie się opłaca.

Schemat: narzędzie, cięcia w zespołach i proces centralny

Pierwszy krok porządkuje dostawców i własną organizację

Budowa procesu zaczyna się od dostawców, na dwa sposoby. Na przyszłość organizacja ustala wytyczne architektoniczne: z jakich zasobów korzystać, jak dostawcy mają raportować budżety i prognozować koszty. Dzięki temu długi ogon kosztów przestaje rosnąć w dotychczasowym tempie. Dla systemów, które już działają na produkcji, organizacja robi inwentaryzację: sprawdza, jakie zasoby są używane i co można zoptymalizować. Z niej powstaje lista najlepszych praktyk i zmian, po których system spełnia wymagania regulacyjne, bezpieczeństwa, governance i compliance.

Własna organizacja też wymaga porządku. Z reguły najpierw przychodzi etap sprzątania: licencje, nieużywane zasoby, złe tagi, budżety i różne podejścia do tej samej pracy FinOps. Procesy trzeba wyczyścić i ujednolicić. Potem organizacja konsoliduje zasoby, których sama używa w wielu miejscach. Przegląd dostawców pokazuje też, których zasobów używają i co opłaca się przejąć pod własną kontrolę, na przykład agentów DevOps, platformę Kubernetes albo platformę do Observability.

Governance łączy spójne budżety z automatycznymi politykami

Drugi krok to governance oparty na widoczności i automatyzacji. Widoczność zaczyna się od budżetów na poziomie organizacji: wszystkie systemy raportują koszty w spójny sposób i według tych samych zasad prognozowania, więc da się je porównać. Organizacja widzi też, z jakich zasobów, w jakich wersjach i gdzie korzysta, i rozbija fakturę na mniejsze pozycje. Przegląda retencję danych i rezerwacje, a potem decyduje, gdzie zainwestować czas, co kupić i z czego zrezygnować.

Pierwsza część automatyzacji to polityki, które wymuszają dobre zachowania. Zasada obowiązuje i koniec, bez polegania na słowie harcerza. Tam, gdzie czegoś nie da się sprawdzić automatycznie, usługi szybko informują o niezgodności. Zasady raportowania skracają czas od zdarzenia do informacji. Jeśli organizacja dowiaduje się o zasobie na przykład po 2 miesiącach jego używania, prośba o zmianę nie zadziała. Jeśli od użycia do informacji mija dzień lub dwa, zmiana staje się bardziej realna.

Nudging daje zespołom gotowe automatyzacje i moduły

Trzeci krok zachęca ludzi, by sami chcieli stosować dobre praktyki, bo sam kij bez marchewki nie wystarcza. Nudging to zachęcanie do dobrych zachowań i ułatwianie ich. Etap ma dwie części: cele i sposób ich dostarczenia. Przykładowy cel to dobre praktyki i niższy koszt Azure albo dowolnej chmury.

Do dostarczenia celów służą na przykład automatyczne włączanie i wyłączanie maszyn, automatyzacja backupów oraz autoskalowanie baz danych, klastrów Kubernetes, maszyn wirtualnych i usług PaaS oraz SaaS. Do tego dochodzi monitorowanie liczby licencji i procesy, w których łatwo zgłosić potrzebę dostępu. Zespół taguje zasób i od tej chwili obejmuje go cała automatyzacja. Może też użyć gotowego modułu CI/CD lub infrastructure as code. Governance może dodać do modułów elementy DevOps i security.

Niektóre organizacje po uzyskaniu widoczności zmieniają sposób działania wewnątrz i we współpracy z dostawcami.

Monitoring zostawia miejsce na wyjątki i zamyka pętlę

Czwarty krok to monitoring, bo nie wszystko da się zautomatyzować i nie wszystko opłaca się automatyzować. Łatwiej byłoby narzucić FinOps pierwszego dnia bez żadnych odstępstw, ale biznes będzie ich wymagał. Monitoring pokazuje, gdzie są odstępstwa, chroni przed regresją i pozwala rozwijać proces. Ta część jest mniej przyjemna i powolna: przeglądy architektury, zasady rozwijania dokumentów dostawców i raportowania.

Wnioski z nudgingu i monitoringu wracają do dokumentów z pierwszego kroku i pokazują, jak powinna zmienić się organizacja, jej dostawcy i istniejące systemy. Tak powstaje pętla zwrotna, w której proces zmienia się razem z organizacją.

Schemat: kroki procesu FinOps tworzą pętlę zwrotną

Pierwsza faza wdrożenia pokazuje, co dzieje się w organizacji

Wdrożenie całego procesu Protopia dzieli na 3 główne fazy, a pierwsza ma pokazać, co w ogóle dzieje się w organizacji. Obejmuje inwentaryzację, założenie alertów, przegląd licencji i identyfikację zasobów przez tagi. Z reguły Protopia stosuje też proste standardy obecne w każdej organizacji, takie jak automatyzacje z kroku trzeciego i automatyzacja retencji backupów. Te praktyki sięgają dalej niż FinOps. Często wychodzą przy tym rzeczy niezgodne z politykami bezpieczeństwa i wymaganiami zgodności.

Z doświadczeń Protopii ta faza trwa mniej więcej 2–3 miesiące, nie dłużej, bo Protopia nie chce jej przeciągać. Czas zależy od organizacji.

W tej fazie klient daje przede wszystkim dostępy i wyznacza osoby kontaktowe. Odpowiadają one na pytania o standardy nazewnictwa, sposób budowy systemów i to, kto jest dostawcą czego, czyli o wiedzę plemienną, której często nie ma w dokumentacji. Z reguły zamyka się to w kilku osobodniach w ciągu całej fazy.

Druga faza zamienia widoczność w konkretne zmiany

Druga faza wyciąga wnioski z widoczności i zaczyna rozmowy o optymalizacji istniejących zasobów. Protopia pokazuje, ile klient może zaoszczędzić, a potem pyta dostawcę, ile kosztuje wdrożenie zmiany. Czasami koszt zmiany może przewyższyć oszczędności. Czasami dostawca wycenia zmianę wysoko, a Protopia przedstawia kontrargumenty. To bywa negocjacja o to, gdzie warto włożyć realny wysiłek.

Faza obejmuje też szczegółowy przegląd nowych architektur. Wcześniej chodziło o ogólne rzeczy, teraz o nowe systemy i proces dostarczania w organizacji. Z tego przeglądu powstaje zbiór dobrych praktyk, który zasila pierwszy krok procesu.

Proces FinOps dostaje teraz szczegóły konkretnej organizacji, w tym punkty kontaktowe. Zapadają decyzje, co będzie zasobem współdzielonym, co zostaje wydzielone i jak zarządzać zasobami współdzielonymi. Zmiany w zasobach chmurowych najczęściej będą wymagane, ale Protopia stara się, by były jak najmniejsze. Zasoby wspólne Protopia może dostarczyć sama, na przykład jako infrastructure as code z pipeline’em CI/CD do automatycznego wdrażania. Klient dostaje zasób, którym da się zarządzać i którego utrzymanie kosztuje minimalnie.

Klient bierze w tym udział, a przekazanie wiedzy ma sprawić, że organizacja sama umie posługiwać się tymi narzędziami i nimi zarządzać. Faza trwa z reguły około pół roku: zaczyna się od większego zakresu i powoli wygasa.

Trzecia faza utrzymuje kulturę FinOps bez końca

Trzecia faza nigdy się nie kończy, bo jej przedmiotem jest proces. Na tym etapie organizacja ma już dobre praktyki, polityki, automatyzacje i monitoring. Sama utrzymuje kulturę FinOps, a Protopia może ją w tym wspierać. Organizacja rozbudowuje tę kulturę, prowadzi pętlę zwrotną i dodaje małe elementy, dzięki którym proces pozostaje zyskiem dla organizacji. Może trwać nadzór nad migracją starych systemów i przeglądy systemów, które dopiero są wdrażane. Proces rozszerza się też na pozostałe części organizacji.

Schemat: fazy wdrożenia FinOps i rola organizacji

Agent AI od PoC do produkcji: spisany proces, dostęp do systemów i decyzja po testach

Łukasz Kałużny, Mikołaj Szczerbicki — Wed, 01 Apr 2026 00:00:00 GMT

TL;DR

Masz pomysł na agenta AI i musisz zdecydować, czy budować pełne rozwiązanie. Tę decyzję przygotowuje PoC. Przed nim zespół spisuje proces z wiedzy pracowników i sprawdza dostęp do systemów, a po testach ocenia wynik jako scale, iterate albo kill według kryteriów ustalonych wcześniej.

Kluczowe wnioski

Zanim powstanie PoC, osoba, która wykonuje proces, spisuje w Wordzie, co robi i dlaczego, albo nagrywa ekran. Takie przygotowanie oszczędza dużo pracy, która nie powinna odbywać się w trybie debugowania.
Ludzie z biznesu, którzy chcą coś przetestować, powinni dostać playground z tym samym gołym modelem, z którego powstanie agent, bo taki model zachowuje się inaczej niż ChatGPT.
W większości PoC najwięcej problemów sprawia dostęp do danych i systemów, a sama budowa agenta to głównie żmudna praca integracyjna.
Już na starcie trzeba ustalić, co uruchamia agenta i w którym momencie do procesu wchodzi człowiek. Macierz akceptacji wyznacza, co może się wykonać automatycznie. Bez człowieka mogą działać procesy, w których ewentualny problem jest bardzo mały i nie szkodzi ani reputacji, ani finansom.
Kryteria sukcesu powstają przed testami. Testy idą prosto do celu: UI jest celowo brzydki, a log zapisuje przebieg, czas i decyzje agenta.
Po testach zapada decyzja scale, iterate albo kill, a kill z dobrze spisanymi wnioskami chroni przed projektem, który i tak by nie działał.

Wersja do czytania

PoC sprawdza agenta AI przed inwestycją w pełne rozwiązanie

Proof of concept (PoC) to studium wykonalności, które sprawdza, czy koncepcja zadziała i czy będzie działać powtarzalnie. W Protopii często nazywa się go też proof of value (PoV), bo ma sprawdzić, czy rozwiązanie wniesie wartość i czy da się je wykonać.

Jeden z klientów napisał, że prompt jest bardzo precyzyjny, ale odpowiedzi różnią się merytorycznie. Żeby PoC się udał, trzeba czasem nieco inaczej podejść do procesu i inaczej wykorzystać wiedzę biznesu niż wtedy, gdy po prostu wrzuca się zadanie do GPT, Copilota, Gemini czy Claude’a.

Schemat: od spisania procesu do decyzji po testach PoC

Pierwszym krokiem jest spisanie procesu z wiedzy pracowników

Przed PoC trzeba dokładnie wiedzieć, jak wygląda proces do automatyzacji: co ludzie robią dziś ręcznie i jak to przebiega w systemach. Protopia sadza osobę, która ma tę wiedzę, żeby w Wordzie spisała krok po kroku, co robi i dlaczego, albo nagrała ekran. Czasem robi to dwójka pracowników lub ekspertów.

Wiedza plemienna to wiedza ludzi, którzy na co dzień wykonują proces. Jej spisanie to pierwszy krok, który w projektach Protopii przynosi największy sukces. Instrukcji często nikt nie aktualizuje, gdy zmienią się warunki biznesowe, konfiguracja systemu albo podejście.

U jednego z klientów ubezpieczeniowych pracownik spisał, że najpierw bierze dane z systemu, potem szuka w internecie, kim naprawdę jest klient i co można mu zaproponować, a na końcu próbuje to dopasować i robi analizę. Taki dokument w Wordzie jest świetnym punktem wyjścia do planowania, bo pokazuje, co faktycznie się dzieje i co robi człowiek. Tydzień przygotowań i zbierania danych oszczędza naprawdę dużo pracy, która w ogóle nie powinna się odbywać w trybie debugowania.

Prawo Conwaya pokazuje, że proces odzwierciedla strukturę komunikacji w firmie, a nie logikę, którą powinien mieć. Spisanie procesu może więc być okazją, żeby sprawdzić, czy nie warto go uprościć i uporządkować.

Playground pokazuje biznesowi, jak naprawdę zachowuje się model

Po spisaniu procesu trzeba zbudować oczekiwania. Osoby nietechniczne powinny móc same sprawdzać, jak zachowują się agenci: na playgroundach, z których zespół potem buduje rozwiązanie, a nie w Copilocie czy ChatGPT. Protopia najczęściej pracuje z Azurem. Playground to miejsce podobne do czatu, które daje dostęp do gołego modelu językowego, a ten model potem trafia do agentów i aplikacji.

Goły model zachowuje się zupełnie inaczej niż ChatGPT w trybie agentowym. Na przykład w modelu OpenAI hostowanym dla Ciebie na Azure wyszukiwanie w internecie działa trochę inaczej: Bing Search pod spodem nie zachowuje się tak jak w publicznym, konsumenckim ChatGPT. Na playgroundzie biznes widzi, jak model faktycznie działa, także przy takim prompcie jak ten z wiadomości klienta.

Jeśli ludzie z biznesu chcą coś przetestować, powinni dostać dostęp do playgroundu, a nie blokadę narzędzi. Zbudują wtedy realistyczne oczekiwania i zaufanie. Te testy odbywają się jeszcze przed właściwym PoC, na etapie zabawy i odkrywania.

Analizę najbardziej utrudnia dostęp do systemów

Po testach na playgroundzie przychodzi analiza, najgorsza faza. W większości PoC Protopii automatyzacja i zachowanie agenta nie sprawiają problemów. Łukasz Kałużny: „Większość problemów to dostęp do systemów.”

Ktoś musi wykonać mrówczą pracę: ustalić, skąd pochodzą potrzebne dane, z jakiego systemu, jak uzyskać do niego dostęp i czy system ma API. Jeśli API nie ma, trzeba sprawdzić, czy da się zautomatyzować dostęp przez przeglądarkę albo czy wystarczy dostęp do bazy danych. To inwentaryzacja systemów, z których korzysta automatyzowany proces. Dziś najczęściej chodzi o pobranie danych i działanie na ich podstawie albo, trochę jak wcześniej w RPA (Robotic Process Automation), zapis do innego systemu lub wywołanie API.

Schemat: jak ustalić dostęp agenta do danych

Gdy proces jest już spisany, większość dalszej pracy technicznej to żmudna integracja. Budowa agentów to mocno programistyczna praca, a nie data science.

Wyzwalacz i miejsce człowieka ustala się na początku

Na początku trzeba odpowiedzieć na dwa pytania. Pierwsze: co uruchamia agenta. Agent sam się nie domyśli, więc jego pracę musi coś wyzwolić, na przykład mail w skrzynce, zdarzenie albo kliknięcie człowieka. Drugie to human in the loop: w którym momencie człowiek wchodzi do procesu, akceptuje pracę agenta albo z niej korzysta.

Macierz akceptacji to jasne reguły, kiedy coś może się wykonać automatycznie, a kiedy nie. To ona wyznacza miejsce człowieka w procesie. Protopia często radzi, żeby na końcu coś zaakceptować, i w wielu przypadkach to wystarcza.

Schemat: wyzwalacz agenta i macierz akceptacji

Miejsce człowieka w procesach z agentem
Proces	Co robi agent	Rola człowieka
Reklamacja lub zapytanie klienta	Przemiela sprawę, przygotowuje uzasadnienie i odpowiedź, skraca czas dostarczenia	Sprawdza to, co wychodzi do klienta, zanim zostanie wysłane; może nic nie zmienić i kliknąć „send”
PoC zbierający dane i przygotowujący analizę	Przygotowuje gotowy raport ze wszystkimi źródłami	Sam weryfikuje, czy raport jest w porządku
Wycena na podstawie wyszukiwania w internecie	Agent szuka i proponuje cenę; dodatkowy agent-sędzia Judge robi screenshoty stron źródłowych i przekazuje cenę dalej, gdy podstawowe informacje na stronach się zgadzają	Akceptuje wynik na końcu
Obsługa posprzedażowa otwartych szkoleń marki Patoarchitekci, należącej do Protopii (zaproszenie, dodanie do szkolenia)	Obsługuje zakup szkolenia	Brak człowieka, bo ewentualny problem jest bardzo mały i nie szkodzi ani reputacji, ani finansom

Interpretację AI Act Protopia zawsze zostawia klientowi, bo to nie jej specjalizacja. Przy ustalaniu miejsca człowieka liczy się pojęcie systemów wysokiego ryzyka i to, jak zinterpretują je prawnicy i compliance firmy. Pierwszy pomysł może okazać się błędny i wyjdzie to w testach. Między innymi po to jest PoV.

Kryteria sukcesu spisuje się przed pierwszym testem

Właściwy PoV zaczyna się od jasnych kryteriów sukcesu. Protopia zwykle stara się w nim wstępnie zautomatyzować cały proces. Trzeba ustalić, co dokładnie zostanie przetestowane: na przykład najważniejsze i najbardziej problematyczne elementy albo cały proces bez edge case’ów i corner case’ów, czyli szczęśliwą ścieżkę z mało problematycznymi odgałęzieniami. Przykładowe kryterium brzmi: w fazie PoC 80% przypadków zostało obsłużonych poprawnie.

Wyniki takie jak raporty ocenia ekspert biznesowy klienta. Niektóre cechy jakości bardzo trudno zmierzyć: to, czy pismo jest językowo w porządku, zawsze zależy od ludzkiego odczucia i jest bardzo subiektywne.

Testy prowadzą prosto do celu, z brzydkim UI i logowaniem

Testy powinny iść prosto do celu i w większości przypadków nie skupiać się na sprawdzaniu technologii ani zabawie nowym frameworkiem. Protopia najczęściej daje do testów kawałek UI, zwykle jak najbrzydszy, żeby nikogo nie kusiło wdrożyć go następnego dnia na produkcję. Ten UI jest tylko minimalnie użyteczny.

Od początku potrzebne jest w miarę dobre logowanie w całym procesie: jak agent działał, ile to trwało, jakie decyzje podjął i co działo się dalej. W PoC wystarczy do tego plik tekstowy.

Logi są katalogiem błędów i roadmapą: pokazują, co trzeba poprawić, a czego nie poprawiać. Przykładem jest znaleziony edge case, który trzeba koniecznie naprawić, jeśli projekt pójdzie do pilotażu lub na produkcję, ale nie w tym momencie. Testy pokazują też czas działania. U jednego z klientów agent nie odpowie w ciągu 30 sekund, bo danych jest za dużo, i tego nie da się przeskoczyć. Generowanie raportu może trwać 5 minut, bo agent musi przejrzeć kilkadziesiąt stron, zanim podejmie decyzję. Takie ograniczenia są w porządku, bo pomagają zbudować oczekiwania i roadmapę, żeby przy decyzji o wejściu na produkcję nie było niespodzianek.

Po testach zapada jedna z trzech decyzji: scale, iterate albo kill

Protopia ocenia wynik testów trzema stanami.

Trzy stany po testach PoC
Stan	Kiedy	Co dalej
Scale	PoC spełnił swoje cele: osiągnął spisane kryteria sukcesu albo biznes subiektywnie potwierdził, że chce iść dalej	Pilotaż i produkcja; eksperyment staje się faktycznym projektem
Iterate	Wynik jest blisko sukcesu, a zespół wie, co poprawić i że potrzebuje na to czasu; samo przeczucie, że będzie dobrze, nie wystarcza	Kolejna iteracja i ponowne testy
Kill	Kryteria nie są osiągane, a zespół kręci się w kółko	Warto rozważyć zamknięcie inicjatywy; wnioski trzeba spisać

W procesie wyceny iteracja polegała na dodaniu agenta-sędziego, który weryfikuje wynik. Ta zmiana i ponowne pełne testy wymagały jeszcze 3–4 dni.

Kill to najbardziej znienawidzony status, bo nie da się odtrąbić sukcesu. Jeśli wnioski są dobrze spisane, wiadomo, dlaczego się nie powiodło, i to też jest sukces. Łukasz Kałużny: „operacja została przeprowadzona z sukcesem. Pacjent zmarł.”

Powodem bywa pomysł, który nie był wart automatyzacji, albo brak dostępu do API. Zbyt wygórowane oczekiwania też się zdarzają, choć coraz rzadziej. Wreszcie dodanie automatyzacji w systemie może okazać się za drogie, gdy koszt dobudowania API pochłonie potencjalne zyski. Zamknięcie chroni zespół przed utopieniem się w projekcie, który i tak by nie działał.

Przy dobrej analizie większość takich PoC kończy się sukcesem, także wtedy, gdy po podsumowaniu kosztów okazuje się, że projekt nie ma sensu.

Observability w działaniu: plan wdrożenia stosu Grafana i demo

Szymon Warda, Mikołaj Szczerbicki — Wed, 11 Mar 2026 00:00:00 GMT

TL;DR

Jeśli masz kilka środowisk, Twój monitoring pewnie rósł z czasem bez porządku, a przy awarii admini i deweloperzy patrzą na różne dane. Samodzielnie hostowany stos Grafana zbiera metryki, logi i trace'y z całej organizacji w jednym miejscu i nie ma licencji liczonych od liczby użytkowników. Od małej firmy wzwyż taki stos wchodzi fazami, obok narzędzi, które już masz, a od Twojego zespołu wymaga głównie dostępów.

Kluczowe wnioski

Własny stos Grafana ma sens w firmie większej niż mikro, a małemu zespołowi z jednym monolitem lepiej posłuży gotowe narzędzie z pudełka.
Wdrożenie zaczyna się od inwentaryzacji i jednego punktu wejścia w Grafanie, bo zmiana typu wielki wybuch, w której ludzie nie przejdą poprawnie na nowe narzędzia, kończy się chaosem.
Twój zespół daje dostęp do CI/CD i do klastra Kubernetes (klaster może też postawić Protopia), potem wskazuje systemy, a każdy oddany system kończy się szkoleniem.
Nowoczesne aplikacje instrumentuje się kilkoma bibliotekami, a kupione systemy agentem, bez zmian w kodzie.
Profiling eBPF pokazuje wywołania pojedynczych metod bez integracji z aplikacją i z mniejszym narzutem niż inne systemy APM, ale działa tylko na Linuksie.
Zabbix czy ELK mogą zostać, bo Grafana z nimi współpracuje, a wdrożenie może iść częściami, choć rekomendowany wariant jest całościowy, ze szkoleniami.

Wersja do czytania

Własny stos Grafana ma sens w firmie większej niż mikro

Samodzielnie hostowany stos Grafana zaczyna mieć duży sens w organizacji małej lub średniej, bo przy tej wielkości narzut na zbieranie danych i ich ilość są już znaczące. Stos nie ma limitów zależnych od skali użycia. W najmniejszych firmach rachunek wygląda inaczej:

Szymon Warda: „Jeżeli masz zespół 10–20 programistów i jeden monolityczny system, to weź coś z pudełka. Po prostu będzie tańsze w utrzymaniu.”

Gotowe narzędzie daje wtedy dobry start, szybkie wdrożenie i szybki zwrot z inwestycji.

Przykład: organizacja z Zabbixem, z ELK dla bezpieczeństwa, ze środowiskiem hybrydowym (trochę on-premises, trochę chmura), z kilkoma chmurami i różnymi językami programowania. Dla takiej firmy własny stos Grafana ma sens, a część elementów observability już w niej działa.

Schemat: kiedy własny stos Grafana, a kiedy narzędzie z pudełka

Cały monitoring trafia w jedno miejsce

Gdy firma ma kilka środowisk, jej monitoring najpewniej rósł z czasem i nikt go nie układał. Każdy system ma wtedy swoją wysepkę: deweloper patrzy w system A, admin w system B, czasem nawet dla tej samej aplikacji. Najgorzej jest, gdy admini zgłaszają awarię, a deweloperzy odpowiadają, że u nich wszystko działa, bo nie widzą błędu.

Pierwszy cel to wrócić do monitoringu i zebrać informacje ze wszystkich systemów w jednym miejscu, żeby wszyscy patrzyli na te same dane i wyciągali te same wnioski. Klienci często mówią, że mają stare systemy i nie wszystko działa w Kubernetesie. Kubernetes jest najłatwiejszy do monitorowania, ale nie jedyny. Stos obejmuje też maszyny wirtualne i aplikacje na serwerach fizycznych, a monitoring chmury, on-premises i hybryd z więcej niż jedną chmurą łączy w jednym widoku.

Do monitoringu trafiają też aplikacje klienckie, bazy danych, kolejki, cache, a nawet serwery DNS, bo zespoły i systemy wpływają na siebie. Przyczyną awarii bywa przepełniony DNS, macierz dyskowa albo serwer tożsamości, więc dane trzeba zbierać ze wszystkich tych miejsc.

Prometheus pewnie działa też u Ciebie, ale prawdopodobnie nie wykorzystujesz go w pełni. Liczba systemów, z których może zbierać metryki, idzie w tysiące, a jego społeczność przygotowała podłączenie do niemal wszystkiego. Gdy zespół szybko stawia własny system, powstaje wydmuszka: zbiera dane z 10–20% tego, co da się zebrać, i nie daje obrazu całości. Przy awarii nikt wtedy nie wie, co było główną przyczyną.

Licencja per użytkownik zniechęca do szerokiego dostępu

Gotowe systemy, takie jak Datadog czy Dynatrace, są z reguły licencjonowane według liczby użytkowników, co zniechęca do udostępnienia ich całej organizacji. Wdraża się je stosunkowo łatwo, ale problemy zaczynają się w finansach. Gdy z narzędzia powinno korzystać 100 czy 200 osób, liczba licencji zaczyna boleć.

Rozmówcy dość często widzą wtedy, że organizacja ogranicza dostęp. W czasie awarii linie wsparcia gorzej wiedzą, co mogą zrobić, a ktoś, kto czegoś nie widzi, stawia kolejny system do monitorowania. Drugi częsty model licencji liczy procesory albo monitorowane systemy. Stos Grafana nie liczy kosztów per użytkownik, więc może działać dużo szerzej.

Wdrożenie zaczyna się od inwentaryzacji

Wdrożenie idzie w kilku fazach i nie wymaga dużego zaangażowania Twojego zespołu. Pierwsza faza to inwentaryzacja: kto korzysta z jakiego narzędzia i co właściwie działa w organizacji. Zmiana typu wielki wybuch dobrze wygląda na papierze. Jeśli jednak nagle zabierzesz administratorom oraz pierwszej i drugiej linii wsparcia ich narzędzia i nie przeniesiesz ich poprawnie, w organizacji powstanie chaos.

W drugim kroku Grafana staje się jednym punktem wejścia do wszystkich metryk i danych monitoringu w organizacji. Zastępuje stronę wiki z listą adresów URL, o której wie tylko część osób. Na tym etapie wychodzą zapomniane systemy, także te, za które firma płaci i których nie używa. Dla każdego zapada decyzja: usunąć go, zastąpić czy zrobić z nim coś innego.

Większość poradników w internecie każe w tym miejscu budować platformę i wysyłać do niej dane. Najpierw jednak staje Grafana Alloy, czyli kolektory, które zbierają dane z maszyn wirtualnych, Kubernetesa, chmury i innych źródeł. Alloy poprawia jakość tych danych, pilnuje ich i buforuje. Częsta sytuacja w firmach: deweloperzy postawili Kafkę do wysyłania logów, choć Kafka słabo się do tego nadaje.

Gdy dane z systemu A wyglądają podobnie do danych z systemu B, staje platforma monitorująca. Pierwsze są metryki w Prometheusie: pokazują stan całego środowiska, jego trendy i cykle dobowe. Na tych liczbach można potem budować alerty i prognozy, kiedy coś przestanie działać.

Stos bazowy ma cztery elementy: Alloy zbiera dane, Prometheus obsługuje metryki i jest standardem rynkowym, Loki zbiera logi, a Tempo trace’y. Loki przyjmuje terabajty danych, jest optymalny czasowo i kosztowo i praktycznie nie wymaga utrzymania.

Schemat: stos bazowy od kolektorów do Grafany

Twój zespół daje dostęp do klastra i CI/CD

Stos stawia Protopia. Od Twojej firmy potrzebny jest dostęp do klastra Kubernetes (albo Protopia stawia klaster sama) i dostęp do CI/CD, na przykład GitHub albo Bitbucket. Całość powstaje z kodu, żeby była odporna. Na tym kończy się zaangażowanie Twojego zespołu w tej części.

Dalej praca idzie fazami. Ty wskazujesz systemy, powstają PoC-e, a Protopia stawia kolektory, przygotowuje testy obciążeniowe, żeby sprawdzić, czy system będzie działał, i podłącza wszystko pod bazową Grafanę.

Każdy system oddany do użytku dostaje szkolenie. Ludzie z pełnym backlogiem nie mają czasu uczyć się sami, więc łatwiej zrobić szkolenie, które trwa 1 dzień, 4 godziny, i pokazać, co mogą z narzędzia wycisnąć. To zachęca pracowników do korzystania z nowego stosu zamiast starych narzędzi.

Schemat: co daje Twój zespół, a co robi Protopia

Stos jest znany i używany przez CNCF i organizacje na całym świecie. Nowa osoba w zespole zna te narzędzia z rynku, więc nie trzeba jej uczyć samych narzędzi, a firma buduje na standardzie, który może rozbudowywać.

Deweloperzy dostają standardy instrumentacji

Drugi element to standardy, których organizacja wymaga od deweloperów aplikacji. Protopia przeprowadza wywiady z kilkoma grupami deweloperów, poznaje sposób pracy i punkt startu, przygotowuje rekomendacje standardów i w razie potrzeby rozpisuje dojście do nich na fazy.

Monitoring działa bez integracji z aplikacjami i bez wsparcia deweloperów, ale więcej wartości daje dopiero udział aplikacji. Dla nowoczesnych technologii, takich jak Java, .NET, Python czy JavaScript, nakład wynosi od pół godziny do 3 godzin na system: kilka bibliotek i działa. Deweloperzy pewnie już próbowali, a biblioteki mogą być niedokonfigurowane, więc drobne zmiany w konfiguracji dużo dają.

Dla systemów kupionych, nieutrzymywanych albo nierozwijanych jest autoinstrumentacja. Autoinstrumentacja to uruchomienie aplikacji przez agenta, bez zmian w jej kodzie. Nie daje wszystkiego i nie jest idealna, ale daje dużo: telemetrię, tracing i metryki. Jest bardzo bezpieczna, a czasem jedyną zmianą jest obraz docelowy, w którym aplikacja się uruchamia.

Wiedza zespołów trafia do alertów

Standardy powstają też dla adminów i zespołów DevOps. Gdy deweloperzy, admini i DevOps patrzą na te same, głębokie dane, można zapytać, kiedy system zaraz przestanie działać i jaki jest główny powód jego problemów.

Ustalenia ze spotkania szybko wyparowują, dlatego wiedza tych ludzi trafia do alertów i metryk predykcyjnych, a system z czasem wie więcej. Dużej jej części nie trzeba zbierać od ludzi. Większość popularnych systemów, takich jak PostgreSQL czy Redis, ma gotowe albo oficjalne zestawy alertów, często promowane przez samych dostawców. Takie zestawy mają nierzadko dziesiątki, jeśli nie setki reguł. Niektóre wdrożenia Kubernetesa wgrywają reguły alertów domyślnie, a Ty konfigurujesz tylko, kto i kiedy dostaje powiadomienie. Ta wiedza jest dostępna, bo ze stosu korzysta bardzo wiele organizacji.

Drilldown w Grafanie pokazuje błędy, ruch i czas odpowiedzi

Najważniejszy ekran demo to Drilldown na danych z tracingu. Pokazuje liczbę błędów, liczbę requestów i rozkład czasu ich trwania. RED to skrót od Request, Error, Duration. To jedno z trzech podstawowych spojrzeń na dowolny system. Operator nie musi wiedzieć, skąd i jak płyną dane: dostaje gotowy sposób patrzenia na system.

Zakładka błędów rozdziela błędy widoczne dla klienta od błędów, które system połyka. Te drugie nie wychodzą na zewnątrz, ale warto się nimi zająć. Dalej widać, ile błędów produkuje który system, oraz root cause errors, czyli statystyczne źródło błędów dla każdego serwisu z ostatniej półgodziny. Przyczyna leży zwykle niżej w łańcuchu wywołań niż system, który się wywalił.

Porównanie zestawia obecne zachowanie systemu z poprzednim okresem. Gonienie każdego błędu pewnie się nie opłaca, bo zawsze coś się zdarzy, więc liczy się to, co się zmieniło. Trace’y pokazują drogę requestu przez cały łańcuch odwołań: gdzie coś nie zadziałało, na które serwisy to wpłynęło i czy użytkownik to zobaczył. Zakładka czasów wskazuje główne źródło opóźnień i automatycznie wyłapuje requesty, które naprawdę były wolne.

Profiling eBPF rozszerza stos bazowy

Rozszerzeniem stosu bazowego jest profiling oparty na eBPF. Jego użycie mocno rośnie w bardzo dużych organizacjach. Monitoring pokazuje dni i godziny, logi i trace’y minuty. Profiling schodzi poniżej 20 milisekund, na przykład gdy deweloperzy analizują wydajność albo gdy coś się wywaliło. Działa w czasie rzeczywistym, tylko na Linuksie, najlepiej na Kubernetesie. Na maszynach wirtualnych też się da, ale nie jest to zalecane, bo nie idzie tak łatwo, jak powinno.

Profiling eBPF a inne systemy APM
Cecha	Profiling eBPF	Inne systemy APM
Narzut wydajnościowy	1–3%	z reguły 5–10%
Włączanie	nic nie trzeba włączać	często trzeba włączyć
Próbkowanie (sampling)	do poziomu wywołań metod	często dużo gorsze
Wiedza aplikacji	aplikacja o nim nie wie	aplikacja musi o nim wiedzieć

Szczegółowy stos wywołań rozumie programista, operator już nie. Przycisk Explain flame graph wysyła dane z flame graphu do modelu językowego, w demo do OpenAI. Model tłumaczy, co się dzieje w danym kawałku kodu, na przykład że się wywala albo zużywa dużo pamięci, i proponuje zmiany na podstawie dobrych praktyk. Odpowiedź nie jest idealna, ale ma dużą wartość: operator nie musi znać kodu, a deweloper, który utrzymuje słabo znany system, dostaje konkretną odpowiedź. Stos nie wiąże Cię z jednym modelem i działa z Anthropic oraz z każdym systemem zgodnym z API OpenAI.

Grafana łączy się z bazami danych

Przy kontrolowanych dostępach bazy można podłączyć do Grafany. Znany scenariusz awarii: baza rzuca wyjątkiem i trzeba szukać DB admina, żeby sprawdził, co się dzieje. Tę funkcję trzeba zbudować i zabezpieczyć. Gdy trace pokazuje wyjątek, bo komenda się nie wykonała, jeden przycisk uruchamia zapytanie w trybie tylko do odczytu na tej bazie. Droga od problemu do odpowiedzi skraca się wtedy do sekund zamiast godzin szukania osoby z uprawnieniami.

Wdrożenie może iść częściami

Zmiany w monitoringu można wdrażać fazami i częściami: zacząć od porządków albo od lepszej widoczności, a potem dokładać kolejne elementy według potrzeb. Rekomendowany wariant jest całościowy: wdrożenie, prawdziwy onboarding i pakiet szkoleń, żeby ludzie wiedzieli, jak wyciągnąć wartość z tego, co powstało.

Grafana współpracuje też z wieloma istniejącymi systemami, w tym z Datadogiem, więc przejście do jednego centralnego miejsca może być płynne. Narzędzia mocno zakorzenione w firmie, jak Zabbix czy ELK, nie muszą znikać, bo Grafana i Prometheus z nimi współpracują. Zmiana idzie ewolucją: celem jest przekonać ludzi wartością, którą widzą, i niczego nie robić na siłę.

Observability dla managera: skąd wiedzieć, że biznes działa

Szymon Warda, Mikołaj Szczerbicki — Wed, 18 Feb 2026 00:00:00 GMT

TL;DR

Jeśli Twoja infrastruktura jest monitorowana, a o awarii i tak dowiadujesz się z telefonu od biznesu, sam monitoring procesora i pamięci nie wystarcza. Observability daje biznesowi, deweloperom i utrzymaniu te same dane o tym, co dzieje się w systemach, więc problem widać wcześniej, a spory rozstrzygają liczby. Z tekstu dowiesz się, kiedy optymalizacja i wyższa dostępność się nie opłacają, co zrobić z drogą platformą vendora i czego wymaga wdrożenie na otwartym standardzie.

Kluczowe wnioski

Monitoring zasobów nie powie, czy biznes działa, a observability pozwala zobaczyć problem, zanim się zacznie, więc zespół wychodzi z trybu strażaka i może sam uprzedzić biznes.
Własne narzędzia w każdym zespole trzeba kupić, poznać i utrzymać, a przy awarii jedni ją widzą, drudzy mogą jej nie widzieć.
Liczby pokazują, dla ilu użytkowników system działa wolno i które maszyny można zmniejszyć, więc wiesz, gdzie wydawać pieniądze, a gdzie przestać.
Przy wysokim rachunku za komercyjną platformę alternatywą jest stos Grafany z OpenTelemetry, który Twój zespół SRE pewnie już zna, choć wdrożenie wymaga zmian po stronie aplikacji.
Najpierw są narzędzia, potem procesy: alerty, wykrywanie anomalii i standardy logowania, które w tle może wdrażać zespół platformowy.
Zamiast pełnej dostępności ustalasz z biznesem mierzalne zobowiązanie i sprawdzasz, które systemy mogą czasem nie działać.

Wersja do czytania

Monitoring widzi zasoby, observability widzi zachowanie systemu

Monitoring to sprawdzanie, czy procesor, pamięć, a może też dysk nie są pełne. Menedżer pyta o coś innego: czy jego biznes działa. Monitoring informuje o awarii albo, jeśli się uda, ostrzega przed nią.

Rozmówcy nieraz słyszą w firmach, że jest tam jakiś monitoring albo observability, a mimo to prawie zawsze trafiają na tę samą sytuację. Biznes dzwoni do menedżera, często dość gniewnie, że system nie działa od pół godziny. Zespół utrzymania sprawdza procesor i RAM, widzi, że są w porządku, i odpowiada, że system chyba działa.

Observability nie jest modną nazwą monitoringu, to coś zupełnie innego. Observability to cel: stan, w którym z danych o systemie da się wywnioskować, jak się zachowuje i co dzieje się w jego wnętrzu. Obejmuje systemy i procesy. Dzięki niej widzisz, że coś się dzieje, a nawet widzisz to, zanim zacznie się dziać.

Logi, metryki i trace’y to kolejne stopnie dojrzałości

Logi ma każdy, lepsze lub gorsze. Zdarza się, że deweloperzy logują się na maszyny i czytają przewijające się logi jak w Matriksie. To umiejętność, ale w większej skali niekoniecznie przydatna.

Metryki dają realne liczby i można ich zbierać naprawdę dużo. Trace to zapis tego, jak cały proces biznesowy przepływa przez serwisy i mikroserwisy w organizacji. Trace’y pokazują, która komunikacja działa, a która nie, jakie ma opóźnienia, gdzie się wywala i jaki jest rozkład czasu odpowiedzi. Dzięki nim wiesz, gdzie warto inwestować czas w optymalizację.

Zespół w trybie strażaka nie realizuje planu

Zespół, który reaguje na awarie, działa w trybie strażaka. Musi tu i teraz szybko przywrócić system do działania, z reguły kosztem jakości. Problem wraca, bo zespół robi to, co trzeba na już, a potem zwykle nie ma czasu naprawić go poprawnie.

W takim trybie nie da się nic zaplanować. Zespół zapowiada coś na kwartał, kwartał mija, a praca nawet się nie zaczęła. Robił dużo, ale nie były to wartościowe rzeczy.

Dzięki observability zespół inwestuje w procesy utrzymaniowe, ma więcej zaplanowanego czasu, a awarii jest po prostu mniej. Zostaje czas, żeby pokazać deweloperom, że coś działa wolno, coś jest źle wykorzystane albo wydajność aplikacji jest zła.

Schemat: tryb strażaka i praca z observability

Gdy zespół wie, że awaria nadchodzi, sam dzwoni do biznesu: coś dzieje się z systemem, pracujemy nad tym. Nawet przy poważnej awarii to zupełnie inna sytuacja niż gniewny telefon od biznesu.

Osobne narzędzia w każdym zespole to dodatkowy koszt

Administratorzy, deweloperzy, opsi i zespoły SRE pracują na swoich kawałkach systemu. Każdy patrzy w swoje i każdy mówi, że jest dobrze. Przy awarii DevOps siada z deweloperem, każdy ma swoją prawdę i nie potrafią się dogadać. Jedni widzą awarię, drudzy mogą jej nie widzieć.

Każdy zespół ma własne narzędzia. Trzeba za nie zapłacić, ludzie muszą się ich nauczyć, trzeba je utrzymać. Deweloperom lokalny debugger już nie wystarcza: w ostatnich latach chcą widzieć, jak system realnie się zachowuje, i mieć liczby. Jeśli sami utrzymują swoje narzędzia, tracą na to czas, a wytwarzanie i wdrażanie oprogramowania zwalnia.

Kierunek to centralizacja. Gdy narzędzia są zunifikowane, wytwarzanie, utrzymanie i monitorowanie posługują się tymi samymi liczbami, czyli jednym językiem. Mało kto będzie się spierać o liczby, które organizacja sama zbiera.

Liczby pokazują, co optymalizować i gdzie zmniejszyć maszyny

Dobry poziom observability pozwala mówić o tym, co się dzieje, a nie o odczuciach, bo każdą sytuację opisują dashboardy i liczby. Menedżer dostaje argument w dyskusji z każdym zespołem.

W dużej organizacji ktoś zawsze będzie narzekał, że system działa wolno. Z liczbami widać, dla ilu osób działa wolno, na przykład dla 2% użytkowników. Wtedy decydujesz, czy warto wydawać pieniądze, żeby ten wynik poprawić. Szymon Warda: „Nie wszystkie systemy opłaca się optymalizować do granicy możliwości.”

Liczby porządkują też decyzje o infrastrukturze. Dla nowego systemu zespół zamawia 20 CPU i 100 GB RAM-u, a potem okazuje się, że korzysta z 50% tych zasobów. Gdy wykresy z miesiąca pokazują, że procesor, pamięć i dysk nie przekraczają pewnej wartości, wniosek brzmi: użyjmy mniejszych maszyn. To bardzo duże oszczędności, a im więcej infrastruktury, tym łatwiej je uzyskać.

Komercyjne platformy observability to znaczący koszt

System observability od vendora kosztuje 5–6 cyfr w dolarach rocznie. Dla średniego zespołu to dość znaczący koszt, a kwota zależy od wielkości organizacji.

Duży klient z sektora finansowego (nazwa nie pada) płaci jednemu z wielkich dostawców rachunek, który ma już 7 i 8 cyfr w dolarach rocznie. Klient zobaczył możliwości platformy, którą rekomenduje Protopia, i rozważa odejście od tego dostawcy. Kilka lat temu publikacje rynkowe opisywały organizacje, które płaciły za systemy observability 15 i 50 milionów dolarów rocznie.

Stos Grafany jest rynkowym standardem

Platforma, którą rekomenduje Protopia, opiera się na stosie Grafany i natywnie integruje się z Kubernetesem. Gdy zaproponujesz ją deweloperom, pewnie odpowiedzą, że ją znają. Twój zespół SRE wie, o jaki system chodzi, bo z niego korzysta. Jeśli poszukasz, znajdziesz go w swojej organizacji, tylko pewnie gorzej utrzymany i niewpięty w procesy.

Te systemy są standardem rynkowym w Kubernetesie i u gigantów chmurowych, czyli hyperskalerów. Narzędzia open source z tego stosu bardzo dobrze się skalują, są opłacalne i łatwe w utrzymaniu. Nie opierasz się na zamkniętym narzędziu, więc korzystasz z wiedzy ogromnej grupy użytkowników, a część dobrych praktyk wdrażasz gotowymi elementami rozwijanymi w ekosystemie. Open source ma też swoje kłopoty.

Wdrożenie wymaga pracy po stronie aplikacji

Observability wymaga pewnej pracy i zmian po stronie aplikacji, choć te zmiany są coraz mniejsze. Im więcej zespół zrobi, tym więcej wartości dostanie, a to praca długofalowa. Warto to zrobić raz a dobrze, bo OpenTelemetry stał się standardem w observability. Korzystają z niego także duzi vendorzy, żeby integrować się z aplikacjami.

Nie jest tak, że wszystko zadziała samo. Jeden z klientów włączył na swoim klastrze automatyczne observability z bardzo znanego rozwiązania i cały system się złożył. Mechanizm wpinał się w miejsce, w które nie powinien, i system natychmiast przestał działać. Ustalenie przyczyny zajęło dwa dni. Tak często działają rozwiązania „magiczne”: obiecują zbyt dużo i potem często nie dowożą, bo nie mogą.

Celem jest biznes, który działa przewidywalnie. Nie chcesz sytuacji, w której podbijasz wersję systemu utrzymaniowego i Twojego biznesu nie ma przez cały dzień, a nikt nie wie dlaczego. Szymon Warda: „Doskonale wiemy, że wdrożenie każdego systemu kosztuje.”

Alerty mogą uprzedzić o awarii, wykresy pokazują ją po fakcie

Spadający wykres pokazuje awarię, która już się wydarzyła. W organizacjach zdarzają się 4, 5, 6 i więcej monitorów z ładnymi wykresami. Wyglądają jak choinka na pokaz, a nikt z nich nie korzysta.

Alerty pozwalają działać wcześniej: mogą powiadomić, że coś wydarzy się za dzień, za dwa albo za jakiś czas. Observability obejmuje też zmianę nawyków organizacji. Kolejność jest taka: najpierw część techniczna daje możliwości, potem zespół wdraża procesy, na przykład alerting i wykrywanie anomalii, czyli sygnałów, że coś zaczyna się psuć.

Systemy produkują czasem dziesiątki tysięcy metryk, więc trzeba umieć je odsiać. Bez tego to picie z hydrantu, przy którym można stracić zęby.

Deweloperzy widzą, jak ich kod działa na produkcji

Jedno zunifikowane narzędzie umożliwia shift left: deweloperzy widzą, jak system zachowuje się na produkcji. Znika tłumaczenie, że na maszynie dewelopera działa, bo są liczby z produkcji, łącznie z wykonywanymi zapytaniami SQL. Dane pokazują, że trzeba coś poprawić albo że jest dobrze i dalsza praca nad wydajnością nie ma sensu, bo system działa tam bardzo dobrze.

Pętla zwrotna się skraca. Zespół wdraża nową wersję i dzień później widzi, czy działa, nie działa albo działa wolno, zamiast dowiadywać się o tym po kwartale. Pomiar pokazuje, czy nowa wersja jest lepsza, czy gorsza, więc zespół dużo szybciej wykrywa regresję i wie dokładnie, co się wydarzyło.

Schemat: pętla zwrotna z liczbami z produkcji

W systemach krytycznych, tam gdzie to ma sens, można wdrożyć nową wersję częściowo i obserwować, jak zachowuje się ruch. Takie wdrożenia nie opłacają się wszędzie.

SLA, SLO i SLI określają, do czego zespół się zobowiązuje

Bez liczb nie zmierzysz, czy inwestycja w poprawę wskaźnika przynosi wartość. Z liczbami można ustalić wskaźniki SLA, SLO i SLI, czyli poziom utrzymania, do którego zespół się zobowiązuje.

Zdarzają się firmy, które mówią, że muszą mieć 100% uptime’u. To nierealne. Żartobliwie mówiąc, każda kolejna dziewiątka po przecinku to kolejne zero przed przecinkiem w kosztach, czasem nawet więcej, czasem nie.

Przy takim zobowiązaniu da się zmierzyć, czy kontrakt z biznesem jest spełniony. Potencjalne awarie i przerwy utrzymaniowe można przełożyć na realne finanse organizacji. Czasem wychodzi, że niektóre systemy mogą bez problemu nie działać w pewnym przedziale czasu, a inne są bardziej krytyczne.

Te same pomiary usuwają tarcia między zespołami deweloperskimi, które tłumaczą, że ich system nie działa, bo nie działa inny. Zespół zobowiązuje się, że jego system działa w ustalonym SLA, a development przestaje być narzekaniem, że komuś coś nie działa.

Standardy wdraża zespół platformowy w tle

Organizacja nie musi przed startem sama ustalać, co i jak monitorować. Są uniwersalne standardy i dobre praktyki, które trzeba wdrożyć, zamiast wymyślać koło na nowo. Każda organizacja jest w pewnym stopniu inna, więc standardy trzeba dostosować.

Jeśli masz zespół platformowy, wdraża on w tle kolejne standardy: jak logować, jakie metryki zbierać, jakie poziomy błędów raportować i co ma się znaleźć w logach. Gdy weszło RODO, zespoły miały dużo pracy z usuwaniem z logów imion, nazwisk i danych identyfikujących użytkowników. To był jednorazowy wysiłek, a teraz te zasady trafiają do standardu.

Deweloperzy nie muszą o tym myśleć: nowy system dostaje ustalone elementy oraz biblioteki i raportuje w ustalony sposób. Odpada kosztowny kawałek wytwarzania systemu. Standard jest aktualny i ogólnorynkowy.

Dane z systemów legacy, nowych, rozwijanych i zewnętrznych można zebrać do jednej rury i raportować w zunifikowany sposób. Zamiast kawałków w różnych narzędziach widać całą organizację i wiadomo, co, gdzie i jak się zachowuje.

Schemat: dane ze wszystkich systemów w jednej rurze

Fabryka agentów AI: wspólna platforma w dużej organizacji

Łukasz Kałużny, Marek Grabarz — Wed, 04 Feb 2026 00:00:00 GMT

TL;DR

Jeśli w Twojej firmie ma powstawać coraz więcej agentów AI, musisz zdecydować, czy każdego budujesz osobno, czy stawiasz wspólną platformę. Fabryka agentów to taka platforma na Azure AI Foundry, API Management i Logic Apps: osobne środowiska do eksperymentów, testów i produkcji, bezpieczeństwo zatwierdzone raz i integracje, które podpina się raz i udostępnia kolejnym agentom. Zespół z zaakceptowanym pomysłem szybko dostaje zabezpieczone środowisko.

Kluczowe wnioski

Gdy strategia firmy zakłada coraz więcej agentów i API, wspólna platforma jest prawdopodobnie jedynym sensownym kierunkiem, a pierwszego agenta dla zarządu da się pewnie zbudować bez niej.
AI Sandbox jest ustandaryzowanym, zabezpieczonym miejscem na sprawdzenie hipotezy biznesowej, a agent przechodzi z niego przez środowisko przedprodukcyjne na produkcję; wdraża się go z repozytorium Git przez CI/CD jak zwykłe oprogramowanie.
W wariancie enterprise'owym dane wątków leżą w zasobach we własnej subskrypcji organizacji, szyfrowanych jej kluczami.
API Management wystawia systemy firmy agentom na jednej fasadzie, z opisem zrozumiałym dla modelu, więc nie trzeba pisać własnych bramek MCP ani zmieniać systemów źródłowych.
Gdy proces jest naprawdę deterministyczny, Logic Apps bardzo często okazuje się bardziej przewidywalny niż własny kod czy agenci, a agent wchodzi tam, gdzie potrzebna jest analiza generatywna.
Pracę nad platformą zaczyna warsztat, na którym z przypadków biznesowych klienta wybiera się te, które dobrze do niej pasują.

Wersja do czytania

Platforma ma sens, gdy agentów i API będzie przybywać

Jeśli strategia firmy przewiduje coraz więcej agentów i coraz więcej API, wspólna platforma jest prawdopodobnie jedynym sensownym kierunkiem. Pierwszego agenta, który ma pokazać zarządowi krótkoterminowy sukces, da się pewnie zbudować w parę tygodni.

Fabryka agentów oznacza tu wdrożenie w dużej organizacji, także w takiej, którą ograniczają regulacje.

Zespół nie stawia za każdym razem całej infrastruktury, więc szybciej zaczyna korzystać z agentów w ustandaryzowany sposób. Raz zaakceptowana platforma zwalnia z otwierania ruchu sieciowego i ponownej certyfikacji środowiska przy każdym przypadku biznesowym. Bezpieczeństwo i spójność, na przykład logi, rozwiązuje się raz.

Wspólna platforma skupia też wiedzę w jednym miejscu. U kilku klientów zespoły testują agentów zamiast kolejnych frameworków open source, których wciąż przybywa i które zmieniają sposób działania.

Agent przechodzi przez trzy środowiska

Platforma ma trzy środowiska: AI Sandbox, środowisko przedprodukcyjne i produkcję. AI Sandbox to miejsce bezpiecznych eksperymentów i innowacji. W wielu firmach sandbox oznacza wolną amerykankę, w której użytkownik robi, co chce. Tutaj jest to zabezpieczone, współdzielone środowisko, ustandaryzowane i podlegające zasadom korporacyjnym, być może z dostępem do danych produkcyjnych. Na danych anonimowych i sztucznych trudno budować agentów i AI w ogóle.

W sandboxie zespół sprawdza proof of value. Proof of value to test hipotezy biznesowej: czy scenariusz ruszy na agentach i będzie działał. Tworzenie i testowanie kodu schodzi na dalszy plan.

Scenariusz, który się sprawdzi, przechodzi z produkcyjnym cyklem życia do środowiska przedprodukcyjnego. Tam zespół sprawdza, czy wszystkie wdrożenia i integracje działają, a agent jest w pełni zintegrowany i gotowy do produkcji.

Każde środowisko składa się z czterech elementów: kanałów dostępowych, środowiska uruchomieniowego agenta, części integracyjnej i części utrzymaniowo-operacyjnej, o której łatwo zapomnieć.

Schemat: elementy jednego środowiska fabryki agentów

Kanał dostępu jest oddzielony od agenta

Agent nie zależy od tego, jak się do niego dostajesz. Może być osobnym bytem, częścią aplikacji mobilnej, czatem na stronie albo procesem w tle. Platforma pozwala wywołać agenta w dowolny sposób, a samo wywołanie jest zewnętrzną integracją:

synchronicznie z systemu biznesowego, na przykład przyciskiem „wygeneruj mi raport”;
asynchronicznie przez zdarzenie, na przykład komunikat, kolejkę albo e-mail na sprawdzanej skrzynce;
przez czat na stronie, w Teams lub w innej aplikacji.

Sposób wywołania zostaje poza platformą, żeby nie narzucać rozwiązania. Proof of value może pokazać, że agenta trzeba wywoływać zupełnie inaczej. Wtedy niczego się nie przepina ani nie przebudowuje.

Jeden z ostatnich przypadków u klientów to analiza wyników finansowych kontrahenta. W testach analityk wkleja wyniki w okno czatu i sprawdza, czy agent odpowiada zgodnie z oczekiwaniami. Docelowo w systemie jest przycisk „Dokonaj mi analizy”, który uruchamia agenta. Agent synchronicznie odpytuje backendy i API, zbiera i analizuje dane, a zwraca tylko wynik końcowy.

Agenci działają w projektach Azure AI Foundry

Środowiskiem uruchomieniowym agentów jest Azure AI Foundry w ekosystemie Microsoftu.

Jednostką pracy w AI Foundry jest projekt, czyli odpowiednik inicjatywy. Technicznie przypomina namespace w Kubernetesie: jest jeden duży klaster, a zespół lub projekt dostaje swój namespace. W Azure podobną rolę pełnią grupy zasobów. Jeden projekt może mieć wielu agentów budowanych przez jeden zespół, a agenci w projekcie mogą się ze sobą komunikować.

Projekt korzysta z modeli z określonej listy: OpenAI oraz wspieranych modeli open source z marketplace, bez modeli konkurencji. Protopia pracuje z klientami zazwyczaj na OpenAI, to jest 99%.

Małych agentów łączy agent orkiestrator

Ze względu na to, jak działają modele językowe, Protopia zazwyczaj buduje małych agentów, każdego do konkretnego zadania albo fragmentu procesu biznesowego. Nad nimi działa agent orkiestrator, który wywołuje mniejszych agentów. Orkiestrator może dostać droższy model z reasoningiem, a mali agenci tańszy model, na przykład GPT-4o mini.

W większości przypadków Protopia nie puszcza procesu przez łańcuch całkowicie niezależnych agentów. Korzysta ze scenariusza connected agents: centralny agent plus mali agenci, a kroki są orkiestrowane świadomie. W AI Foundry dosłownie wskazujesz, który agent łączy się z którym.

Schemat: agent orkiestrator i mali agenci w jednym projekcie

Wątek to konwersacja agenta w jednej sprawie. Handoff to chwilowe przekazanie wątku innemu agentowi: agent czeka na odpowiedź i przetwarza dalej.

A2A (agent to agent) to protokół open source do komunikacji między agentami, zainicjowany przez Google. Jest dostępny w AI Foundry, ale nie warto się do niego mocno przywiązywać, bo agenci zazwyczaj łączą się w obrębie jednego projektu.

W wariancie enterprise’owym dane wątków zostają w Twojej subskrypcji

Historia wątków pozwala później wznowić wątek asynchroniczny i zebrać z niego wyniki. W wariancie mniej enterprise’owym usługa trzyma te dane u siebie. W wariancie enterprise’owym, który Protopia zazwyczaj wdraża, dane trafiają do osobnych usług, które trzeba wdrożyć:

storage na pliki;
Cosmos DB na konwersacje i dane agentów;
Search z indeksami odwróconymi i bazą wektorową do wyszukiwania tekstowego lub semantycznego w tekstach, dokumentach i załącznikach, czyli podstawa RAG.

Bring your own resources to model, w którym organizacja dokłada storage, Cosmos DB i Search we własnej subskrypcji. Widzisz je i masz nad nimi kontrolę. Zasoby wdraża się prawie w całości na zasadach organizacji, więc można je dostosować do jej wewnętrznych wymagań regulacyjnych, na przykład bezpiecznej komunikacji i niezależnych logów.

Historia konwersacji może zawierać dane wrażliwe i chronione, na przykład w branży medycznej, farmaceutycznej czy bankowej. Dlatego zasoby szyfruje się kluczami organizacji (CMK), zgodnie z regulacjami, które organizacja wypracowała.

API Management jest centralnym punktem integracji

W tej architekturze API Management jest sercem platformy, bo agent bez API jest zwykłym czatem. Wystawia API organizacji spójnie, na jednej fasadzie, tak żeby agenci łatwo je konsumowali.

System biznesowy podpięty raz przez API jest dostępny dla każdego agenta, którego z nim połączysz. Agent nie dostaje od razu dostępu do wszystkiego: uwierzytelnianie i autoryzacja określają, z którym API rozmawia dany agent.

API musi być wystawione inaczej niż system backendowy. Systemy dostarczone z zewnątrz albo przez wewnętrzny dział często są słabo opisane. Agent nie wie z pamięci, co robi dana metoda, a sam opis metody tego nie gwarantuje. Dlatego w API Management dopisuje się opis zrozumiały dla agenta, żeby wiedział, który endpoint rozwiązuje jego problem. Działa to i dla OpenAPI Schema, i dla MCP (Model Context Protocol): każde API, wywołanie i spodziewaną odpowiedź opisuje się językiem naturalnym dostosowanym do modelu.

Opis pisze czat z system promptem, który mówi mu, że tekst ma służyć jemu samemu. Ludzka dokumentacja zamienia się w dokumentację maszynowo-tłumaczoną.

API Management tłumaczy też w locie, na przykład wystawia API SOAP jako REST. Dzięki API Management nie trzeba pisać własnej bramki MCP do systemu ani, co gorsze, modyfikować systemu źródłowego, żeby wystawiał endpointy dla agentów. Taka praca programistyczna potrafi być bardzo kosztowna i często nieprzewidywalna w czasie.

W API Management są dwie nowe możliwości. Dowolne istniejące API, z którego korzystają też systemy spoza świata agentów, można praktycznie jednym przełącznikiem przekształcić w MCP. Od niedawna można też przenieść na fasadę zewnętrzne MCP: cudze albo takie, które ktoś w firmie zbudował od razu jako MCP, bez API. Organizacja kontroluje je jak własne, z dodatkowymi zabezpieczeniami, politykami i orkiestracją.

Logic Apps obsługuje kroki, które da się przewidzieć

Jeśli scenariusz jest naprawdę deterministyczny, czyli znasz proces i wiesz, jak go podpiąć, Logic Apps bardzo często okazuje się bardziej precyzyjny i przewidywalny, a przy tym prostszy w budowie niż własny kod czy agenci.

Często zostają wąsko wyspecjalizowane, niskopoziomowe API i API Management, który je wystawia, a brakuje kleju do orkiestracji, na przykład: wywołaj API, odbierz odpowiedź, wyślij trzy e-maile albo SMS, poczekaj na zgodę i potwierdź na innym endpoincie. W tej architekturze klejem jest Logic Apps, narzędzie no-code Microsoftu, którym można też zarządzać z kodu. Logic Apps razem z API Management to iPaaS (Integration PaaS).

Przepływ w Logic Apps można wyklikać jak w Power Apps, ale konektorów systemowych i biznesowych jest więcej: do Oracle, SAP, CRM czy Salesforce. Przepływ może też wywołać API w API Management albo agenta. Gotowych integracji i akcji są, z grubsza, setki. Control flow obejmuje warunki (IF), pętle (FOR), obsługę błędów i wznawianie integracji.

Model OpenAI jest, w uproszczeniu, niedeterministyczny. Agent wchodzi dopiero tam, gdzie potrzebna jest analiza generatywna, wytworzenie czegoś nowego albo łączenie faktów w locie.

W niektórych scenariuszach punktem wejścia jest workflow w Logic Apps. Marek Grabarz: „to nie agent odpala workflow, tylko workflow woła agenta.” Na podstawie wyniku agenta workflow robi dalej coś przewidywalnego. Kanałem dostępowym jest wtedy integracja w iPaaS.

Agenta wdraża się jak kod

Agent jest takim samym kawałkiem oprogramowania jak każdy inny, więc część utrzymaniowo-operacyjna opiera się na podejściu DevOps. Specjalnych zasad nie ma, zmieniają się tylko niektóre detale techniczne.

Agenci są w repozytorium Git: GitHub, Bitbucket, GitLab lub innym, które organizacja już ma. Przygotowane skrypty CI/CD wdrażają agentów na kolejne środowiska.

Plik agenta w repozytorium zawiera definicję agenta z system promptem oraz podłączone integracje i innych agentów. Można go traktować jak manifest infrastructure as code. W tym przypadku są to skrypty w Pythonie, więc plik jest też definicją agenta w kodzie Pythona. Gdy platforma już działa, wdrożenie często sprowadza się do kopiuj-wklej albo pomocy GitHub Copilota czy innego agenta do kodowania.

Schemat: agent z repozytorium Git na kolejne środowiska

Observability pokazuje przebieg każdego wątku

Gdy w agencie coś pójdzie źle albo ktoś zgłosi, że dostał złą odpowiedź, zespół sprawdza wątek. AI Foundry przechowuje w bazie pełne wątki konwersacji każdego agenta, dopóki ich nie usuniesz: wejście, wszystkie wywołane narzędzia, treść żądań do innych systemów, integracji i agentów oraz odpowiedzi. Wątek jest stanowy. W Azure AI Foundry Studio możesz go znaleźć, wrócić do niego, obejrzeć w playgroundzie i sprawdzić, co się stało.

Observability włącza się w projekcie prawie bez pracy wdrożeniowej. Application Insights, klasyczny APM Microsoftu, śledzi cykl życia agenta: pytania, odpowiedzi i wywołania, w całym wątku konwersacji z czatu albo w wątku wywołania z innego systemu.

AI Foundry ma też obszar oceny jakości: inny model ocenia, czy cały przepływ przebiegł dobrze. Zaczynają się pojawiać metryki ewaluacji odpowiedzi, ale rynek dopiero tu raczkuje, bo niedeterministyczną rzecz mierzy kolejna niedeterministyczna rzecz.

Content filtering działa od początku i chroni przed tym, że użytkownicy wrzucą do agenta coś groźnego. Organizacja reguluje, na jakie treści pozwala. Niektóre firmy mogą chcieć poluzować filtry, na przykład w e-commerce z treściami dla dorosłych.

Miarą platformy jest użycie i liczba skarg

Pierwszą miarą platformy i przypadków agentowych jest to, czy po wdrożeniu ktoś z nich korzysta.

Druga metryka dotyczy każdego agenta osobno: ile jest skarg i zgłoszeń błędów, na przykład na jakość odpowiedzi, w stosunku do liczby użyć. Dobry wynik to użycie, które nie spada, i brak skarg na jakość.

Pracę zaczyna warsztat, a sandbox ma być dostępny następnego dnia roboczego

Zanim zacznie się praca nad platformą, Protopia stara się zorganizować warsztat. Klient przygotowuje na niego przypadki biznesowe. Zaproszeni są architekci biznesowi, niekoniecznie osoby od utrzymania, bo to jeszcze nie ten etap. Na warsztacie zespół wskazuje przypadki, które dobrze pasują do platformy i dobrze się zintegrują. Przy 5, 10 czy 15 takich przykładach zachęta do budowy platformy jest dużo większa. Łukasz Kałużny: „to istotny element, żeby nie budować platformy dla samej platformy.”

Gdy inicjatywa zostanie zaakceptowana do testów w AI Sandbox, zespół powinien mieć dostęp następnego dnia roboczego. Zespół utrzymujący platformę może na przykład udostępnić takie środowisko w kilkanaście minut. Self-service jest możliwy, ale nie jest tu założeniem. Czas liczy się od akceptacji i nie obejmuje procesów organizacyjnych firmy.

API Management w PZU: wspólna brama do systemów i plan dla agentów AI

Marek Grabarz — Wed, 07 Jan 2026 00:00:00 GMT

TL;DR

Jeśli integracje w Twojej firmie wciąż stoją na platformie SOA, a część API omija platformę integracyjną, możesz przejść na wspólną bramę API tak jak PZU i zostawić przepływ danych we własnej infrastrukturze. W PZU jest nią Azure API Management, a developerzy sami publikują przez niego swoje API. Ten sam portfel API ma teraz obsłużyć agentów AI, a bez bramy chmurowej trudno będzie im coś atrakcyjnego zaoferować.

Kluczowe wnioski

API Management wszedł do PZU jako fasada do nowej platformy integracyjnej i silnika procesów, żeby firma mogła gładko wyjść z platformy SOA i zebrać API w jednym portfelu.
Self-hosted gateway pozwolił korzystać z usługi chmurowej, a przepływ danych zostawił po stronie PZU. To ułatwiło wdrożenie w branży regulowanej.
Wspólne polityki bramy dają zespołom zabezpieczenia, observability i zapis danych na potrzeby rozliczalności, więc aplikacje nie budują tego same.
Zespół integracji utrzymuje platformę i standardy, a developerzy publikują API samodzielnie i dostają większe uprawnienia dopiero wtedy, gdy pokażą współodpowiedzialność.
Powstają standardy, które mają wychwytywać odstępstwa od dobrych praktyk już przy wytwarzaniu API, z myślą o automatyzacji i agentach AI.
AI Gateway działa w bramie chmurowej. Bez niego i bez wsparcia MCP agentom trudno korzystać z API PZU, dlatego firma przyspiesza uruchomienie tej bramy.

Wersja do czytania

API Management miał pomóc PZU wyjść z platformy SOA

Azure API Management był jednym z elementów strategii, którą PZU opracowało na przełomie 2021/2022, żeby przekształcić obszar integracji. Nie wdrażało go z myślą o agentach AI. Przed nim zbudowało wewnętrzną platformę hybrydową typu iPaaS i wdrożyło nowy silnik procesów biznesowych. Brakowało jednego komponentu: fasady, przez którą da się dostać do tych narzędzi. W PZU nazywa się ją „lekkim proxy”. Strategia miała pozwolić gładko wyjść z platformy SOA, a połączone wymagania dały przepis na API Management.

Dziś API Management stoi na wejściu, a platforma integracyjna działa między nim a backendami. Platforma SOA, z epoki takich produktów jak BizTalk, była wcześniej główną architekturą integracji. Jej potencjał powoli się jednak kończy.

Krzysztof Radzimowski, Product Delivery obszaru integracji w PZU: „Potrzebujemy czegoś o wiele bardziej elastycznego. Czegoś, co pozwala nam dopasowywać siebie do biznesu, a nie odwrotnie.”

Ważnym celem było też przyciągnięcie API, które wtedy omijały platformę integracyjną. Część z nich omija ją do dziś. PZU chciało ściągnąć na platformę te API i zespoły wytwórcze, żeby uzyskać efekt skali i zbudować bardzo atrakcyjny portfel API. To był główny motywator i na tym PZU nadal zależy najbardziej: z portfela mają powstawać kolejne rozwiązania, automatyzacja i agentyzacja. Inteligentna orkiestracja API wymaga, żeby ciekawych i potrzebnych API było jak najwięcej.

Self-hosted gateway zostawił przepływ danych po stronie PZU

PZU działa w branży regulowanej, a API Management jest usługą chmurową. Przy wcześniejszych wymaganiach regulacyjnych wobec chmury PZU miało szereg wątpliwości i obaw. Rozwiązaniem był self-hosted gateway, czyli architektura hybrydowa: usługa jest chmurowa, ale przepływ danych zostaje on-premises, po stronie PZU. To ułatwiło wdrożenie platformy. PZU wdrażało API Management wspólnie z Protopią.

Schemat: usługa w chmurze, przepływ danych po stronie PZU

Dziś PZU boi się chmury trochę mniej. W tym czasie wykonało bardzo dużo pracy, żeby dostosować się do nowych wymogów regulacyjnych. API Management nie jest już jego jedynym rozwiązaniem chmurowym, bo PZU bardzo odważnie weszło w chmurę. Przy innych rozwiązaniach spełniło już zalecenia regulacyjne, a zespół integracji może z tego korzystać. Dlatego PZU z większym spokojem przygotowuje uruchomienie bramy w chmurze, której dotąd nie używało.

Biznes i partnerzy traktują API jako naturalny sposób integracji

Głównym klientem zespołu integracji jest biznes, który reprezentuje klienta zewnętrznego: likwidacja szkód, sprzedaż polis, a także back office. Back office obsługuje zgłoszenia klientów i musi sięgać do danych na zewnątrz. Biznes w dużej mierze nauczył się korzystać z API i traktuje je jako naturalny sposób komunikacji. Dla partnerów PZU i startupów, które oferują PZU swoje rozwiązania, API też jest punktem wejścia.

PZU raczej nie wystawia API dostępnych dla wszystkich. Przeważa model B2B: firma zewnętrzna uzgadnia, jakie informacje zostaną jej udostępnione. Wewnętrzny partner biznesowy przychodzi z potrzebą współpracy z jakimś podmiotem i zgłasza się do zespołu integracji. Zespół mu tę współpracę ułatwia, a czasami w ogóle umożliwia.

Ruch idzie w dwie strony. PZU udostępnia podmiotowi zewnętrznemu funkcje systemu sprzedażowego, polisowego albo likwidacyjnego. Może też pozyskać usługi zewnętrzne, które często usprawniają na przykład likwidację szkód, i użyć ich w procesach wewnętrznych.

Porównywarka ubezpieczeń dostaje wycenę przez API Management

Jedna z popularnych porównywarek ubezpieczeń wysyła przez API parametry polisy, dostaje wycenę i porównuje ją z innymi ofertami. PZU zrobiło tę integrację z myślą o kliencie zewnętrznym. W tym kanale udostępnia API systemu polisowego, a cały proces przechodzi przez API Management. Za zabezpieczenie tego API odpowiada zespół integracji.

Brama pozwala też na testy porównawcze: część zapytań może trafiać do API, a część do innego systemu, żeby porównać ich działanie. Reguły w API Management mogą przekierować klienta na infolinię, jeśli system nie odpowiada wystarczająco szybko, choć w porównywarce niekoniecznie.

Rozliczalność dla rejestrów państwowych zapewniają polityki bramy

Drugi przykład to dane z rejestrów państwowych, które PZU pobiera z zewnątrz. Rozliczalność to możliwość udokumentowania na żądanie instytucji, która udostępnia dane, kto i kiedy o nie pytał oraz jakie dane dostał. Biznes, który korzysta z rejestrów, musi ją zapewnić. API Management i tak ma te dane, więc odkłada je do osobnych baz, z których można je później wyciągnąć. Biznes nie musi ich gromadzić sam.

PZU stosuje ten wzorzec do dziś na platformie SOA i przeniosło go do API Management. Odpowiedź z systemu rejestru, który wymaga rozliczalności, można zapisywać punktowo dla wybranych operacji, a w razie potrzeby nawet dla pojedynczych wywołań. Ta logika siedzi w politykach i w samym API. Rozliczalność jest jednym z wymagań regulatora, z którymi obszar integracji mierzy się od kilkunastu lat.

Klient API nie zawsze musi się tym martwić, bo robi to współdzielona platforma. Przy integracji bezpośrednio z API każda wywołująca aplikacja albo każde API potrzebowałoby własnej logiki odkładania danych.

Developer dostaje zabezpieczenia i observability z pudełka

System, który korzysta z API, ma mieć bardzo prostą metodę autoryzacji dostępu i przedstawienia się platformie. Backendy mogą mieć własne metody, na przykład klucz albo certyfikat, bo wymyślali je wewnętrzni developerzy, zewnętrzni albo dostawca. API Management uwierzytelnia się do każdego systemu w odpowiedni sposób. Wywołujący łączą się z bramą w jeden, ustandaryzowany sposób.

Schemat: jedno wejście, wspólne polityki, różne backendy

Warstwa zabezpieczeń i rozliczalności nie wystarcza, żeby przyciągnąć developerów systemów dziedzinowych. Dlatego PZU daje im też observability zbudowane na platformie, z pudełka. Developer tylko publikuje API albo się do niego podłącza. Resztę, w tym security we wbudowanych politykach, bierze na siebie zespół integracji.

Developerzy sami publikują API, a zespół integracji utrzymuje platformę

W PZU developerzy mają dostęp do środowiska i sami konfigurują swoje API. Zespół integracji ma dwie role. Jest centrum kompetencji (Center of Excellence), które daje know-how i model governance. Jest też właścicielem platformy: utrzymuje ją, odpowiada za jej stabilność i wprowadza niezbędny poziom standaryzacji i uprawnień.

Wysoki stopień samoobsługi był celem wdrożenia i dziś działa. Developer, który chce opublikować API, definiuje je w środowisku developerskim i może je wyklikać. Wkrótce zrobi to prościej, bezpośrednio ze swojego kodu. Developer ma pracować z API Management jak z modułem własnej aplikacji, bez wchodzenia w niuanse. Służą temu ułatwienia oparte na Management API do API Management, które mają pozwolić developerom obsłużyć się samodzielnie.

Szereg zespołów developerskich wystawia już API i coraz śmielej korzysta z repozytorium kodu zespołu integracji. Zanim ktoś dostanie więcej uprawnień do platformy, musi się nauczyć pracy z nią i pokazać, że jest za nią współodpowiedzialny. Na środowiskach nieprodukcyjnych jest dziś szacunkowo ponad 50 API, raczej bliżej 100.

Zespół integracji wymusza jeden ukryty standard i porządkuje API w API Center

Prawdopodobnie jedyny standard, o którym developer może nie wiedzieć, a który jest wdrożony, to polityki zasilające narzędzia observability danymi potrzebnymi do diagnostyki. Developerzy czasami nie są przyzwyczajeni do spełniania cudzych zaleceń, więc zespół integracji go wymusza. Standard jest dobrze udokumentowany i developerzy wiedzą, czego się spodziewać w API Management. Klasycznego hardeningu, na przykład usuwania nagłówków, PZU dziś nie robi, chyba że ktoś o to poprosi. API służą przede wszystkim wewnętrznie.

Równolegle zespół dużo pracuje nad standardami, które mają wychwytywać odstępstwa od przyjętych dobrych praktyk już na etapie wytwarzania. API, które trafia na środowiska nieprodukcyjne, a potem na produkcję, ma być dzięki temu znacznie dojrzalsze. Powodem są automatyzacja, agentyzacja i AI.

Krzysztof Radzimowski: „To my musimy mieć takie standardy, które umożliwią w sposób bezpośredni, bez dodatkowych jakichś narzędzi, zrozumienie tego, co to API robi chociażby właśnie dla mechanizmów AI.”

PZU używa Azure API Center, na razie powoli. Usługa działa właściwie z pudełka, ale wiele funkcji ma dopiero w roadmapie. Automatycznie czyta dane, które są już w API Management, i pozwala porządkować API, których w API Management jeszcze nie ma. Działa jak przedsionek do całego zasobu API PZU. PZU widzi, jak mocno Microsoft zmienia API Management i API Center, i jest dobrej myśli, że API Center będzie dość dynamicznie dojrzewać.

Bez bramy chmurowej PZU trudno obsłużyć agentów AI

PZU bardzo mocno inwestuje w wykorzystanie modeli agentów AI i wchodzi w narzędzia AI coraz śmielej, tak jak w chmurę. Zespół integracji chce być w projektach, które korzystają z komponentów AI. API Management oferuje tu AI Gateway i wsparcie dla protokołu MCP (Model Context Protocol). Bez nich agentom, zwłaszcza zewnętrznym, trudno komunikować się z API PZU.

AI Gateway to użycie API Management przed modelami AI, w dużym uproszczeniu przed ChatGPT czy OpenAI. Widać, kto dzwoni, jak, ile razy i ile tokenów zużywa. Wszystkie zapytania i odpowiedzi mogą trafiać do wewnętrznych logów. Kolejną funkcją jest cache’owanie semantyczne.

W chwili nagrania AI Gateway był dostępny prawdopodobnie od ponad roku, ale w bramie chmurowej, a PZU jeszcze go nie używało. Dlatego wtedy kluczowe było dla PZU, żeby szybciej wejść w bramę chmurową. Jeśli PZU nie zaoferuje bramy chmurowej, bardzo trudno będzie mu dać coś atrakcyjnego wewnętrznym projektom AI i zewnętrznym agentom, które zechcą korzystać z jego API.

Schemat: brama chmurowa między agentami AI a API PZU

Udostępnianie API, rozliczalność i zabezpieczenie dostępu, na przykład to, jakie saldo tokenów dany proces może wykorzystać, były tematem warsztatów zaplanowanych na wrzesień. PZU miało też nadzieję jeszcze w tym samym roku zrobić wewnętrzny hackathon, który połączy API Management z modelami AI. Miał pomóc oswoić się z tym, co jest dostępne w chmurze.

Technologie łatwo pokazać, trudniej opisać potrzebę biznesową na tyle ambitną i szeroką, żeby dało się ją zrealizować tymi narzędziami. Potrzeby, z którymi zespół się spotyka, często da się spełnić o wiele prościej, bez tak wyrafinowanych technologii. PZU liczy, że pokazywanie możliwości zachęci biznes, żeby poszedł krok dalej. W najbliższym czasie spodziewa się projektu, który wykorzysta AI Gateway i Azure Logic Apps. PZU używa Logic Apps jako orkiestratora, a z różnych rozmów wynika, że mocno wykorzystuje się je też do budowy agentów i pipeline’ów opartych na AI.

Portfel technologii integracyjnych daje wybór zamiast dwóch dużych platform

Jeszcze około 5 lat temu PZU miało do dyspozycji dwie duże platformy integracyjne typu szyna. W dużej mierze zmuszały architektów, żeby ich używali i dopasowywali potrzebę biznesową do platformy. Dziś PZU ma portfel technologii integracyjnych, które pozwalają dopasować obszar integracji do rzeczywistych potrzeb biznesu bez nadmiernych kompromisów. Zespół integracji wypracował ten portfel przez kilka lat i szuka do niego kolejnych komponentów.

Należy do niego mechanizm importu plików, który PZU przygotowało wspólnie z Protopią. To technologia podwójnego zastosowania: służy do transferu plików i obsługi zdarzeń, ale może też nieść niezależną logikę aplikacji, na przykład powiadomienia o wrzuceniu pliku.

Zespół ocenia, że to się opłaciło.

API Management jako brama agentów AI do systemów firmy

Szymon Warda, Marek Grabarz — Wed, 17 Dec 2025 00:00:00 GMT

TL;DR

Planujesz agentów AI, którzy mają korzystać z danych w systemach firmy i wykonywać w nich akcje. Musisz zdecydować, czy każdy zespół podłączy ich do systemów osobno, czy przez wspólną bramę. Azure API Management jest taką bramą: porządkuje API firmy, wystawia je agentom jako serwery MCP i trzyma zasady bezpieczeństwa, sieci i dostępu w jednym miejscu. Dowiesz się, kiedy ta brama jest potrzebna, czego nie robi, jak działa przy systemach on-premises i jak ją wprowadzić, żeby zespół integracyjny nie stał się wąskim gardłem.

Kluczowe wnioski

Przy wielu agentach wspólna platforma API Management oszczędza zespołom powtarzania tych samych integracji.
API wystawione w API Management można udostępnić agentom jako serwer MCP, ale długie procesy ze stanem i cofaniem kroków należą do platformy integracyjnej, bo dużą orkiestrację w API Management trudno utrzymać i debugować.
Wspólna brama pozwala z góry uzgodnić z działem bezpieczeństwa, siecią i compliance ścieżki ruchu oraz jedne zasady dla wszystkich API, także tych budowanych przez kontraktorów.
Przy systemach on-premises lokalna brama zatrzymuje dane wrażliwe w prywatnym data center, a konfiguracja i monitoring zostają w chmurze.
Z APIOps przeszkoleni developerzy sami zgłaszają zmiany przez pull request z automatycznym lintingiem, a zespół integracyjny tylko je weryfikuje.
Warsztaty z listą procesów szybko pokazują, że agentów będzie wielu, a wspólna platforma może na starcie kosztować trochę więcej.

Wersja do czytania

Przy wielu agentach API Management staje się kluczowy

API Management staje się kluczowy, gdy firma buduje wielu agentów albo całą fabrykę agentów dla organizacji. Żeby agent sięgał do źródeł informacji w firmie i automatyzował kolejne akcje, musi rozmawiać z systemami wewnętrznymi, a preferowaną formą tej komunikacji jest ustandaryzowane API.

Pojedynczy agent nie wymaga API, jeśli potrzebne mu dane da się wyciągnąć z systemów i dostarczyć w formie statycznej. API staje się krytyczne, gdy dane pod spodem zmieniają się dynamicznie, a akcje agenta też są dynamiczne.

Przy wielu agentach bez wspólnej platformy każda grupa twórców może wykonywać tę samą mrówczą pracę. W e-commerce każdy agent osobno integrowałby się na przykład z API danych produktowych. API Management dostarcza agentom te same API w ustandaryzowany sposób:

Marek Grabarz: „API to systematyzuje, a API Management sprawia, że możemy reużywać tego API w różnych miejscach.”

Azure API Management składa się z trzech części

W dużym uproszczeniu Azure API Management ma trzy główne komponenty: Control Plane, Developer Portal i samą końcówkę API.

Control Plane to portal do zarządzania. API już istnieją w firmie, więc tutaj się je importuje i konfiguruje, a zasady opisuje się politykami. Polityka może na przykład wpuszczać tylko członków grupy Active Directory, określać zabezpieczenia i monitoring albo ustawiać rate limiting, czyli limit wywołań, które dany system może wykonać w ciągu minuty czy sekundy.

Developer Portal to wizualna wersja tego, co zdefiniowano w Control Plane. Programista lub członek zespołu, który integruje się z API, robi tu discovery: znajduje API i widzi ich opisy, końcówki, wartość biznesową, sposób uwierzytelnienia i wywołania oraz dozwoloną liczbę wywołań.

Trzecia część to sama końcówka API wystawiona dla systemów. Korzystają z niej agenci, aplikacje mobilne, wewnętrzne aplikacje line of business, portale, a nawet aplikacje desktopowe.

Istniejące API trafiają do agentów jako serwery MCP

API Management potrafi wystawić to samo API jako REST, gRPC albo jako serwer MCP, który rozumieją agenci. Dla API, które już działa jako REST lub w innej formie, jest dziś w uproszczeniu jeden checkbox: wystaw też jako MCP. API Management sam wykonuje translację. W dużym stopniu pozwala to podłączyć stare systemy do agentów bez ich modyfikowania.

Firma, która wcześniej dobrze wystawiła API dla aplikacji, może użyć tych samych API dla agentów. Przykład: agent hurtowni podaje listę produktów z wybranej kategorii, dodaje produkt do koszyka i składa zamówienie przez API, które już są wystawione.

Warunkiem są opisy. Nazwy GetCustomer czy GetProduct brzmią zrozumiale, ale przy bardziej złożonych operacjach biznesowych sama nazwa endpointu nie mówi, co on robi. Dlatego każdą operację opisuje się w API Management tak, żeby agent wiedział, której końcówki użyć i w jaki sposób. W projektach Protopii zespół stara się zlecać te opisy LLM-owi. Model dostaje polecenie, żeby opisał endpointy w sposób zrozumiały dla samego siebie, czyli dla agenta.

Procesy wieloetapowe wymagają platformy integracyjnej

API Management służy do wystawiania API, więc procesy z wieloma krokami i logiką biznesową potrzebują pod spodem dodatkowej warstwy. Integration Platform as a Service (iPaaS) to warstwa przepływów, workflow i orkiestracji między API Management a systemami firmy. API Management nie zawsze sięga głęboko do SAP-a czy bazy danych i sam nie wysyła maili, powiadomień ani SMS-ów, chyba że firma ma do tego API.

Przykład: agent wywołuje API zamówienia produktu wystawione w API Management. API Management, zamiast od razu wywołać API systemu, uruchamia workflow, który wysyła klientowi maila o zamówieniu albo o zmianie jego statusu. Integracja z 5 czy 10 krokami, z cofaniem się między krokami i stanami, musi gdzieś przechowywać stan, odtwarzać go i działać przewidywalnie.

API Management daje prostą orkiestrację. Dużą też da się zbudować, ale trudno ją utrzymać, debugować i ustalić, co się w niej wykłada. Do tego nie jest stanowa.

Marek Grabarz: „Ja zawsze klientom odradzam, żeby nie robili dużej orkiestracji w ramach API Management.”

Prosta orkiestracja w API Management przydaje się, gdy nie ma innej możliwości, na przykład gdy trzeba dodać wysyłkę SMS bez modyfikowania starego systemu.

Jeśli stary system, na przykład SAP, wystawia API, to API trafia prosto do API Management. Jeśli jedynym interfejsem systemu jest select do bazy, potrzebna jest warstwa pośrednicząca, która wystawia API w formie workflow. Najpierw sprawdź, czy ktoś nie wystawił już tych danych przez serwis HTTP: skoro istnieje select do bazy, ktoś mógł mieć tę potrzebę wcześniej.

Schemat: API Management wystawia API, a procesy ze stanem obsługuje iPaaS

Jedna brama porządkuje ruch i zasady bezpieczeństwa

Gdy systemy łączą się przez API Management, zamiast komunikacji każdy z każdym jest jedna brama. W dużych firmach to wspólna fasada bezpieczeństwa i sieci: API nie są wystawiane raz tu, raz tam do publicznego internetu. Agenci i aplikacje dostają jeden spójny interfejs, choć systemy pod spodem używają różnych protokołów, na przykład SOAP, i różnych sposobów uwierzytelniania. Uwierzytelnianie można wzmocnić na bramie, a starsze systemy zostawić w spokoju. Developer, który chce się zintegrować, musi się przedstawić i opisać integrację, więc widać, kto korzysta z którego systemu, także wewnątrz firmy.

Rozmówcy widzą u klientów powtarzający się wzorzec: firmy, z którymi pracują, często z branży regulowanej, mają dość mocno dokręcone zasady bezpieczeństwa i sieci. Jeśli systemy są w jednym miejscu, a API w innym, trudno uzgodnić z działem bezpieczeństwa, siecią i compliance, kto z kim może rozmawiać. Wspólna brama pozwala z wyprzedzeniem zbudować przejścia sieciowe, zgody i kontrakty bezpieczeństwa dla dwóch wytrasowanych ścieżek: od agentów do API Management i od API Management do poszczególnych API.

Schemat: połączenia każdy z każdym i jedna brama API Management

W pewnym sensie to white listing wewnętrznych API: wiadomo, kto może konsumować które dane. Compliance, rozliczanie, widoczność, monitoring i zgoda bezpieczeństwa na sposób wystawienia są w jednym miejscu.

Wspólne zasady bezpieczeństwa na bramie to kolejny powód, żeby nie integrować systemów bezpośrednio 1:1. Rozmówcy widzą API jako główne miejsce nadużyć. Chodzi mniej o włamania do infrastruktury, a bardziej o wykorzystanie systemów firmy: nabijanie punktów czy próby dostępu.

Punktem odniesienia jest OWASP API Security Top 10. W dokumentacji Microsoftu łatwo znaleźć, jak API Management i inne narzędzia, na przykład Microsoft Defender for APIs czy ochrona przed DDoS, odpowiadają na poszczególne zagrożenia z tej listy.

Nawet klientowi wewnętrznemu nie można w pełni ufać. W firmie z 10 działami API budują różne grupy: pracownicy, zewnętrzni kontraktorzy i firmy, które coś zbudowały i dostarczyły. Do tego dochodzi kupiony SaaS, który działa jak black box i którego nie da się zmodyfikować. Każda z tych grup ma inne doświadczenie i inne podejście do bezpieczeństwa, więc każda może się pomylić. Skoro wszyscy integrują się przez API Management, zespół platformy razem z działem bezpieczeństwa ustala zasady dla wszystkich wystawionych API i łata w ten sposób potencjalne dziury.

Partnerzy dostają przez produkty wybrany podzbiór API

Część API można wystawić na zewnątrz, a mechanizm produktów określa, który podzbiór widzi dany konsument. Odbiorcami są partnerzy biznesowi, inne firmy czy startupy. Spełniają ustalone kontrakty, zgody oraz warunki dostępu i konsumują tylko te dane, które firma celowo dla nich wystawia. Firma może w ten sposób otworzyć nowe kanały komunikacji i sprzedaży, być może także nowe produkty.

To część koncepcji API Economy, obecnej od mniej więcej 10 lat. API Economy to zarządcze określenie wartości, jaką dają API firmy. Chodzi głównie o monetyzację wewnętrzną: na wystawionych danych firma buduje kolejne systemy i nadbudówki, i zyskuje wartość wewnątrz, a także z zewnątrz. Nie chodzi o sprzedaż API jako SaaS z opłatą za użycie.

Produkt w API Management grupuje API, na przykład jako integrację z określonym typem systemów. Nazwa brzmi jak SaaS, ale produktu się nie kupuje: podpina się go dla konsumenta, firmy albo projektu. Jedno API może należeć do wielu produktów. Przez produkty konsumenci uwierzytelniają się i są autoryzowani w ustandaryzowany sposób.

Self-hosted gateway zostawia dane w prywatnym data center

Self-hosted gateway pozwala obsłużyć systemy on-premises bez wysyłania ruchu do chmury, gdy aplikacja i API są w prywatnym data center. W projektach Protopii mniej więcej połowa wdrożeń API Management działa w modelu hybrydowym. W dużym uproszczeniu Developer Portal i Control Plane, gdzie konfiguruje się API, zostają wtedy w chmurze. Bramę, przez którą wystawia się API, można uruchomić w dwóch miejscach.

Dwa miejsca bramy API Management
Brama	Gdzie działa	Wywołanie, gdy aplikacja i API są w prywatnym data center
Cloud gateway	W chmurze	Aplikacja → chmura → API → chmura → aplikacja
Self-hosted gateway	Kontener z obrazem od Microsoftu, stawiany przez klienta, zwykle na jego infrastrukturze: on-premises lub w innej chmurze	Ruch zostaje lokalnie

Lokalna brama skraca drogę wywołania, co pomaga w latency i ogranicza koszty transferu danych do chmury i z powrotem. Ostatni zysk dotyczy compliance: dane bankowe, medyczne czy ubezpieczeniowe w żaden sposób nie opuszczają prywatnego data center, a w chmurze jest tylko monitoring i ewentualnie observability.

Schemat: model hybrydowy z self-hosted gateway

Brama hostowana lokalnie na Kubernetesie albo na maszynie wirtualnej może wystawić API także na zewnątrz, przez własny endpoint i firewall firmy, według jej wewnętrznych zasad. API nie są wtedy wystawiane z regionu chmury, na przykład West Europe w Amsterdamie. Systemy on-premises można więc wystawić na zewnątrz i jednocześnie włączyć do platformy agentowej.

API Center i linting porządkują API przed wystawieniem

Firma wreszcie wie, jakie ma API, a linting w CI/CD dopuszcza na bramę tylko API opisane według standardu. Wcześniej wdrożenia API Management zwykle zaczynały się od nabrzmiałej potrzeby: firma ma całą masę API tworzonych przez lata i chce je usystematyzować i wystawić centralnie. Często stoi za tym zespół integracyjny, który chce uprościć sobie pracę, albo osoby w roli CTO, które widzą, że API Economy jest kluczowa dla sukcesu firmy w przyszłości.

Azure API Center to katalog API, który można nazwać CMDB dla API. Protopia często wdraża go obok API Management. API w katalogu nie muszą być wystawione przez API Management: mogą działać bezpośrednio albo gdzie indziej. API Center daje ich pełen opis, także maszynowy, jak Swagger czy OpenAPI, i zastępuje nieaktualne strony wiki z opisami API.

Linting API działa jak analiza kodu, która sprawdza bezpieczeństwo, nazewnictwo, strukturę i podatności.

Wiele API już dziś działa, więc nowe standardy wywołują napięcie: działy, które wystawiają API, w którymś momencie muszą się do nich nagiąć. Protopia głównie wdraża platformę, procesy i linting. Za dostosowanie API do standardów odpowiadają zespoły integracyjne i grupy, które te API wystawiają.

APIOps przenosi konfigurację API do repozytorium

APIOps to podejście ze świata API Management Microsoftu, podobne do GitOps w Kubernetesie: polityki, integracje i całe API są skonfigurowane w repozytorium kodu, a zespół tylko promuje tę konfigurację do kolejnych środowisk. Protopia wdrażała je już kilka razy.

API i jego rewizje, wersje czy zmiany przechodzą ze środowiska deweloperskiego przez integracyjne, UAT i preprodukcyjne do produkcji. Środowisk może być tyle, ile firma potrzebuje. Ręczna rekonfiguracja API w każdym z nich to więcej pracy i ryzyko ludzkich błędów: ktoś źle przeklika, źle przeniesie albo nie ustawi elementu polityki czy orkiestracji. W Gicie jest za to historia zmian: kto, kiedy, gdzie i dlaczego coś zmienił.

Bez APIOps zespół integracyjny, na przykład 5–10 osób, w którymś momencie stałby się wąskim gardłem, bo cała firma przychodziłaby do niego z prośbą o integrację swojego API. Jeden z rozmówców pracował kiedyś w firmach, w których wystawienie API wymagało zapisu na posiedzenie architecture review board, z terminem za 2 tygodnie. Board oddawał długą listę poprawek, a cały proces trwał 2–4 miesiące, choć chodziło tylko o prostą iterację.

Z APIOps developerzy sami tworzą brancha, kodują integrację i zgłaszają pull request. Ktoś z działu integracyjnego przegląda zmiany i komentuje, co poprawić. Pull request daje zgodę na wdrożenie na kolejne środowiska i uruchamia kroki automatyczne, na przykład linting zgodności ze standardami. Developerzy potrzebują do tego podstawowej wiedzy, więc wprowadzenie APIOps wiąże się ze szkoleniami w firmie i budowaniem świadomości. Wiedza się rozprasza, a zespół centralny weryfikuje zmiany, zamiast być wąskim gardłem.

Schemat: zmiana API w APIOps od brancha do produkcji

Wdrożenie zaczyna się od warsztatów z listą procesów

Zanim Protopia zacznie prace techniczne, zwykle prowadzi warsztaty z klientem. Zbiera architektów biznesowych oraz osoby odpowiedzialne za obszary firmy i ustala z nimi, które procesy można usprawnić agentami. Z takiej długiej listy klienci szybko widzą, że skończy się na 10, 30 agentach lub więcej, a nie na jednym, dwóch czy trzech.

Przy realnej platformie w organizacji koszt integracji API i tak się pojawi. Protopia zwykle buduje platformę tak, żeby dało się jej użyć ponownie. Na początku może to kosztować trochę więcej: trzeba zbudować podwaliny, połączyć elementy i przejść wewnętrzną certyfikację w dziale bezpieczeństwa czy zakupów.

Wiele wdrożeń API Management w Protopii powstało, zanim ktokolwiek mówił o LLM-ach, a uporządkowanie API było wtedy dla organizacji celem samym w sobie.

Fabryka agentów AI: jak zacząć i dojść do produkcji

Łukasz Kałużny, Mikołaj Szczerbicki — Thu, 27 Nov 2025 00:00:00 GMT

TL;DR

Chcesz wdrożyć w firmie agenty AI i musisz zdecydować, na czym je zbudować i jak bezpiecznie dopuścić je do danych i systemów. Pomaga w tym fabryka agentów: gotowa platforma (przy wdrożonej chmurze usługa jej dostawcy), wspólna brama do systemów firmy i zamknięta przestrzeń testowa, z której agent trafia na produkcję jak zwykła aplikacja. Zaczynasz od prostego przypadku, dla którego wiesz, co agent dostaje i co ma oddać.

Kluczowe wnioski

Agent AI to ten sam proces z modelem językowym co chatbot, tyle że dłużej pracuje na danych i sam decyduje w granicach, które mu wyznaczysz.
Na start proces biznesowy zwykle obsługuje jeden agent orkiestrator z małymi, wyspecjalizowanymi agentami, bo długi kontekst kosztuje, a agent gorzej trzyma się wtedy instrukcji.
Integracje wystawione przez jedną bramę służą każdemu kolejnemu agentowi i są tańsze w utrzymaniu.
Gdy masz już chmurę, bierzesz gotową usługę jej dostawcy, a model i platformę da się później wymienić bez przebudowy integracji.
Sandbox narzuca bezpieczną konfigurację. Z niego agent trafia przez repozytorium i CI/CD najpierw na środowisko nieprodukcyjne, a po testach na produkcję.
Zwykle najtrudniejszy i najdłuższy jest pierwszy etap: wybór przypadku i ustalenie, z jakimi systemami agent musi się zintegrować.

Wersja do czytania

Agent AI decyduje sam, ale w granicach, które mu wyznaczysz

Agent AI to proces, który korzysta z dużego modelu językowego (LLM), dłużej pracuje na danych i sam podejmuje decyzje w granicach, które mu wyznaczysz. Część definicji opisuje agenta jako samodzielny, żyjący byt. W praktyce to ten sam chatbot albo model językowy wpięty w proces, na przykład w aplikacji, tylko w innej formie.

Agenta uruchamia runtime framework. Jest nim gotowa usługa chmurowa albo kod w Pythonie lub innym języku z frameworkiem, który łączy się z LLM, na przykład od OpenAI. Pod spodem agent jest pętlą, która wywołuje się na podstawie danych z wejścia.

Agenty u klientów obsługują dokumenty, raporty i procesy bez stałego przebiegu

Przetwarzanie dokumentów to przypadek, który ciągle wraca u klientów Protopii. Agent dostaje dokument już po OCR, na przykład z maila na skrzynce albo z systemu, do którego wrzucił go pracownik. Rozpoznaje w nim PESEL, numer klienta i inne dane identyfikacyjne, próbuje zebrać informacje z różnych systemów firmy i wspiera pracownika. Typowym dokumentem jest reklamacja, prawdopodobnie najczęstszy taki przypadek. Przykład od jednego z klientów: ktoś reklamuje rachunek, agent sprawdza, że rabat naliczono źle, i przygotowuje dla handlowca szkic maila, który to wyjaśnia.

Drugi przypadek to raporty z danych rozproszonych po systemach. U klientów kilka razy pojawiła się potrzeba scalonego widoku klienta z kilku systemów (CRM, ERP, helpdesk albo inny system dziedzinowy), żeby nie przeskakiwać między nimi albo żeby znaleźć niespójności w danych.

Trzeci przypadek to procesy, których przebieg trudno ustalić z góry. Agent może wtedy, zależnie od sytuacji, zbierać dane albo wykonywać akcje w systemach. Jeśli czegoś brakuje, uzupełnia dane w kilku miejscach.

Na start proces biznesowy zwykle obsługuje jeden orkiestrator i małe agenty

Układ na start to jeden agent orkiestrator na proces biznesowy i podpięte do niego małe agenty, które wykonują akcje w poszczególnych systemach. Technicznie ten scenariusz nazywa się connected agents. Orkiestrator działa jak dyrygent albo team leader: rozdziela pracę i łączy wyniki w całość. Inne scenariusze też istnieją, ale na początek nie są polecane, bo mogą być koszmarem do testowania, a wyniki mogą bardzo rozczarować.

Klienci, którzy budują agenty samodzielnie, najpierw próbują zrobić superagenta i podpiąć do niego wszystko. Odwrotny trend przypomina mikroserwisy: bardzo dużo małych agentów. Potrzebny jest balans między tymi skrajnościami.

Powodem jest okno kontekstowe. Okno kontekstowe to limit tekstu, który LLM przyjmuje na wejściu. Przy automatyzacji długi kontekst okazuje się kosztowny, a agent nie trzyma się instrukcji. Dlatego kontekst się minimalizuje, a zadania dzieli między mniejsze, wyspecjalizowane agenty.

Oprócz budżetu ograniczeniem jest na razie technologia. Agenty są niedeterministyczne. Celem Anthropic na najbliższe miesiące i lata jest model językowy, który dokładnie trzyma się przekazanych instrukcji i kolejności wykonywania.

Jedna brama integracyjna udostępnia systemy wszystkim agentom

System podpięty raz pod bramę integracyjną jest potem dostępny dla wszystkich agentów, które firma zbuduje. Protopia rekomenduje klientom Azure API Management jako centralną bramę, która udostępnia agentom różne systemy w jednolity sposób. Model językowy i kod runtime są uniwersalne, a firma musi ujednolicić sposób, w jaki integruje się ze swoimi systemami.

Schemat: agenty sięgają do systemów firmy przez jedną bramę

Łukasz Kałużny: „A sercem, wbrew pozorom, nie jest agent, tylko sposób dostarczenia do niego wiedzy i możliwości wykonywania akcji przez integrację z innymi systemami.”

Integracja agenta z systemem to opis wywołań w języku naturalnym, zoptymalizowany pod LLM. Opis pisze się tak, jak tłumaczyłoby się wywołanie człowiekowi: jakie dane metoda pobiera albo zapisuje i co trzeba jej przekazać. Przykład: to wywołanie zwraca dane o kliencie po numerze PESEL albo po ID klienta.

Zespół, który pisze kod agenta bez gotowej platformy, może spróbować sam zrobić integrację. W większej skali systemy źródłowe mogą wymagać zmian, żeby dało się je podłączyć. Większa organizacja chce też jak najtaniej użyć raz zbudowanej integracji w innych miejscach. Bez bramy da się to zrobić, ale z doświadczenia Protopii jest to droższe i wolniejsze.

W bramie powstaje też centralna dokumentacja opisów, na przykład: w systemie HR dane pracownika są tu, a jego urlopy tam. Z tych opisów korzystają kolejne osoby, które budują i testują agenty. Brama porządkuje integracje w organizacji i obniża późniejszy koszt utrzymania.

Fabryka agentów działa jak platform engineering dla agentów

Fabryka agentów to platforma, która pozwala szybko przejść od testu agenta do uruchomienia go na produkcji. Droga prowadzi przez PoC i proof of value, a jeśli wszystko jest w porządku, kończy się oddaniem agenta do użycia.

W małej skali data scientist albo programista pisze agenta w Pythonie z frameworkami od Microsoftu, OpenAI albo Google’a. Tak zaczyna się PoC i powstają pierwsze agenty. Klienci Protopii, często firmy z branży finansowej, z branż regulowanych albo większe organizacje, chcą ten proces uporządkować.

Testy zwykle prowadzi się na danych jak najbliższych tym z systemów produkcyjnych, żeby wychwycić wartość agenta.

Przy wdrożonej chmurze wybierz gotową usługę PaaS jej dostawcy

Jeśli Twoja organizacja ma już wdrożoną chmurę, gotowa usługa platform as a service (PaaS) jej dostawcy zwykle jest najlepszym i najbardziej opłacalnym wyborem, szczególnie gdy chcesz pokazać wartość i zacząć testy. Każdy hyperscaler ma odpowiednik Azure AI Foundry. Z perspektywy Protopii, która na co dzień pracuje z Azure, AI Foundry jest „good enough”.

Opcje platformy dla agentów
Opcja	Co oznacza
Usługa PaaS dostawcy chmury, np. Azure AI Foundry	Dla organizacji z wdrożoną chmurą. Ma pewne ograniczenia, ale po wdrożeniu platformy działa od ręki.
Gotowa platforma open source dla agentów, np. Dify	Alternatywa, gdy nie masz chmury. Model językowy trzeba i tak jakoś dostarczyć.
Własna platforma na rozwiązaniach open source	Prawdopodobnie kilka miesięcy, zanim zacznie w pełni działać. Ten czas nie idzie na budowę agentów.

Gotowa usługa ogranicza ilość kodu i liczbę frameworków. Zespół skupia się na dwóch rzeczach: projektowaniu agentów oraz podłączaniu systemów i źródeł danych razem z testowaniem. Praca przesuwa się z pisania kodu na pisanie promptów. Nie zakopuj się we frameworkach open source i przepięknych diagramach z LinkedIna.

Przy wycofaniu się z Azure AI Foundry nie ma dużego vendor lock-in, więc firma nie jest uwiązana do Microsoftu. Model językowy można wymienić. System prompty, czyli instrukcje agenta, po zmianie modelu trzeba sprawdzić i dopasować, bo każdy model ma swoje niuanse, ale to raczej szlifowanie. Integracje z Azure API Management każdy framework, także open source, konsumuje dokładnie tak samo. Strategię wyjścia da się więc opisać jako copy-paste plus testy.

Schemat: co zmienia się przy wyjściu z Azure AI Foundry

AI Sandbox narzuca bezpieczną konfigurację wszystkim eksperymentom

AI Sandbox to przygotowana przestrzeń, na przykład w Azure, w której zespół bezpiecznie eksperymentuje z agentami. Tak Protopia nazywa ten koncept w pracy z klientami. Przygotowanie obejmuje zabezpieczenia, konfigurację platformy, nadawanie dostępów i kontrolę ruchu sieciowego, przychodzącego i wychodzącego.

Standardy ustalone przy projektowaniu platformy muszą respektować wszyscy. Mechanizmy platformy chmurowej pozwalają wymusić konfigurację, w której ani developer, ani data scientist nie może kliknąć przycisku „wystaw to do internetu”.

Sandbox ogranicza też zmiany konfiguracji, a zespołowi zostaje przetestowanie agenta. U jednego z klientów czas szedł na ustalanie, jak w bibliotece open source podłączyć się do usługi AI i bezpiecznie się zalogować.

Łukasz Kałużny: „Sandbox ma więc dwa cele. Pierwszy to zabezpieczenie i możliwość eksperymentów. Drugi to wymuszenie skupienia na wartości biznesowej, a nie na zabawie technologicznej.”

Agent przechodzi na produkcję jak kolejna aplikacja

Agent przechodzi z sandboxa na produkcję tak jak kolejna aplikacja na Kubernetesie. Przy wdrożeniu platformy Protopia przygotowuje zestaw skryptów deploymentowych dla całego procesu: agent z sandboxa trafia na środowisko nieprodukcyjne, a po testach na produkcję. Platformę buduje się w tej kolejności: najpierw bezpieczny AI Sandbox z usług PaaS albo gotowych usług, potem proces przejścia na środowiska, w których agent działa.

AI Sandbox jest przestrzenią współdzieloną, podzieloną podobnie jak namespace’y w Kubernetesie. Obowiązują w nim te same praktyki developerskie co przy zwykłych aplikacji. Agenta trzyma się as code w repozytorium i wdraża przez CI/CD, bez żadnej magii i specjalnego klikania. Środowisko od testu do użycia ma być takie samo, żeby pozbyć się syndromu „a u mnie to działało”.

Schemat: droga agenta z AI Sandbox na produkcję

Pierwszy etap to prosty przypadek z opisanym wejściem i wynikiem

Na początek wybierz proste przypadki do testowania agentów. Następnie określ, co trafi do agenta, na przykład informacja, prośba albo dokument, i jaki ma być wynik. Potem ustal, jakie systemy trzeba zintegrować z agentem. Dopiero z tą wiedzą przechodzisz do realizacji. Ten etap jest zwykle najtrudniejszy i najdłuższy.