Skip to main content
Powrót do aktualności

VivaDrive

BLOG
AI Watch Tower: how we taught our AI to answer the question “why?”
7 minut czytania
BLOG

AI Watch Tower: jak nauczyliśmy nasze AI odpowiadać na pytanie „dlaczego?”

Zbudowaliśmy AI Watch Tower — warstwę kontrolną dla firmowych systemów AI. Jedna bramka, przez którą przechodzi cały ruch do modeli językowych, dzięki czemu każde wywołanie jest obserwowalne, rozliczone kosztowo, zgodne z polityką i wyjaśnialne. Zbudowaliśmy ją najpierw dla siebie. Dziś działa produkcyjnie i pracujemy z nią u klientów z sektorów regulowanych.

TL;DR: Zbudowaliśmy AI Watch Tower — warstwę kontrolną dla firmowych systemów AI. Jedna bramka, przez którą przechodzi cały ruch do modeli językowych, dzięki czemu każde wywołanie jest obserwowalne, rozliczone kosztowo, zgodne z polityką i wyjaśnialne. Zbudowaliśmy ją najpierw dla siebie. Dziś działa produkcyjnie i pracujemy z nią u klientów z sektorów regulowanych.

Pytanie, które zatrzymuje wdrożenia

Od wielu lat pracujemy z korporacjami w Polsce i Europie. W ostatnich dwóch latach niemal każda rozmowa o GenAI kończyła się tym samym pytaniem — zadawanym przez zarząd, dział compliance albo audytora:

„Co dokładnie robi nasze AI, ile to kosztuje i czy umiemy to udowodnić?”

To pytanie brzmi prosto, ale w większości organizacji nie ma dziś na nie odpowiedzi. Asystenci, agenci i systemy RAG wchodzą do firm szybciej, niż firmy potrafią je nadzorować. W praktyce wygląda to tak: faktura za AI to jedna pozycja bez przypisania do centrów kosztów. Prompty zmieniane są ad hoc na produkcji, bez śladu kto, kiedy i po co. Na pytanie „dlaczego system odpowiedział tak, a nie inaczej” nikt nie umie odpowiedzieć. Dane osobowe lądują w logach. A kiedy przychodzi audyt — nie ma dowodów.

W sektorze regulowanym — bankach, ubezpieczeniach, energetyce — to nie jest niewygoda. To jest blokada. Projekty AI czekają w kolejce do wdrożenia, bo nikt nie umie wziąć za nie odpowiedzialności.

My też stanęliśmy przed tym problemem — z własnymi produktami AI. Więc zbudowaliśmy rozwiązanie. Najpierw dla siebie.

Czym jest AI Watch Tower

AI Watch Tower to warstwa kontrolna (control plane) dla firmowych systemów AI. Zasada jest prosta: cały ruch do modeli językowych przechodzi przez jedną bramkę. Aplikacja zmienia tylko adres endpointu i klucz — nic więcej. Od tego momentu każde wywołanie LLM jest:

Obserwowalne. Pełny ślad każdej interakcji: prompt i jego wersja, decyzje agenta, wywołane narzędzia, źródła danych z pipeline’u RAG (z pochodzeniem: skąd, która wersja dokumentu, kiedy), koszt, tokeny, latencja. Wszystko w jednym śladzie — rozumowanie agenta i generacje modelu razem, nie w osobnych systemach.

Rozliczone kosztowo. Każde wywołanie tagowane centrum kosztów (MPK), systemem, klientem, a nawet użytkownikiem końcowym. Hierarchia organizacyjna z roll-upem kosztów, reguły alokacji, budżety miesięczne z alertami i twarde limity, które fizycznie odcinają ruch po przekroczeniu. Eksporty w formatach, które dział kontrolingu otwiera bez tłumacza — łącznie z CSV, który poprawnie otwiera się w polskim Excelu. To brzmi jak drobiazg. Dla działu finansów to jest różnica między „narzędziem inżynierów” a systemem, z którego korzysta się na co dzień.

Zgodne z polityką. I tu jest sedno. Większość narzędzi na rynku obserwuje. Watch Tower potrafi egzekwować. Prompty żyją w centralnym rejestrze z wersjami i procesem promocji (draft → staging → production, z wymaganym zatwierdzeniem). Jeśli na produkcji pojawia się prompt spoza rejestru, system — w zależności od trybu — odnotowuje lukę do raportu zgodności albo blokuje wywołanie, zanim cokolwiek dotknie klienta. Polityka, która działa, a nie polityka, która wisi w intranecie.

Wyjaśnialne. Jeden endpoint składa z pojedynczego śladu kompletną odpowiedź na pytanie „dlaczego”: jaki prompt i w której wersji, jakie źródła, jakie narzędzia, jakie opcje system rozważył i odrzucił — z powodami. A kiedy zdarzy się incydent, można go odtworzyć: to samo wejście, przez tę samą bramkę, opcjonalnie z poprawioną wersją prompta — i porównać wyniki obok siebie. Incydent przestaje być zagadką, a staje się przypadkiem testowym.

Bezpieczeństwo: fail-closed, EU-only

Dwie decyzje projektowe, które podjęliśmy na samym początku i których się trzymamy.

Po pierwsze, dane osobowe są maskowane na bramce, zanim cokolwiek trafi do logów i systemu obserwowalności — PESEL, NIP, IBAN, adresy e-mail, numery telefonów, nazwiska. Co ważne: jeśli komponent maskujący zawiedzie, system nie przepuszcza danych dalej „bo trudno” — redaguje treść (fail-closed). Wyciek przez logi to jeden z najczęstszych i najbardziej wstydliwych scenariuszy incydentów AI. U nas jest wyeliminowany konstrukcyjnie: skoro maskowanie następuje przed zapisem, każdy eksport i każdy artefakt audytowy z definicji nie zawiera danych osobowych.

Po drugie, całość jest self-hosted i EU-only. Platforma działa na infrastrukturze klienta lub naszej, modele w regionie Warszawa, a żadne dane nie płyną do SaaS-a strony trzeciej. Dla sektora regulowanego to nie jest feature — to warunek wejścia.

Audyt też potraktowaliśmy dosłownie. Zdarzenia polityki trafiają do ewidencji append-only w plikach czytelnych bez specjalnych narzędzi, a wpisy o zmianach (np. promocja prompta na produkcję) lądują w audit trailu z łańcuchem skrótów — każdy rekord zawiera hash poprzedniego, więc modyfikacja historii jest wykrywalna. Audytor nie musi ufać naszemu dashboardowi. Może przeczytać ewidencję i zweryfikować ją samodzielnie.

Jakość mierzy się tym samym torem, co produkcja

Governance bez pomiaru jakości to tylko biurokracja. Dlatego Watch Tower ma trzy pętle pomiaru: offline (golden set pytań i oczekiwań, przepuszczany przez bramkę przy każdej zmianie — z bramką regresji w CI: jakość poniżej progu blokuje merge), online (sędzia LLM co godzinę próbkuje realny ruch, a odpowiedzi ocenione nisko trafiają automatycznie do kolejki przeglądu przez człowieka) i sygnały ruchu (błędy i rozrzut latencji per wersja prompta — „nierówny” prompt widać, zanim ktokolwiek go oceni).

Kluczowa zasada: wszystko mierzymy tym samym torem, którym płynie ruch produkcyjny. Benchmark, który przechodzi przez inną drogę niż produkcja, mierzy inną rzeczywistość.

Czego nauczył nas własny benchmark

Modele frontier są znakomite — sami używamy ich codziennie, do pisania kodu i ogarniania operacji. Tam, gdzie model pracuje dla nas, niech będzie najmocniejszy.

Ale w produktach obowiązuje inna matematyka: każde wywołanie mnoży się przez tysiące użytkowników. Przepuściliśmy więc trzy modele przez własny golden set — tą samą bramką, którą płynie produkcja. Wynik: najtańszy i najszybszy model osiągnął najwyższą jakość — 3.6/5, zero halucynacji, p95 na poziomie 1,2 sekundy — wyprzedzając modele większe i droższe. W czatbotach świetnie sprawdzają się modele klasy Gemini 2.5 czy Mistral.

Wniosek, który powtarzamy klientom: pytanie nie brzmi „jaki model jest najlepszy”, tylko „jaki model jest najlepszy do tego zadania”. Firmy, które tego nie mierzą, co miesiąc przepłacają za duże modele „na wszelki wypadek”.

A co z wydajnością?

Uczciwe pytanie: ile kosztuje ta cała kontrola na ścieżce każdego żądania?

Zmierzyliśmy to metodologią, której da się bronić: mock modelu o stałej latencji, dwa ramiona testu na tych samych wirtualnych użytkownikach — bezpośrednio do mocka i przez bramkę do tego samego mocka. Czas modelu identyczny w obu ramionach, więc różnica to czysty narzut bramki. Wynik: ~31 ms mediany — przy pełnym tagowaniu, governance i maskowaniu PII na ścieżce. Użytkownik nie ma szans tego zauważyć.

Produkcja, nie prezentacja

Watch Tower działa produkcyjnie na naszym DigitalFleet — platformie fleet-management, z której korzystają prawdziwi klienci. Pod maską pracuje multiagentowy asystent i pipeline RAG na dokumentach. Jeden ślad łączy decyzję agenta, wywołania narzędzi, retrieval z pełnym pochodzeniem danych i generacje modelu — z kosztami widocznymi per klient i per użytkownik końcowy. Prompty pięciu agentów żyją w centralnym rejestrze: podmiana wersji na produkcji to zmiana etykiety w rejestrze, bez deployu — aplikacja podejmuje nową wersję w ciągu minuty. Tryb enforce jest włączony na produkcji.

Onboarding kolejnego systemu do platformy? Wystawienie jednego klucza z metadanymi. Zero zmian w orkiestracji aplikacji.

Wniosek, którego się nie spodziewaliśmy

Zaczynaliśmy od myślenia o Watch Tower jako o koszcie — podatku od bezpieczeństwa, który trzeba zapłacić, żeby compliance pozwoliło wdrażać. Skończyliśmy z czymś odwrotnym.

Kontrola nie spowalnia innowacji. Uwalnia ją. Kiedy warstwa bezpieczeństwa, rozliczeń i dowodów jest zbudowana raz, każdy kolejny system AI wchodzi do organizacji szybciej — bo nie zaczyna od zera dyskusji o ryzyku. Kiedy compliance widzi dowody zamiast obietnic, przestaje mówić „nie” i zaczyna pytać „co następne?”. Struktura przestaje być hamulcem, a staje się pasem startowym.

Zaufania do AI się nie deklaruje. Zaufanie do AI się mierzy.

Zbudowaliśmy AI Watch Tower najpierw dla siebie. Dziś pracujemy z klientami z sektorów regulowanych — m.in. finansowego i energetycznego — i udostępniamy tę technologię także im. Jeśli Twoja organizacja potrzebuje dowodów, a nie obietnic — porozmawiajmy.