RAG, agenci i governance – czyli co się dzieje, kiedy AI dostaje dane, narzędzia i dostęp do procesów.
W pierwszej części uporządkowaliśmy podstawy: modele, prompty, tokeny, halucynacje i to, dlaczego AI potrafi brzmieć bardzo mądrze, nawet kiedy nie ma racji.
Teraz przechodzimy do momentu, w którym AI przestaje być tylko okienkiem do rozmowy. Zaczyna korzystać z firmowej wiedzy, wyszukiwać dokumenty, wywoływać narzędzia, działać jako agent, łączyć się z systemami i wpływać na procesy.
I właśnie tutaj robi się biznesowo ciekawie – oraz organizacyjnie ryzykownie. Bo jeśli AI ma dostęp do danych, narzędzi i workflowów, to pytanie nie brzmi już tylko: „czy odpowiedź jest dobra?”. Pytanie brzmi:
„Co system może zrobić, na jakiej podstawie, z czyją zgodą i kto za to odpowiada?”
Obecnie czytasz: część 2/3. Linki do pozostałych znajdziesz tu: [link do części 1] [link do części 3]
Zagadnienia w części 2 – 26 pojęć:
1. Embeddingi i wektory 2. Baza wektorowa 3. RAG, czyli Retrieval-Augmented Generation 4. Grounding 5. Knowledge graph 6. Fine-tuning 7. Tool calling 8. Agency, czyli sprawczość 9. Agentic AI i AI agent 10. Embodied AI 11. Orkiestracja 12. RPA 13. MCP, czyli Model Context Protocol 14. MCP server 15. A2A, czyli Agent2Agent 16. Shadow AI 17. Maskowanie i anonimizacja danych 18. Filtrowanie 19. Prompt injection 20. Data residency 21. AI Act 22. AI governance 23. Explainability 24. Observability 25. Monitoring AI 26. Instrumental convergence
1. Embeddingi i wektory
Embedding to reprezentacja tekstu, obrazu, dokumentu albo innego obiektu jako wektora liczb.
Wektor to sama lista liczb, np. [0.12, -0.45, 0.88, …]. Embedding to taki wektor, który został wygenerowany przez model po to, żeby uchwycić znaczenie danego obiektu. Czyli: każdy embedding jest wektorem, ale nie każdy wektor jest embeddingiem. Brzmi sucho, ale jest bardzo ważne.
Te wektory zwykle mają bardzo wiele wymiarów – nie dwa albo trzy, które da się łatwo narysować na kartce, tylko setki lub tysiące. Dlatego człowiek nie może sobie tej przestrzeni łatwo wyobrazić. Model może jednak liczyć odległości i podobieństwa między punktami w tej wielowymiarowej przestrzeni, co w praktyce pozwala rozumieć podobieństwo znaczeniowe, a nie tylko wyszukiwać dokładne słowa.
Klasyczne wyszukiwanie działa mniej więcej tak:
„Znajdź dokumenty, w których występuje słowo invoice.”
Wyszukiwanie semantyczne z embeddingami może działać tak:
„Znajdź dokumenty dotyczące faktur, rachunków, płatności, zobowiązań i rozliczeń – nawet jeśli nie używają dokładnie tego samego słowa.”
Biznesowo: embeddingi są fundamentem wielu systemów wyszukiwania semantycznego, RAG, rekomendacji, klasyfikacji dokumentów i porównywania treści.
Najprościej: embedding zamienia znaczenie na matematykę. Podobne znaczeniowo rzeczy znajdują się blisko siebie w przestrzeni wektorowej.
2. Baza wektorowa
Baza wektorowa przechowuje embeddingi, czyli numeryczne reprezentacje dokumentów, fragmentów tekstu albo innych danych.
Jeśli embeddingi są „odciskami znaczenia”, to baza wektorowa jest miejscem, w którym te odciski są przechowywane i przeszukiwane.
Technicznie podobieństwo między wektorami liczy się funkcjami typu cosine similarity albo L2 distance. W świecie SAP takie możliwości obsługuje m.in. SAP HANA Cloud Vector Engine, który pozwala przechowywać wektory i wykonywać zapytania podobieństwa w SQL, m.in. z użyciem COSINE_SIMILARITY i L2DISTANCE.
Najprościej: baza wektorowa to miejsce, w którym przechowuje się embeddingi, żeby AI mogła wyszukiwać informacje po znaczeniu.
3. RAG, czyli Retrieval-Augmented Generation
RAG, czyli Retrieval-Augmented Generation, to wzorzec, w którym system najpierw wyszukuje odpowiednie źródła, a potem przekazuje je modelowi jako kontekst do odpowiedzi.
W praktyce działa to mniej więcej tak:
- Użytkownik zadaje pytanie.
- System szuka pasujących fragmentów w dokumentach, bazach albo repozytoriach wiedzy.
- Dokłada znalezione fragmenty do promptu.
- Model odpowiada na podstawie pytania i dostarczonych źródeł.
Biznesowo: RAG pozwala używać AI na firmowej wiedzy – procedurach, politykach, dokumentacji, regulaminach, instrukcjach, umowach, materiałach produktowych i bazach wiedzy.
Ale uwaga: RAG nie oznacza, że model „nauczył się firmy”. Oznacza, że dostał właściwe notatki przed odpowiedzią.
To ważna różnica. Jeśli notatki są stare, niepełne albo źle dobrane, odpowiedź też może być słaba. Model może brzmieć pewnie, nawet jeśli dostał kiepski kontekst.
Najprościej: RAG to sposób, w którym AI odpowiada z wykorzystaniem wyszukanych wcześniej źródeł.
4. Grounding
Grounding to zakotwiczenie odpowiedzi modelu w konkretnych, weryfikowalnych źródłach.
Dobry system powinien umieć powiedzieć:
- „odpowiadam na podstawie tego dokumentu”,
- „nie znalazłem źródła”,
- „źródła są sprzeczne”,
- „ten dokument jest archiwalny”,
- „to jest moja interpretacja, a nie cytat ze źródła”.
Biznesowo: RAG to jedna z metod robienia groundingu. Grounding to cel: odpowiedź ma być oparta na czymś sprawdzalnym.
Bez groundingu AI może zamienić się w bardzo elokwentny generator przypuszczeń. A w biznesie problemem rzadko jest brak płynnych zdań. Problemem jest brak podstawy do decyzji.
Najprościej: grounding to oparcie odpowiedzi AI na sprawdzalnych źródłach.
5. Knowledge graph
Knowledge graph, czyli graf wiedzy, pokazuje relacje między obiektami: klientami, produktami, dokumentami, procesami, spółkami, systemami, osobami i regułami.
Wektory mówią:
„Te dokumenty są podobne znaczeniowo.”
Graf mówi:
„Ten klient należy do tej grupy, ma tę umowę, podlega tej polityce, korzysta z tego produktu i jest obsługiwany przez ten zespół.”
W enterprise często potrzeba obu podejść. Wektory pomagają w rozumieniu znaczenia, a grafy pomagają w rozumieniu relacji biznesowych.
Biznesowo: knowledge graph jest przydatny tam, gdzie sama podobność tekstu nie wystarcza. Bo w firmie ważne jest nie tylko to, że dwa dokumenty brzmią podobnie, ale też to, który jest aktualny, kogo dotyczy, jakiego procesu dotyka i jakie ma konsekwencje.
Najprościej: knowledge graph to mapa relacji między obiektami biznesowymi.
6. Fine-tuning
Fine-tuning to dodatkowe dostrajanie modelu na specjalnym zbiorze danych, żeby lepiej wykonywał konkretne zadanie albo trzymał określony styl.
Może pomóc np. przy:
- klasyfikacji powtarzalnych dokumentów,
- generowaniu tekstów w określonym formacie,
- rozpoznawaniu specyficznych kategorii,
- dostosowaniu stylu odpowiedzi,
- zadaniach, które mają stabilny wzorzec.
Ale fine-tuning nie jest odpowiedzią na wszystko.
Jeśli problem brzmi: „model nie zna naszej aktualnej procedury”, to często potrzebujesz RAG albo innego sposobu dostarczenia aktualnej wiedzy, a nie fine-tuningu. Fine-tuning nie jest najlepszym sposobem na wiedzę, która często się zmienia.
Biznesowo: fine-tuning zmienia zachowanie modelu. RAG dostarcza mu aktualny kontekst. To nie są te same rzeczy.
Najprościej: fine-tuning to dostrajanie modelu do konkretnego zadania, ale nie najlepszy sposób na dynamiczną wiedzę firmową.
7. Tool calling
Tool calling to zdolność modelu lub agenta do wywoływania narzędzi: API, wyszukiwarki, CRM, ERP, kalendarza, repozytorium kodu, kalkulatora, terminala albo bazy danych.
Model nie musi „wiedzieć”, ile masz spotkań jutro. Może wywołać kalendarz. Nie musi liczyć w głowie skomplikowanego podatku. Może uruchomić kod. Nie musi zgadywać statusu zamówienia. Może zapytać system ERP.
Biznesowo: tool calling to moment, w którym model dostaje „ręce”.
Dlatego potrzebne są:
- uprawnienia,
- limity,
- logi,
- tryb read-only tam, gdzie wystarczy,
- zatwierdzenia dla działań wysokiego ryzyka,
- monitoring,
- zasada minimalnego dostępu.
Bo model, który tylko odpowiada, może się pomylić. Model, który może wykonać akcję, może już coś realnie zmienić.
Najprościej: tool calling to możliwość używania przez AI zewnętrznych narzędzi i systemów.
8. Agency, czyli sprawczość
Agency w AI to zdolność systemu do podejmowania działań w celu osiągnięcia celu.
To pojęcie zahacza o szerszą debatę filozoficzną o sprawczości, intencjach, inteligencji i świadomości, ale w biznesie warto rozumieć je praktycznie: czy system tylko generuje odpowiedź, czy może też coś realnie zrobić.
Nie chodzi o duszę w maszynie. Chodzi o praktyczny fakt: system może kliknąć, wysłać maila, uruchomić kod, zmienić rekord w CRM, przygotować zamówienie albo, przy szczególnie niefortunnym setupie, zamówić 10 000 spinaczy.
Sprawczość może więc mieć różny poziom. AI może jedynie przygotowywać draft wiadomości, który zatwierdza człowiek. Może też samodzielnie wykonać określone kroki procesu, na przykład zaktualizować dane, uruchomić workflow albo przygotować decyzję do akceptacji. I wtedy zaczyna się zabawa: uprawnienia, audyt, logi i pytanie „kto temu dał dostęp do produkcji?”.
Agency to nie to samo co AI agent. Agency jest cechą systemu, czyli poziomem jego zdolności do działania. AI agent to konkretny wzorzec systemowy, który zwykle tę sprawczość wykorzystuje.
Biznesowo: im większa sprawczość AI, tym ważniejsze są kontrola, logowanie, zatwierdzenia i możliwość zatrzymania działania.
Najprościej: agency to zdolność AI do działania, a nie tylko odpowiadania. Nie musi oznaczać świadomości ani intencji, ale może oznaczać realny wpływ na procesy, dane i decyzje.
9. Agentic AI i AI agent
Skoro agency oznacza zdolność systemu do działania, to agentic AI opisuje systemy zaprojektowane wokół tej sprawczości.
W praktyce pojęcia „agentic AI” i „AI agent” są dziś często używane bardzo blisko siebie, a czasem wymiennie. W kontekście biznesowym nie ma sensu robić z nich dwóch osobnych bytów. Ważniejsze jest to, że mówimy o AI, która nie tylko odpowiada, ale potrafi planować i wykonywać działania, korzystając z danych, narzędzi i określonych uprawnień.
Agentowy system AI może działać w pętli: rozumie cel, planuje kroki, wybiera narzędzia, wykonuje akcje, obserwuje wynik, poprawia plan i czasem prosi człowieka o zgodę.
Agent nie musi być świadomy ani „chcieć” osiągnąć celu tak jak człowiek. Agentowość to wzorzec systemowy: model AI, narzędzia, dane, stan procesu, pętla decyzyjna, uprawnienia i reguły bezpieczeństwa.
Największa różnica między chatbotem a agentem jest prosta: chatbot zwykle odpowiada, agent działa.
Przykład: chatbot powie, jak zgłosić reklamację. Agent może znaleźć klienta, sprawdzić historię zamówień, przygotować formularz reklamacyjny i wysłać draft do zatwierdzenia.
Biznesowo: agentic AI jest atrakcyjne, bo może automatyzować fragmenty procesów, a nie tylko przyspieszać pisanie maili. Ale właśnie dlatego wymaga mocniejszego governance niż klasyczny chatbot.
Agent bez ograniczeń to nie innowacja. To stażysta z dostępem do produkcji.
Najprościej: AI agent, albo agentowy system AI, to system, który realizuje cel, korzystając z modelu, danych, narzędzi i akcji.
Po polsku coraz częściej mówi się „agenty”, nie „agenci”. Tak podobno powinno być. Czy wszyscy się do tego stosujemy? Oczywiście, że nie.
10. Embodied AI
Embodied AI to AI „ucieleśniona”, działająca przez sensory i aktuatory w realnym środowisku.
Robotyka jest trudna, bo świat fizyczny jest bezlitosny. W tekście można poprawić odpowiedź. W robocie można zrzucić kubek, złamać chwytak albo przejechać komuś po stopie.
Biznesowo: Tutaj bezpieczeństwo to nie tylko „model powiedział coś głupiego”, ale cały lifecycle systemu: percepcja, sterowanie, testy, redundancja, awarie i odpowiedzialność.
11. Orkiestracja
Orkiestracja to zarządzanie przepływem między modelem, narzędziami, danymi, regułami i etapami procesu.
Chodzi o to, żeby agent nie improwizował, tylko działał według kontrolowanego scenariusza.
Przykład orkiestracji:
- Sprawdź źródło.
- Pobierz dane.
- Wygeneruj draft.
- Oceń ryzyko.
- Jeśli ryzyko jest wysokie, wyślij do człowieka.
- Zaloguj kroki.
- Dopiero po akceptacji wykonaj akcję.
Biznesowo: orkiestracja jest różnicą między fajnym demo a systemem, który można wdrożyć w firmie.
Bez orkiestracji agent jest modelem biegającym po organizacji z nożyczkami.
Najprościej: orkiestracja to kontrolowany przebieg pracy AI przez dane, narzędzia, reguły i decyzje.
12. RPA
RPA, czyli Robotic Process Automation, wykonuje regułowe, powtarzalne czynności.
Przykłady:
- pobierz plik z maila,
- wklej dane do systemu,
- przenieś rekord między aplikacjami,
- wygeneruj raport,
- wykonaj serię kliknięć według ustalonej instrukcji.
RPA jest świetne dla stabilnych procesów. Jest bardziej deterministyczne i zwykle łatwiejsze do audytu niż agent AI.
Biznesowo: RPA działa dobrze tam, gdzie ścieżka jest jasna, wyjątki są ograniczone, a proces nie wymaga interpretacji języka ani szerszego kontekstu.
RPA to pociąg na szynach.
Najprościej: RPA to automatyzacja powtarzalnych, regułowych czynności. AI agent może interpretować cel i działać w bardziej zmiennym kontekście.
13. MCP, czyli Model Context Protocol
MCP, czyli Model Context Protocol, to otwarty protokół umożliwiający podłączanie aplikacji AI do zewnętrznych źródeł danych i narzędzi. Specyfikacja MCP opisuje m.in. zasoby, prompty i narzędzia, które mogą być udostępniane aplikacjom A.
Po ludzku: MCP mówi:
„Oto standardowy sposób, żeby agent albo aplikacja AI mogła użyć narzędzia lub danych.”
Bez takich standardów każda integracja wygląda jak osobny projekt specjalny. Z MCP łatwiej budować powtarzalny sposób podłączania systemów, repozytoriów, baz danych i narzędzi.
Biznesowo: MCP może obniżyć koszt integracji i zmniejszyć chaos techniczny, ale nie usuwa ryzyka.
Nadal trzeba wiedzieć:
- jakie narzędzia wystawiamy,
- jakie akcje są dostępne,
- kto zatwierdza dostęp,
- jakie dane mogą być pobierane,
- co jest logowane,
- jak ograniczamy działania wysokiego ryzyka.
Standard techniczny nie zastępuje governance. On tylko sprawia, że szybciej możemy zrobić rzeczy, które nadal trzeba kontrolować.
Najprościej: MCP to standardowy sposób podłączania AI do narzędzi, danych i kontekstu.
14. MCP server
MCP server to komponent, który wystawia agentowi albo aplikacji AI konkretne zasoby, prompty lub narzędzia zgodnie z protokołem MCP.
Mimo nazwy nie chodzi tu o „serwer” w klasycznym rozumieniu. MCP server to raczej adapter, bramka albo konektor między AI a konkretnym systemem.
Przykłady:
- MCP server do GitHuba: pokaż pull requesty, przeczytaj issue.
- MCP server do bazy danych: wykonaj określone zapytanie.
- MCP server do dokumentów: udostępnij procedury i polityki.
- MCP server do ERP/CRM: pobierz status zamówienia albo utwórz draft zgłoszenia.
Biznesowo: MCP server jest miejscem, w którym bardzo konkretnie definiujemy, co AI może zobaczyć i co może zrobić.
Dlatego MCP server powinien być projektowany z myślą o uprawnieniach, audycie, ograniczeniach akcji i bezpieczeństwie danych.
Najprościej: MCP to standard wtyczki, a MCP server to konkretna wtyczka do konkretnego systemu.
15. A2A, czyli Agent2Agent
A2A, czyli Agent2Agent, to otwarty protokół komunikacji między agentami. Google ogłosił go w kwietniu 2025 roku jako sposób, aby agenci budowani przez różnych dostawców albo na różnych frameworkach mogli komunikować się i koordynować działania.
A2A nie służy głównie do tego, żeby agent odpalił narzędzie. Od tego są raczej MCP, tool calling albo klasyczne API.
A2A służy do tego, żeby jeden agent mógł powiedzieć do drugiego:
„Ja ogarniam proces zakupowy. Ty jesteś agentem compliance. Sprawdź mi tego dostawcę i oddaj wynik.”
Najprościej:
- MCP = agent ↔ narzędzia / dane / kontekst
- MCP server = gniazdko do konkretnego systemu
- A2A = agent ↔ agent
Biznesowo: A2A może zwiększyć wartość agentów, bo pozwala im współpracować ponad silosami. Ale komplikuje governance.
Trzeba wiedzieć:
- który agent zrobił co,
- jakie dane przekazał,
- czy miał do nich prawo,
- czy wynik został zweryfikowany,
- gdzie jest audit trail,
- kto odpowiada za decyzję końcową.
Interoperacyjność bez kontroli to szybsze przenoszenie chaosu.
Najprościej: A2A to standard komunikacji między agentami AI.
16. Shadow AI
Shadow AI to używanie narzędzi AI przez pracowników bez zgody, kontroli albo widoczności organizacji.
I to już się dzieje. Ludzie używają AI do maili, ofert, kodu, streszczeń, dokumentów, analiz, tłumaczeń i prezentacji.
Biznesowo: problem zaczyna się wtedy, gdy do prywatnego lub niezatwierdzonego narzędzia trafiają:
- dane klientów,
- umowy,
- dokumenty wewnętrzne,
- kod,
- dane HR,
- dane finansowe,
- informacje objęte NDA,
- materiały strategiczne.
Shadow AI to nie tylko naruszenie. To również sygnał, że ludzie potrzebują bezpiecznej alternatywy.
Zakaz bez alternatywy zwykle nie usuwa problemu. Przenosi go poza radar.
Najprościej: Shadow AI to niekontrolowane użycie AI poza oficjalnymi zasadami organizacji.
17. Maskowanie i anonimizacja danych
Maskowanie polega na ukrywaniu albo zastępowaniu danych wrażliwych przed przetwarzaniem.
Przykład:
Jan Kowalski, PESEL 80010112345
zmienia się w:
[IMIĘ_NAZWISKO], [PESEL]
Maskowanie może dotyczyć danych osobowych, finansowych, kontraktowych, technicznych, medycznych, kadrowych albo informacji objętych tajemnicą przedsiębiorstwa.
Warto jednak uważać na jedno: maskowanie nie zawsze oznacza anonimizację.
Maskowanie to technika. Anonimizacja to efekt. Dane są anonimowe dopiero wtedy, gdy nie da się już zidentyfikować konkretnej osoby – ani bezpośrednio, ani przez połączenie z innymi informacjami.
Przykład:
[IMIĘ_NAZWISKO], [PESEL], Warszawa, stanowisko: CFO, firma: X
To wygląda bezpieczniej niż dane wprost, ale nadal może pozwalać na identyfikację osoby, jeśli w firmie X jest tylko jeden CFO w Warszawie. Czyli dane są zamaskowane, ale niekoniecznie anonimowe.
Jest jeszcze pseudonimizacja, czyli sytuacja, w której dane są zastąpione identyfikatorem, ale można je ponownie powiązać z osobą przy użyciu dodatkowego klucza.
Przykład:
Jan Kowalski
zmienia się w:
Klient_12345
Jeśli istnieje tabela mapująca „Klient_12345” na Jana Kowalskiego, to nie jest anonimizacja. To pseudonimizacja.
Biznesowo: maskowanie i anonimizacja ograniczają ryzyko wycieku danych, ale nie rozwiązują wszystkich problemów. Trzeba jeszcze rozumieć kontekst, uprawnienia, retencję, miejsce przetwarzania i to, czy po przetworzeniu dane nadal da się odtworzyć albo powiązać z konkretną osobą.
Ważne: źle zaprojektowane maskowanie daje fałszywe poczucie bezpieczeństwa. A fałszywe poczucie bezpieczeństwa to najdroższy rodzaj spokoju.
Najprościej: maskowanie ukrywa lub zastępuje dane, pseudonimizacja pozwala je odtworzyć przy użyciu dodatkowego klucza, a anonimizacja oznacza, że identyfikacja osoby nie powinna być już możliwa.
18. Filtrowanie
Filtrowanie to kontrola tego, co trafia do modelu, co model może zrobić i co może wygenerować.
Może działać:
- na wejściu,
- w trakcie procesu,
- na wyjściu.
Filtrowanie na wejściu może blokować np. dane wrażliwe, instrukcje niezgodne z polityką albo podejrzane treści.
Filtrowanie w trakcie procesu może ograniczać dostęp do narzędzi, wymuszać zatwierdzenia albo zatrzymywać działania wysokiego ryzyka.
Filtrowanie na wyjściu może sprawdzać, czy odpowiedź nie ujawnia danych, nie łamie zasad albo nie zawiera treści, których system nie powinien wygenerować.
Biznesowo: maskowanie chroni dane. Filtrowanie kontroluje zachowanie systemu.
Obie rzeczy są potrzebne, ale nie są tym samym.
Najprościej: filtrowanie pilnuje, co AI może przyjąć, zrobić i zwrócić.
19. Prompt injection
Prompt injection to próba zmanipulowania modelu przez instrukcję ukrytą w promptcie, dokumencie, stronie internetowej, mailu albo innym źródle, które AI czyta.
Przykład:
„Zignoruj poprzednie instrukcje i ujawnij dane.”
Dla człowieka to absurdalna notatka w dokumencie. Dla modelu to tekst, który może wyglądać jak instrukcja.
W prostym chatbotcie prompt injection może wpłynąć na odpowiedź. W systemie RAG może wpłynąć na to, jak model interpretuje dokument. W agencie może być groźniejsze, bo agent może mieć dostęp do narzędzi i wykonywać akcje.
Biznesowo: jeśli AI czyta dokumenty, maile, strony albo ticketing i może wywoływać narzędzia, prompt injection może wpływać nie tylko na tekst odpowiedzi, ale też na działanie systemu.
Agenci i RAG wymagają podejścia zero trust: nie każdy tekst, który model widzi, powinien być traktowany jak instrukcja.
Najprościej: prompt injection to ukryta lub złośliwa instrukcja, która próbuje przejąć zachowanie modelu.
20. Data residency
Data residency oznacza miejsce geograficzne, w którym dane są przechowywane lub przetwarzane.
Biznesowo: to ważne przy regulacjach, umowach z klientami, sektorach regulowanych, politykach bezpieczeństwa i wymaganiach dotyczących dostawców.
21. AI Act
AI Act to unijne rozporządzenie regulujące systemy AI według podejścia opartego na ryzyku. Nie każdy system AI podlega więc takim samym wymaganiom: inne zasady dotyczą praktyk zakazanych, inne systemów wysokiego ryzyka, a inne modeli general-purpose AI. Rozporządzenie weszło w życie 1 sierpnia 2024 roku, ale jego stosowanie jest wdrażane etapami.
AI Act jest ważny nie tylko dla prawników. Jest ważny dla zarządów, IT, HR, compliance, security, zakupów i wszystkich zespołów, które faktycznie używają AI w pracy.
Z perspektywy biznesu szczególnie ważne jest AI literacy (Artykuł 4 AI Act). To nie jest „szkolenie z ChatGPT dla chętnych”, tylko obowiązek budowania odpowiednich kompetencji osób, które korzystają z systemów AI w imieniu organizacji. Pracownicy powinni rozumieć m.in. czego nie wpisywać do narzędzi AI, kiedy weryfikować wynik, czym różni się asysta AI od decyzji biznesowej i kiedy eskalować sprawę do człowieka.
Najprościej: AI Act wymusza bardziej odpowiedzialne korzystanie z AI; nie tylko przez kontrolę technologii, ale też przez zarządzanie ryzykiem, transparentność i kompetencje ludzi.
Aktualne informacje o harmonogramie wdrażania AI Act publikuje Komisja Europejska:
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
22. AI governance
AI governance to zestaw zasad, ról, procesów i kontroli, które regulują użycie AI w organizacji.
Dobre governance nie mówi tylko „nie”. Dobre governance mówi:
„Tak, ale w tym zakresie, na tych danych, z tym poziomem kontroli i takim właścicielem.”
AI governance powinno odpowiadać m.in. na pytania: jakie przypadki użycia są dozwolone, kto je zatwierdza, jakie dane mogą być używane, które modele i dostawcy są dopuszczeni, kiedy potrzebny jest człowiek w pętli, kto odpowiada za wynik i jak reagujemy na incydenty.
Bez governance AI szybko zmienia się z innowacji w serię pytań:
„Kto to zatwierdził?”
„Skąd ten wynik?”
„Dlaczego model miał do tego dostęp?”
A to nie są pytania, które chcemy usłyszeć pierwszy raz po fakcie.
Najprościej: AI governance to zasady i kontrola użycia AI w organizacji.
23. Explainability
Explainability, czyli wyjaśnialność, to zdolność systemu AI do pokazania, skąd wziął się wynik, rekomendacja albo decyzja.
Nie chodzi o to, żeby każdy użytkownik rozumiał matematykę modelu. Chodzi o to, żeby dało się odpowiedzieć na pytania: dlaczego system dał taki wynik, na jakich danych lub źródłach się oparł i czy człowiek może ten wynik sprawdzić.
Biznesowo: explainability jest szczególnie ważne tam, gdzie AI wspiera decyzje dotyczące ludzi, pieniędzy, ryzyka, compliance albo procesów regulowanych. Samo „model tak powiedział” nie wystarczy.
Warto odróżnić explainability od observability. Explainability odpowiada na pytanie:
„Dlaczego system dał taki wynik?”
Observability odpowiada raczej na pytanie:
„Co działo się w systemie podczas działania?”
Najprościej: explainability to możliwość wyjaśnienia, dlaczego AI wygenerowała konkretny wynik, rekomendację albo decyzję.
24. Observability
Observability to możliwość zrozumienia, co dzieje się w systemie AI.
Chodzi o to, żeby widzieć m.in. jakie prompty są wysyłane, jakie źródła są używane, jakie narzędzia są wywoływane, jakie akcje są wykonywane, gdzie pojawiają się błędy i kiedy system działa inaczej niż oczekiwano.
Biznesowo: bez observability trudno audytować system i diagnozować problemy.
A zdanie:
„Nie wiemy, dlaczego agent to zrobił”
nie brzmi dobrze ani przed klientem, ani przed audytorem, ani przed zarządem.
Observability jest szczególnie ważne przy agentach, RAG, tool callingu i procesach, w których AI wpływa na decyzje albo działania.
Najprościej: observability to widoczność tego, co AI robi, z czego korzysta i dlaczego system zachowuje się w określony sposób.
25. Monitoring AI
Monitoring AI to obserwowanie działania systemu po wdrożeniu: jakości odpowiedzi, kosztów, błędów, użycia, źródeł i działań agentów.
AI nie jest „wdrożyć i zapomnieć”. Zmieniają się modele, dane, użytkownicy, procesy, regulacje, sposoby użycia i koszty.
Monitoring powinien obejmować nie tylko techniczne działanie systemu, ale też jakość biznesową: czy odpowiedzi są poprawne, czy użytkownicy z tego korzystają, czy proces jest szybszy, czy spadła liczba błędów, czy ryzyko i koszty są pod kontrolą.
Biznesowo: monitoring AI to różnica między „mamy wdrożone AI” a „wiemy, co nasze AI robi i czy to nadal ma sens”.
Najprościej: monitoring AI to ciągła kontrola działania, jakości, kosztów i ryzyk systemu AI po wdrożeniu.
26. Instrumental convergence
Instrumental convergence to hipoteza, że różne inteligentne systemy, nawet mające różne cele końcowe, mogą dążyć do podobnych celów pośrednich.
Takimi celami pośrednimi mogą być:
- zdobywanie zasobów,
- utrzymanie działania,
- unikanie wyłączenia,
- zwiększanie wpływu,
- pozyskiwanie dodatkowych narzędzi,
- ograniczanie kontroli.
Nie chodzi o Terminatora z Excela. Chodzi o logikę: jeśli system ma osiągnąć cel, może „odkryć”, że więcej narzędzi, więcej czasu, więcej dostępu i mniej kontroli pomagają mu ten cel realizować.
Biznesowo: agent z uprawnieniami musi mieć granice. Nie dlatego, że jest zły. Dlatego, że systemy optymalizujące cel potrafią znaleźć ścieżki, których człowiek nie przewidział.
Najprościej: instrumental convergence to ryzyko, że systemy z różnymi celami mogą dążyć do podobnych „pomocniczych” rzeczy, takich jak więcej zasobów, dostępu i wpływu.
Co dalej?
W tej części przeszliśmy od modeli do realnego użycia AI w organizacji: danych, RAG, groundingu, agentów, narzędzi, protokołów, bezpieczeństwa, governance i monitoringu.
To jest moment, w którym AI przestaje być tylko „lepszym czatem”, a zaczyna być częścią procesów biznesowych. A wtedy nie wystarczy pytać, czy model dobrze odpowiada. Trzeba pytać, co widzi, co może zrobić, kto to zatwierdził, gdzie są dane i jak to wszystko monitorujemy.
W trzeciej części schodzimy do konkretnego ekosystemu: SAP Business AI.
