Scenariusze wdrożeniowe
Use cases AI Governance
Poniższe scenariusze przedstawiają typowe wyzwania organizacyjne związane z wdrażaniem i nadzorem AI oraz podejście supnetAI do ich rozwiązania — w oparciu o ISO/IEC 42001 i europejski AI Act.
Uwaga: to scenariusze referencyjne (archetypy problemów), a nie opisy wdrożeń u konkretnych klientów.
Use Case 1: Niekontrolowane Shadow AI → Uporządkowany Governance
Organizacja odkrywa, że AI jest używana oddolnie (SaaS, wtyczki, modele publiczne, automatyzacje), często bez jasnych zasad, właściciela i kontroli nad danymi. Celem jest przejście od „Shadow AI” do modelu zarządzania opartego o role, odpowiedzialność decyzyjną i kontrolowane ścieżki użycia AI.
* Schemat uproszczony
Typowe symptomy (w praktyce)
- Fragmentacja techniczna: AI pojawia się jako API (np. modele LLM), biblioteki open-source, wtyczki w CRM/Office oraz funkcje „AI” w SaaS – bez jednego rejestru i właściciela.
- Brak ścieżki innowacji: zespoły wdrażają „na skróty”, bo nie ma prostego procesu zgłoszenia i akceptacji use-case’u.
- Rozmyta odpowiedzialność decyzyjna: „AI tylko podpowiada”, ale nikt nie umie wskazać, kto formalnie odpowiada za decyzję wspartą AI.
- Zakazy nie działają: blokady powodują przeniesienie użycia AI na prywatne konta/urządzenia.
Ryzyka (biznes + regulacje)
- Dane i IP: ujawnienie informacji poufnych / PII / know-how w niekontrolowanych narzędziach.
- Brak audytowalności: brak śladów decyzyjnych i dowodów nadzoru (kto, kiedy, na jakiej podstawie).
- Ryzyko błędnych decyzji: halucynacje, bias, błędne rekomendacje bez mechanizmu walidacji.
- Nieprzygotowanie do wymogów governance: AI Literacy (AI Act) i mechanizmy AIMS (ISO/IEC 42001) są „na papierze”, nie w procesach.
Podejście supnetAI (fazy)
Faza 0 — Uzgodnienie zakresu i definicji
- Definicja „AI” w kontekście organizacji (SaaS, GenAI, automatyzacje)
- Ustalenie obszarów krytycznych (dane, decyzje, procesy)
- Model ról: kto sponsoruje, kto odpowiada, kto dostarcza dane
Faza 1 — Controlled discovery (bez „polowania na winnych”)
- Inwentaryzacja użyć AI (scenariusze, narzędzia, dane, procesy)
- Identyfikacja punktów decyzyjnych i „miejsc ryzyka”
- Wstępna klasyfikacja użyć (dozwolone / warunkowe / niedozwolone)
Faza 2 — Governance i odpowiedzialność decyzyjna
- Mapowanie decyzji: AI → decyzja → proces → właściciel odpowiedzialności (RACI).
- Macierz klasyfikacji ryzyka use-case: reguły (cel biznesowy, typ danych, kanał dostępu, dostawca, integracje) → wynik: Low / High / Prohibited.
- Projekt „human oversight”: punkty zatwierdzania, eskalacje, progi ryzyka, warunki użycia.
- Minimalny evidence pack: co musi istnieć, aby use-case był „Approved” (dowody, owner, zakres danych).
Faza 3 — Operacjonalizacja i AI Literacy
- Role-based AI Literacy (IT / HR / Biznes) – decyzje, nie teoria
- Polityka BYOD dla AI (Bring Your Own Data/Device): zasady użycia prywatnych kont/narzędzi AI na urządzeniach służbowych, warunki dopuszczalności oraz obszary „no-go” (PII/IP/dane poufne).
- „Światła drogowe” + proste reguły danych (publiczne/wrażliwe)
- Wdrożenie ścieżki: jak legalnie zgłaszać i zatwierdzać use-case AI
Co powstaje (artefakty / deliverables)
Artefakty governance
- Rejestr systemów i użyć AI (AI Register) z klasyfikacją roli Provider vs Deployer oraz statusem dopuszczalności (Approved / Conditional / Prohibited).
- Zasady użycia AI (polityka / standard / guideline)
- Model ról i odpowiedzialności (RACI)
- Zasady Human Oversight + ścieżki eskalacji
Artefakty ryzyka i zgodności
- Wstępny AI Risk & Impact Assessment (dla kluczowych use-case)
- Reguły danych (co wolno, czego nie wolno, i dlaczego)
- Minimalny zestaw dowodów audytowych (evidence pack)
- Mapowanie artefaktów do ISO/IEC 42001 (Annex A): powiązanie kontroli, ról, rejestrów i procedur z wymaganiami normy – w formie audytowalnej macierzy.
- Plan działań i roadmapa wdrożeniowa (kolejne kroki)
Efekt docelowy
Shadow AI przestaje być „ukryte”, decyzje mają właściciela, a organizacja zyskuje jasne zasady użycia AI i kontrolowaną ścieżkę rozwoju — bez blokowania innowacji.
Use Case 2: Wymogi Regulacyjne (AI Act) → Gotowość Operacyjna (AIMS)
Organizacja chce podejść do AI systemowo: z jednej strony wymagania AI Act, z drugiej ISO/IEC 42001 (AIMS). Problemem nie jest brak dobrej woli — tylko brak planu, właściciela i spójnego modelu zarządzania decyzjami.
* Schemat uproszczony
Typowe symptomy
- „Czekamy do 2026” – brak działań operacyjnych tu i teraz
- Compliance w dokumentach, ale bez osadzenia w procesach
- Niejasne role: Legal vs IT vs Biznes
- Paraliż decyzyjny przy skalowaniu AI
Ryzyka
- Pozorna zgodność i brak obrony „w razie kontroli”
- Brak dowodów, rejestrów i spójnych procedur
- Niezgodne interpretacje i konflikt między obszarami
- Brak gotowości audytowej i niekontrolowane skalowanie
Podejście supnetAI (fazy)
Faza 0 — Readiness i priorytetyzacja
- Ocena gotowości względem AI Act (co jest „już”, co „później”)
- Ustalenie właściciela AIMS i governance (sponsor, owner, operacje)
- Mapa procesów: gdzie AI jest w cyklu życia i gdzie są decyzje
Faza 1 — Projekt AIMS (ISO/IEC 42001)
- Architektura AIMS: polityka AI, role, rejestry, cykle przeglądów i zasady podejmowania decyzji.
- AIMS Impact/Risk Assessment: ustandaryzowana ocena ryzyk (technicznych, etycznych, prawnych) i ich mapowanie na mechanizmy kontroli w AIMS.
- Integracja z ekosystemem (ISO/IEC 27001, RODO): zapewnienie spójności ról, rejestrów i przeglądów, aby uniknąć dublowania procedur i traktować AIMS jako rozszerzenie obecnego ładu, a nie "nową biurokrację.
Faza 2 — Evidence i gotowość audytowa
- Model dowodowy: co zbieramy, kto odpowiada, gdzie przechowujemy, jak często przeglądamy.
- Ślad decyzyjny (audit trail): rejestrowanie akceptacji, zmian, przeglądów, incydentów oraz działań korygujących.
- Human Oversight w praktyce: dowody nadzoru człowieka (punkty kontroli, role, kryteria akceptacji, testy).
Faza 3 — Legal alignment (gdy wymagane)
- Spójność interpretacyjna AI Act i dokumentacji
- Wsparcie kancelarii prawnej w obszarach wymagających ekspertyzy prawnej
- Proporcjonalność: minimum konieczne + rozsądna skalowalność
Co powstaje (artefakty / deliverables)
Artefakty AIMS (ISO/IEC 42001)
- AI Policy i zasady governance (ramy i odpowiedzialności)
- Rejestry: AI Register, ryzyk, incydentów, działań korygujących
- Procedury: zatwierdzanie, zmiana, wycofanie systemów AI
- Model przeglądów: KPI / KRI, ryzyka, nadzór, doskonalenie
Artefakty AI Act (operacyjnie)
- Mapa obowiązków i ról (provider/deployer) + działania
- Evidence pack: co zbierać, gdzie, kto odpowiada
- AI Literacy – plan kompetencji (role-based)
- Pakiet dokumentacji systemu AI (gdy ma zastosowanie, np. dla High-Risk): struktura dokumentacji technicznej i dowodowej zgodna z wymaganiami AI Act (w tym elementy z Art. 11 i Annex IV, jeśli dotyczy).
- Plan wdrożenia i roadmapa zgodności
Efekt docelowy
Organizacja ma spójny AIMS (ISO/IEC 42001), a wymagania AI Act są „osadzone” w procesach i dowodach. Znika chaos interpretacyjny, a AI może być skalowana w sposób kontrolowany i audytowalny.
Use Case 3: Ryzyko Halucynacji w GenAI → Bezpieczna Warstwa Zaufania
Organizacja wdraża rozwiązania GenAI (RAG, agenci AI) do pracy na danych wewnętrznych: dokumentach, procedurach, wiedzy eksperckiej. Wyzwanie polega na zapewnieniu, że odpowiedzi generowane przez AI są wiarygodne, bezpieczne i możliwe do rozliczenia — zarówno biznesowo, jak i regulacyjnie.
* Schemat uproszczony
Kontekst architektoniczny
- Modele LLM połączone z wewnętrznymi repozytoriami wiedzy (RAG).
- Agenci AI wykonujący sekwencje działań (np. analiza dokumentów, rekomendacje).
- Dane o różnej wrażliwości: publiczne, wewnętrzne, poufne, regulowane.
- Brak spójnego „owner’a” odpowiedzialności za odpowiedź wygenerowaną przez AI.
Kluczowe ryzyka
- Halucynacje: odpowiedzi brzmiące wiarygodnie, ale niepoparte źródłami.
- Prompt injection: manipulacja zapytaniami prowadząca do ujawnienia danych.
- Brak rozliczalności: niemożność wskazania, dlaczego AI udzieliła danej odpowiedzi.
- Ryzyko regulacyjne: brak śladów decyzyjnych i dowodów nadzoru (AI Act, ISO 42001).
Podejście supnetAI (Trust Layer)
1. Definicja granic zaufania
- Klasyfikacja danych dostępnych dla RAG (co AI „może widzieć”).
- Określenie, które decyzje AI są informacyjne, a które wymagają zatwierdzenia.
- Przypisanie właściciela odpowiedzialności do klas odpowiedzi AI.
2. Guardrails i reguły użycia
- Polityki danych: ograniczenia kontekstu, zakresu i tonu odpowiedzi.
- Reguły bezpieczeństwa zapytań (prompt hygiene, ochrona przed injection).
- Warunki, w których AI musi odmówić odpowiedzi lub eskalować do człowieka.
- Effective Human Oversight (AI Act – Art. 14, gdy ma zastosowanie): projektowanie interfejsów i punktów kontroli umożliwiających realną interwencję człowieka (eskalacja, zatrzymanie, nadpisanie decyzji), a nie wyłącznie „fasadowe zatwierdzanie”.
3. Grounding i weryfikacja
- Wymóg oparcia odpowiedzi o konkretne źródła (retrieval-based answers).
- Mechanizmy sygnalizujące brak wystarczających danych.
- Oddzielenie „wiedzy” od „interpretacji” w odpowiedziach AI.
4. Audit trail i dowody nadzoru
- Rejestrowanie zapytań, kontekstu, źródeł i odpowiedzi AI.
- Ślad decyzyjny: kto zatwierdził, kto użył, w jakim procesie.
- Dowody Human Oversight zgodne z AIMS (ISO/IEC 42001).
Co powstaje (artefakty)
Artefakty governance
- Model odpowiedzialności za odpowiedzi generowane przez AI.
- Polityki użycia RAG i agentów AI.
- Reguły eskalacji i zatwierdzania odpowiedzi.
Artefakty dowodowe
- Rejestr zapytań i odpowiedzi (audit trail).
- Dowody nadzoru ludzkiego i testów jakości odpowiedzi.
- Mapowanie mechanizmów do ISO/IEC 42001 (Annex A).
Efekt docelowy
Organizacja może bezpiecznie wykorzystywać RAG i agentów AI w procesach biznesowych, zachowując kontrolę nad danymi, jakością odpowiedzi i odpowiedzialnością decyzyjną — bez blokowania innowacji i bez ryzyka „czarnej skrzynki”.