AI Act od strony inżyniera: artykuły 12-15

AI Act (Rozporządzenie 2024/1689) liczy 459 paragrafów i 180 stron. Większość zespołów inżynierskich, z którymi pracuję, czyta executive summary i kończy. Rezultatem są review architektoniczne, na których nikt nie potrafi powiedzieć, czy system jest wysokiego ryzyka i nikt nie wie, które artykuły stosują się do pipeline wdrożeniowego.

Ten post to praktyczna referencja dla czterech artykułów, które najmocniej dotykają codziennej inżynierii: art. 12 (logowanie), art. 13 (transparentność), art. 14 (nadzór człowieka), art. 15 (dokładność, odporność, cyberbezpieczeństwo).

Kogo to dotyczy

Te cztery artykuły siedzą w Rozdziale III, Sekcji 2: "Wymagania dla systemów AI wysokiego ryzyka." Zanim zaczną obowiązywać, twój system musi zostać sklasyfikowany jako wysokiego ryzyka na podstawie art. 6 i Annex III. Większość AI używanego w regulowanych branżach (scoring kredytowy, underwriting ubezpieczeniowy, dokumentacja kliniczna, identyfikacja biometryczna, screening rekrutacyjny, komponenty bezpieczeństwa w infrastrukturze krytycznej) trafia do Annex III. Jeśli nie wiesz, czy twój system jest w zakresie, to osobne pytanie, na które odpowiada etap klasyfikacji.

Cztery artykuły poniżej dotyczą providerów wprowadzających system wysokiego ryzyka na rynek UE i wdrażających, którzy go używają. Jeśli budujesz AI we własnym produkcie i twoi klienci go wdrażają, jesteś zazwyczaj providerem. Jeśli integrujesz cudzy model we własnym procesie biznesowym (ubezpieczyciel używający narzędzia underwritingowego vendora), jesteś zazwyczaj wdrażającym.

Obie role mają obowiązki w tych artykułach i są to różne obowiązki.

Artykuł 12 - Automatyczne logowanie

Artykuł 12 wymaga, aby systemy AI wysokiego ryzyka "automatycznie rejestrowały zdarzenia (logi) przez cały okres życia systemu." Sześć kategorii musi być uchwyconych dla każdego zdarzenia operacyjnego: specyfikacja techniczna systemu w momencie zdarzenia (wersja modelu, suma kontrolna wag, wersja szablonu promptu, schemat narzędzi, wersja indeksu retrieval); dane wejściowe przetwarzane przez system (prompt lub stabilny hash plus surowy prompt zgodnie z regułami retencji, pobrane dokumenty, załączone pliki); dane wyjściowe wyprodukowane przez system (pełna odpowiedź modelu, w tym przypadki odmowy i pośrednie wywołania narzędzi); identyfikacja osób fizycznych zaangażowanych (konto użytkownika, które wyzwoliło inferencję, operator zatwierdzający decyzję wysokiego ryzyka, recenzent nadpisujący rekomendację systemu); data i znacznik czasu z precyzją UTC do ułamków sekundy; odniesienie do bazy danych lub źródła danych konsultowanych podczas inferencji (trafienia retrieval, węzły grafu wiedzy, identyfikatory chunków vector store). Retencja na podstawie art. 12(2) wynosi sześć miesięcy, z możliwością przedłużenia o okres operacyjny. Logi muszą być "udostępniane na żądanie właściwym organom." To ten artykuł psujący domyślnie większość wrapperów LLM w chmurze. Chat API zwracające odpowiedź i HTTP 200 nie daje logów, które go spełniają - system odbierający musi je sam uchwycić i przechowywać.

Artykuł 13 - Transparentność i informacje dla wdrażających

Artykuł 13 wymaga, aby systemy wysokiego ryzyka były dostarczane z instrukcjami użytkowania zawierającymi "zwięzłe, kompletne, poprawne i jasne informacje" istotne, dostępne i zrozumiałe dla wdrażających. Dwanaście pozycji jest wymienionych w art. 13(3). Zespoły inżynierskie najczęściej pomijają: dane identyfikacyjne i kontaktowe providera (imię, email, adres fizyczny); charakterystykę, możliwości i ograniczenia systemu (znane tryby awarii, metryki wydajności rozbite na zmienne demograficzne lub kontekstowe istotne dla danego zastosowania); deklarowaną dokładność, odporność i cyberbezpieczeństwo (które muszą zgadzać się z dokumentacją techniczną z art. 11 i monitoringiem po wprowadzeniu do obrotu z art. 72); przewidywalne ryzyka niewłaściwego użycia (musisz wyliczyć przypadki niewłaściwego użycia, które rozważałeś, nie tylko zamierzone zastosowania); wymagany poziom nadzoru człowieka (interlock z art. 14; niejasny język nie przechodzi audytu).

W SPA to endpoint /transparency, w CLI komenda tool model-info, w integracji API dokument JSON podlinkowany z dokumentacji kontraktowej wdrażającego. Dla wdrażających art. 13 mapuje się na krok potwierdzenia: vendor musi ci dać ten dokument, a ty musisz go mieć w aktach. Jeśli nie, to jest luka w twojej ocenie ryzyka dostawcy na podstawie art. 21 NIS2 i art. 28 DORA.

Artykuł 14 - Nadzór człowieka

Artykuł 14 wymaga, aby systemy wysokiego ryzyka były "zaprojektowane i rozwijane... w taki sposób... aby mogły być skutecznie nadzorowane przez osoby fizyczne w okresie użytkowania." Pięć wymaganych właściwości jest wymienionych:

1. Osoby fizyczne mogą zrozumieć zachowanie systemu. Nie tylko widzieć wynik: śledzić ścieżkę rozumowania, pobrany kontekst, wywołania narzędzi, prompt.
2. Operatorzy mogą zdecydować, kiedy użyć systemu i kiedy nadpisać. Ścieżki nadpisania muszą być w UI, nie w kodzie źródłowym.
3. Operatorzy mogą interweniować lub przerwać. Kill switch na poziomie żądania, a nie tylko rollback deploymentu.
4. Operatorzy mogą odmówić użycia systemu w konkretnej sytuacji. Sam score konfidencji tego nie spełnia - operator musi mieć możliwość jawnej odmowy wyniku.
5. Świadomość automation bias. Projekt systemu musi umożliwiać operatorom wiedzieć, że interagują z AI i unikać nadmiernego zaufania do jego wyniku.

Deliverables inżynierskie są konkretne: konsola recenzenta z wejściem, pobranym kontekstem, odpowiedzią modelu i wymaganym polem decyzji; metryka konfidencji lub równoważna przy każdym wyjściu; taksonomia nadpisań ze stabilnymi kodami (approve, modify, reject, escalate) i wpisem logu dla każdego; automatyczne ostrzeżenie o bias w UI w interwałach zdefiniowanych wzorcami użytkowania. Pięć właściwości wymaga designu operacyjnego, nie tylko wpisu w model card - to rozróżnia wdrażających operacyjnie zgodnych od tych, którzy mają tylko dokumentację.

Artykuł 15 - Dokładność, odporność, cyberbezpieczeństwo

Artykuł 15 grupuje trzy odrębne właściwości pod jednym artykułem.

Dokładność (15(1)): system musi wykazać "odpowiedni poziom dokładności" dla zamierzonego celu. Art. 15(4) wymaga, aby była zadeklarowana w instrukcjach użytkowania. W praktyce trzy pomiary są wymagane minimum: accuracy na poziomie zadania na held-out teście reprezentatywnym dla rozkładu wdrożeniowego, błąd kalibracji oraz accuracy na segmentach przestrzeni wejścia istotnych dla regulowanej decyzji (klauzule specyficzne dla jurysdykcji, segmenty demograficzne, typy dokumentów). Pojedynczy globalny F1 nie spełnia tego wymogu.

Odporność (15(1)): system musi być odporny na błędy, awarie i niespójności. Art. 15(4) wymaga "technicznych i organizacyjnych środków" przeciwko przewidywalnemu niewłaściwemu użyciu i zapewniających "bezpieczeństwo systemu." Trzy ścieżki inżynierskie to zasilają: red teaming i testy adversarialne wejść prompt, fault injection podczas inferencji (model dropout, backend retrieval niedostępny, częściowy kontekst) oraz testy behawioralne znanych trybów awarii modelu (konfabulacja, nadpisanie instrukcji, wstrzykiwanie persony role-play).

Cyberbezpieczeństwo (15(1) i 15(5)): system musi być chroniony przed "nieautoryzowanym dostępem, manipulacją i przykładami adversarialnymi." Dla modeli ogólnego przeznaczenia zintegrowanych z systemem wysokiego ryzyka "model i system" muszą spełniać te właściwości jako połączona powierzchnia. Praktyczne kontrolki: podpisane prompty i odpowiedzi (HMAC lub asymetryczne), walidacja wejścia na granicy, weryfikacja integralności artefaktu modelu przy ładowaniu, kontrole egressu oraz standardowe kontrolki zgodne z NIS2 (mTLS, zarządzanie sekretami, skany podatności, przegląd zależności) w każdym punkcie integracji.

Co idzie źle w praktyce

Sześć wzorców powtarza się w review architektonicznych, które prowadzę.

1. Logowanie bez wersji modelu. Logi są uchwycone, ale suma kontrolna wag nie jest. Wynik jest nieweryfikowalny na podstawie art. 12(1)(a).
2. Claims o dokładności na rozkładzie treningowym, nie wdrożeniowym. Test zbudowany z danych treningowych nie jest dowodem na podstawie art. 15(4).
3. Nadzór człowieka jako checkbox w UI. Recenzenci mogą zaznaczyć "approved", ale nie mogą przeczytać pobranego kontekstu. Art. 14(1) wymaga rozumienia, nie tylko potwierdzenia.
4. Dokument transparentności utrzymywany przez legal, nigdy nieaktualizowany przez inżynierię. Dokument rozjeżdża się z systemem; w ocenie zgodności to finding.
5. Brak logowania nadpisań po stronie wdrażającego. Zdarzenie nadpisania dzieje się w UI, ale nie jest uchwycone w śladzie audytowym. Art. 12 obejmuje to domyślnie; brakujące wpisy nie przechodzą audytu.
6. Odporność testowana raz, przy uruchomieniu. Art. 15 oczekuje ciągłego testowania. Monitoring po wprowadzeniu do obrotu z art. 72 czyni to bieżącym obowiązkiem.

Żadne z nich nie jest egzotycznym edge case. To modalne awarie regulowanych MŚP przygotowujących się do pierwszego audytu AI.

Jak wygląda dobry wynik dla małego zespołu

Nie potrzebujesz dedykowanego zespołu platformowego dla art. 12-15, jeśli zaczniesz od właściwych komponentów. Pojedyncza tabela Postgresa ze stabilnym schematem JSON pokrywa logowanie z art. 12. model-card.md w repozytorium, mirrorowany jako strona /transparency i PDF dla zakupów, pokrywa art. 13. Mała konsola recenzenta z jawną taksonomią nadpisań pokrywa art. 14. Standaryzowany harness testowy (Ragas, promptfoo lub pytest z held-out fixtures) podpięty do CI pokrywa art. 15.

ArtCode Software wdraża dokładnie ten baseline w regulowanych polskich MŚP w zleceniach od dwóch do ośmiu tygodni. Wynik przechodzi cykl zakupowy i jest bazą techniczną do oceny zgodności z art. 43.

Jeśli potrzebujesz fixed-scope diagnostyki tego, gdzie stoisz w tych czterech artykułach, AI Readiness Audit mapuje każdy artykuł na artefakty obecne lub brakujące w twoim systemie. Jeśli chcesz zaprojektować architekturę przed napisaniem linii kodu, Fractional AI Architect Retainer osadza jeden dzień w tygodniu w twoim procesie inżynierskim, aż plan wdrożenia daje się recenzować.