--- title: "Co to jest obserwowalność AI? Poradnik dla firm" url: "https://majchrzycki.com/blog/co-to-jest-obserwowalnosc-ai-poradnik-dla-firm" description: "Jak obserwować system AI: ślady wywołań, koszt tokenów, jakość odpowiedzi i incydenty. Standard OpenTelemetry, narzędzia, ewaluacje i pierwszy krok." --- # Co to jest obserwowalność AI? Poradnik dla firm 6 października 2026· Aktualizacja: 6 października 2026·8 min czytania·[Krzysztof Majchrzycki](https://majchrzycki.com/o-mnie) Temat: [Bezpieczeństwo i utrzymanie AI](https://majchrzycki.com/blog/filar/bezpieczenstwo-i-utrzymanie-ai) **Obserwowalność AI to zdolność odpowiedzi na pytanie, co dokładnie zrobił system AI, ile to kosztowało i czy wynik był dobry — dla każdej sprawy, a nie tylko „średnio”.** Zwykły monitoring powie, że serwer działa i odpowiada w dwie sekundy. Nie powie, że agent przez tydzień podawał klientom nieaktualny cennik, bo wyszukiwanie znajdowało stary dokument. Dlatego system AI obserwuje się na czterech warstwach: użytkownik, agent, model i narzędzia. Zaczyna się od śladów wywołań i małego zestawu testowego, a nie od zakupu platformy. Poradnik jest dla zarządu i lidera IT firmy od 50 osób, która ma już pilota z AI albo właśnie go planuje. Na końcu jest mapa wszystkich wpisów o obserwowalności na blogu. Szerszy kontekst odpowiedzialności daje przewodnik [bezpieczeństwo i utrzymanie AI](https://majchrzycki.com/blog/filar/bezpieczenstwo-i-utrzymanie-ai). ## Dlaczego system AI obserwuje się inaczej niż zwykłą aplikację Zwykła aplikacja na to samo wejście daje to samo wyjście. Gdy coś się psuje, widać to po błędzie, kodzie odpowiedzi albo czasie. System z modelem językowym psuje się ciszej. Są cztery różnice, które zarząd powinien znać. **Odpowiedzi są niedeterministyczne.** To samo pytanie zadane dwa razy może dać dwie różne odpowiedzi. Test „raz zadziałało” niczego nie dowodzi. Jakość trzeba mierzyć na zestawie przypadków i śledzić w czasie. **Błąd nie wygląda jak błąd.** Agent zwraca poprawną technicznie odpowiedź, z kodem 200 i w ładnym formacie, a w treści z pełnym przekonaniem cytuje regulamin, który wygasł w zeszłym roku. Pewny ton odpowiedzi nie mówi nic o jej poprawności. Monitoring infrastruktury tego nie wychwyci, bo z jego punktu widzenia wszystko działa. **Koszt zależy od treści.** W zwykłej aplikacji koszt rośnie z liczbą użytkowników. W systemie AI płaci się za tokeny, czyli za długość promptu, kontekstu i odpowiedzi. Agent, który wpadnie w pętlę albo dołącza do każdego pytania cały katalog produktów, może podnieść rachunek bez wzrostu ruchu. **Bezpieczeństwo ma nowe wejścia.** Złośliwa treść w mailu albo dokumencie może zmienić zachowanie agenta (prompt injection). Agent z narzędziami może wywołać operację, której nikt nie przewidział. Te zdarzenia trzeba widzieć w śladach, bo log serwera pokaże tylko „żądanie obsłużone”. [NIST AI Risk Management Framework](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) ujmuje to w funkcji MEASURE: działanie systemu AI i jego komponentów powinno być monitorowane na produkcji, a firma powinna mieć ludzi i metody do regularnego śledzenia ryzyk, także tych nieprzewidzianych (MEASURE 2.4 i 3.1, stan na 6.10.2026). To nie jest jednorazowy test przed wdrożeniem. ## Co mierzyć: sześć grup sygnałów Obserwowalność nie polega na zbieraniu wszystkiego. Polega na tym, żeby dla każdej sprawy dało się odtworzyć przebieg i ocenić wynik. Proponuję sześć grup sygnałów (podział autora). Każda ma innego odbiorcę w firmie. Grupa Co obejmuje Pytanie, na które odpowiada Kto czyta Ślady wywołań cała ścieżka sprawy: pytanie, kroki agenta, wywołania modelu i narzędzi, z jednym identyfikatorem co dokładnie się stało w tej sprawie? IT, osoba prowadząca agenta Koszt tokeny wejścia i wyjścia, liczba wywołań modelu na sprawę, koszt na sprawę ile kosztuje jedna obsłużona sprawa? IT, finanse, właściciel procesu Opóźnienie czas całej sprawy, czas modelu, czas narzędzi, czas do pierwszej odpowiedzi gdzie użytkownik czeka? IT Jakość i ugruntowanie ocena odpowiedzi, zgodność ze źródłem, odsetek poprawek, oceny użytkowników czy odpowiedź była dobra i oparta na właściwym dokumencie? właściciel procesu Błędy narzędzi nieudane wywołania API, odmowy uprawnień, przekroczone limity, ponowienia czy agent może wykonać swoją pracę? IT Incydenty i eskalacje wykryte próby prompt injection, działania poza zakresem, sprawy oddane człowiekowi co poszło źle i kto to przejął? bezpieczeństwo, właściciel procesu Najważniejszy jest pierwszy wiersz. Ślad (trace) łączy wszystkie kroki jednej sprawy w całość. Bez niego koszt, opóźnienie i błąd są osobnymi liczbami, których nie da się przypisać do konkretnej rozmowy. Z nim można zapytać: „pokaż mi wszystkie sprawy z wczoraj, w których agent dał rabat, i dokumenty, na których się oparł”. Druga uwaga dotyczy jakości. Opóźnienie i koszt mierzy się automatycznie. Jakość wymaga definicji, którą musi dać biznes: co to jest dobra odpowiedź na reklamację? Bez tej definicji narzędzie pokaże piękne wykresy, ale nie odpowie, czy system pomaga. Co obserwować w systemie AI: cztery warstwy połączone jednym śladem sprawy. Użytkownik — oceny, poprawki, eskalacje, czas całej sprawy. Agent — kroki, decyzje, wywołania narzędzi, pętle, działania poza zakresem. Model — tokeny wejścia i wyjścia, koszt, opóźnienie, wersja modelu i promptu. Narzędzia i dane — błędy API, odmowy uprawnień, znalezione dokumenty, czas odpowiedzi. Jakość i incydenty ocenia się na całym śladzie. Co obserwować w systemie AI: cztery warstwy i jeden ślad sprawy. Uproszczenie autora na podstawie konwencji OpenTelemetry dla GenAI i NIST AI RMF. ## Standard: OpenTelemetry i konwencje dla generatywnej AI [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/) to otwarty framework do generowania, eksportu i zbierania śladów, metryk i logów, niezależny od vendora. Jest projektem Cloud Native Computing Foundation. Ważne zastrzeżenie: OpenTelemetry nie przechowuje ani nie pokazuje danych. Zbiera je i wysyła do zaplecza, na przykład Prometheus i Grafany albo platformy komercyjnej. Dla AI istotne są konwencje semantyczne, czyli wspólne nazwy dla tego, co się mierzy: operacja modelu, wywołanie agenta, wykonanie narzędzia, zużycie tokenów. Dzięki nim ślad z aplikacji w Pythonie i ślad z usługi w .NET można oglądać w jednym narzędziu. Stan na 6.10.2026: - konwencje dla generatywnej AI mają status **Development**, czyli mogą się jeszcze zmieniać ([dokument konwencji](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/README.md)), - od wydania v1.42.0 głównych konwencji (12.06.2026) definicje GenAI żyją w osobnym repozytorium [semantic-conventions-genai](https://github.com/open-telemetry/semantic-conventions-genai), które nie ma jeszcze żadnego wydania; najnowsze wydanie głównych konwencji to v1.44.0 z 4.08.2026, - konwencje obejmują spany modelu i agenta, metryki (m.in. czas operacji, czas wywołania agenta, liczbę wywołań modelu i narzędzi), zdarzenia, wyjątki, Model Context Protocol oraz konwencje dla OpenAI, Anthropic, AWS Bedrock i Azure AI Inference, - zapis treści promptów, odpowiedzi i instrukcji systemowych jest **opcjonalny (opt-in)**, a dokumentacja ostrzega, że może on zawierać dane wrażliwe, w tym dane osobowe. Co z tego wynika dla zarządu? Wymagajcie od vendora i partnera, żeby system eksportował ślady w formacie OpenTelemetry (OTLP). To chroni przed zamknięciem historii działania systemu w jednym narzędziu. Jednocześnie zaplanujcie, że nazwy atrybutów zmienią się co najmniej raz, zanim standard się ustabilizuje. Nazwy metryk tokenów zmieniły się już przy przenosinach do nowego repozytorium. Szczegóły techniczne i wdrożenie opisuje wpis [OpenTelemetry w suwerennym AI OS](https://majchrzycki.com/blog/opentelemetry-agenci-ai-os). ## Narzędzia: jaka jest ich rola Narzędzi jest dużo i często robią podobne rzeczy. Zamiast rankingu — role. Wersje i licencje sprawdzone w repozytoriach projektów, stan na 6.10.2026. Rola Przykłady Licencja / forma Uwagi Standard i zbieranie danych OpenTelemetry, Collector v0.162.0 Apache-2.0 zbiera i przekazuje, nie przechowuje Metryki i alerty Prometheus v3.15.0 Apache-2.0 opóźnienia, błędy, zużycie GPU, progi alarmowe Dashboardy i eksploracja Grafana v13.2.3, zestaw LGTM AGPL-3.0 wspólny widok metryk, logów i śladów Ślady i ewaluacje aplikacji LLM Langfuse v4.53.0 MIT dla rdzenia, osobna licencja dla katalogów `ee/` przyjmuje ślady OpenTelemetry, koszt, prompty, zbiory testowe Ślady i ewaluacje aplikacji LLM LangSmith usługa LangChain: chmura, hybryda, samodzielny hosting przyjmuje ślady OpenTelemetry, ewaluacje offline i online Ślady i ewaluacje aplikacji LLM Arize Phoenix v20.19.0 Elastic License 2.0 oparty na OpenTelemetry i OpenInference, do samodzielnego hostowania Platformy komercyjne Datadog, Splunk, ClickStack usługi vendorów lub stos open source sensowne, gdy firma już ich używa do APM i logów Bezpieczeństwo i incydenty Wazuh, TheHive, Cortex różne licencje, zobacz wpisy widoczność hostów, obsługa incydentu, analiza Trzy uwagi przy wyborze. **Najpierw sprawdźcie, co już macie.** Jeśli IT używa Grafany albo platformy APM, ślady z agenta zwykle da się tam wysłać przez OpenTelemetry. Narzędzie specjalizowane dokładacie, gdy zespół zaczyna regularnie oceniać jakość odpowiedzi. **Licencja to nie formalność.** Langfuse ma rdzeń na licencji MIT, ale część funkcji na osobnej licencji. Phoenix jest na Elastic License 2.0, która ogranicza m.in. oferowanie oprogramowania jako usługi zarządzanej. Grafana jest na AGPL-3.0. Każdą z tych licencji przy wdrożeniu powinien ocenić prawnik; zasady porządkuje [poradnik o licencjach open source](https://majchrzycki.com/blog/co-to-jest-licencja-open-source-poradnik-dla-firm). **Gdzie leżą ślady.** Ślady z treścią promptów to dane firmy, często także dane klientów. Samodzielny hosting zatrzymuje je we własnym środowisku. Usługa w chmurze wymaga sprawdzenia regionu, retencji i dostępu operatorów vendora. Zespoły, które budują agentów na LangChain i LangGraph, zwykle zaczynają od LangSmith. Jego miejsce w ekosystemie LangChain opisuje [poradnik LangChain](https://majchrzycki.com/blog/co-to-jest-langchain-poradnik-dla-firm). ## Ewaluacje offline i online Ślady mówią, co się stało. Ewaluacje mówią, czy to było dobre. [Dokumentacja LangSmith](https://docs.langchain.com/langsmith/evaluation-concepts) dzieli je na dwa rodzaje, i ten podział warto przyjąć niezależnie od narzędzia. **Ewaluacja offline** to test przed zmianą. Macie zestaw przypadków z oczekiwanym wynikiem: pytania typowe, trudne i takie, które wcześniej skończyły się błędem. Każda zmiana — nowy model, nowa instrukcja, nowe źródło wiedzy — przechodzi przez ten zestaw, a wynik porównuje się z poprzednią wersją. To odpowiednik testów regresji w zwykłym oprogramowaniu. W praktyce opisuje to wpis [jak testować zmianę agenta przed sezonem](https://majchrzycki.com/blog/test-zmiany-agenta-przed-szczytem-sezonu). **Ewaluacja online** to ocena działającego systemu na prawdziwym ruchu. Próbka odpowiedzi trafia do oceny, użytkownicy klikają „pomocne / niepomocne”, a system liczy odsetek spraw oddanych człowiekowi i poprawianych ręcznie. Tu wychodzą problemy, których nie było w zestawie testowym, bo klienci pytają inaczej, niż zakładał zespół. Kto ocenia? Są trzy możliwości: - **człowiek** — najdroższy, ale najlepszy przy ocenie, czy odpowiedź jest merytorycznie dobra; od tego warto zacząć, - **reguła w kodzie** — sprawdza rzeczy jednoznaczne: czy odpowiedź nie jest pusta, czy zawiera numer zamówienia, czy nie przekracza progu kwoty, - **model jako sędzia** — ocenia dużą liczbę odpowiedzi, na przykład zgodność ze źródłem. Model oceniający też jest modelem. Ma te same wady co oceniany, więc jego oceny trzeba regularnie porównywać z oceną człowieka na tej samej próbce. Jeśli się rozjeżdżają, zmieniacie sędziego, a nie wynik. Ewaluacje są częścią wytwarzania oprogramowania z AI, nie osobnym projektem. Miejsce testów i bramek w całym cyklu pokazuje [poradnik AI SDLC](https://majchrzycki.com/blog/co-to-jest-ai-sdlc-poradnik-dla-firm). ## Kto odpowiada za obserwowalność Narzędzie zbiera dane. Nie decyduje, co jest błędem i kto zatrzymuje system. To trzeba ustalić w firmie, najlepiej przed uruchomieniem pilota. Rola Za co odpowiada Właściciel procesu definicja dobrej odpowiedzi, zestaw testowy przypadków, progi jakości, decyzja o zatrzymaniu IT instrumentacja, przechowywanie śladów, retencja, dostęp, koszty infrastruktury Osoba prowadząca agenta codzienny przegląd śladów i ocen, poprawki instrukcji, eskalacje Bezpieczeństwo wykrywanie i obsługa incydentów, przegląd prób nadużycia Inspektor ochrony danych i prawnik ocena, co wolno zapisywać w śladach i jak długo Najczęstsza luka jest w pierwszym wierszu. IT potrafi zebrać ślady, ale nie wie, która odpowiedź na reklamację jest dobra. Jeśli właściciel procesu nie da definicji i przykładów, ewaluacja sprowadzi się do pytania „czy odpowiedź brzmi rozsądnie”, a na to modele są wyjątkowo dobrze przygotowane. Obserwowalność dotyczy każdego agenta, nie tylko dużych systemów. Z czego składa się agent i gdzie w nim są narzędzia i uprawnienia, wyjaśnia [poradnik o agentach AI](https://majchrzycki.com/blog/co-to-jest-agent-ai-poradnik-dla-firm). Na wypadek, gdy pomiar pokaże, że system trzeba wyłączyć, potrzebny jest też plan opisany we wpisie [kto przejmie pracę, gdy automatyzacja się zatrzyma](https://majchrzycki.com/blog/awaryjne-przejecie-pracy-po-automatyzacji). ## Jak zacząć: ślady i zestaw testowy Nie zaczynajcie od wyboru platformy. Zacznijcie od jednego procesu, w którym AI już działa albo zaraz ruszy pilot. **Krok 1. Ślady od pierwszego dnia.** Każda sprawa dostaje jeden identyfikator, a każde wywołanie modelu i narzędzia zapisuje się w śladzie przez OpenTelemetry. Zapis treści promptów włączcie świadomie: z maskowaniem danych osobowych i ustaloną retencją. **Krok 2. Koszt i czas na sprawę.** Policzcie koszt tokenów i czas obsługi jednej sprawy, nie średnią miesięczną. Dopiero to pozwala porównać system AI z dzisiejszym procesem. **Krok 3. Zestaw testowy od właściciela procesu.** Kilkadziesiąt prawdziwych przypadków z oczekiwanym wynikiem, w tym trudne i takie, które już kiedyś poszły źle. Każda zmiana przechodzi przez ten zestaw przed wdrożeniem. **Krok 4. Ocena próbki na produkcji.** Co tydzień człowiek ocenia próbkę odpowiedzi. Gdy ocen jest za dużo, dokładacie regułę albo model jako sędziego — i sprawdzacie go na tej samej próbce. **Krok 5. Progi i reakcja.** Ustalcie z góry, przy jakim odsetku złych odpowiedzi, kosztów albo błędów narzędzi system przechodzi w tryb z zatwierdzeniem człowieka albo się zatrzymuje. I kto o tym decyduje. Karta „Od czego zacząć pomiar systemu AI”. Pięć kroków: ślady od pierwszego dnia z jednym identyfikatorem sprawy, koszt i czas na sprawę, zestaw testowy od właściciela procesu, cotygodniowa ocena próbki na produkcji, progi i reakcja z nazwaną osobą, która zatrzymuje system. Uproszczenie autora. Od czego zacząć pomiar systemu AI: pięć kroków przed wyborem platformy. Uproszczenie autora. Jeśli po kroku 3 nikt nie potrafi powiedzieć, jak wygląda dobra odpowiedź, problem nie leży w narzędziu. Wtedy potrzebna jest rozmowa zarządu o tym, co system ma robić i kto odpowiada za wynik. Na tym polega [prezentacja dla zarządu](https://majchrzycki.com/wspolpraca/prezentacja-systemu-ai-dla-zarzadu): nazwiemy proces, miary i osobę, która może zatrzymać system, niezależnie od vendora i partnera. ## Mapa wpisów o obserwowalności AI Wszystkie wpisy o obserwowalności, ewaluacjach i incydentach systemów AI w pięciu grupach. ### A. Standard i zbieranie danych Jak zbierać ślady, metryki i logi niezależnie od narzędzia. - [OpenTelemetry w suwerennym AI OS](https://majchrzycki.com/blog/opentelemetry-agenci-ai-os) — jeden ślad od pytania do wywołania modelu i narzędzia. - [Prometheus w suwerennym AI OS](https://majchrzycki.com/blog/prometheus-monitoring-ai-os) — metryki i alerty dla usług modelowych. - [ClickStack w suwerennym AI OS](https://majchrzycki.com/blog/clickstack-obserwowalnosc-ai) — logi, ślady i metryki agentów w jednym silniku. ### B. Dashboardy i platformy Gdzie ludzie oglądają dane i szukają przyczyny problemu. - [Grafana w suwerennym AI OS](https://majchrzycki.com/blog/grafana-ai-os) — dashboardy metryk, logów i śladów. - [LGTM w suwerennym AI OS](https://majchrzycki.com/blog/grafana-lgtm-ai-os) — Loki, Grafana, Tempo i Mimir jako jeden stos. - [Datadog w suwerennym AI OS](https://majchrzycki.com/blog/datadog-obserwowalnosc-ai) — zarządzana platforma obserwowalności i bezpieczeństwa. - [Splunk w suwerennym AI OS](https://majchrzycki.com/blog/splunk-obserwowalnosc-ai) — analiza logów w istniejącym środowisku operacyjnym. ### C. Ślady i ewaluacje aplikacji LLM Narzędzia, które pokazują rozmowę, prompt, koszt i ocenę odpowiedzi. - [Langfuse w suwerennym AI OS](https://majchrzycki.com/blog/langfuse-ewaluacja-agentow) — otwarta platforma śledzenia i ewaluacji. - [LangSmith: jak oceniać i śledzić aplikacje AI](https://majchrzycki.com/blog/langsmith-ai-application-lifecycle-management-alm) — ewaluacje i ślady w ekosystemie LangChain. - [MLflow w suwerennym AI OS](https://majchrzycki.com/blog/mlflow-ai-sdlc) — śledzenie eksperymentów i wersji modeli. ### D. Bezpieczeństwo i incydenty Co się dzieje, gdy ktoś próbuje nadużyć systemu albo coś poszło źle. - [Wazuh w AI OS: widoczność hostów, alertów i agentów](https://majchrzycki.com/blog/wazuh-siem-ai-os-agenci) — wykrywanie zmian i podejrzanego zachowania węzłów. - [TheHive w AI OS: obsługa incydentów i koszt licencji](https://majchrzycki.com/blog/thehive-reagowanie-incydenty-ai-os) — praca zespołu reagującego na incydent. - [Cortex w SOC dla AI OS: analiza i kontrolowana odpowiedź](https://majchrzycki.com/blog/cortex-analizatory-reakcja-ai-os) — analizatory i automatyczne działania w SOC. ### E. Testy zmian i ciągłość pracy Jak wdrażać zmiany bez niespodzianek i co robić, gdy system trzeba wyłączyć. - [Jak testować zmianę agenta przed sezonem?](https://majchrzycki.com/blog/test-zmiany-agenta-przed-szczytem-sezonu) — porównanie wersji, ograniczone uruchomienie, karta wydania. - [Kto przejmie pracę, gdy firmowa automatyzacja się zatrzyma?](https://majchrzycki.com/blog/awaryjne-przejecie-pracy-po-automatyzacji) — plan zatrzymania i przejęcia otwartych spraw. - Obserwowalność - Agenci AI - Utrzymanie - Zarząd ## Sprawdźmy, czy widzicie, co robi Wasz system AI Prezentacja dla zarządu: wybierzemy jeden proces z AI, ustalimy, co trzeba mierzyć, kto czyta wyniki i kto może zatrzymać system — zanim kupicie narzędzie. Niezależnie od vendora i partnera. [Umów prezentację dla zarządu](https://majchrzycki.com/wspolpraca/prezentacja-systemu-ai-dla-zarzadu) FAQ ## Najczęstsze pytania Czym obserwowalność AI różni się od zwykłego monitoringu? Monitoring odpowiada na pytanie, czy system działa: czy serwer odpowiada i ile trwa żądanie. Obserwowalność AI pozwala też wyjaśnić, dlaczego agent dał taką odpowiedź: jaki prompt dostał model, które dokumenty znalazł, jakie narzędzia wywołał, ile to kosztowało i czy wynik był poprawny. Bez tego odpowiedź „technicznie poprawna, merytorycznie błędna” przechodzi niezauważona. Czy OpenTelemetry ma już stabilny standard dla AI? Nie. Konwencje semantyczne dla generatywnej AI mają status Development (stan na 6.10.2026). Od wydania v1.42.0 głównych konwencji żyją w osobnym repozytorium semantic-conventions-genai, które nie ma jeszcze żadnego wydania. Warto ich używać, ale trzeba liczyć się ze zmianą nazw atrybutów i metryk. Czy do obserwowalności AI potrzebny jest Langfuse albo LangSmith? Nie zawsze. Ślady wywołań modelu można zbierać przez OpenTelemetry i oglądać w narzędziach, które firma już ma, na przykład w Grafanie albo w platformie APM. Narzędzia specjalizowane, takie jak Langfuse, LangSmith czy Phoenix, dokładają widok rozmowy, zbiory testowe i ewaluacje. Są potrzebne, gdy zespół regularnie ocenia jakość odpowiedzi. Czy można zapisywać treść promptów i odpowiedzi? Technicznie tak, ale w konwencjach OpenTelemetry zapis treści jest opcjonalny (opt-in), bo prompty i odpowiedzi mogą zawierać dane osobowe. Firma musi ustalić, co maskuje, jak długo przechowuje ślady i kto ma do nich dostęp. Ocenę zgodności z RODO zostawcie prawnikowi i inspektorowi ochrony danych. Co to jest ewaluacja offline i online? Ewaluacja offline to test przed zmianą: nowa wersja agenta odpowiada na stały zestaw przypadków, a wynik porównuje się ze starą wersją. Ewaluacja online to ocena działającego systemu na prawdziwym ruchu: próbka odpowiedzi oceniana przez człowieka, regułę albo model, plus oceny użytkowników. Potrzebne są obie. Czy model może oceniać odpowiedzi innego modelu? Może, i to przyspiesza ocenę dużej liczby odpowiedzi. Model oceniający też się jednak myli, więc jego oceny trzeba co jakiś czas porównać z oceną człowieka na tej samej próbce. Przy decyzjach o dużym skutku ostatnie słowo powinien mieć człowiek. Kto w firmie odpowiada za obserwowalność systemu AI? IT odpowiada za instrumentację, przechowywanie danych i dostęp. Właściciel procesu odpowiada za definicję dobrej odpowiedzi, zestaw testowy i progi, po których przekroczeniu system trzeba zatrzymać. Zespół bezpieczeństwa obsługuje incydenty. Narzędzie pokazuje dane, ale nie decyduje, co jest błędem. ## Czytaj dalej - [Datadog w suwerennym AI OS](https://majchrzycki.com/blog/datadog-obserwowalnosc-ai) - [Langfuse w suwerennym AI OS](https://majchrzycki.com/blog/langfuse-ewaluacja-agentow) - [Splunk w suwerennym AI OS](https://majchrzycki.com/blog/splunk-obserwowalnosc-ai) - [TheHive w AI OS: obsługa incydentów i koszt licencji](https://majchrzycki.com/blog/thehive-reagowanie-incydenty-ai-os)