Interaktywny ebook AI: pojęcia i legenda

AB testy polegają na porównaniu dwóch wersji rozwiązania. Obie wersje działają w tych samych warunkach. Dzięki temu można sprawdzić, która działa lepiej.

Scenariusz 1: Poprawa skuteczności asystenta

• Cel: poprawa skuteczności asystenta.
• Wejście: dwie instrukcje systemowe.
• Kroki: uruchom A/B -> mierz jakość -> wybierz wersję.
• Rezultat: lepsza odpowiedź.
• Zabezpieczenie: stałe kryteria oceny.

Scenariusz 2: Poprawa FAQ

• Cel: poprawa FAQ.
• Wejście: dwie wersje tekstu.
• Kroki: test ruchu -> pomiar -> decyzja.
• Rezultat: wyższa skuteczność.
• Zabezpieczenie: kontrola stronniczości grup.

Scenariusz 3: Optymalizacja automatyzacji

• Cel: optymalizacja automatyzacji.
• Wejście: dwa przepływy pracy.
• Kroki: test czasu i błędów -> analiza -> wdrożenie.
• Rezultat: sprawniejszy proces.
• Zabezpieczenie: plan wycofania zmian.

Ryzyko 1: Błędna interpretacja

• Ryzyko: Błędna interpretacja.
• Jak ograniczać: ustal metryki i sprawdź istotność statystyczną.

Ryzyko 2: Stronniczość grup

• Ryzyko: Stronniczość grup.
• Jak ograniczać: stosuj losowy podział i kontroluj rozkład.

Ryzyko 3: Złe wdrożenie

• Ryzyko: Złe wdrożenie.
• Jak ograniczać: wprowadzaj zmiany stopniowo i prowadź monitoring.

• Czy jest jedna zmienna testowa?
• Czy metryki są zdefiniowane?
• Czy próbka jest wystarczająca?
• Czy masz plan rollbacku?
• Czy wyniki są udokumentowane?

• Wersja A i wersja B są testowane na podobnych danych lub grupach.
• Metryki pokazują, która wersja daje lepszy wynik.
• To metoda decyzji oparta na danych, nie na intuicji.

• Za mała próbka testowa.
• Zmiana wielu zmiennych na raz.
• Brak kryteriów sukcesu.

Diagram pokazuje, że A/B test polega na porównaniu dwóch wersji w tych samych warunkach, zebraniu metryk i wyborze lepszego wariantu po analizie wyników.

• Benchmark
• Ewaluacja (evaluation)
• Monitoring jakości
• Fact-checking (weryfikacja faktów)
• Human-in-the-loop (człowiek w pętli)

Agent AI to system, który planuje i wykonuje zadania. Często korzysta z narzędzi i danych zewnętrznych. Może przejść przez kilka kroków zamiast udzielić jednej odpowiedzi. To opis sposobu działania aplikacji, a nie pojedynczego modelu.

Scenariusz 1: Automatyzacja raportu tygodniowego

• Cel: automatyzacja raportu tygodniowego.
• Wejście: dane z CRM i narzędzia BI.
• Kroki: pobierz -> podsumuj -> wyślij.
• Rezultat: raport na czas.
• Zabezpieczenie: zatwierdzenie przed wysyłką.

Scenariusz 2: Obsługa zgłoszeń

• Cel: obsługa zgłoszeń.
• Wejście: zgłoszenie.
• Kroki: klasyfikacja -> propozycja odpowiedzi -> eskalacja.
• Rezultat: szybsza obsługa.
• Zabezpieczenie: człowiek w pętli.

Scenariusz 3: Porządkowanie dokumentów

• Cel: porządkowanie dokumentów.
• Wejście: folder z plikami.
• Kroki: analiza → tagowanie → archiwizacja.
• Rezultat: uporządkowana baza.
• Zabezpieczenie: ograniczenia uprawnień.

Ryzyko 1: Niepożądane działania

• Ryzyko: Niepożądane działania.
• Jak ograniczać: ograniczenia narzędzi i uprawnień.

Ryzyko 2: Błędy w automatyzacji

• Ryzyko: Błędy w automatyzacji.
• Jak ograniczać: przegląd wyników i testy.

Ryzyko 3: Brak śladu audytowego

• Ryzyko: Brak śladu audytowego.
• Jak ograniczać: logowanie kroków.

• Czy agent ma minimalne uprawnienia?
• Czy wiesz, jakie narzędzia może uruchamiać?
• Czy jest kontrola człowieka w kluczowych krokach?
• Czy logujesz wszystkie działania?
• Czy masz plan awaryjny?

• Agent AI to „samodzielny wykonawca”, który realizuje cel krok po kroku.
• Może pobierać dane, uruchamiać akcje i tworzyć wyniki.
• Wymaga jasnych granic i kontroli, bo działa bardziej autonomicznie.
• Najlepiej sprawdza się w dobrze zdefiniowanych procesach.

• Zbyt szerokie uprawnienia agenta.
• Brak logowania działań.
• Zaufanie bez weryfikacji.

Diagram pokazuje, że agent AI nie tylko odpowiada, ale planuje kroki, używa narzędzi i przekazuje wynik do zatwierdzenia.

• Asystent AI
• Orkiestracja
• Human-in-the-loop
• Audit trail
• Guardrails

AI Act to unijne rozporządzenie regulujące sztuczną inteligencję. Wprowadza podejście oparte na poziomie ryzyka i określa obowiązki dla wybranych systemów AI oraz modeli ogólnego przeznaczenia.

Scenariusz 1: Weryfikacja systemu do oceny wniosków

• Cel: sprawdzić, czy system używany w urzędzie albo firmie podlega szczególnym obowiązkom.
• Wejście: opis systemu, jego funkcje, dane wejściowe i proces decyzyjny.
• Kroki: analiza zastosowania -> ocena poziomu ryzyka -> decyzja o wymaganiach.
• Rezultat: wiadomo, czy potrzebna jest dokumentacja, nadzór i dodatkowe kontrole.
• Zabezpieczenie: przegląd prawny i udział właściciela procesu.

Scenariusz 2: Zakup gotowego narzędzia AI od dostawcy

• Cel: ocenić, czy kupowane rozwiązanie spełnia wymagania regulacyjne.
• Wejście: oferta dostawcy, opis produktu, warunki korzystania i deklaracje zgodności.
• Kroki: przegląd umowy -> ocena obowiązków -> sprawdzenie dokumentacji dostawcy.
• Rezultat: mniejsze ryzyko zakupu narzędzia, którego nie da się bezpiecznie wdrożyć.
• Zabezpieczenie: checklista zakupowa i zapis o odpowiedzialności dostawcy.

Scenariusz 3: Wdrożenie modelu do wsparcia rekrutacji

• Cel: ocenić, czy użycie AI w procesie kadrowym wymaga dodatkowych zabezpieczeń.
• Wejście: opis funkcji modelu, zakres decyzji i dane kandydatów.
• Kroki: analiza procesu -> ocena wpływu na osoby -> decyzja o dopuszczalności użycia.
• Rezultat: wiadomo, czy rozwiązanie można wdrożyć i w jakiej formie.
• Zabezpieczenie: human-in-the-loop i dokumentacja decyzji.

Ryzyko 1: Błędna klasyfikacja systemu

• Ryzyko: błędna klasyfikacja systemu.
• Jak ograniczać: prowadź ocenę ryzyka przed wdrożeniem.

Ryzyko 2: Brak zgodności formalnej

• Ryzyko: brak zgodności formalnej.
• Jak ograniczać: twórz dokumentację i przypisz właściciela procesu.

Ryzyko 3: Użycie niedozwolonego zastosowania

• Ryzyko: użycie niedozwolonego zastosowania.
• Jak ograniczać: weryfikuj przypadki użycia przed zakupem lub uruchomieniem.

Ryzyko 4: Kary i konieczność wycofania systemu

• Ryzyko: kary i konieczność wycofania systemu.
• Jak ograniczać: łącz przegląd prawny z przeglądem operacyjnym.

• Czy wiadomo, do czego dokładnie służy system?
• Czy oceniono poziom ryzyka?
• Czy wiadomo, kto odpowiada za zgodność?
• Czy dostawca przekazał potrzebną dokumentację?
• Czy użytkownicy znają ograniczenia systemu?

To zestaw reguł mówiących, kiedy i jak można wdrażać AI w organizacji. Nie każdy system AI podlega tym samym obowiązkom. Im większe ryzyko dla ludzi, praw i bezpieczeństwa, tym więcej wymagań.

Dla organizacji oznacza to potrzebę sprawdzenia:

• czy dane rozwiązanie w ogóle podpada pod AI Act,
• jaki ma poziom ryzyka,
• jakie obowiązki trzeba spełnić przed wdrożeniem i w trakcie używania.

• Założenie, że każde narzędzie AI działa poza regulacją.
• Traktowanie AI Act jako problemu wyłącznie działu prawnego.
• Brak klasyfikacji systemu przed wdrożeniem.
• Kupowanie narzędzia bez sprawdzenia obowiązków po stronie organizacji.

Diagram pokazuje, że przed wdrożeniem AI trzeba najpierw ocenić zastosowanie, poziom ryzyka i wymagane obowiązki.

• AI Governance (Ład korporacyjny AI)

• GPAI

• RODO / DPIA

• Transparentność

• Human-in-the-loop (człowiek w pętli)

---

AI Governance to zbiór zasad, ról, procesów i mechanizmów nadzoru, które pomagają organizacji wdrażać AI w sposób bezpieczny, zgodny z prawem i kontrolowany biznesowo.

Scenariusz 1: Zatwierdzanie nowych projektów AI

• Cel: uporządkować wdrażanie nowych zastosowań AI.
• Wejście: opis projektu, dane, cel biznesowy i ryzyka.
• Kroki: zgłoszenie projektu -> ocena ryzyka -> decyzja o wdrożeniu.
• Rezultat: wiadomo, które projekty mogą wejść do realizacji.
• Zabezpieczenie: udział prawa, bezpieczeństwa i właściciela biznesowego.

Scenariusz 2: Powołanie właścicieli procesu AI

• Cel: przypisać odpowiedzialność za systemy AI.
• Wejście: lista narzędzi, zastosowań i właścicieli biznesowych.
• Kroki: identyfikacja systemów -> przypisanie ról -> opis odpowiedzialności.
• Rezultat: mniej chaosu i szybsze decyzje przy incydentach.
• Zabezpieczenie: centralny rejestr zastosowań AI.

Scenariusz 3: Przegląd zgodności i jakości

• Cel: regularnie oceniać, czy system AI nadal spełnia wymagania.
• Wejście: metryki jakości, incydenty, zmiany w procesie i dokumentacja.
• Kroki: przegląd okresowy -> ocena ryzyk -> decyzja o zmianach.
• Rezultat: system nie działa bez nadzoru i kontroli.
• Zabezpieczenie: harmonogram przeglądów i checklisty zgodności.

Ryzyko 1: Brak odpowiedzialności

• Ryzyko: brak odpowiedzialności.
• Jak ograniczać: przypisz role i właścicieli systemów.

Ryzyko 2: Rozjazd decyzji w organizacji

• Ryzyko: rozjazd decyzji w organizacji.
• Jak ograniczać: wprowadź wspólny proces oceny zastosowań.

Ryzyko 3: Brak zgodności

• Ryzyko: brak zgodności.
• Jak ograniczać: łącz governance z przeglądem prawnym i bezpieczeństwa.

Ryzyko 4: Spadek jakości bez reakcji

• Ryzyko: spadek jakości bez reakcji.
• Jak ograniczać: dodaj monitoring jakości i regularne przeglądy.

• Czy wiadomo, kto odpowiada za ten system?
• Czy istnieje proces zgłaszania i zatwierdzania AI?
• Czy oceniono ryzyka prawne i operacyjne?
• Czy są zasady dla danych i jakości?
• Czy organizacja prowadzi rejestr zastosowań AI?

To sposób uporządkowania odpowiedzialności za AI w organizacji. Nie chodzi tylko o technologię. Chodzi też o decyzje, ryzyka, zgodność, jakość i odpowiedzialność za skutki wdrożenia.

AI Governance odpowiada na pytania:

• kto może wdrażać AI,
• kto zatwierdza nowe użycia,
• jak ocenia się ryzyko,
• jak kontroluje się jakość i zgodność.

• Traktowanie governance jako papierowego obowiązku.
• Brak właściciela biznesowego systemu.
• Brak połączenia między bezpieczeństwem, prawem i operacjami.
• Wdrażanie AI bez procesu zatwierdzania.

Diagram pokazuje, że AI Governance porządkuje drogę od pomysłu na AI do wdrożenia i późniejszego nadzoru.

• Polityka użycia AI w organizacji

• AI Act (Akt w sprawie sztucznej inteligencji)

• RODO / DPIA

• Ślad audytowy

• Monitoring jakości

---

AI Literacy to praktyczne rozumienie tego, czym jest AI, do czego może służyć, jakie ma ograniczenia i jak używać jej odpowiedzialnie w codziennej pracy.

Scenariusz 1: Szkolenie pracowników biurowych

• Cel: nauczyć bezpiecznego i sensownego używania AI w codziennej pracy.
• Wejście: grupa użytkowników, przykładowe zadania i zasady organizacji.
• Kroki: szkolenie podstawowe -> ćwiczenia na scenariuszach -> sprawdzenie zrozumienia.
• Rezultat: pracownicy lepiej rozumieją, kiedy AI pomaga, a kiedy szkodzi.
• Zabezpieczenie: materiały o danych wrażliwych, halucynacjach i odpowiedzialności.

Scenariusz 2: Wdrożenie nowego asystenta AI

• Cel: przygotować użytkowników do pracy z narzędziem.
• Wejście: opis narzędzia, przypadki użycia i ograniczenia systemu.
• Kroki: onboarding -> pokaz dobrych praktyk -> checklista użytkownika.
• Rezultat: mniej błędów i mniej nadmiernego zaufania.
• Zabezpieczenie: jasne reguły pracy i kanał zgłaszania problemów.

Scenariusz 3: Przygotowanie kadry kierowniczej

• Cel: podnieść jakość decyzji o zakupie i użyciu AI.
• Wejście: przykłady wdrożeń, ryzyka i wymagania zgodności.
• Kroki: warsztat decyzyjny -> omówienie ryzyk -> zasady oceny wdrożeń.
• Rezultat: lepsze decyzje zarządcze i mniej przypadkowych inwestycji.
• Zabezpieczenie: połączenie perspektywy biznesowej, prawnej i bezpieczeństwa.

Ryzyko 1: Błędne użycie AI

• Ryzyko: błędne użycie AI.
• Jak ograniczać: szkol użytkowników na realnych przykładach.

Ryzyko 2: Nadmierne zaufanie

• Ryzyko: nadmierne zaufanie.
• Jak ograniczać: ucz weryfikacji i krytycznego myślenia.

Ryzyko 3: Shadow AI

• Ryzyko: shadow AI.
• Jak ograniczać: daj bezpieczne narzędzia i jasne zasady.

Ryzyko 4: Brak trwałego efektu

• Ryzyko: brak trwałego efektu.
• Jak ograniczać: planuj edukację jako proces, nie jedną prezentację.

• Czy użytkownicy znają ograniczenia AI?
• Czy wiedzą, jak pracować z danymi wrażliwymi?
• Czy wiedzą, kiedy trzeba sprawdzić wynik ręcznie?
• Czy znają politykę organizacji?
• Czy mają gdzie zgłaszać błędy i ryzyka?

To nie jest wiedza tylko dla specjalistów technicznych. Chodzi o podstawowy poziom świadomości użytkownika, lidera albo pracownika, który korzysta z AI albo podejmuje decyzje o jej wdrożeniu.

AI Literacy obejmuje między innymi:

• rozumienie ograniczeń modeli,
• rozpoznawanie ryzyk,
• umiejętność weryfikacji odpowiedzi,
• podstawy pracy na danych,
• znajomość zasad organizacji.

• Założenie, że AI Literacy to tylko obsługa jednego narzędzia.
• Szkolenie bez praktycznych scenariuszy.
• Pomijanie tematu danych i odpowiedzialności.
• Traktowanie edukacji jako jednorazowego wydarzenia.

Diagram pokazuje, że kompetencje AI zmniejszają liczbę błędów i zwiększają odpowiedzialne użycie narzędzi.

• Polityka użycia AI w organizacji

• Nadmierne zaufanie (Overreliance)

• Shadow AI (Szara strefa AI)

• Human-in-the-loop (człowiek w pętli)

• Fact-checking (weryfikacja faktów)

---

Anonimizacja usuwa możliwość rozpoznania osoby. Pseudonimizacja zastępuje identyfikatory, na przykład nazwisko, innym oznaczeniem. Zwykle pozwala wrócić do danych przy użyciu klucza.

Scenariusz 1: Szkic odpowiedzi na pismo

• Cel: szkic odpowiedzi na pismo: zastąp nazwiska i numery identyfikatorów.
• Wejście: tekst, zgłoszenie albo przykład z danymi identyfikującymi.
• Kroki: usuń identyfikatory -> zastąp szczegóły -> sprawdź ryzyko ponownej identyfikacji.
• Rezultat: materiał gotowy do bezpieczniejszej analizy.
• Zabezpieczenie: minimalizacja danych i przegląd prywatności.

Scenariusz 2: Analiza skarg/zgłoszeń

• Cel: analiza skarg/zgłoszeń: usuń dane kontaktowe i szczegóły identyfikujące.
• Wejście: tekst, zgłoszenie albo przykład z danymi identyfikującymi.
• Kroki: usuń identyfikatory -> zastąp szczegóły -> sprawdź ryzyko ponownej identyfikacji.
• Rezultat: materiał gotowy do bezpieczniejszej analizy.
• Zabezpieczenie: minimalizacja danych i przegląd prywatności.

Scenariusz 3: Szkolenia

• Cel: szkolenia: przykłady na danych syntetycznych.
• Wejście: tekst, zgłoszenie albo przykład z danymi identyfikującymi.
• Kroki: usuń identyfikatory -> zastąp szczegóły -> sprawdź ryzyko ponownej identyfikacji.
• Rezultat: materiał gotowy do bezpieczniejszej analizy.
• Zabezpieczenie: minimalizacja danych i przegląd prywatności.

Ryzyko 1: Reidentyfikacja

• Ryzyko: Reidentyfikacja.
• Jak ograniczać: usuń rzadkie szczegóły, agreguj dane.

Ryzyko 2: Błędy procesu

• Ryzyko: Błędy procesu.
• Jak ograniczać: checklista + drugi czytelnik.

Ryzyko 3: Brak spójności

• Ryzyko: Brak spójności.
• Jak ograniczać: standard anonimizacji w organizacji.

• Czy usunąłem nazwiska, adresy, numery?
• Czy usunąłem dane rzadkie, które identyfikują?
• Czy klucz pseudonimizacji jest chroniony?
• Czy narzędzie AI jest zatwierdzone?
• Czy loguję użycie?

• Anonimizacja jest „mocniejsza”, ale trudniejsza.
• Pseudonimizacja jest częstsza w procesach, bo pozwala śledzić sprawę bez ujawniania nazwisk.
• Do narzędzi AI najbezpieczniej podawać dane zanonimizowane lub pseudonimizowane.

• Zostawienie „pośrednich” identyfikatorów, na przykład opisu „jedyna osoba na tym stanowisku”.
• Pseudonimizacja bez kontroli klucza.

Diagram pokazuje, że dane osobowe są przetwarzane tak, aby ograniczyć możliwość identyfikacji osoby przed dalszym użyciem.

• PII
• DLP
• RODO / DPIA
• Audit trail
• Human-in-the-loop

API to sposób, w jaki systemy komputerowe „rozmawiają” ze sobą. Na przykład aplikacja organizacji wysyła zapytanie do modelu i odbiera odpowiedź.

Scenariusz 1: Asystent na intranecie do procedur

• Cel: asystent na intranecie do procedur.
• Wejście: wymagania procesu i dostępne systemy.
• Kroki: wybierz endpoint -> przekaż dane -> odbierz wynik.
• Rezultat: integracja działa w kontrolowany sposób.
• Zabezpieczenie: uwierzytelnianie, limity i logowanie.

Scenariusz 2: Generator szkiców pism w systemie obiegu dokumentów

• Cel: generator szkiców pism w systemie obiegu dokumentów.
• Wejście: wymagania procesu i dostępne systemy.
• Kroki: wybierz endpoint -> przekaż dane -> odbierz wynik.
• Rezultat: integracja działa w kontrolowany sposób.
• Zabezpieczenie: uwierzytelnianie, limity i logowanie.

Scenariusz 3: Automatyczne kategoryzowanie zgłoszeń

• Cel: automatyczne kategoryzowanie zgłoszeń.
• Wejście: wymagania procesu i dostępne systemy.
• Kroki: wybierz endpoint -> przekaż dane -> odbierz wynik.
• Rezultat: integracja działa w kontrolowany sposób.
• Zabezpieczenie: uwierzytelnianie, limity i logowanie.

Ryzyko 1: Wycieki danych

• Ryzyko: Wycieki danych.
• Jak ograniczać: anonimizacja + DLP.

Ryzyko 2: Nadużycia

• Ryzyko: Nadużycia.
• Jak ograniczać: IAM i limity zapytań.

Ryzyko 3: Błędy jakości

• Ryzyko: Błędy jakości.
• Jak ograniczać: ewaluacja i monitoring.

• Czy API ma uwierzytelnianie?
• Czy są limity zapytań?
• Czy logujesz parametry i źródła?
• Czy dane są filtrowane (PII)?
• Czy masz testy regresji?

• API to „formularz” dla programu: co wysłać i co dostaniesz.
• Pozwala zintegrować AI z intranetem, formularzami czy systemem zgłoszeń.
• Daje większą kontrolę nad logami, limitami i uprawnieniami.

• Brak limitów (koszty i nadużycia).
• Brak logów i śladu audytowego.

Diagram pokazuje, że API pośredniczy między aplikacją a usługą AI i kontroluje sposób wymiany danych.

• Orkiestracja
• SSO / IAM
• Audit trail
• DLP
• RAG

Asystent AI to narzędzie do rozmowy z użytkownikiem. Odpowiada na pytania, tłumaczy i pomaga w zadaniach. Zwykle działa w określonym zakresie. Sam nie wykonuje działań w systemach.

Scenariusz 1: Wsparcie działu obsługi klienta

• Cel: wsparcie działu obsługi klienta.
• Wejście: pytanie klienta.
• Kroki: odpowiedź -> korekta -> wysyłka.
• Rezultat: szybka reakcja.
• Zabezpieczenie: przegląd odpowiedzi.

Scenariusz 2: Wsparcie pracowników w procedurach

• Cel: wsparcie pracowników w procedurach.
• Wejście: pytanie o proces.
• Kroki: wyszukaj → wyjaśnij → podaj źródło.
• Rezultat: krótkie wskazówki.
• Zabezpieczenie: cytaty i źródła.

Scenariusz 3: Pomoc w redakcji treści

• Cel: pomoc w redakcji treści.
• Wejście: szkic tekstu.
• Kroki: propozycje → wybór → redakcja.
• Rezultat: poprawiony tekst.
• Zabezpieczenie: kontrola stylu.

Ryzyko 1: Halucynacje

• Ryzyko: Halucynacje.
• Jak ograniczać: proś o źródła i sprawdzaj odpowiedzi.

Ryzyko 2: Dane osobowe

• Ryzyko: Dane osobowe.
• Jak ograniczać: anonimizuj dane i stosuj jasne zasady.

Ryzyko 3: Stronniczość

• Ryzyko: Stronniczość.
• Jak ograniczać: testuj jakość na różnych przykładach.

• Czy asystent ma jasno zdefiniowany zakres?
• Czy odpowiedzi są weryfikowane?
• Czy dane wrażliwe są chronione?
• Czy masz monitoring jakości?
• Czy użytkownicy są przeszkoleni?

• To „czatowy pomocnik”, który tłumaczy, streszcza i podpowiada.
• Pomaga w codziennych zadaniach, ale nie podejmuje decyzji sam.
• Jakość zależy od danych i konfiguracji.
• Wymaga weryfikacji w ważnych procesach.

• Traktowanie asystenta jako źródła prawdy.
• Brak kontekstu w zapytaniu.
• Brak weryfikacji odpowiedzi.

Diagram pokazuje, że asystent AI odpowiada na pytanie, ale wynik powinien przejść przez etap sprawdzenia.

• Agent AI
• LLM
• RAG
• Instrukcja systemowa
• Guardrails

Baza wektorowa to system, który przechowuje embeddingi i pozwala szybko znaleźć najbardziej podobne fragmenty treści.

Scenariusz 1: Asystent procedur

• Cel: asystent procedur.
• Wejście: pytanie.
• Kroki: embedding → search w bazie → cytaty.
• Rezultat: odpowiedź z linkami.
• Zabezpieczenie: tylko zatwierdzone źródła.

Scenariusz 2: Obsługa infolinii (skrypty)

• Cel: obsługa infolinii (skrypty).
• Wejście: temat rozmowy.
• Kroki: wyszukaj podobne przypadki → podpowiedzi.
• Rezultat: szybsza obsługa.
• Zabezpieczenie: log + kontrola jakości.

Scenariusz 3: Wyszukiwanie w regulaminch/zarządzeniach

• Cel: wyszukiwanie w regulaminch/zarządzeniach.
• Wejście: fraza „po sensie”.
• Kroki: embedding → top fragmenty.
• Rezultat: lista cytatów.
• Zabezpieczenie: wersjonowanie dokumentów.

Ryzyko 1: Zatrucie bazy (poisoning)

• Ryzyko: Zatrucie bazy (poisoning): wstrzyknięty złośliwy fragment.
• Jak ograniczać: whitelist źródeł + review.

Ryzyko 2: Prywatność

• Ryzyko: Prywatność: embeddingi mogą „niosą” sens danych.
• Jak ograniczać: polityka danych + anonimizacja.

Ryzyko 3: Błędne cytowanie

• Ryzyko: Błędne cytowanie: brak kontroli fragmentów.
• Jak ograniczać: zawsze pokazuj źródło i cytat.

• Czy źródła są zatwierdzone?
• Czy jest proces aktualizacji indeksu?
• Czy są filtry po dziale i dacie?
• Czy wynik zawsze pokazuje cytat i link?
• Czy logujesz zapytania (audit trail)?

• To „wyszukiwarka po znaczeniu”, tylko zoptymalizowana pod liczby (wektory).
• Zamiast szukać słów kluczowych, szuka „najbliższych sensów”.
• Najczęściej działa razem z RAG.

• Brak filtrów po dacie/typie dokumentu.
• Niewłaściwe metadane (tagi) → złe wyniki.
• Indeks nieaktualny.

Diagram pokazuje, że baza wektorowa służy do wyszukiwania podobnych treści po znaczeniu, a nie tylko po słowach.

• Embedding
• Chunking
• RAG
• Audit trail
• Konektory danych

Benchmark to zestaw testów, który pozwala porównać modele lub ustawienia na tych samych zasadach.

Scenariusz 1: Porównanie dwóch konfiguracji RAG dla procedur

• Cel: porównanie dwóch konfiguracji RAG dla procedur.
• Wejście: dwa warianty rozwiązania i zestaw testowy.
• Kroki: ustal kryteria -> uruchom test -> porównaj wyniki.
• Rezultat: porównanie oparte na tych samych warunkach.
• Zabezpieczenie: stała metryka i ten sam zestaw danych.

Scenariusz 2: Porównanie stylu komunikatów (czytelność, plain language)

• Cel: porównanie stylu komunikatów (czytelność, plain language).
• Wejście: dwa warianty rozwiązania i zestaw testowy.
• Kroki: ustal kryteria -> uruchom test -> porównaj wyniki.
• Rezultat: porównanie oparte na tych samych warunkach.
• Zabezpieczenie: stała metryka i ten sam zestaw danych.

Scenariusz 3: Porównanie bezpieczeństwa, na przykład odporności na wstrzyknięcie poleceń

• Cel: porównanie bezpieczeństwa, na przykład odporności na wstrzyknięcie poleceń.
• Wejście: dwa warianty rozwiązania i zestaw testowy.
• Kroki: ustal kryteria -> uruchom test -> porównaj wyniki.
• Rezultat: porównanie oparte na tych samych warunkach.
• Zabezpieczenie: stała metryka i ten sam zestaw danych.

Ryzyko 1: Zły dobór testów

• Ryzyko: Zły dobór testów.
• Jak ograniczać: udział użytkowników i przykłady z praktyki.

Ryzyko 2: Nadmierna optymalizacja pod test

• Ryzyko: Nadmierna optymalizacja pod test.
• Jak ograniczać: mieszanka przykładów + losowanie.

Ryzyko 3: Brak porównywalności

• Ryzyko: Brak porównywalności.
• Jak ograniczać: stała metodologia i wersjonowanie.

• Czy testy obejmują realne scenariusze?
• Czy masz rubrykę oceny?
• Czy testujesz też bezpieczeństwo?
• Czy zapisujesz wyniki i wersje?
• Czy benchmark jest aktualny?

• To jak „sprawdzian” z ustalonymi pytaniami.
• Dzięki temu wiesz, czy nowa wersja jest lepsza, czy tylko „inna”.
• Benchmark powinien odpowiadać na realne potrzeby organizacji.

• Benchmark z zadaniami ułożonymi „pod model”, a nie pod użytkownika.
• Brak aktualizacji benchmarku po zmianach procesów.

Diagram pokazuje, że benchmark porównuje modele lub rozwiązania na wspólnym zestawie testowym, aby zmierzyć ich jakość.

• Ewaluacja
• A/B testy
• Monitoring jakości
• LLMOps
• RAG

Biblioteka promptów to zestaw sprawdzonych szablonów poleceń do powtarzalnych zadań: streszczeń, analiz, komunikatów, klasyfikacji albo checklist.

Scenariusz 1: Streszczenia dokumentów

• Cel: ujednolicenie streszczeń.
• Wejście: dokument i szablon streszczenia.
• Kroki: wstaw dokument -> użyj szablonu -> sprawdź wynik.
• Rezultat: streszczenia w stałym formacie.
• Zabezpieczenie: kontrola źródeł i braków.

Scenariusz 2: Posty do mediów społecznościowych

• Cel: spójny ton i długość komunikatów.
• Wejście: temat, grupa odbiorców i format.
• Kroki: wybór szablonu -> generowanie -> redakcja.
• Rezultat: szybsze przygotowanie wersji roboczej.
• Zabezpieczenie: przegląd redakcyjny.

Scenariusz 3: Ocena jakości treści

• Cel: powtarzalna ocena według tych samych kryteriów.
• Wejście: tekst i rubryka oceny.
• Kroki: ocena -> uzasadnienie -> propozycja poprawki.
• Rezultat: łatwiejsze porównanie jakości.
• Zabezpieczenie: testy A/B i ewaluacja.

Ryzyko 1: Przestarzały szablon

• Ryzyko: Przestarzały szablon.
• Jak ograniczać: wersjonuj prompty i testuj je okresowo.

Ryzyko 2: Dane wrażliwe w placeholderach

• Ryzyko: Dane wrażliwe w placeholderach.
• Jak ograniczać: stosuj anonimizację i DLP.

Ryzyko 3: Rozjazd standardów w zespole

• Ryzyko: Rozjazd standardów w zespole.
• Jak ograniczać: trzymaj jedną zatwierdzoną bibliotekę.

• Czy prompt ma właściciela?
• Czy wiadomo, do jakiego zadania służy?
• Czy ma wersję i datę aktualizacji?
• Czy był testowany na przykładach?

Zamiast za każdym razem pisać od zera, masz gotowce. Wkładasz dane w wyznaczone miejsca i dostajesz bardziej przewidywalny format odpowiedzi.

To działa jak szablony dokumentów. Jeden raz dopracowujesz jakość i styl, a potem korzystasz wielokrotnie.

Biblioteka promptów pomaga też utrzymać spójność w zespole. Każdy używa tych samych standardów, a zmiany w promptach można wersjonować.

Diagram pokazuje, że biblioteka promptów łączy szablon, dane i ocenę jakości w powtarzalny proces.

• Prompt
• Prompt systemowy
• AB testy
• Ewaluacja
• Monitoring jakości
• Polityka użycia AI w organizacji

Caching to zapisywanie wyników (np. odpowiedzi, embeddingów, fragmentów retrieval), żeby przy kolejnym podobnym pytaniu nie liczyć wszystkiego od zera.

Scenariusz 1: FAQ

• Cel: „Jak działa RAG?” — cache gotowej, zaakceptowanej odpowiedzi.
• Wejście: powtarzalne pytanie albo kosztowny wynik.
• Kroki: zapisz wynik -> sprawdź cache -> odśwież po czasie.
• Rezultat: szybsza i tańsza odpowiedź.
• Zabezpieczenie: czas ważności i czyszczenie cache.

Scenariusz 2: RAG

• Cel: cache embeddingów dokumentów, żeby nie przeliczać po każdej zmianie.
• Wejście: powtarzalne pytanie albo kosztowny wynik.
• Kroki: zapisz wynik -> sprawdź cache -> odśwież po czasie.
• Rezultat: szybsza i tańsza odpowiedź.
• Zabezpieczenie: czas ważności i czyszczenie cache.

Scenariusz 3: Agent

• Cel: cache wyników „lista plików w folderze”, jeśli folder się nie zmienia.
• Wejście: powtarzalne pytanie albo kosztowny wynik.
• Kroki: zapisz wynik -> sprawdź cache -> odśwież po czasie.
• Rezultat: szybsza i tańsza odpowiedź.
• Zabezpieczenie: czas ważności i czyszczenie cache.

Ryzyko 1: Przestarzałe odpowiedzi

• Ryzyko: przestarzałe odpowiedzi.
• Jak ograniczać: TTL (czas ważności) + czyszczenie cache po aktualizacji źródeł.

Ryzyko 2: Cache zawiera dane wrażliwe

• Ryzyko: cache zawiera dane wrażliwe.
• Jak ograniczać: szyfrowanie, minimalizacja danych, separacja per tenant.

Ryzyko 3: „mieszanie” użytkowników (cross-tenant)

• Ryzyko: „mieszanie” użytkowników (cross-tenant).
• Jak ograniczać: klucze cache uwzględniające tenant i uprawnienia.

To jak „zapamiętanie raz znalezionej odpowiedzi”, żeby nie szukać jej ponownie. Daje:

• szybciej (mniejsze opóźnienia),
• taniej (mniej tokenów/wywołań),
• stabilniej (mniej losowości).

W AI cache może dotyczyć:

• wyników wyszukiwania,
• embeddingów,
• odpowiedzi na powtarzalne pytania,
• pośrednich kroków w agentach.

Diagram pokazuje, że system najpierw sprawdza zapisany wynik, a dopiero gdy go nie ma, liczy odpowiedź od zera.

Chain-of-thought to podejście, w którym prosisz model o pokazanie drogi do odpowiedzi: kroków, założeń, planu albo krótkiego uzasadnienia.

Scenariusz 1: Plan projektu

• Cel: uporządkowanie pracy.
• Wejście: opis celu i ograniczeń.
• Kroki: założenia -> plan -> ryzyka.
• Rezultat: lista działań do sprawdzenia.
• Zabezpieczenie: przegląd przez osobę odpowiedzialną.

Scenariusz 2: Decyzja z uzasadnieniem

• Cel: lepsze zrozumienie rekomendacji.
• Wejście: warianty decyzji.
• Kroki: kryteria -> porównanie -> wybór.
• Rezultat: rekomendacja z krótkim uzasadnieniem.
• Zabezpieczenie: sprawdzenie faktów i założeń.

Scenariusz 3: Checklista jakości

• Cel: wychwycenie braków przed publikacją.
• Wejście: szkic treści lub procedury.
• Kroki: kryteria -> ocena -> poprawki.
• Rezultat: lista rzeczy do poprawy.
• Zabezpieczenie: fact-checking i human-in-the-loop.

Ryzyko 1: Ładne, ale błędne uzasadnienie

• Ryzyko: Ładne, ale błędne uzasadnienie.
• Jak ograniczać: sprawdzaj źródła i dane wejściowe.

Ryzyko 2: Za długie odpowiedzi

• Ryzyko: Za długie odpowiedzi.
• Jak ograniczać: ogranicz liczbę kroków.

Ryzyko 3: Pozorna pewność

• Ryzyko: Pozorna pewność.
• Jak ograniczać: każ modelowi wskazać niepewności.

• Czy potrzebujesz uzasadnienia, czy tylko wyniku?
• Czy kroki można zweryfikować?
• Czy odpowiedź nie jest zbyt długa?
• Czy model ma wskazać założenia i niepewności?

Nie chcesz tylko wyniku. Chcesz też zrozumieć, co model założył, co sprawdził i z czego wynika odpowiedź.

To bywa przydatne w planowaniu, analizie ryzyk, tworzeniu procedur i checklist. Trzeba jednak pamiętać, że uzasadnienie może brzmieć sensownie nawet wtedy, gdy wniosek jest błędny.

W praktyce często lepiej prosić o „plan i krótkie uzasadnienie” niż o bardzo długi tok rozumowania.

Diagram pokazuje, że rozumowanie krok po kroku powinno kończyć się sprawdzeniem, a nie tylko ładnym wnioskiem.

• Prompt
• Halucynacje
• Fact-checking
• Ewaluacja
• Human-in-the-loop

Content Credentials to zestaw metadanych opisujących pochodzenie treści cyfrowej, w tym informacje o autorze, narzędziu, zmianach i sposobie powstania materiału.

Scenariusz 1: Publikacja obrazu wygenerowanego lub edytowanego przez AI

• Cel: pokazać, że materiał ma ślad pochodzenia i zmian.
• Wejście: plik graficzny i narzędzie do publikacji.
• Kroki: zapis metadanych -> dołączenie informacji -> publikacja.
• Rezultat: odbiorca ma więcej informacji o pochodzeniu treści.
• Zabezpieczenie: zachowanie metadanych przy eksporcie i publikacji.

Scenariusz 2: Obieg materiałów promocyjnych w organizacji

• Cel: wiedzieć, kto stworzył materiał i jakie narzędzia były użyte.
• Wejście: plik roboczy, autor i historia edycji.
• Kroki: rejestracja źródła -> zapis zmian -> zatwierdzenie materiału.
• Rezultat: łatwiejsze ustalenie pochodzenia treści.
• Zabezpieczenie: standard pracy z plikami i wersjonowanie.

Scenariusz 3: Oznaczanie treści syntetycznych

• Cel: zmniejszyć ryzyko pomylenia treści syntetycznej z oryginalną.
• Wejście: materiał wygenerowany albo zmodyfikowany przez AI.
• Kroki: identyfikacja treści -> dodanie metadanych -> publikacja.
• Rezultat: większa przejrzystość wobec odbiorcy.
• Zabezpieczenie: polityka oznaczania i kontrola publikacji.

Ryzyko 1: Utrata metadanych

• Ryzyko: utrata metadanych.
• Jak ograniczać: testuj kanały publikacji i eksportu.

Ryzyko 2: Fałszywe poczucie pewności

• Ryzyko: fałszywe poczucie pewności.
• Jak ograniczać: traktuj je jako pomoc, nie absolutny dowód.

Ryzyko 3: Brak spójności organizacyjnej

• Ryzyko: brak spójności organizacyjnej.
• Jak ograniczać: ustal standard oznaczania treści.

Ryzyko 4: Niska użyteczność dla odbiorcy

• Ryzyko: niska użyteczność dla odbiorcy.
• Jak ograniczać: łącz metadane z czytelną komunikacją.

• Czy wiadomo, skąd pochodzi treść?
• Czy zapisano historię zmian?
• Czy metadane przetrwają publikację?
• Czy organizacja ma zasady oznaczania treści AI?
• Czy odbiorca rozumie, co oznacza taki ślad?

To „metryczka treści”, która pomaga odpowiedzieć na pytanie, skąd pochodzi plik i co się z nim działo. W praktyce może dotyczyć obrazu, filmu, dokumentu albo innej treści cyfrowej.

Content Credentials pomagają:

• zwiększać transparentność,
• śledzić historię zmian,
• oznaczać użycie narzędzi AI,
• lepiej oceniać wiarygodność materiału.

• Założenie, że metadane zawsze przetrwają eksport i publikację.
• Brak standardu oznaczania treści w organizacji.
• Mylenie Content Credentials z pełnym dowodem autentyczności.
• Pomijanie śladu zmian wewnątrz organizacji.

Diagram pokazuje, że Content Credentials dodają do treści ślad pochodzenia i zmian przed publikacją.

• Transparentność

• Data provenance (pochodzenie danych)

• Watermarking (znakowanie treści)

• Deepfake

• Fact-checking (weryfikacja faktów)

---

Cytowanie źródeł to podawanie, skąd pochodzą informacje użyte w odpowiedzi. Może to być link, dokument albo konkretny fragment.

Scenariusz 1: Odpowiedzi na pytania klientów z linkiem do procedury

• Cel: odpowiedzi na pytania klientów z linkiem do procedury.
• Wejście: odpowiedź, dokument źródłowy i link do konkretnego fragmentu.
• Kroki: znajdź źródło -> dopasuj cytat -> sprawdź aktualność.
• Rezultat: odpowiedź łatwiejsza do zweryfikowania.
• Zabezpieczenie: cytowanie tylko oficjalnych i aktualnych źródeł.

Scenariusz 2: Komunikaty o terminach z linkiem do zarządzenia albo ogłoszenia

• Cel: komunikaty o terminach z linkiem do zarządzenia albo ogłoszenia.
• Wejście: odpowiedź, dokument źródłowy i link do konkretnego fragmentu.
• Kroki: znajdź źródło -> dopasuj cytat -> sprawdź aktualność.
• Rezultat: odpowiedź łatwiejsza do zweryfikowania.
• Zabezpieczenie: cytowanie tylko oficjalnych i aktualnych źródeł.

Scenariusz 3: Opisy usług z linkiem do strony WWW lub FAQ organizacji

• Cel: opisy usług z linkiem do strony WWW lub FAQ organizacji.
• Wejście: odpowiedź, dokument źródłowy i link do konkretnego fragmentu.
• Kroki: znajdź źródło -> dopasuj cytat -> sprawdź aktualność.
• Rezultat: odpowiedź łatwiejsza do zweryfikowania.
• Zabezpieczenie: cytowanie tylko oficjalnych i aktualnych źródeł.

Ryzyko 1: Błędne źródła

• Ryzyko: Błędne źródła.
• Jak ograniczać: whitelist + wersjonowanie.

Ryzyko 2: Brak transparentności

• Ryzyko: Brak transparentności.
• Jak ograniczać: wymóg źródeł dla twierdzeń.

Ryzyko 3: Przeciążenie linkami

• Ryzyko: Przeciążenie linkami.
• Jak ograniczać: wybieraj 1–3 kluczowe.

• Czy źródło jest oficjalne i aktualne?
• Czy link prowadzi do konkretu?
• Czy cytat odpowiada twierdzeniu?
• Czy widać datę dokumentu?
• Czy treść jest zrozumiała bez klikania?

• To „paragon” do informacji: można sprawdzić, czy jest prawdziwa.
• W firmie zwiększa wiarygodność i ułatwia akceptację treści.
• W RAG cytowanie bywa automatyczne, ale trzeba je kontrolować.

• Link do strony głównej zamiast do konkretnego punktu.
• Cytowanie nieaktualnej wersji dokumentu.

Diagram pokazuje, że ważne twierdzenie powinno być powiązane z konkretnym źródłem i cytatem, aby dało się je sprawdzić.

• Grounding
• Fact-checking
• RAG
• Audit trail
• Transparentność

PII (dane osobowe) to informacje, które pozwalają zidentyfikować osobę bezpośrednio lub pośrednio.

Scenariusz 1: Tworzenie odpowiedzi „na szablonie” bez wklejania danych wrażliwych

• Cel: tworzenie odpowiedzi „na szablonie” bez wklejania danych wrażliwych.
• Wejście: tekst zawierający możliwe dane osobowe.
• Kroki: wykryj PII -> usuń lub zastąp -> sprawdź wynik.
• Rezultat: materiał bez zbędnych danych osobowych.
• Zabezpieczenie: minimalizacja danych i DLP.

Scenariusz 2: Analiza sprawy na podstawie opisu po anonimizacji

• Cel: analiza sprawy na podstawie opisu po anonimizacji.
• Wejście: tekst zawierający możliwe dane osobowe.
• Kroki: wykryj PII -> usuń lub zastąp -> sprawdź wynik.
• Rezultat: materiał bez zbędnych danych osobowych.
• Zabezpieczenie: minimalizacja danych i DLP.

Scenariusz 3: Automatyczne wykrywanie PII w tekście (DLP)

• Cel: automatyczne wykrywanie PII w tekście (DLP).
• Wejście: tekst zawierający możliwe dane osobowe.
• Kroki: wykryj PII -> usuń lub zastąp -> sprawdź wynik.
• Rezultat: materiał bez zbędnych danych osobowych.
• Zabezpieczenie: minimalizacja danych i DLP.

Ryzyko 1: Naruszenie prywatności

• Ryzyko: Naruszenie prywatności.
• Jak ograniczać: anonimizacja/pseudonimizacja.

Ryzyko 2: Wycieki

• Ryzyko: Wycieki.
• Jak ograniczać: DLP + polityka.

Ryzyko 3: Brak kontroli dostępu

• Ryzyko: Brak kontroli dostępu.
• Jak ograniczać: IAM/SSO.

• Czy mogę usunąć dane osobowe?
• Czy mam podstawę prawną i zgodę procesu?
• Czy narzędzie jest zatwierdzone?
• Czy wynik nie ujawnia danych?
• Czy mam log i audyt?

• To np. imię i nazwisko, PESEL, adres, numer telefonu, ale też zestaw danych, który razem wskazuje osobę.
• W kontekście AI najważniejsze jest: nie wklejać danych, jeśli nie ma do tego podstaw i zabezpieczeń.
• Bezpieczniej pracować na danych zanonimizowanych.

• Wklejenie całego pisma z danymi do narzędzia zewnętrznego.
• Trzymanie promptów z danymi w historii narzędzia.

Diagram pokazuje, że dane osobowe powinny zostać wykryte i ograniczone przed użyciem ich w systemach AI.

• Anonimizacja
• DLP
• RODO / DPIA
• Audit trail
• SSO / IAM

Dane syntetyczne to dane wygenerowane (np. przez algorytm lub AI), które mają przypominać dane prawdziwe, ale nie są bezpośrednią kopią konkretnych osób czy zdarzeń.

Scenariusz 1: Test chatbotów na „udawanych” zgłoszeniach, bez prawdziwych nazwisk

• Cel: test chatbotów na „udawanych” zgłoszeniach, bez prawdziwych nazwisk.
• Wejście: dane źródłowe albo schemat danych.
• Kroki: wygeneruj dane -> sprawdź podobieństwo -> przetestuj proces.
• Rezultat: bezpieczniejszy materiał testowy.
• Zabezpieczenie: kontrola reidentyfikacji.

Scenariusz 2: Demo systemu na fikcyjnych dokumentach i formularzach

• Cel: demo systemu na fikcyjnych dokumentach i formularzach.
• Wejście: dane źródłowe albo schemat danych.
• Kroki: wygeneruj dane -> sprawdź podobieństwo -> przetestuj proces.
• Rezultat: bezpieczniejszy materiał testowy.
• Zabezpieczenie: kontrola reidentyfikacji.

Scenariusz 3: Trening klasyfikacji na sztucznie wygenerowanych przykładach

• Cel: trening klasyfikacji na sztucznie wygenerowanych przykładach.
• Wejście: dane źródłowe albo schemat danych.
• Kroki: wygeneruj dane -> sprawdź podobieństwo -> przetestuj proces.
• Rezultat: bezpieczniejszy materiał testowy.
• Zabezpieczenie: kontrola reidentyfikacji.

Ryzyko 1: Dane syntetyczne są zbyt podobne do prawdziwych (ryzyko reidentyfikacji)

• Ryzyko: dane syntetyczne są zbyt podobne do prawdziwych (ryzyko reidentyfikacji).
• Jak ograniczać: testy prywatności, kontrola podobieństwa, anonimizacja źródeł.

Ryzyko 2: Bias i zniekształcenia (syntetyk „upiększa” świat)

• Ryzyko: bias i zniekształcenia (syntetyk „upiększa” świat).
• Jak ograniczać: ewaluacja, analiza bias, mieszanie źródeł.

Ryzyko 3: „zatruwanie” systemu kiepskimi danymi

• Ryzyko: „zatruwanie” systemu kiepskimi danymi.
• Jak ograniczać: kontrola jakości, walidacje, wersjonowanie.

To jak „symulacja danych”. Zamiast pracować na prawdziwych rekordach (czasem wrażliwych), tworzysz dane podobne w strukturze. Po co?

• do testów (żeby nie ryzykować danych osobowych),
• do nauki i demo,
• do zasilenia modeli, gdy brakuje danych.

Ważne: syntetyczne ≠ automatycznie bezpieczne. Jeśli są zrobione źle, mogą „przemycić” wzorce z danych wrażliwych.

Diagram pokazuje, że dane syntetyczne powstają na bazie modelu i wymagają sprawdzenia jakości oraz ryzyka prywatności przed użyciem.

Data poisoning to celowe wprowadzenie złośliwych lub mylących treści do danych, aby model lub RAG zwracał błędne odpowiedzi.

Scenariusz 1: Podmieniony PDF w repozytorium powoduje błędne odpowiedzi asystenta

• Cel: podmieniony PDF w repozytorium powoduje błędne odpowiedzi asystenta.
• Wejście: repozytorium dokumentów, FAQ albo baza wiedzy.
• Kroki: sprawdź źródło -> wykryj zmianę -> odizoluj podejrzany materiał.
• Rezultat: mniejsze ryzyko odpowiedzi opartych na zatrutych danych.
• Zabezpieczenie: provenance, review i kontrola wersji.

Scenariusz 2: Złośliwy fragment w FAQ próbuje wymusić ujawnienie danych

• Cel: złośliwy fragment w FAQ próbuje wymusić ujawnienie danych.
• Wejście: repozytorium dokumentów, FAQ albo baza wiedzy.
• Kroki: sprawdź źródło -> wykryj zmianę -> odizoluj podejrzany materiał.
• Rezultat: mniejsze ryzyko odpowiedzi opartych na zatrutych danych.
• Zabezpieczenie: provenance, review i kontrola wersji.

Ryzyko 1: Błędne decyzje

• Ryzyko: Błędne decyzje.
• Jak ograniczać: whitelist + review + podpisywanie źródeł.

Ryzyko 2: Prompt injection w dokumentach

• Ryzyko: Prompt injection w dokumentach.
• Jak ograniczać: skanowanie i filtracja.

Ryzyko 3: Utrata zaufania

• Ryzyko: Utrata zaufania.
• Jak ograniczać: monitoring jakości i szybki rollback.

• Czy źródła są zatwierdzone?
• Czy dokumenty mają właściciela i wersję?
• Czy jest przegląd zmian?
• Czy testujesz RAG na „złych” przykładach?
• Czy masz monitoring i alarmy?

• To jak podmiana karteczek w instrukcji, żeby ktoś robił źle.
• W RAG wystarczy wstrzyknąć jeden „sprytny” fragment do bazy wiedzy.
• Skutkiem mogą być błędne procedury lub wycieki.

• Brak kontroli źródeł (każdy może dodać dokument).
• Brak przeglądu zmian i wersjonowania.

Diagram pokazuje, że zatrute dane mogą wpłynąć na model już na etapie treningu, dlatego trzeba kontrolować jakość zbioru.

• RAG
• Baza wektorowa
• Prompt injection
• Red teaming
• Audit trail

Data provenance to informacja o tym, skąd pochodzą dane: kto je stworzył, kiedy, w jakiej wersji, jak były przetwarzane i gdzie są używane.

Scenariusz 1: W pojęciowniku

• Cel: data aktualizacji definicji i autor zmian.
• Wejście: dokument, dane albo wynik modelu.
• Kroki: zapisz źródło -> śledź wersję -> pokaż pochodzenie.
• Rezultat: łatwiejsza weryfikacja materiału.
• Zabezpieczenie: kontrola wersji i właściciel źródła.

Scenariusz 2: W RAG

• Cel: informacja z jakiego dokumentu i wersji pochodzi fragment.
• Wejście: dokument, dane albo wynik modelu.
• Kroki: zapisz źródło -> śledź wersję -> pokaż pochodzenie.
• Rezultat: łatwiejsza weryfikacja materiału.
• Zabezpieczenie: kontrola wersji i właściciel źródła.

Scenariusz 3: W firmie

• Cel: ślad, że procedura pochodzi z polityki X wersja Y.
• Wejście: dokument, dane albo wynik modelu.
• Kroki: zapisz źródło -> śledź wersję -> pokaż pochodzenie.
• Rezultat: łatwiejsza weryfikacja materiału.
• Zabezpieczenie: kontrola wersji i właściciel źródła.

Ryzyko 1: Brak provenance = brak zaufania i trudna naprawa błędów

• Ryzyko: brak provenance = brak zaufania i trudna naprawa błędów.
• Jak ograniczać: wersjonowanie, daty aktualizacji, identyfikatory dokumentów.

Ryzyko 2: Provenance jest, ale rozproszone i nieczytelne

• Ryzyko: provenance jest, ale rozproszone i nieczytelne.
• Jak ograniczać: standard zapisu metadanych, szablony i automaty.

Ryzyko 3: Ujawnianie zbyt dużo informacji wrażliwych

• Ryzyko: ujawnianie zbyt dużo informacji wrażliwych.
• Jak ograniczać: publikuj tylko potrzebne metadane, resztę trzymaj w logach z dostępem.

To „metryczka danych”. Dzięki niej da się odpowiedzieć na pytania:

• „Skąd to wiemy?”
• „Czy to jest aktualne?”
• „Kto to zmienił?”
• „Czy można temu ufać?”

W AI provenance jest ważne, bo jakość odpowiedzi zależy od jakości źródeł.

Diagram pokazuje, że pochodzenie danych trzeba śledzić od źródła przez transformacje aż do późniejszego użycia i audytu.

Deepfake to zmanipulowane materiały audio lub wideo tworzone przez AI, które imitują prawdziwe osoby. Mogą wyglądać realistycznie, mimo że są fałszywe. To ryzyko w obszarze dezinformacji i reputacji.

Scenariusz 1: Ochrona marki

• Cel: ochrona marki.
• Wejście: monitoring mediów.
• Kroki: wykrycie → weryfikacja → reakcja.
• Rezultat: szybkie sprostowanie.
• Zabezpieczenie: plan kryzysowy.

Scenariusz 2: Weryfikacja nagrań w procesach HR

• Cel: weryfikacja nagrań w procesach HR.
• Wejście: nagranie wideo.
• Kroki: analiza → potwierdzenie źródła → decyzja.
• Rezultat: bezpieczny proces.
• Zabezpieczenie: zasada dwóch kanałów.

Scenariusz 3: Szkolenia bezpieczeństwa

• Cel: szkolenia bezpieczeństwa.
• Wejście: przykłady deepfake.
• Kroki: szkolenie → testy → procedury.
• Rezultat: większa odporność zespołu.
• Zabezpieczenie: regularne przypomnienia.

Ryzyko 1: Dezinformacja

• Ryzyko: Dezinformacja.
• Jak ograniczać: monitoring i szybkie sprostowania.

Ryzyko 2: Oszustwa

• Ryzyko: Oszustwa.
• Jak ograniczać: weryfikacja tożsamości wieloma kanałami.

Ryzyko 3: Reputacja

• Ryzyko: Reputacja.
• Jak ograniczać: plan komunikacji kryzysowej.

• Czy masz procedurę weryfikacji nagrań?
• Czy zespół zna ryzyko deepfake?
• Czy masz plan komunikacji kryzysowej?
• Czy treści są odpowiednio oznaczone?
• Czy logujesz incydenty?

• Deepfake „udaje” prawdziwe nagranie lub głos.
• Może być użyty do oszustw lub manipulacji.
• W biznesie grozi reputacji i bezpieczeństwu informacji.
• Wymaga procedur weryfikacji i oznaczania treści.

• Traktowanie każdego nagrania jako wiarygodnego.
• Brak procedur weryfikacji.
• Brak komunikacji kryzysowej.

Diagram pokazuje, że deepfake powstaje z materiałów prawdziwej osoby, potem jest generowany przez model i może trafić do publikacji. Punkt kontroli to weryfikacja i oznaczenie treści przed użyciem.

• GenAI
• Model multimodalny
• Fact-checking
• Transparentność
• Dostępność treści AI

Destylacja modelu to technika, w której mniejszy model uczy się na podstawie odpowiedzi albo zachowania większego modelu, aby przejąć część jego jakości przy niższym koszcie działania.

Scenariusz 1: Tańsza klasyfikacja zgłoszeń

• Cel: zastąpić kosztowny model dużej skali w prostym procesie klasyfikacji.
• Wejście: przykłady wejść, odpowiedzi większego modelu i kryteria oceny.
• Kroki: generowanie wzorców -> uczenie mniejszego modelu -> benchmark.
• Rezultat: lżejszy model do jednego konkretnego zadania.
• Zabezpieczenie: porównanie z wynikiem modelu nauczyciela.

Scenariusz 2: Przygotowanie modelu lokalnego

• Cel: uruchomić model bliżej danych i na słabszej infrastrukturze.
• Wejście: większy model, dane zadaniowe i wymagania środowiska.
• Kroki: wybór nauczyciela -> przygotowanie zbioru -> destylacja.
• Rezultat: model łatwiejszy do uruchomienia lokalnie.
• Zabezpieczenie: testy jakości po wdrożeniu.

Scenariusz 3: Stabilizacja formatu odpowiedzi

• Cel: nauczyć mniejszy model stałego stylu i formatu.
• Wejście: zestaw przykładów generowanych przez model większy.
• Kroki: przygotowanie par wejście-wyjście -> uczenie -> ocena formatu.
• Rezultat: bardziej przewidywalne odpowiedzi w produkcji.
• Zabezpieczenie: kontrola błędów i monitoring regresji.

Ryzyko 1: Utrwalenie błędów nauczyciela

• Ryzyko: utrwalenie błędów nauczyciela.
• Jak ograniczać: sprawdzaj jakość danych treningowych.

Ryzyko 2: Spadek jakości w trudniejszych przypadkach

• Ryzyko: spadek jakości w trudniejszych przypadkach.
• Jak ograniczać: testuj na realnych scenariuszach.

Ryzyko 3: Pozorna oszczędność

• Ryzyko: pozorna oszczędność.
• Jak ograniczać: licz pełny koszt przygotowania i utrzymania.

Ryzyko 4: Zbyt wąskie zastosowanie

• Ryzyko: zbyt wąskie zastosowanie.
• Jak ograniczać: jasno określ zakres zadania dla modelu ucznia.

• Czy znasz konkretne zadanie dla modelu po destylacji?
• Czy dane od modelu nauczyciela są dobrej jakości?
• Czy wykonano benchmark przed i po?
• Czy zakres użycia jest ograniczony?
• Czy wiadomo, kiedy trzeba przełączyć się na większy model?

To sposób tworzenia „lżejszego ucznia” na bazie „większego nauczyciela”. Organizacja używa dużego modelu do przygotowania wzorców albo odpowiedzi, a potem uczy nimi model mniejszy.

Celem jest zwykle:

• obniżenie kosztu,
• skrócenie czasu odpowiedzi,
• łatwiejsze wdrożenie lokalne,
• zachowanie wystarczającej jakości w węższym zadaniu.

• Zakładanie, że mały model przejmie całą jakość dużego.
• Uczenie na słabych albo błędnych odpowiedziach nauczyciela.
• Brak benchmarku po destylacji.
• Mylenie destylacji z kwantyzacją.

Diagram pokazuje, że destylacja przenosi część jakości dużego modelu do mniejszego modelu przez przykłady i późniejszy test jakości.

• Small Language Model (SLM)

• Fine-tuning (dostrajanie)

• Kwantyzacja (Quantization)

• Ewaluacja

• Benchmark

---

Deterministyczność oznacza, że przy tych samych danych wejściowych system daje ten sam (lub bardzo podobny) wynik.

Scenariusz 1: Generowanie komunikatu urzędowego

• Cel: chcesz, żeby format zawsze był taki sam.
• Wejście: to samo wejście i ustawienia modelu.
• Kroki: uruchom test -> porównaj wyniki -> ustabilizuj parametry.
• Rezultat: bardziej powtarzalne odpowiedzi.
• Zabezpieczenie: kontrola temperatury i wersji modelu.

Scenariusz 2: Zmiana temperatury

• Cel: niższa = bardziej powtarzalne odpowiedzi.
• Wejście: to samo wejście i ustawienia modelu.
• Kroki: uruchom test -> porównaj wyniki -> ustabilizuj parametry.
• Rezultat: bardziej powtarzalne odpowiedzi.
• Zabezpieczenie: kontrola temperatury i wersji modelu.

Scenariusz 3: RAG

• Cel: odpowiedź bardziej stabilna, bo opiera się na tych samych źródłach.
• Wejście: to samo wejście i ustawienia modelu.
• Kroki: uruchom test -> porównaj wyniki -> ustabilizuj parametry.
• Rezultat: bardziej powtarzalne odpowiedzi.
• Zabezpieczenie: kontrola temperatury i wersji modelu.

Ryzyko 1: Zbyt duża deterministyczność = „sztywne” odpowiedzi

• Ryzyko: zbyt duża deterministyczność = „sztywne” odpowiedzi.
• Jak ograniczać: dobierz parametry do celu (kreatywność vs procedura).

Ryzyko 2: Zbyt mała deterministyczność = chaos i brak kontroli

• Ryzyko: zbyt mała deterministyczność = chaos i brak kontroli.
• Jak ograniczać: szablony, structured output, testy.

Ryzyko 3: Zmiany modelu psują powtarzalność

• Ryzyko: zmiany modelu psują powtarzalność.
• Jak ograniczać: wersjonowanie i benchmarki.

Modele generatywne mają element losowości. Czasem to zaleta (kreatywność), a czasem wada (chcesz powtarzalności). Deterministyczność zależy m.in. od:

• temperatury i sampling (np. „temperatura”),
• długości i struktury promptu,
• użycia źródeł (RAG),
• wersji modelu.

Diagram pokazuje, że deterministyczność oznacza powtarzalny wynik przy tych samych danych i ustawieniach.

DLP to zestaw mechanizmów, które pomagają zapobiegać wyciekom danych. Na przykład mogą blokować wysyłkę danych osobowych poza organizację.

Scenariusz 1: Blokowanie wklejania PII do czatów AI

• Cel: blokowanie wklejania PII do czatów AI.
• Wejście: tekst, plik albo log z możliwymi danymi wrażliwymi.
• Kroki: wykryj wzorzec -> zablokuj lub zamaskuj -> zapisz decyzję.
• Rezultat: mniejsze ryzyko wycieku danych.
• Zabezpieczenie: polityki DLP i testy wyjątków.

Scenariusz 2: Ostrzeganie, gdy ktoś próbuje wysłać wrażliwy plik

• Cel: ostrzeganie, gdy ktoś próbuje wysłać wrażliwy plik.
• Wejście: tekst, plik albo log z możliwymi danymi wrażliwymi.
• Kroki: wykryj wzorzec -> zablokuj lub zamaskuj -> zapisz decyzję.
• Rezultat: mniejsze ryzyko wycieku danych.
• Zabezpieczenie: polityki DLP i testy wyjątków.

Scenariusz 3: Maskowanie danych w logach

• Cel: maskowanie danych w logach.
• Wejście: tekst, plik albo log z możliwymi danymi wrażliwymi.
• Kroki: wykryj wzorzec -> zablokuj lub zamaskuj -> zapisz decyzję.
• Rezultat: mniejsze ryzyko wycieku danych.
• Zabezpieczenie: polityki DLP i testy wyjątków.

Ryzyko 1: Fałszywe alarmy

• Ryzyko: Fałszywe alarmy.
• Jak ograniczać: strojenie reguł i tryb ostrzegania.

Ryzyko 2: Obejścia

• Ryzyko: Obejścia.
• Jak ograniczać: szkolenia + audyt.

Ryzyko 3: Brak spójności

• Ryzyko: Brak spójności.
• Jak ograniczać: centralna polityka.

• Czy reguły DLP obejmują PII i dokumenty?
• Czy jest proces wyjątków?
• Czy logi są przeglądane?
• Czy użytkownicy są przeszkoleni?
• Czy DLP obejmuje narzędzia AI?

• DLP działa jak „bramka bezpieczeństwa”.
• Może wykrywać numery PESEL, adresy, numery kont i je blokować lub maskować.
• Wspiera bezpieczne użycie AI w organizacji.

• Zbyt ostre reguły (blokują pracę).
• Brak wyjątków kontrolowanych (dla uprawnionych procesów).

Diagram pokazuje, że DLP wykrywa i zatrzymuje ryzykowny przepływ danych według ustalonych polityk.

• PII
• Anonimizacja
• RODO / DPIA
• SSO / IAM
• Audit trail

To zestaw zasad, które sprawiają, że treści tworzone z pomocą AI są czytelne i użyteczne dla wszystkich. Dotyczy to także osób z niepełnosprawnościami.

Scenariusz 1: Opisy grafik w social media i na stronach WWW

• Cel: opisy grafik w social media i na stronach WWW.
• Wejście: treść, grafika albo komunikat do publikacji.
• Kroki: sprawdź dostępność -> popraw język -> zweryfikuj odbiór.
• Rezultat: treść bardziej dostępna dla różnych użytkowników.
• Zabezpieczenie: kontrola WCAG i przegląd redakcyjny.

Scenariusz 2: Upraszczanie komunikatów i instrukcji

• Cel: upraszczanie komunikatów i instrukcji.
• Wejście: treść, grafika albo komunikat do publikacji.
• Kroki: sprawdź dostępność -> popraw język -> zweryfikuj odbiór.
• Rezultat: treść bardziej dostępna dla różnych użytkowników.
• Zabezpieczenie: kontrola WCAG i przegląd redakcyjny.

Scenariusz 3: Porządkowanie artykułów, ofert i komunikatów urzędowych

• Cel: porządkowanie artykułów, ofert i komunikatów urzędowych.
• Wejście: treść, grafika albo komunikat do publikacji.
• Kroki: sprawdź dostępność -> popraw język -> zweryfikuj odbiór.
• Rezultat: treść bardziej dostępna dla różnych użytkowników.
• Zabezpieczenie: kontrola WCAG i przegląd redakcyjny.

Ryzyko 1: Wykluczenie części odbiorców

• Ryzyko: Wykluczenie części odbiorców.
• Jak ograniczać: stosuj checklistę dostępności i przegląd przed publikacją.

Ryzyko 2: Nieczytelność treści

• Ryzyko: Nieczytelność treści.
• Jak ograniczać: skracaj zdania i dziel treść na mniejsze części.

Ryzyko 3: Błędy publikacji

• Ryzyko: Błędy publikacji.
• Jak ograniczać: sprawdzaj nagłówki, linki, teksty alternatywne i kolejność informacji.

• Czy nagłówki mają logiczną kolejność?
• Czy długie akapity da się podzielić na krótsze części?
• Czy grafiki mają sensowny tekst alternatywny?
• Czy język jest prosty i konkretny?
• Czy ktoś sprawdził treść przed publikacją?

• AI może pomagać w pisaniu, ale może też pogarszać jakość treści.
• Problemem bywają zbyt długie zdania, brak struktury i brak tekstów alternatywnych.
• Dobra treść powinna być prosta, logiczna i poprawnie sformatowana.
• W praktyce liczą się nagłówki, listy, prosty język i opisy grafik.

• Brak tekstów alternatywnych.
• Przeładowane akapity.
• Nagłówki używane tylko „dla ozdoby”.
• Publikacja treści bez szybkiego przeglądu człowieka.

Diagram pokazuje, że treść wygenerowana przez AI powinna przejść przez etap dostosowania i sprawdzenia dostępności.

• Polecenie dla modelu
• Transparentność
• Fact-checking
• Human-in-the-loop
• Stack

Dryft to sytuacja, w której z czasem zmieniają się dane, kontekst lub zachowanie systemu AI. Przez to wyniki stają się gorsze albo inne niż wcześniej.

Scenariusz 1: Słownik

• Cel: dodajesz nowe pojęcia, a wyszukiwarka zaczyna gorzej trafiać.
• Wejście: metryki jakości i dane produkcyjne.
• Kroki: monitoruj zmianę -> porównaj z bazą -> uruchom korektę.
• Rezultat: szybsze wykrycie spadku jakości.
• Zabezpieczenie: alerty i okresowa ewaluacja.

Scenariusz 2: Firma

• Cel: zmiana procedury, a chatbot nadal odpowiada „po staremu”.
• Wejście: metryki jakości i dane produkcyjne.
• Kroki: monitoruj zmianę -> porównaj z bazą -> uruchom korektę.
• Rezultat: szybsze wykrycie spadku jakości.
• Zabezpieczenie: alerty i okresowa ewaluacja.

Scenariusz 3: Produkt

• Cel: nowe funkcje, a model nie nadąża z instrukcjami.
• Wejście: metryki jakości i dane produkcyjne.
• Kroki: monitoruj zmianę -> porównaj z bazą -> uruchom korektę.
• Rezultat: szybsze wykrycie spadku jakości.
• Zabezpieczenie: alerty i okresowa ewaluacja.

Ryzyko 1: Spadek jakości i zaufania

• Ryzyko: spadek jakości i zaufania.
• Jak ograniczać: regularna ewaluacja + monitoring + poprawki na podstawie logów.

Ryzyko 2: Błędne decyzje na podstawie „starych” odpowiedzi

• Ryzyko: błędne decyzje na podstawie „starych” odpowiedzi.
• Jak ograniczać: daty aktualizacji, cytowanie źródeł, sygnalizowanie niepewności.

Ryzyko 3: Drift bezpieczeństwa (nowe typy ataków)

• Ryzyko: drift bezpieczeństwa (nowe typy ataków).
• Jak ograniczać: red teaming i aktualizacja zabezpieczeń.

AI może działać dobrze dziś, a gorzej za miesiąc, bo:

• zmieniły się dokumenty i procesy,
• pojawiły się nowe słowa, nazwy, produkty,
• użytkownicy pytają inaczej,
• dane „w tle” mają inny rozkład niż w testach.

To normalne zjawisko. Problem zaczyna się wtedy, gdy nikt go nie zauważa.

Diagram pokazuje, że zmiana danych lub warunków użycia w czasie może obniżyć jakość modelu i wymaga monitoringu.

Dynamiczny kontekst to podejście, w którym system dobiera do promptu tylko te fragmenty informacji, które są potrzebne do konkretnego pytania — zamiast wklejać „wszystko”.

Scenariusz 1: Pytasz o „prompt injection” → system dobiera fragmenty o atakach, a nie całe rozdziały

• Cel: pytasz o „prompt injection” → system dobiera fragmenty o atakach, a nie całe rozdziały.
• Wejście: zapytanie i wiele możliwych fragmentów kontekstu.
• Kroki: wybierz fragmenty -> ogranicz długość -> wygeneruj odpowiedź.
• Rezultat: bardziej trafny kontekst.
• Zabezpieczenie: limity fragmentów i ranking źródeł.

Scenariusz 2: Pytasz o „koszty tokenów” → dobiera definicje token/okno kontekstowe/caching

• Cel: pytasz o „koszty tokenów” → dobiera definicje token/okno kontekstowe/caching.
• Wejście: zapytanie i wiele możliwych fragmentów kontekstu.
• Kroki: wybierz fragmenty -> ogranicz długość -> wygeneruj odpowiedź.
• Rezultat: bardziej trafny kontekst.
• Zabezpieczenie: limity fragmentów i ranking źródeł.

Scenariusz 3: Pytasz o „RAG” → dobiera retrieval, chunking, vector database

• Cel: pytasz o „RAG” → dobiera retrieval, chunking, vector database.
• Wejście: zapytanie i wiele możliwych fragmentów kontekstu.
• Kroki: wybierz fragmenty -> ogranicz długość -> wygeneruj odpowiedź.
• Rezultat: bardziej trafny kontekst.
• Zabezpieczenie: limity fragmentów i ranking źródeł.

Ryzyko 1: System dobierze zły kontekst

• Ryzyko: system dobierze zły kontekst.
• Jak ograniczać: reranking, testy, fallback „pokaż źródła”.

Ryzyko 2: Brak przejrzystości („skąd to wzięte?”)

• Ryzyko: brak przejrzystości („skąd to wzięte?”).
• Jak ograniczać: cytowanie i provenance fragmentów.

Ryzyko 3: Ataki przez dokumenty (context poisoning)

• Ryzyko: ataki przez dokumenty (context poisoning).
• Jak ograniczać: filtry, polityka źródeł, guardrails.

Okno kontekstowe ma limit. Jeśli wrzucisz za dużo, AI:

• gubi sedno,
• jest droższa,
• bywa mniej trafna.

Dynamiczny kontekst działa jak selekcja: „weź najlepsze 3–8 fragmentów” i nic więcej.

Diagram pokazuje, że odpowiedź modelu może być budowana z uwzględnieniem bieżącej rozmowy i zapisanych ustaleń.

Chunking to dzielenie dokumentów na mniejsze fragmenty. Dzięki temu łatwiej je wyszukać i wstawić do kontekstu modelu.

Scenariusz 1: RAG do procedur

• Cel: RAG do procedur.
• Wejście: PDF procedury.
• Kroki: podział na sekcje → embedding → baza.
• Rezultat: trafne cytaty.
• Zabezpieczenie: zachowanie numerów rozdziałów.

Scenariusz 2: Baza odpowiedzi do strony WWW i FAQ

• Cel: baza odpowiedzi do strony WWW i FAQ.
• Wejście: regulaminy i FAQ.
• Kroki: podział na fragmenty -> linkowanie -> wyszukiwarka.
• Rezultat: szybkie dopasowanie.
• Zabezpieczenie: kontrola wersji.

Scenariusz 3: Analiza uchwał

• Cel: analiza uchwał.
• Wejście: długie dokumenty.
• Kroki: dziel po paragrafach.
• Rezultat: cytowanie konkretów.
• Zabezpieczenie: spójne ID fragmentów.

Ryzyko 1: Utrata kontekstu

• Ryzyko: Utrata kontekstu: fragment bez definicji.
• Jak ograniczać: overlap (nakładanie) + sekcje.

Ryzyko 2: Błędne cytaty

• Ryzyko: Błędne cytaty: brak źródła fragmentu.
• Jak ograniczać: metadane: tytuł, rozdział, URL.

Ryzyko 3: Bałagan w aktualizacjach

• Ryzyko: Bałagan w aktualizacjach: fragmenty się „rozjeżdżają”.
• Jak ograniczać: stałe identyfikatory.

• Czy chunk ma tytuł/sekcję?
• Czy jest overlap (np. 10–20%)?
• Czy fragment ma link do źródła?
• Czy rozmiar chunków jest testowany na pytaniach?
• Czy aktualizacja dokumentu przebudowuje indeks?

• Model nie „połknie” całej książki naraz — ma limit kontekstu.
• Dlatego dokument dzieli się na sensowne części, na przykład akapity albo sekcje.
• Dobre fragmenty zwykle dają lepsze odpowiedzi w RAG.

• Zbyt krótkie fragmenty -> brak kontekstu.
• Zbyt długie fragmenty -> szum i gorsze wyniki.
• Dzielenie w losowych miejscach (bez nagłówków).

Diagram pokazuje, że długi dokument trzeba podzielić na sensowne fragmenty, aby łatwiej go wyszukać i zacytować.

• RAG
• Embedding
• Okno kontekstowe
• Ewaluacja
• Monitoring jakości

Ewaluacja to systematyczne sprawdzanie, jak dobrze model lub asystent radzi sobie z konkretnymi zadaniami.

Scenariusz 1: Test odpowiedzi na 50 typowych pytań klientów

• Cel: test odpowiedzi na 50 typowych pytań klientów.
• Wejście: zestaw testowy i kryteria jakości.
• Kroki: uruchom test -> oceń wyniki -> zapisz wnioski.
• Rezultat: mierzalna ocena jakości.
• Zabezpieczenie: stała rubryka i powtarzalny zestaw testowy.

Scenariusz 2: Test streszczeń dokumentów (czy sens się zgadza)

• Cel: test streszczeń dokumentów (czy sens się zgadza).
• Wejście: zestaw testowy i kryteria jakości.
• Kroki: uruchom test -> oceń wyniki -> zapisz wnioski.
• Rezultat: mierzalna ocena jakości.
• Zabezpieczenie: stała rubryka i powtarzalny zestaw testowy.

Scenariusz 3: Test wykrywania danych wrażliwych (czy asystent nie prosi o PII)

• Cel: test wykrywania danych wrażliwych (czy asystent nie prosi o PII).
• Wejście: zestaw testowy i kryteria jakości.
• Kroki: uruchom test -> oceń wyniki -> zapisz wnioski.
• Rezultat: mierzalna ocena jakości.
• Zabezpieczenie: stała rubryka i powtarzalny zestaw testowy.

Ryzyko 1: Spadek jakości po zmianie

• Ryzyko: Spadek jakości po zmianie.
• Jak ograniczać: regresja testów.

Ryzyko 2: Stronniczość

• Ryzyko: Stronniczość.
• Jak ograniczać: zestawy testowe z różnymi przypadkami.

Ryzyko 3: Brak powtarzalności

• Ryzyko: Brak powtarzalności.
• Jak ograniczać: benchmark i stałe instrukcje.

• Czy masz zestaw pytań testowych?
• Czy masz kryteria oceny (rubryka)?
• Czy mierzysz błędy krytyczne?
• Czy testujesz bezpieczeństwo, na przykład wstrzyknięcie poleceń?
• Czy logujesz wersję modelu i danych?

• To „testy jakości”, zanim coś trafi do ludzi.
• W firmie liczy się: poprawność, zgodność z procedurą, język prosty, bezpieczeństwo.
• Bez ewaluacji nie wiesz, czy ulepszenie nie pogorszyło wyniku.

• Testowanie na 5 przykładach „które akurat wyszły”.
• Brak stałych kryteriów oceny.

Diagram pokazuje, że ewaluacja polega na mierzeniu jakości systemu na ustalonych przykładach.

• Benchmark
• LLMOps
• Monitoring jakości
• Grounding
• Polecenie dla modelu

Fact-checking to proces sprawdzania, czy treść jest zgodna z faktami i źródłami.

Scenariusz 1: Komunikat

• Cel: komunikat: sprawdź daty, godziny, miejsce, warunki.
• Wejście: treść do publikacji i źródła referencyjne.
• Kroki: wyodrębnij twierdzenia -> sprawdź źródła -> popraw błędy.
• Rezultat: mniej błędów faktograficznych.
• Zabezpieczenie: oficjalne źródła i druga para oczu.

Scenariusz 2: Odpowiedź na pismo

• Cel: odpowiedź na pismo: sprawdź podstawę prawną w źródle.
• Wejście: treść do publikacji i źródła referencyjne.
• Kroki: wyodrębnij twierdzenia -> sprawdź źródła -> popraw błędy.
• Rezultat: mniej błędów faktograficznych.
• Zabezpieczenie: oficjalne źródła i druga para oczu.

Scenariusz 3: Post w social media

• Cel: post w social media: sprawdź liczby i nazwy własne.
• Wejście: treść do publikacji i źródła referencyjne.
• Kroki: wyodrębnij twierdzenia -> sprawdź źródła -> popraw błędy.
• Rezultat: mniej błędów faktograficznych.
• Zabezpieczenie: oficjalne źródła i druga para oczu.

Ryzyko 1: Błędy reputacyjne

• Ryzyko: Błędy reputacyjne.
• Jak ograniczać: checklista + drugi czytelnik.

Ryzyko 2: Błędy formalne

• Ryzyko: Błędy formalne.
• Jak ograniczać: odwołanie do dokumentu źródłowego.

Ryzyko 3: Deepfake/dezinformacja

• Ryzyko: Deepfake/dezinformacja.
• Jak ograniczać: weryfikacja materiału i metadanych.

• Czy mam źródło do każdego twierdzenia?
• Czy daty/liczby są zgodne z dokumentem?
• Czy nazwy instytucji i jednostek są poprawne?
• Czy linki prowadzą do aktualnych stron?
• Czy ktoś drugi przeczytał?

• To nie „czepianie się” — to ochrona przed błędem.
• W firmie chodzi też o zgodność z dokumentami i przepisami.
• AI może pomóc pisać, ale człowiek odpowiada za prawdę.

• Weryfikacja „na oko”, bez źródła.
• Brak listy elementów do sprawdzenia (daty/liczby/nazwy).

Diagram pokazuje, że faktograficzna odpowiedź powinna zostać sprawdzona w źródłach przed użyciem lub publikacją.

• Halucynacje
• Cytowanie źródeł
• Grounding
• Human-in-the-loop
• Deepfake

Few-shot to sposób użycia modelu, w którym dodajesz kilka przykładów poprawnych odpowiedzi, żeby model lepiej trafił w format i styl.

Scenariusz 1: Odpowiedzi do klientów

• Cel: utrzymanie tonu i struktury odpowiedzi.
• Wejście: 2 przykłady dobrych odpowiedzi i nowa sprawa.
• Kroki: pokaż wzorce -> podaj przypadek -> wygeneruj odpowiedź.
• Rezultat: bardziej spójna komunikacja.
• Zabezpieczenie: przegląd odpowiedzi przed wysłaniem.

Scenariusz 2: Ocena zgłoszeń

• Cel: podobna klasyfikacja zgłoszeń.
• Wejście: przykłady ocen i nowe zgłoszenie.
• Kroki: wzorzec -> klasyfikacja -> uzasadnienie.
• Rezultat: mniej przypadkowe etykiety.
• Zabezpieczenie: testy na kilku zestawach.

Scenariusz 3: Pisanie haseł do pojęciownika

• Cel: utrzymanie struktury wpisów.
• Wejście: przykładowe hasło i nowe pojęcie.
• Kroki: wzorzec -> szkic -> korekta.
• Rezultat: wpis zgodny ze stylem repo.
• Zabezpieczenie: przegląd przez glossary-architect.

Ryzyko 1: Dane wrażliwe w przykładach

• Ryzyko: Dane wrażliwe w przykładach.
• Jak ograniczać: anonimizuj i stosuj DLP.

Ryzyko 2: Przejmowanie błędów z przykładów

• Ryzyko: Przejmowanie błędów z przykładów.
• Jak ograniczać: testuj na kilku zestawach i poprawiaj wzorce.

Ryzyko 3: Za długi prompt

• Ryzyko: Za długi prompt.
• Jak ograniczać: pilnuj tokenów i zostaw tylko potrzebne przykłady.

• Czy przykłady są dobre jakościowo?
• Czy nie zawierają danych wrażliwych?
• Czy format jest jasny?
• Czy wynik da się porównać z oczekiwaniami?

Zamiast długo tłumaczyć, pokazujesz 2-3 wzorce. Model łatwiej kopiuje strukturę niż domyśla się, jak ma wyglądać wynik.

Few-shot jest przydatny, gdy chcesz utrzymać konsekwentny format, uzyskać podobne wyniki w zespole albo pilnować wymagań redakcyjnych.

To często złoty środek między chaosem zero-shot a kosztami treningu.

Diagram pokazuje, że przykłady działają jak wzorzec formatu dla nowego zadania.

• Prompt
• Okno kontekstowe
• Token
• Dane osobowe (PII)
• Ewaluacja

Fine-tuning to proces dopasowania modelu do konkretnego stylu lub zadania przez dodatkowe uczenie na wybranych danych.

Scenariusz 1: Stały styl komunikatów

• Cel: stały styl komunikatów.
• Wejście: zestaw dobrych przykładów.
• Kroki: trening → testy → wdrożenie.
• Rezultat: spójne komunikaty.
• Zabezpieczenie: ewaluacja + human-in-the-loop.

Scenariusz 2: Klasyfikacja zgłoszeń (kategorie)

• Cel: klasyfikacja zgłoszeń (kategorie).
• Wejście: opis sprawy.
• Kroki: fine-tuning na etykietach.
• Rezultat: szybsze kierowanie.
• Zabezpieczenie: próg pewności + ręczna korekta.

Scenariusz 3: Poprawa tonu pism

• Cel: poprawa tonu pism.
• Wejście: wzorce + błędy.
• Kroki: trening stylu.
• Rezultat: mniej poprawek.
• Zabezpieczenie: kontrola prawna.

Ryzyko 1: PII/RODO

• Ryzyko: PII/RODO: dane w treningu.
• Jak ograniczać: anonimizacja + DPIA.

Ryzyko 2: Overfitting

• Ryzyko: Overfitting: model „uczy się na pamięć”.
• Jak ograniczać: walidacja, test set.

Ryzyko 3: Koszty i zależności

• Ryzyko: Koszty i zależności: lock-in.
• Jak ograniczać: dokumentacja i możliwość wycofania.

• Czy dane są legalne i zanonimizowane?
• Czy masz zbiór testowy i metryki?
• Czy masz proces wycofania wersji?
• Czy rezultat przechodzi review człowieka?
• Czy wiesz, czy nie wystarczy RAG?

• To jak „doszkolenie” modelu do Twojego języka i standardów.
• Nie zawsze poprawia wiedzę faktograficzną — często poprawia styl i powtarzalność.
• W firmie częściej wystarczy RAG + dobre prompty niż fine-tuning.

• Uczenie na małej, słabej jakości próbce.
• Wrzucanie danych wrażliwych do treningu.
• Brak ewaluacji po zmianie.

Diagram pokazuje, że fine-tuning polega na dodatkowym uczeniu modelu na wybranych danych i późniejszym testowaniu efektu.

• RAG
• Ewaluacja
• LLMOps
• Human-in-the-loop
• Vendor lock-in

Function calling to mechanizm, w którym model zamiast „zgadywać odpowiedź”, zwraca ustrukturyzowaną prośbę o wywołanie konkretnej funkcji (np. pobierz dane, policz, wyszukaj), a potem wykorzystuje wynik tej funkcji do odpowiedzi.

Scenariusz 1: Planowanie

• Cel: „Sprawdź wolne terminy w kalendarzu i zaproponuj 3 sloty.” (funkcja: odczyt kalendarza).
• Wejście: pytanie użytkownika i dostępna funkcja.
• Kroki: wybierz funkcję -> przekaż parametry -> użyj wyniku.
• Rezultat: odpowiedź oparta na wyniku funkcji.
• Zabezpieczenie: walidacja parametrów i obsługa błędów.

Scenariusz 2: Obsługa wiedzy

• Cel: „Znajdź w repo definicję RAG i podaj skrót.” (funkcja: wyszukaj w plikach).
• Wejście: pytanie użytkownika i dostępna funkcja.
• Kroki: wybierz funkcję -> przekaż parametry -> użyj wyniku.
• Rezultat: odpowiedź oparta na wyniku funkcji.
• Zabezpieczenie: walidacja parametrów i obsługa błędów.

Scenariusz 3: Automatyzacja

• Cel: „Zapisz to jako notatkę i dodaj tag ‘AI’.” (funkcja: utwórz wpis w systemie notatek).
• Wejście: pytanie użytkownika i dostępna funkcja.
• Kroki: wybierz funkcję -> przekaż parametry -> użyj wyniku.
• Rezultat: odpowiedź oparta na wyniku funkcji.
• Zabezpieczenie: walidacja parametrów i obsługa błędów.

Ryzyko 1: Model wybierze złą funkcję albo poda złe parametry

• Ryzyko: model wybierze złą funkcję albo poda złe parametry.
• Jak ograniczać: walidacja parametrów + lista dozwolonych funkcji (allowlist) + testy przypadków brzegowych.

Ryzyko 2: Wyciek danych (model „poprosi” o zbyt szeroki zakres)

• Ryzyko: wyciek danych (model „poprosi” o zbyt szeroki zakres).
• Jak ograniczać: minimalizacja danych, maskowanie PII, zasady dostępu per rola.

Ryzyko 3: Nadużycie funkcji przez prompt injection (atak w treści)

• Ryzyko: nadużycie funkcji przez prompt injection (atak w treści).
• Jak ograniczać: oddzielanie danych od instrukcji + guardrails + kontrola uprawnień.

Wyobraź sobie, że AI to „gadatliwy asystent”, który czasem powinien przestać gadać i… po prostu coś sprawdzić lub wykonać. Function calling to sposób, żeby AI powiedziało: „hej, potrzebuję danych z kalendarza / pliku / API — zróbmy to technicznie, a nie na słowo”. W praktyce: 1) Ty zadajesz pytanie, 2) model wybiera funkcję (np. „pobierz pogodę”, „wyszukaj w bazie”), 3) system wywołuje funkcję, 4) wynik wraca do modelu, 5) model tworzy finalną odpowiedź.

Dzięki temu AI częściej bazuje na faktach (bo „widzi” wynik funkcji), a rzadziej fantazjuje.

Diagram pokazuje, że model może poprosić system o wywołanie konkretnej funkcji zamiast zgadywać wynik.

GenAI (Generative AI) to systemy, które generują nowe treści: tekst, obraz, dźwięk lub kod. Modele uczą się wzorców z danych i tworzą nowe warianty. To kategoria technologii, a nie pojedynczy produkt.

Scenariusz 1: Szkice kampanii marketingowej

• Cel: szkice kampanii marketingowej.
• Wejście: brief i grupa docelowa.
• Kroki: prompt → warianty → wybór.
• Rezultat: pomysły do dopracowania.
• Zabezpieczenie: kontrola brandowa.

Scenariusz 2: Opisy produktów

• Cel: opisy produktów.
• Wejście: specyfikacja.
• Kroki: generacja → redakcja → publikacja.
• Rezultat: spójne opisy.
• Zabezpieczenie: weryfikacja faktów.

Scenariusz 3: Materiały szkoleniowe

• Cel: materiały szkoleniowe.
• Wejście: zakres szkolenia.
• Kroki: generacja konspektu → korekta → zatwierdzenie.
• Rezultat: szkic materiału.
• Zabezpieczenie: review merytoryczne.

Ryzyko 1: Dezinformacja

• Ryzyko: Dezinformacja.
• Jak ograniczać: weryfikacja faktów.

Ryzyko 2: Prawa autorskie

• Ryzyko: Prawa autorskie.
• Jak ograniczać: polityka źródeł i review.

Ryzyko 3: Deepfake

• Ryzyko: Deepfake.
• Jak ograniczać: oznaczanie treści i procedury.

• Czy masz jasny cel i brief?
• Czy weryfikujesz fakty i daty?
• Czy treść jest zgodna z marką?
• Czy masz politykę praw autorskich?
• Czy wiesz, gdzie nie używać GenAI?

• GenAI „wytwarza” treści na podstawie polecenia.
• Jakość zależy od danych wejściowych i ustawień.
• Może przyspieszać pracę kreatywną i automatyzacje.
• Wymaga weryfikacji, bo może tworzyć błędy.

• Traktowanie treści GenAI jako gotowych do publikacji.
• Brak kontroli praw autorskich.
• Zbyt ogólne prompty.

Diagram pokazuje podstawowy przepływ generowania treści przez model AI i potrzebę sprawdzenia wyniku.

• LLM
• Deepfake
• Model multimodalny
• Fact-checking
• Transparentność

GPAI (General-Purpose AI, czyli AI ogólnego przeznaczenia) to modele, które mogą być używane w wielu różnych zadaniach i kontekstach. Nie są zaprojektowane do jednego wąskiego celu. To pojęcie opisuje klasę modeli, a nie konkretny produkt.

Scenariusz 1: Jedna platforma AI dla wielu działów

• Cel: jedna platforma AI dla wielu działów.
• Wejście: polityka użycia.
• Kroki: konfiguracja → role → monitoring.
• Rezultat: spójne wykorzystanie.
• Zabezpieczenie: audyt i ograniczenia.

Scenariusz 2: Szybkie prototypowanie usług

• Cel: szybkie prototypowanie usług.
• Wejście: brief produktu.
• Kroki: testy → pilotaż → wdrożenie.
• Rezultat: szybszy time-to-market.
• Zabezpieczenie: ocena ryzyk.

Scenariusz 3: Automatyzacja procesów

• Cel: automatyzacja procesów.
• Wejście: opis procesów.
• Kroki: mapowanie → prompty → kontrola.
• Rezultat: oszczędność czasu.
• Zabezpieczenie: human-in-the-loop.

Ryzyko 1: Nieprzewidywalne użycia

• Ryzyko: Nieprzewidywalne użycia.
• Jak ograniczać: jasne polityki i role.

Ryzyko 2: Stronniczość

• Ryzyko: Stronniczość.
• Jak ograniczać: testy na różnych danych.

Ryzyko 3: Vendor lock-in

• Ryzyko: Vendor lock-in.
• Jak ograniczać: strategia wyjścia.

• Czy określono dozwolone przypadki użycia?
• Czy są role i uprawnienia?
• Czy jest plan monitoringu jakości?
• Czy są procedury eskalacji błędów?
• Czy logujesz użycie?

• To „uniwersalne” modele, które potrafią robić wiele rzeczy.
• Mogą zasilać różne aplikacje: od obsługi klienta po analizę dokumentów.
• Taka ogólność zwiększa możliwości, ale też ryzyka.
• Wymaga to jasnych zasad użycia i kontroli jakości.

• Traktowanie modelu ogólnego jako „gotowego na wszystko”.
• Brak ograniczeń zakresu użycia.
• Zbyt szeroki dostęp w organizacji.

Diagram pokazuje, że GPAI to model używany do wielu różnych zastosowań, a nie do jednego wąskiego zadania.

• GenAI
• LLM
• Polityka AI
• Ewaluacja
• Vendor lock-in

Ground truth to „prawidłowa odpowiedź” lub zestaw danych referencyjnych, do których porównujesz wyniki AI.

Scenariusz 1: Zestaw 100 pytań o pojęciownik z przygotowanymi dobrymi odpowiedziami

• Cel: zestaw 100 pytań o pojęciownik z przygotowanymi dobrymi odpowiedziami.
• Wejście: zestaw referencyjnych odpowiedzi albo etykiet.
• Kroki: porównaj wynik -> policz różnice -> popraw model lub prompt.
• Rezultat: ocena jakości oparta na wzorcu.
• Zabezpieczenie: aktualizacja i przegląd danych referencyjnych.

Scenariusz 2: Lista „poprawnych” fragmentów dokumentów do retrieval

• Cel: lista „poprawnych” fragmentów dokumentów do retrieval.
• Wejście: zestaw referencyjnych odpowiedzi albo etykiet.
• Kroki: porównaj wynik -> policz różnice -> popraw model lub prompt.
• Rezultat: ocena jakości oparta na wzorcu.
• Zabezpieczenie: aktualizacja i przegląd danych referencyjnych.

Scenariusz 3: Testy bezpieczeństwa

• Cel: oczekiwana reakcja „odmowa” na niebezpieczne prośby.
• Wejście: zestaw referencyjnych odpowiedzi albo etykiet.
• Kroki: porównaj wynik -> policz różnice -> popraw model lub prompt.
• Rezultat: ocena jakości oparta na wzorcu.
• Zabezpieczenie: aktualizacja i przegląd danych referencyjnych.

Ryzyko 1: Ground truth jest nieaktualne

• Ryzyko: ground truth jest nieaktualne.
• Jak ograniczać: aktualizacje, wersjonowanie, daty.

Ryzyko 2: Ground truth jest stronnicze

• Ryzyko: ground truth jest stronnicze.
• Jak ograniczać: różne osoby, różne przypadki, analiza bias.

Ryzyko 3: Porównujesz nie to, co trzeba (zła metryka)

• Ryzyko: porównujesz nie to, co trzeba (zła metryka).
• Jak ograniczać: jasne kryteria jakości i metryki.

Jeśli chcesz ocenić, czy AI działa dobrze, musisz mieć punkt odniesienia:

• prawidłowe odpowiedzi,
• poprawne etykiety,
• sprawdzone źródła.

Bez ground truth łatwo wpaść w pułapkę: „wydaje się OK”, ale w praktyce jest źle.

Diagram pokazuje, że ground truth jest punktem odniesienia do oceny jakości systemu.

Grounding to technika, w której model odpowiada na podstawie wskazanych źródeł, a nie tylko „z pamięci modelu”.

Scenariusz 1: Komunikat do klientów z regulaminy

• Cel: komunikat do klientów z regulaminy.
• Wejście: regulamin.
• Kroki: wybierz fragmenty → generuj → dodaj cytaty.
• Rezultat: czytelny komunikat.
• Zabezpieczenie: weryfikacja prawnika.

Scenariusz 2: Odpowiedź na zgłoszenie o informację

• Cel: odpowiedź na zgłoszenie o informację.
• Wejście: procedura + wzór.
• Kroki: RAG → odpowiedź → źródła.
• Rezultat: spójna odpowiedź.
• Zabezpieczenie: usunięcie PII.

Scenariusz 3: Streszczenie regulaminu

• Cel: streszczenie regulaminu.
• Wejście: regulamin.
• Kroki: grounding → plain language.
• Rezultat: skrót z odnośnikami.
• Zabezpieczenie: brak zmian sensu.

Ryzyko 1: Błędne źródła

• Ryzyko: Błędne źródła: zły dokument w bazie.
• Jak ograniczać: whitelist + wersjonowanie.

Ryzyko 2: Nadinterpretacja

• Ryzyko: Nadinterpretacja: model dopowiada.
• Jak ograniczać: polecenie: „tylko na podstawie cytatów”.

Ryzyko 3: Ukryte wstrzyknięcia

• Ryzyko: Ukryte wstrzyknięcia: złośliwy fragment w źródle.
• Jak ograniczać: skan + review.

• Czy źródła są oficjalne i aktualne?
• Czy odpowiedź zawiera cytaty/linki?
• Czy w treści nie ma dopowiedzeń poza źródłem?
• Czy wersje dokumentów są zgodne?
• Czy jest akceptacja człowieka?

• Chodzi o to, by odpowiedź miała „podparcie” w dokumentach.
• Model dostaje fragmenty tekstu i ma się na nich oprzeć.
• Dzięki temu łatwiej ograniczyć halucynacje i podać cytaty.

• Podanie źródeł nie na temat.
• Brak cytowania fragmentów (tylko „link ogólny”).
• Mieszanie wersji dokumentów.

Diagram pokazuje, że grounding polega na osadzeniu odpowiedzi w konkretnych materiałach źródłowych.

• RAG
• Halucynacje
• Ewaluacja
• Prompt
• Prompt injection

Guardrails to zestaw zasad i zabezpieczeń, które ograniczają, co model może zrobić i jak ma odpowiadać.

Scenariusz 1: Wymóg

• Cel: wymóg: odpowiedzi tylko z dokumentów organizacji (grounding).
• Wejście: reguły systemu i przykładowe zapytania użytkowników.
• Kroki: zdefiniuj ograniczenie -> przetestuj odpowiedzi -> popraw reguły.
• Rezultat: bezpieczniejsze zachowanie systemu.
• Zabezpieczenie: testy regresji i monitoring naruszeń.

Scenariusz 2: Blokada

• Cel: blokada: nie podawaj danych osobowych ani nie proś o nie.
• Wejście: reguły systemu i przykładowe zapytania użytkowników.
• Kroki: zdefiniuj ograniczenie -> przetestuj odpowiedzi -> popraw reguły.
• Rezultat: bezpieczniejsze zachowanie systemu.
• Zabezpieczenie: testy regresji i monitoring naruszeń.

Scenariusz 3: Szablon

• Cel: szablon: komunikaty w plain language.
• Wejście: reguły systemu i przykładowe zapytania użytkowników.
• Kroki: zdefiniuj ograniczenie -> przetestuj odpowiedzi -> popraw reguły.
• Rezultat: bezpieczniejsze zachowanie systemu.
• Zabezpieczenie: testy regresji i monitoring naruszeń.

Ryzyko 1: Jailbreaking

• Ryzyko: Jailbreaking.
• Jak ograniczać: red teaming + aktualizacja zasad.

Ryzyko 2: Prompt injection

• Ryzyko: Prompt injection.
• Jak ograniczać: filtrowanie źródeł i instrukcji.

Ryzyko 3: Fałszywe blokady

• Ryzyko: Fałszywe blokady.
• Jak ograniczać: strojenie + wyjątki.

• Czy guardrails są spisane i wdrożone technicznie?
• Czy testowałeś obejścia?
• Czy logujesz odmowy i wyjątki?
• Czy masz eskalację problemów?
• Czy jest wersjonowanie zasad?

• To „poręcze”, które trzymają AI w bezpiecznych granicach.
• Mogą wymuszać: styl, cytaty, zakaz podawania danych wrażliwych, odmowę niebezpiecznych treści.
• Guardrails nie zastępują człowieka, ale zmniejszają ryzyko.

• Guardrails tylko „na papierze” (brak testów).
• Zbyt luźne zasady, które łatwo obejść.

Diagram pokazuje, że guardrails działają przed i po generowaniu odpowiedzi, ograniczając ryzyko.

• Prompt injection
• Jailbreaking
• Red teaming
• Polityka użycia AI
• Human-in-the-loop

Halucynacje to sytuacja, gdy model podaje fałszywe informacje, ale robi to w sposób przekonujący.

Scenariusz 1: Odpowiedź klientowi

• Cel: odpowiedź klientowi.
• Wejście: zadanie, dane wejściowe i źródła.
• Kroki: wykonaj zadanie -> sprawdź ryzyko: błędna podstawa prawna -> zastosuj zabezpieczenie.
• Rezultat: odpowiedź mniej podatna na zmyślenia.
• Zabezpieczenie: grounding + cytaty + akceptacja.

Scenariusz 2: Opis projektu/inwestycji

• Cel: opis projektu/inwestycji.
• Wejście: zadanie, dane wejściowe i źródła.
• Kroki: wykonaj zadanie -> sprawdź ryzyko: „dopowiedzenie” liczb -> zastosuj zabezpieczenie.
• Rezultat: odpowiedź mniej podatna na zmyślenia.
• Zabezpieczenie: dane wejściowe z tabeli + weryfikacja.

Scenariusz 3: Streszczenie regulaminu

• Cel: streszczenie regulaminu.
• Wejście: zadanie, dane wejściowe i źródła.
• Kroki: wykonaj zadanie -> sprawdź ryzyko: zmiana sensu -> zastosuj zabezpieczenie.
• Rezultat: odpowiedź mniej podatna na zmyślenia.
• Zabezpieczenie: porównanie punkt po punkcie.

Ryzyko 1: Dezinformacja

• Ryzyko: Dezinformacja.
• Jak ograniczać: fact-checking + źródła.

Ryzyko 2: Błąd formalny

• Ryzyko: Błąd formalny.
• Jak ograniczać: checklista prawna.

Ryzyko 3: Utrata zaufania

• Ryzyko: Utrata zaufania.
• Jak ograniczać: transparentność, że to szkic.

• Czy odpowiedź ma źródła/cytaty?
• Czy liczby i daty są weryfikowalne?
• Czy treść przeszła review?
• Czy użyto zatwierdzonych dokumentów?
• Czy logujesz wersję i autora?

• Model nie „wie”, tylko przewiduje kolejne słowa.
• Może tworzyć odpowiedzi, które brzmią sensownie, ale są nieprawdziwe.
• Ryzyko rośnie przy braku źródeł i przy zbyt ogólnych poleceniach.

• Proszenie o „przepisy” bez podania źródła.
• Brak prośby o cytaty i linki.
• Publikowanie bez weryfikacji.

Diagram pokazuje, że halucynacja pojawia się wtedy, gdy model uzupełnia brak wiedzy zgadywaniem.

• Grounding
• RAG
• Fact-checking
• Ewaluacja
• Cytowanie źródeł

Human-in-the-loop oznacza, że człowiek sprawdza i zatwierdza wyniki AI na kluczowych etapach.

Scenariusz 1: Posty i komunikaty

• Cel: posty i komunikaty: zawsze akceptacja redaktora.
• Wejście: wynik AI wymagający decyzji albo publikacji.
• Kroki: AI proponuje -> człowiek sprawdza -> człowiek akceptuje.
• Rezultat: kontrolowana decyzja lub publikacja.
• Zabezpieczenie: jasny właściciel decyzji.

Scenariusz 2: Odpowiedzi na pisma

• Cel: odpowiedzi na pisma: zawsze akceptacja merytoryczna/prawna.
• Wejście: wynik AI wymagający decyzji albo publikacji.
• Kroki: AI proponuje -> człowiek sprawdza -> człowiek akceptuje.
• Rezultat: kontrolowana decyzja lub publikacja.
• Zabezpieczenie: jasny właściciel decyzji.

Scenariusz 3: Klasyfikacja zgłoszeń

• Cel: klasyfikacja zgłoszeń: AI proponuje, człowiek poprawia.
• Wejście: wynik AI wymagający decyzji albo publikacji.
• Kroki: AI proponuje -> człowiek sprawdza -> człowiek akceptuje.
• Rezultat: kontrolowana decyzja lub publikacja.
• Zabezpieczenie: jasny właściciel decyzji.

Ryzyko 1: Błędy merytoryczne

• Ryzyko: Błędy merytoryczne.
• Jak ograniczać: checklisty i źródła.

Ryzyko 2: Przeciążenie ludzi

• Ryzyko: Przeciążenie ludzi.
• Jak ograniczać: automatyzuj tylko część, mierz jakość.

Ryzyko 3: Brak odpowiedzialności

• Ryzyko: Brak odpowiedzialności.
• Jak ograniczać: role i ślad audytowy.

• Czy wiadomo, kto zatwierdza?
• Czy są kryteria oceny?
• Czy treść ma źródła?
• Czy w treści nie ma PII?
• Czy zapisujesz wersję i autora?

• AI robi szkic, człowiek odpowiada za decyzję.
• Najważniejsze w treściach publicznych i sprawach formalnych.
• To podstawowy „bezpiecznik” na halucynacje i błędy.

• „Zatwierdzanie na ślepo”.
• Brak kryteriów oceny.

Diagram pokazuje, że człowiek pozostaje punktem decyzyjnym w ważnym etapie procesu.

• Polityka użycia AI
• Fact-checking
• Halucynacje
• Audit trail
• Transparentność

Hybrid search to łączenie dwóch podejść do wyszukiwania: klasycznego (słowa kluczowe) i semantycznego (embeddingi), aby lepiej trafiać w intencję pytania.

Scenariusz 1: Pytanie

• Cel: „jak chronić dane osobowe w AI” → semantyka trafia w PII/DLP.
• Wejście: zapytanie użytkownika i indeks tekstowy/wektorowy.
• Kroki: wyszukaj tekstowo -> wyszukaj semantycznie -> połącz wyniki.
• Rezultat: większa trafność wyszukiwania.
• Zabezpieczenie: reranking i testy jakości.

Scenariusz 2: Pytanie

• Cel: „prompt leakage” → keyword search łapie termin.
• Wejście: zapytanie użytkownika i indeks tekstowy/wektorowy.
• Kroki: wyszukaj tekstowo -> wyszukaj semantycznie -> połącz wyniki.
• Rezultat: większa trafność wyszukiwania.
• Zabezpieczenie: reranking i testy jakości.

Scenariusz 3: Pytanie

• Cel: „baza wektorowa” → hybryda znajduje i „vector database”, i „embedding”.
• Wejście: zapytanie użytkownika i indeks tekstowy/wektorowy.
• Kroki: wyszukaj tekstowo -> wyszukaj semantycznie -> połącz wyniki.
• Rezultat: większa trafność wyszukiwania.
• Zabezpieczenie: reranking i testy jakości.

Ryzyko 1: Skomplikowanie i trudność strojenia

• Ryzyko: skomplikowanie i trudność strojenia.
• Jak ograniczać: testy na realnych pytaniach + proste heurystyki.

Ryzyko 2: Złe wyniki w długich dokumentach

• Ryzyko: złe wyniki w długich dokumentach.
• Jak ograniczać: chunking + reranking.

Ryzyko 3: Koszty

• Ryzyko: koszty.
• Jak ograniczać: cache, top-k, profilowanie.

Słowa kluczowe świetnie działają, gdy ktoś zna nazwę („RAG”, „DLP”). Semantyka działa, gdy ktoś opisuje problem („jak uniknąć wycieków danych do AI”). Hybryda bierze najlepsze z obu światów:

• dopasowanie po frazach,
• dopasowanie po znaczeniu.

Diagram pokazuje, że wyszukiwanie hybrydowe łączy dopasowanie po słowach i po sensie.

Idempotencja oznacza, że wykonanie tej samej operacji wiele razy daje ten sam efekt (np. „utwórz X” nie tworzy duplikatów).

Scenariusz 1: Agent tworzy zadanie w systemie — idempotency key zapobiega duplikatom

• Cel: agent tworzy zadanie w systemie — idempotency key zapobiega duplikatom.
• Wejście: akcja możliwa do ponowienia.
• Kroki: nadaj identyfikator -> sprawdź duplikat -> wykonaj raz.
• Rezultat: brak podwójnych operacji.
• Zabezpieczenie: klucze idempotencji i logi.

Scenariusz 2: Integracja z API — ponowienie żądania po timeout nie robi szkody

• Cel: integracja z API — ponowienie żądania po timeout nie robi szkody.
• Wejście: akcja możliwa do ponowienia.
• Kroki: nadaj identyfikator -> sprawdź duplikat -> wykonaj raz.
• Rezultat: brak podwójnych operacji.
• Zabezpieczenie: klucze idempotencji i logi.

Scenariusz 3: Publikacja wpisu — „update” zamiast „create”, jeśli już istnieje

• Cel: publikacja wpisu — „update” zamiast „create”, jeśli już istnieje.
• Wejście: akcja możliwa do ponowienia.
• Kroki: nadaj identyfikator -> sprawdź duplikat -> wykonaj raz.
• Rezultat: brak podwójnych operacji.
• Zabezpieczenie: klucze idempotencji i logi.

Ryzyko 1: Brak idempotencji = duble, chaos, koszty

• Ryzyko: brak idempotencji = duble, chaos, koszty.
• Jak ograniczać: klucze idempotencji, wykrywanie duplikatów, transakcje.

Ryzyko 2: Trudna diagnoza „czemu są dwa wpisy”

• Ryzyko: trudna diagnoza „czemu są dwa wpisy”.
• Jak ograniczać: audit trail i identyfikatory żądań.

Ryzyko 3: Agent zapętla się

• Ryzyko: agent zapętla się.
• Jak ograniczać: limity kroków, rate limiting, checkpointy.

W AI z narzędziami łatwo o powtórzenia: agent może kliknąć „wyślij” dwa razy, bo nie był pewien wyniku. Idempotencja to zabezpieczenie: nawet jeśli to się zdarzy, system nie zrobi dubla (albo bezpiecznie go wykryje).

Diagram pokazuje, że ponowienie tej samej operacji nie powinno wywołać nowego skutku.

Inferencja to uruchomienie modelu, żeby wygenerował wynik: tekst, klasyfikację, embeddingi albo inną odpowiedź. To użycie modelu, a nie jego uczenie.

Scenariusz 1: Odpowiedź chatbota

• Cel: wsparcie działu obsługi klienta.
• Wejście: pytanie klienta.
• Kroki: analiza pytania -> odpowiedź -> ewentualna eskalacja.
• Rezultat: szybka reakcja.
• Zabezpieczenie: przegląd odpowiedzi przy trudnych sprawach.

Scenariusz 2: Streszczenie dokumentu

• Cel: skrócenie długiego materiału.
• Wejście: dokument lub fragment tekstu.
• Kroki: podaj tekst -> wskaż format -> wygeneruj streszczenie.
• Rezultat: krótsza wersja do dalszej pracy.
• Zabezpieczenie: sprawdzenie, czy streszczenie nie pomija ważnych zastrzeżeń.

Scenariusz 3: Klasyfikacja wiadomości

• Cel: podział zgłoszeń na kategorie.
• Wejście: treść wiadomości.
• Kroki: klasyfikacja -> przypisanie etykiety -> zapis wyniku.
• Rezultat: łatwiejsze kierowanie zgłoszeń.
• Zabezpieczenie: testy jakości i monitoring błędów.

Ryzyko 1: Wyciek danych w prompcie

• Ryzyko: Wyciek danych w prompcie.
• Jak ograniczać: stosuj DLP, minimalizację danych i anonimizację.

Ryzyko 2: Koszty i opóźnienia

• Ryzyko: Koszty i opóźnienia.
• Jak ograniczać: ustaw limity, cache i monitoring.

Ryzyko 3: Niestabilne odpowiedzi

• Ryzyko: Niestabilne odpowiedzi.
• Jak ograniczać: kontroluj temperaturę i testuj wyniki.

• Czy dane wejściowe są potrzebne w takiej szczegółowości?
• Czy znasz koszt i limit tokenów?
• Czy odpowiedź wymaga przeglądu człowieka?
• Czy wynik jest monitorowany?

Inferencja to moment, gdy AI odpowiada na pytanie. To jak odpalenie kalkulatora: liczysz teraz, ale nie zmieniasz zasad matematyki.

Wiele osób myli inferencję z uczeniem się modelu. Tymczasem w typowych narzędziach model nie zapamiętuje rozmowy na stałe. Bierze prompt, kontekst i ustawienia, a potem generuje odpowiedź.

To ważne dla prywatności, kosztów i jakości. Każda inferencja zużywa zasoby obliczeniowe, zwykle rozliczane tokenami.

Diagram pokazuje, że inferencja to pojedyncze użycie modelu, które ma wejście, wynik oraz koszt.

• Token
• Temperatura / sampling
• API
• LLMOps
• Monitoring jakości

Instruction tuning to uczenie modelu odpowiadania na polecenia. RLHF to metoda, w której model uczy się preferencji na podstawie ocen (np. ludzkich), aby lepiej trzymać się zasad.

Scenariusz 1: Stały ton odpowiedzi

• Cel: stały ton odpowiedzi.
• Wejście: standard komunikacji.
• Kroki: instrukcje → testy.
• Rezultat: mniej „odjazdów”.
• Zabezpieczenie: ewaluacja i monitoring.

Scenariusz 2: Ograniczenie ryzykownych treści

• Cel: ograniczenie ryzykownych treści.
• Wejście: polityka.
• Kroki: guardrails + instrukcje.
• Rezultat: bezpieczniejsze wyniki.
• Zabezpieczenie: log + audyt.

Ryzyko 1: Fałszywe poczucie bezpieczeństwa

• Ryzyko: Fałszywe poczucie bezpieczeństwa.
• Jak ograniczać: checklisty i review.

Ryzyko 2: Błędna pewność

• Ryzyko: Błędna pewność: model brzmi przekonująco.
• Jak ograniczać: grounding + cytaty.

Ryzyko 3: Jailbreaking

• Ryzyko: Jailbreaking: obejście zasad.
• Jak ograniczać: red teaming + guardrails.

• Czy masz politykę użycia AI?
• Czy testowałeś obejścia (red teaming)?
• Czy masz logi i audyt?
• Czy jest proces eskalacji błędów?
• Czy odpowiedzi mają źródła?

• Dzięki temu model nie tylko „generuje tekst”, ale stara się wykonywać polecenie.
• RLHF pomaga ograniczać toksyczność i wprowadza zachowania „bardziej bezpieczne”.
• To nie gwarantuje prawdy — tylko lepszą zgodność z instrukcją.

• Przekonanie, że „model jest już bezpieczny” i nie trzeba kontroli.
• Brak własnych zasad organizacji (policy).

Diagram pokazuje, że model uczy się lepiej wykonywać instrukcje dzięki przykładom i ocenom ludzi.

• Jailbreaking
• Prompt systemowy
• Guardrails
• Red teaming
• Halucynacje

Jailbreaking to próby obejścia ograniczeń modelu, aby wykonywał działania sprzeczne z zasadami. Zwykle polega na manipulowaniu promptem i kontekstem rozmowy. To problem bezpieczeństwa w aplikacjach opartych o LLM.

Scenariusz 1: Testy bezpieczeństwa asystenta

• Cel: testy bezpieczeństwa asystenta.
• Wejście: lista prób obejścia.
• Kroki: test → analiza → poprawki.
• Rezultat: większa odporność.
• Zabezpieczenie: stały monitoring.

Scenariusz 2: Ochrona automatyzacji

• Cel: ochrona automatyzacji.
• Wejście: nietypowe prompty.
• Kroki: wykrycie → blokada → eskalacja.
• Rezultat: bezpieczne działanie.
• Zabezpieczenie: log i alerty.

Scenariusz 3: Polityka użycia AI

• Cel: polityka użycia AI.
• Wejście: scenariusze ryzyk.
• Kroki: opis zakazów → szkolenie → kontrola.
• Rezultat: mniejsze nadużycia.
• Zabezpieczenie: audyty.

Ryzyko 1: Obejście zasad

• Ryzyko: Obejście zasad.
• Jak ograniczać: guardrails i monitoring.

Ryzyko 2: Ujawnienie danych

• Ryzyko: Ujawnienie danych.
• Jak ograniczać: ograniczenia dostępu i DLP.

Ryzyko 3: Treści ryzykowne

• Ryzyko: Treści ryzykowne.
• Jak ograniczać: filtry treści i review.

• Czy masz politykę użycia AI?
• Czy testowałeś próby obejścia?
• Czy logujesz podejrzane zachowania?
• Czy masz procedurę eskalacji?
• Czy wiesz, jakie dane są szczególnie wrażliwe?

• Użytkownik stara się „przekonać” model do złamania zasad.
• Często wykorzystuje podstępne scenariusze i role.
• Skuteczny jailbreaking może prowadzić do ujawnień lub ryzykownych treści.
• Potrzebne są testy i guardrails.

• Przekonanie, że model „sam z siebie” jest bezpieczny.
• Brak testów red teaming.
• Brak procedury reagowania.

Diagram pokazuje, że jailbreaking to próba obejścia zasad systemu i wymaga blokady na etapie kontroli.

• Prompt injection
• Prompt systemowy
• Guardrails
• Red teaming
• Polityka AI

Knowledge cutoff to data, do której model miał dostęp do informacji podczas treningu. Po tej dacie model nie „wie”, co się wydarzyło - chyba że dostanie dane w kontekście, np. przez RAG albo narzędzie.

Scenariusz 1: Sprawdzenie zmian w prawie

• Cel: ograniczenie ryzyka nieaktualnej odpowiedzi.
• Wejście: pytanie o nowe przepisy.
• Kroki: podaj źródła -> sprawdź datę -> wygeneruj odpowiedź.
• Rezultat: odpowiedź oparta na aktualnym materiale.
• Zabezpieczenie: fact-checking i cytowanie źródeł.

Scenariusz 2: Streszczenie świeżego raportu

• Cel: praca na materiale, którego model nie zna z treningu.
• Wejście: raport lub jego fragmenty.
• Kroki: wklej materiał -> wskaż zakres -> poproś o streszczenie.
• Rezultat: streszczenie oparte na dostarczonym tekście.
• Zabezpieczenie: kontrola, czy odpowiedź nie wychodzi poza źródło.

Scenariusz 3: Porównanie ofert na dziś

• Cel: uniknięcie zgadywania cen i parametrów.
• Wejście: aktualne dane z ofert.
• Kroki: zbierz dane -> podaj je w kontekście -> porównaj kryteria.
• Rezultat: porównanie aktualne dla wskazanej daty.
• Zabezpieczenie: data porównania i lista źródeł.

Ryzyko 1: Nieaktualne odpowiedzi

• Ryzyko: Nieaktualne odpowiedzi.
• Jak ograniczać: podawaj daty, źródła i stosuj fact-checking.

Ryzyko 2: Mieszanie starych i nowych informacji

• Ryzyko: Mieszanie starych i nowych informacji.
• Jak ograniczać: dopisz w prompcie, że model ma wskazać braki danych.

Ryzyko 3: Fałszywa pewność

• Ryzyko: Fałszywa pewność.
• Jak ograniczać: wymagaj cytowania źródeł przy tematach zmiennych w czasie.

• Czy pytanie dotyczy aktualnych informacji?
• Czy model dostał źródło nowsze niż jego granica wiedzy?
• Czy odpowiedź ma datę i źródła?
• Czy weryfikujesz fakty przed publikacją?

Model jest jak książka wydana w konkretnym dniu. Może dobrze tłumaczyć i łączyć fakty, ale nie dopisuje automatycznie nowych rozdziałów o tym, co wydarzyło się później.

W praktyce oznacza to, że gdy pytasz o coś najnowszego, model może podać odpowiedź, która brzmi sensownie, ale nie jest aktualna. Dotyczy to zmian przepisów, cen, wydarzeń, funkcji narzędzi albo świeżych raportów.

Jeśli potrzebujesz aktualności, musisz dostarczyć je modelowi: wkleić materiał, dodać plik, użyć RAG albo narzędzia, które pobierze dane ze źródła.

Diagram pokazuje, że po granicy wiedzy model potrzebuje aktualnych źródeł, aby nie zgadywać.

• RAG
• Okno kontekstowe
• Fact-checking
• Grounding
• Cytowanie źródeł
• Halucynacje

Konektory danych to bezpieczne „wtyczki”, które łączą system AI z repozytoriami dokumentów (np. dyskiem, intranetem, stroną WWW/FAQ lub bazą wiedzy).

Scenariusz 1: Podłączenie procedur z intranetu do RAG

• Cel: podłączenie procedur z intranetu do RAG.
• Wejście: źródło danych i zasady dostępu.
• Kroki: podłącz źródło -> sprawdź uprawnienia -> odśwież indeks.
• Rezultat: asystent korzysta z właściwych danych.
• Zabezpieczenie: kontrola dostępu i wersjonowanie źródeł.

Scenariusz 2: Podłączenie FAQ ze strony WWW/FAQ do asystenta

• Cel: podłączenie FAQ ze strony WWW/FAQ do asystenta.
• Wejście: źródło danych i zasady dostępu.
• Kroki: podłącz źródło -> sprawdź uprawnienia -> odśwież indeks.
• Rezultat: asystent korzysta z właściwych danych.
• Zabezpieczenie: kontrola dostępu i wersjonowanie źródeł.

Scenariusz 3: Aktualizacja bazy wiedzy po publikacji dokumentu

• Cel: aktualizacja bazy wiedzy po publikacji dokumentu.
• Wejście: źródło danych i zasady dostępu.
• Kroki: podłącz źródło -> sprawdź uprawnienia -> odśwież indeks.
• Rezultat: asystent korzysta z właściwych danych.
• Zabezpieczenie: kontrola dostępu i wersjonowanie źródeł.

Ryzyko 1: Wycieki

• Ryzyko: Wycieki.
• Jak ograniczać: IAM + DLP + ograniczenia zakresu.

Ryzyko 2: Data poisoning

• Ryzyko: Data poisoning.
• Jak ograniczać: zatwierdzanie źródeł.

Ryzyko 3: Nieaktualność

• Ryzyko: Nieaktualność.
• Jak ograniczać: harmonogram odświeżania + monitoring.

• Czy konektor ma minimalne uprawnienia?
• Czy są filtry po typie i dacie?
• Czy źródła są zatwierdzone?
• Czy logujesz pobrania?
• Czy jest proces aktualizacji i rollback?

• Dzięki konektorom AI nie musi mieć wszystkiego „wklejonego ręcznie”.
• Ważne: konektor musi respektować uprawnienia (kto co widzi).
• Konektor to częsty punkt ryzyka — trzeba go kontrolować.

• Konektor pobiera „za dużo” (brak filtrów).
• Brak wersjonowania i przeglądu zmian.

Diagram pokazuje, że konektor łączy system AI ze źródłami danych i dostarcza treści do dalszego użycia.

• RAG
• SSO / IAM
• DLP
• Audit trail
• Baza wektorowa

Kwantyzacja to technika optymalizacji modelu polegająca na zmniejszeniu precyzji zapisu jego parametrów, na przykład z 16-bit do 8-bit albo 4-bit, aby ograniczyć zużycie pamięci i zasobów.

Scenariusz 1: Uruchomienie modelu na laptopie

• Cel: uruchomić model lokalny bez drogiego serwera GPU.
• Wejście: model bazowy i dostępny sprzęt.
• Kroki: wybór formatu -> kwantyzacja -> test jakości.
• Rezultat: model działa na tańszym sprzęcie.
• Zabezpieczenie: porównanie jakości przed i po zmianie.

Scenariusz 2: Obniżenie kosztu wdrożenia

• Cel: zmniejszyć koszt utrzymania modelu w produkcji.
• Wejście: obecna architektura, koszt zasobów i metryki jakości.
• Kroki: test wersji skwantyzowanej -> pomiar kosztu -> decyzja wdrożeniowa.
• Rezultat: niższy koszt działania systemu.
• Zabezpieczenie: benchmark i monitoring jakości.

Scenariusz 3: Wdrożenie modelu na urządzeniu brzegowym

• Cel: uruchomić model bliżej użytkownika albo danych.
• Wejście: ograniczone zasoby urządzenia i model do wdrożenia.
• Kroki: dobór wariantu -> kwantyzacja -> test wydajności.
• Rezultat: model działa w środowisku o małej mocy obliczeniowej.
• Zabezpieczenie: testy błędów i testy wydajności.

Ryzyko 1: Spadek jakości odpowiedzi

• Ryzyko: spadek jakości odpowiedzi.
• Jak ograniczać: testuj model na realnych scenariuszach.

Ryzyko 2: Nieprzewidywalne zachowanie

• Ryzyko: nieprzewidywalne zachowanie.
• Jak ograniczać: porównuj wyniki z wersją bazową.

Ryzyko 3: Problemy kompatybilności

• Ryzyko: problemy kompatybilności.
• Jak ograniczać: dobieraj format do konkretnego środowiska wdrożenia.

Ryzyko 4: Fałszywa oszczędność

• Ryzyko: fałszywa oszczędność.
• Jak ograniczać: licz koszt razem z ryzykiem błędów jakościowych.

• Czy wiesz, jaki jest cel kwantyzacji?
• Czy masz wersję bazową do porównania?
• Czy wykonano benchmark jakości?
• Czy środowisko obsługuje wybrany format?
• Czy spadek jakości jest akceptowalny?

To sposób „odchudzenia” modelu. Model dalej wykonuje to samo zadanie, ale potrzebuje mniej pamięci i słabszego sprzętu.

W praktyce kwantyzacja pomaga:

• uruchamiać modele lokalnie,
• obniżać koszt inferencji,
• skracać czas odpowiedzi,
• zmniejszać wymagania infrastrukturalne.

Czasem jednak dzieje się to kosztem części jakości.

• Zakładanie, że każda kwantyzacja daje taki sam efekt.
• Brak testów jakości po zmianie formatu.
• Zbyt agresywne obniżenie precyzji.
• Mylenie kwantyzacji z fine-tuningiem.

Diagram pokazuje, że kwantyzacja zmniejsza rozmiar modelu i koszt działania, ale wymaga sprawdzenia jakości po zmianie.

• Model lokalny

• Inferencja (inference)

• Zarządzanie kosztami AI

• Benchmark

• Monitoring jakości

---

Latency to czas od wysłania pytania do otrzymania odpowiedzi (lub pierwszego sensownego fragmentu odpowiedzi).

Scenariusz 1: Chat

• Cel: 1–2 sekundy jest „komfortowe”, 10 sekund często frustruje.
• Wejście: żądanie użytkownika i pomiar czasu.
• Kroki: zmierz czas -> znajdź wąskie gardło -> uprość proces.
• Rezultat: krótsze oczekiwanie na odpowiedź.
• Zabezpieczenie: monitoring i limity czasu.

Scenariusz 2: RAG

• Cel: długi retrieval + reranking = dłuższa odpowiedź, ale lepsza jakość.
• Wejście: żądanie użytkownika i pomiar czasu.
• Kroki: zmierz czas -> znajdź wąskie gardło -> uprość proces.
• Rezultat: krótsze oczekiwanie na odpowiedź.
• Zabezpieczenie: monitoring i limity czasu.

Scenariusz 3: Agent

• Cel: kilka kroków narzędzi = rośnie latency, ale „robi więcej”.
• Wejście: żądanie użytkownika i pomiar czasu.
• Kroki: zmierz czas -> znajdź wąskie gardło -> uprość proces.
• Rezultat: krótsze oczekiwanie na odpowiedź.
• Zabezpieczenie: monitoring i limity czasu.

Ryzyko 1: Użytkownik porzuca proces

• Ryzyko: użytkownik porzuca proces.
• Jak ograniczać: streaming odpowiedzi + krótkie komunikaty „co się dzieje”.

Ryzyko 2: Próby przyspieszenia obniżą jakość

• Ryzyko: próby przyspieszenia obniżą jakość.
• Jak ograniczać: profilowanie i testy; przyspieszaj to, co nie zmienia jakości (cache, top-k).

Ryzyko 3: Przeciążenie

• Ryzyko: przeciążenie.
• Jak ograniczać: rate limiting, skalowanie, priorytety.