AI governance dla branż regulowanych — co to znaczy w praktyce

AI governance w branży regulowanej działa wtedy, gdy każda ważna decyzja o systemie ma właściciela, kryterium, dowód i termin ponownego przeglądu. Sama polityka AI tego nie zapewni. Potrzebny jest model operacyjny, który łączy odpowiedzialność RACI, zapis decyzji, Evidence Pack i cykliczne AI Assurance. Prawo wyznacza obowiązki zależne od roli, ryzyka i zastosowania; opisany niżej sposób pracy to praktyka Semitory, która pomaga te obowiązki przekładać na zadania techniczne i ślad audytowy.

Spis treści

Poniższa mapa prowadzi od odpowiedzialności za pojedynczy system do dowodów, przeglądów sektorowych i granicy prawnej.

• Model operacyjny: decyzja, dowód, działanie
• RACI i prawa decyzyjne dla konkretnego systemu
• Decision Record: jedna decyzja, jeden ślad
• Evidence Pack i AI Assurance
• Macierz decyzji dla finansów, zdrowia i produkcji
• Warunki ponownej oceny
• Co wynika z AI Act, a co jest praktyką Semitory
• FAQ o AI governance w branżach regulowanych

Model operacyjny: decyzja, dowód, działanie

Najmniejszą użyteczną jednostką governance nie jest komitet ani polityka, tylko decyzja dotycząca określonej wersji systemu i przypadku użycia.

Dobra decyzja odpowiada na pięć pytań: co dopuszczamy, kto odpowiada za wynik, na podstawie jakiego dowodu, na jakich warunkach oraz kiedy wracamy do oceny. Dopiero wtedy zespół może wykonać pracę: poprawić zbiór testowy, zmienić uprawnienia, zatrzymać wdrożenie albo świadomie zaakceptować ograniczenie.

Model pracuje w pętli. Zespół najpierw opisuje system i jego zastosowanie, potem ocenia ryzyko oraz wymagania, zbiera dowody, podejmuje decyzję i monitoruje warunki, na których ją podjęto. Zmiana modelu, danych lub procesu uruchamia kolejny obrót. To nie oznacza, że każdą drobną zmianę zatwierdza zarząd. Oznacza, że organizacja wcześniej ustala progi eskalacji i wie, kto może podjąć daną decyzję.

W praktyce warto prowadzić rejestr systemów jako wejście do pętli, ale sam rejestr nie jest wynikiem. Wynikiem jest stan, który da się obronić: aktualna klasyfikacja, zatwierdzone kryteria jakości, działający nadzór człowieka, plan reakcji oraz przypisani właściciele. Jeśli któregoś elementu brakuje, rekord powinien pokazać lukę i termin jej zamknięcia, zamiast udawać gotowość zielonym statusem.

RACI i prawa decyzyjne dla konkretnego systemu

RACI porządkuje pracę dopiero wtedy, gdy dotyczy nazwanych decyzji, a nie ogólnych haseł takich jak „IT odpowiada za AI”.

Dla każdego etapu przypisz jedno A, czyli rolę rozliczaną z wyniku. R wykonuje pracę, C wnosi konsultację przed decyzją, a I dostaje informację. Przy klasyfikacji ryzyka rolę A może pełnić osoba odpowiedzialna za zgodność, a zespół techniczny dostarcza opis funkcji i danych. Przy dopuszczeniu wersji produkcyjnej rolę A może pełnić właściciel procesu biznesowego, podczas gdy osoby odpowiedzialne za bezpieczeństwo, ochronę danych i model oceniają swoje kryteria. Taki rozdział zależy od organizacji; AI Act nie narzuca tabeli RACI.

Prawa decyzyjne powinny obejmować co najmniej: wejście do PoC, dopuszczenie do produkcji, zgodę na zmianę modelu lub źródeł danych, akceptację ryzyka resztkowego, przekazanie sprawy człowiekowi, przywrócenie poprzedniej wersji i wycofanie systemu. Nazwa komitetu jest drugorzędna. Liczy się to, czy operator na zmianie wie, kto może zatrzymać system, a osoba odpowiedzialna dostaje dowód wystarczający do podpisania decyzji.

Możesz zacząć od otwartego szablonu AI Governance RACI i decision rights. Wypełnij go dla jednego systemu, używając nazw ról obecnych w firmie. Potem sprawdź go scenariuszem: model zaczyna zwracać odpowiedzi bez podstawy w źródłach. Jeśli tabela nie mówi, kto ustawia próg alarmu, kto odcina ruch i kto zatwierdza powrót, nadal opisuje strukturę organizacji, nie sterowanie ryzykiem.

Decision Record: jedna decyzja, jeden ślad

Decision Record powinien pozwolić niezależnej osobie odtworzyć, dlaczego określona wersja systemu została dopuszczona, ograniczona albo zatrzymana.

Rekord zawiera identyfikator systemu i wersji, opis decyzji, właściciela, datę, kryteria, odnośniki do dowodów, znane ograniczenia, warunki ważności, datę następnego przeglądu kalendarzowego oraz zdarzenia wymuszające ponowną ocenę. Nie trzeba kopiować raportów do formularza. Lepiej wskazać wersjonowany wynik ewaluacji, zgłoszenie naprawcze, zatwierdzoną architekturę i dziennik decyzji. Dzięki temu rekord pozostaje krótki, ale prowadzi do materiału źródłowego.

Przykład: zespół dopuszcza asystenta RAG dla pracowników call center, ale tylko dla dwóch kategorii spraw. Kryteria obejmują kompletność cytowania, zakaz samodzielnej zmiany danych klienta i przekazanie rozmowy człowiekowi po wykryciu określonego zamiaru. Dowodem są wyniki referencyjnego zestawu testowego, test uprawnień i dziennik z próbnego ruchu. Ponowną ocenę wymusza zmiana modelu bazowego, dodanie nowej kategorii dokumentów albo spadek wskaźnika odpowiedzi opartych na źródłach poniżej uzgodnionego progu. To jest konkret, który można skontrolować.

Nie zapisuj decyzji „system zgodny z AI Act”, jeśli analiza obejmowała tylko test jakości. Zapisz zakres: „spełnia kryteria techniczne bramki produkcyjnej dla wersji X; klasyfikacja prawna znajduje się w dokumencie Y; otwarte działania są w rejestrze Z”. Precyzja chroni przed rozszerzaniem wniosku poza zebrane dowody.

Evidence Pack i AI Assurance

Evidence Pack zbiera dowody potrzebne do decyzji, a AI Assurance sprawdza, czy dowody nadal odpowiadają działającemu systemowi i jego ryzyku.

W praktyce Semitory pakiet obejmuje inwentarz i właściciela, klasyfikację roli oraz ryzyka, kryteria i referencyjny zestaw testowy, plan i wyniki ewaluacji, dzienniki z wersjonowaniem, przekazanie sprawy człowiekowi, przywrócenie poprzedniej wersji, decyzję o kontynuacji albo zatrzymaniu oraz działania naprawcze. Nie jest to jeden dokument wymagany pod taką nazwą przez AI Act. To struktura robocza, która łączy artefakty pochodzące z produktu, danych, bezpieczeństwa, zgodności i operacji.

Szczegółowy układ opisuje przewodnik Evidence Pack dla AI Act: siedem rodzajów dowodów. Usługa AI Assurance dodaje do pakietu cykl niezależnego sprawdzenia: czy oceniono właściwą wersję, czy próbka jest adekwatna, czy wyniki da się powtórzyć, czy kontrola człowieka działa i czy decyzja odpowiada wynikom. Taki przegląd nie zastępuje formalnej oceny zgodności ani porady prawnej.

Pakiet powinien rosnąć proporcjonalnie do skutków błędu. Wewnętrzna wyszukiwarka procedur potrzebuje mniejszej głębokości niż system wpływający na świadczenie zdrowotne albo decyzję kredytową. Nawet w prostym przypadku zachowaj jednak minimum: wersję, właściciela, kryterium, wynik i decyzję. Bez tych pól kolejny zespół nie odróżni sprawdzonego systemu od prezentacji demonstracyjnej.

Macierz decyzji dla finansów, zdrowia i produkcji

Sektor zmienia kontekst szkody, dane i ścieżkę eskalacji, dlatego ten sam model nie powinien automatycznie dostawać tej samej decyzji governance.

Sektor i przykład	Decyzja governance	Dowód Semitory	Właściciel	Warunek ponownej oceny
Finanse — asystent analityka kredytowego	Czy wynik wyłącznie wspiera analizę, czy wpływa na decyzję oraz kiedy pracownik musi odrzucić rekomendację	Mapa procesu, test niedozwolonej automatyzacji, referencyjny zestaw testowy, dziennik zmian decyzji i zapis podstawy odpowiedzi	Właściciel procesu kredytowego	Zmiana źródeł danych, modelu, progu decyzyjnego albo sposobu użycia przez analityka
Ochrona zdrowia — RAG dla personelu	Czy narzędzie podaje informację organizacyjną, czy wchodzi w obszar decyzji klinicznej oraz jak działa przekazanie do człowieka	Zakres zastosowania, przegląd źródeł, test kompletności cytowań, scenariusze przekazania człowiekowi i dziennik incydentu	Właściciel procesu medycznego	Nowa specjalizacja, nowy zbiór dokumentów, zmiana modelu albo błąd mogący wpłynąć na pacjenta
Produkcja — asystent instrukcji utrzymania ruchu	Czy rekomendacja może uruchomić działanie na maszynie i jakie blokady obowiązują przed wykonaniem	Wersja instrukcji, kontrola uprawnień, test odpowiedzi poza zakresem, potwierdzenie operatora i plan przywrócenia poprzedniej wersji	Właściciel utrzymania ruchu	Zmiana linii, instrukcji, integracji sterującej, poziomu autonomii albo zdarzenie bezpieczeństwa

Kolumny „Dowód Semitory”, „Właściciel” i „Warunek ponownej oceny” są praktyką wdrożeniową Semitory, a nie literalnym wymogiem AI Act. Macierz nie klasyfikuje automatycznie żadnego z przykładów jako systemu wysokiego ryzyka. Klasyfikacja wymaga oceny konkretnego celu, funkcji, roli organizacji, załączników oraz wyjątków. Pomaga w tym audyt gotowości AI: co sprawdzamy, ale formalną interpretację prawną należy uzgodnić z właściwym doradcą.

Najważniejsza różnica między sektorami często leży poza modelem. W finansach może nią być sposób wykorzystania rekomendacji przez analityka. W zdrowiu będzie to granica pomiędzy informacją administracyjną a kliniczną. W produkcji decyduje połączenie z procesem fizycznym. Governance musi więc obejmować interfejs, procedurę i zachowanie człowieka, nie tylko parametry API.

Warunki ponownej oceny

Przegląd kalendarzowy jest potrzebny, lecz nie wystarcza, bo ryzyko zmienia się najczęściej po konkretnym zdarzeniu w systemie lub procesie.

Techniczny warunek ponownej oceny to na przykład nowa wersja modelu, embeddingu, instrukcji systemowej, bazy wiedzy, narzędzia agenta albo mechanizmu kontroli dostępu. Warunek biznesowy obejmuje nową grupę użytkowników, produkt, kanał, jurysdykcję lub decyzję, którą wspiera system. Warunek dowodowy pojawia się po regresji jakości, incydencie, skardze, nieskutecznym przekazaniu sprawy człowiekowi albo zmianie rozkładu danych. Warunek prawny wynika ze zmiany przepisów, wytycznych lub klasyfikacji zastosowania.

Dla każdego warunku ustal reakcję. Mała aktualizacja indeksu może wymagać automatycznej regresji na referencyjnym zestawie testowym. Zmiana modelu bazowego może blokować wdrożenie do czasu ponownej ewaluacji. Incydent dotyczący bezpieczeństwa pacjenta powinien uruchamiać ścieżkę eskalacji, zabezpieczenie dzienników i decyzję o zatrzymaniu. Sam alert bez właściciela i czasu reakcji jest tylko powiadomieniem.

Metryki powinny prowadzić do działania. Artykuł ewaluacja RAG: jak mierzyć jakość pokazuje, jak połączyć kryterium, zbiór testowy i wynik. Governance dodaje do tego próg decyzji, osobę odpowiedzialną oraz zasadę, co dzieje się po przekroczeniu progu. To zmienia panel z narzędzia obserwacji w narzędzie sterowania.

Co wynika z AI Act, a co jest praktyką Semitory

AI Act nakłada obowiązki zależne od roli organizacji, rodzaju systemu i zastosowania; nie ustanawia jednego uniwersalnego modelu operacyjnego RACI dla każdej firmy.

Źródłem podstawowym jest rozporządzenie (UE) 2024/1689. Dla systemów wysokiego ryzyka akt obejmuje między innymi zarządzanie ryzykiem, wymagania dotyczące danych, dokumentację techniczną, rejestrowanie zdarzeń, informacje dla podmiotu stosującego, nadzór człowieka oraz dokładność, odporność i cyberbezpieczeństwo. Zakres odpowiedzialności różni się dla dostawcy i podmiotu stosującego. Nie wolno więc przenosić całej listy na każdy chatbot ani uznawać, że zakup gotowego narzędzia usuwa obowiązki użytkownika biznesowego.

Terminy zmieniło rozporządzenie (UE) 2026/1744, które weszło w życie 27 lipca 2026. Zmieniony art. 113 utrzymuje ogólną datę rozpoczęcia stosowania na 2 sierpnia 2026. W odniesieniu do systemów wysokiego ryzyka, o których mowa w art. 6 ust. 2 i załączniku III, rozdział III sekcje 1–3, z wyjątkiem art. 6 ust. 5, stosuje się od 2 grudnia 2027. W odniesieniu do systemów wysokiego ryzyka, o których mowa w art. 6 ust. 1 i załączniku I, ten sam zakres, również z wyjątkiem art. 6 ust. 5, stosuje się od 2 sierpnia 2028. Te późniejsze daty nie usuwają przepisów już stosowanych ani obowiązków wynikających z innych regulacji sektorowych. Aktualny kontekst prawny zbiera strona AI Act w Semitora.

RACI, Decision Record, nazwa Evidence Pack, pojedyncze A, zestaw warunków ponownej oceny i opisany cykl AI Assurance są praktyką wdrożeniową Semitory. Mają tworzyć czytelny ślad pomiędzy obowiązkiem, kontrolą techniczną, wynikiem testu i decyzją. Nie są gwarancją zgodności. Materiał ma charakter informacyjny i nie zastępuje porady prawnej, formalnej klasyfikacji ani oceny zgodności konkretnego systemu.

FAQ o AI governance w branżach regulowanych

Poniższe odpowiedzi wyjaśniają najczęstsze granice odpowiedzialności bez zamieniania praktyki wdrożeniowej w uniwersalny obowiązek prawny.

Czy każda firma korzystająca z AI potrzebuje komitetu AI governance?

Nie. Potrzebuje natomiast jasnych praw decyzyjnych, właściciela systemu i ścieżki eskalacji adekwatnej do ryzyka. W małej organizacji te funkcje mogą wykonywać istniejące role. Komitet ma sens, gdy decyzje przecinają wiele domen albo wymagają wspólnej akceptacji, ale jego powołanie samo nie dowodzi kontroli.

Czy RACI jest wymagane przez AI Act?

AI Act nie wymaga tabeli nazwanej RACI. W określonych sytuacjach wymaga jednak przypisania odpowiedzialności i wykonania konkretnych obowiązków przez właściwe role. RACI jest sposobem Semitory na przełożenie tego podziału na decyzje operacyjne. Organizacja może użyć innego mechanizmu, jeśli równie jasno pokazuje role odpowiedzialne za wynik i wykonawców.

Czym Evidence Pack różni się od dokumentacji technicznej?

Dokumentacja techniczna ma zakres określony prawem dla systemów, których dotyczą właściwe obowiązki. Evidence Pack to szerszy układ roboczy Semitory: łączy dokumenty, wyniki testów, logi operacyjne, decyzje i działania naprawcze. Może wskazywać dokumentację techniczną jako jeden z dowodów, lecz jej nie zastępuje.

Jak często trzeba przeglądać system AI?

Nie ma jednego rozsądnego interwału dla wszystkich systemów. Ustal przegląd kalendarzowy oraz zdarzenia wymuszające ponowną ocenę. Im większy możliwy skutek błędu oraz tempo zmian modelu, danych lub procesu, tym mocniejsza powinna być kontrola. Każdy Decision Record dotyczący ważnej decyzji powinien zawierać zarówno datę następnego przeglądu kalendarzowego, jak i zdarzenia wymuszające wcześniejszą ocenę.

Od czego zacząć porządkowanie AI governance?

Wybierz jeden działający lub planowany system. Opisz przypadek użycia, rolę firmy, właściciela, dane, użytkowników i możliwy skutek błędu. Potem utwórz RACI, zdefiniuj pierwszą bramkę decyzyjną i zbierz do niej dowody. Jeżeli nie masz pewności co do zakresu, zacznij od audytu gotowości AI i oddziel ustalenia techniczne od opinii prawnej.