W zeszłym tygodniu omawialiśmy nowy front ryzyka w IT, skupiając się na atakach zewnętrznych. Dziś przechodzimy od zagrożeń zewnętrznych do wewnętrznego systemu kontroli. Solidna obrona wymaga inżynierskiej dyscypliny. Przez lata zarządzanie ładem danych (na przykład przy okazji wprowadzenia RODO) realizowane było poprzez komitety, listy kontrolne i manualne audyty. To analogowe mechanizmy kontrolne w cyfrowym świecie, nieprzystające do tempa i skali nowoczesnego tworzenia oprogramowania. Tworzą lukę między polityką a praktyką, w której kryje się poważne ryzyko. Skuteczny ład (governance) to nie biurokratyczna funkcja realizowana po fakcie. To zestaw zautomatyzowanych, audytowalnych mechanizmów kontrolnych wbudowanych w proces tworzenia – koncepcja znana jako „Governance-as-Code”. To zestaw narzędzi do budowania bezpieczniejszych i zgodnych z regulacjami systemów AI.
Briefing#
Workslop#
Oprócz problemów z osiągnięciem zwrotu z inwestycji, powszechne wdrożenie generatywnej AI wprowadziło nowe ryzyko operacyjne. Zjawisko to, określane jako “workslop”, oznacza niskiej jakości treści generowane przez AI, które mają negatywny wpływ na produktywność ludzi, podważają zaufanie i generują ukryte koszty w całej organizacji. Badacze z BetterUp Labs we współpracy ze Stanford Social Media Lab stworzyli termin “workslop” na określenie specyficznego rodzaju spadku produktywności, powodowanego przez „treści stworzone przez AI, które udają dobrze wykonaną pracę, ale brakuje im merytorycznej wartości, by realnie posunąć dane zadanie do przodu”. Takie materiały często wyglądają na dopracowane i pozornie kompletne, ale w rzeczywistości są bezużyteczne, niepełne lub pozbawione kluczowego kontekstu, który pozwoliłby współpracownikowi na podjęcie dalszych działań. Główny problem z “workslop” polega na tym, że przenosi on cognitive load na kolejny etap. Odbiorca jest zmuszony do interpretacji, poprawiania lub wykonania pracy od nowa, co niweczy wszelkie zyski w produktywności z użycia AI i w efekcie zwiększa pracochłonność zadania. Trwające badanie z udziałem 1150 amerykańskich pracowników wykazało, że 40% z nich otrzymało “workslop” w ciągu ostatniego miesiąca. Koszt jest wymierny: pracownicy deklarują, że spędzają średnio dwie godziny na poprawianiu lub ponownym wykonywaniu każdego otrzymanego przypadku “workslop”. Dla dużej organizacji przekłada się to na tysiące straconych dni roboczych rocznie, co stanowi znaczący, ukryty koszt operacyjny. Problem ten występuje na wszystkich szczeblach hierarchii korporacyjnej: 40% przypadków ma miejsce między współpracownikami na tym samym poziomie, ale 18% jest przesyłane przez podwładnych do menedżerów, a 16% trafia od menedżerów do ich zespołów. Innymi słowy — stworzyliśmy narzędzia, które umożliwiają ukrywanie umysłowego lenistwa a teraz zbieramy efekty.
Kalifornia uchwala ustawę o bezpieczeństwie AI#
Kalifornia wprowadziła w życie kompleksową ustawę o bezpieczeństwie AI, wypełniając federalną próżnię regulacyjną, ustanawiając de facto krajowy standard w zakresie zarządzania zaawansowanymi modelami AI i nakładając natychmiastowe obowiązki w zakresie zgodności na największych graczy w branży. Mimo że z naszej perspektywy wydaje się to odległy problem, pamiętajmy, ze to właśnie w Kalifornii powstaje wiele z najbardziej zaawansowanych systemów AI, które wykorzystujemy w codziennej pracy, więc w naturalny sposób obowiązujące tam prawo będzie miało przełożenie na cały świat. Wymogi ustawy są aktywowane przez określone progi techniczne i finansowe, a jej celem jest regulacja najpotężniejszych systemów AI. Ustawa reguluje przede wszystkim model Frontier, definiowane jest jako te, które zostały wytrenowane przy użyciu ponad 10^26 operacji zmiennoprzecinkowych (FLOPS) oraz ich developerów, definiowanych jako firmy o rocznych przychodach co najmniej 500 milionów dolarów. Ustawa nakłada na objętych nią deweloperów szereg nowych, prawnie wiążących wymogów, skoncentrowanych na transparentności, raportowaniu bezpieczeństwa i odpowiedzialności. Wcześniej praktyki w zakresie bezpieczeństwa AI były w dużej mierze dobrowolnymi zobowiązaniami korporacyjnymi. Nowe prawo kodyfikuje te zobowiązania, m.in zapewniając solidną ochronę sygnalistów (whistleblowerów). Daje ona wewnętrznym ekspertom możliwość zgłaszania obaw dotyczących bezpieczeństwa bezpośrednio do organów regulacyjnych bez obawy przed odwetem.
Tworzymy “duchy” czy “zwierzęta”?#
Nowa teza badacza AI, Andreja Karpathy’ego, prezentuje ciekawy model myślowy ułatwiający zrozumienie ograniczeń obecnej technologii i wpływający na wieloletnie decyzje w obszarze R&D. W swoim wpisie na blogu z 1 października 2025 roku, Karpathy wprowadza analogię, by opisać obecny stan i przyszłość rozwoju AI: „Zwierzęta kontra Duchy”. Ten schemat myślowy ułatwia zrozumienie natury dzisiejszych dużych modeli językowych (LLM). Karpathy argumentuje, że obecne badania nad modelami LLM nie polegają na tworzeniu prawdziwej, adaptacyjnej inteligencji, lecz na „przywoływaniu duchów”. „Duchy” są definiowane jako „statystyczna destylacja udokumentowanej wiedzy ludzkości” – echa ogromnego korpusu tekstów i danych, na których zostały wytrenowane. Ich inteligencja wywodzi się z tych statycznych, istniejących już danych. Są one cyfrowymi artefaktami, które nie wchodzą w interakcję ze światem fizycznym ani nie uczą się na nim w czasie rzeczywistym. Ten paradygmat sugeruje istnienie sufitu możliwości rozwoju obecnej architektury LLM. Ponieważ „duchy” opierają się na ograniczonej puli danych wygenerowanych przez ludzi, w końcu wyczerpią wysokiej jakości dane treningowe, co doprowadzi do spadku korzyści z treningu. W przeciwieństwie do nich, „zwierzęta” reprezentują inny paradygmat inteligencji, która uczy się dynamicznie i nieustannie poprzez bezpośrednią interakcję ze swoim otoczeniem za pomocą uczenia przez wzmacnianie (reinforcement learning). Koncepcja ta jest zbieżna ze stworzoną przez Alana Turinga w 1950 roku wizją „maszyny-dziecka”, która uczy się z doświadczenia, napędzana wewnętrznymi motywacjami, takimi jak ciekawość, zamiast być z góry „załadowana” ekstraktami wiedzy. Teoria dywergencji sugeruje, że mogą współistnieć dwa odrębne i cenne typy AI. „Duchy” doskonale nadają się do zadań polegających na syntezie istniejącej ludzkiej wiedzy. „Zwierzęta” byłyby lepsze w zadaniach wymagających nowatorskiego rozwiązywania problemów w dynamicznych środowiskach. Pytanie, które sobie zadaję, brzmi: czy „zwierzęta” ostatecznie wykształciłyby inny model świata niż „duchy” i o ile rzędów wielkości wzrosłaby złożoność ich treningu? Trenując „duchy”, dajemy im bardzo użyteczne skróty myślowe, wynikające z setek tysięcy lat ewolucji naszego gatunku, ale jednocześnie karmimy je naszymi uprzedzeniami. Czy ten nowy model ewolucji „od zera” mógłby stworzyć nowe, inne uprzedzenia?
Potok MLOps: Audytowalna fabryka AI#
Aby zarządzać AI, trzeba najpierw zrozumieć, jak jest budowana. Nowoczesne modele AI są „produkowane” na zautomatyzowanej linii montażowej, znanej jako potok MLOps. Zrozumienie tego procesu jest podstawą wszelkiego skutecznego ładu (governance). Dobrą analogią jest nowoczesna fabryka samochodów. Podstawowe komponenty wchodzą na linię produkcyjną, przechodzą przez sekwencję zautomatyzowanych stanowisk montażowych i kontroli jakości, a na końcu wyjeżdża gotowy pojazd. Potok MLOps stosuje tę samą przemysłową dyscyplinę do uczenia maszynowego. Jest to seria zautomatyzowanych etapów:
Data ingestion: Surowce – dane – są pozyskiwane i walidowane.
Feature engineering: Dane są przetwarzane i udoskonalane do formatu, który model może wykorzystać.
Trening i ocena modelu: Model jest budowany, a jego wydajność testowana w odniesieniu do zdefiniowanych benchmarków.
Przygotowanie do wdrożenia i dokumentacja modelu: Gotowy model jest przygotowywany do wdrożenia i tworzona jest jego dokumentacja.
Wdrożenie: Zatwierdzony model jest udostępniany w środowisku produkcyjnym.
Monitorowanie w środowisku produkcyjnym: Rzeczywista wydajność modelu jest śledzona w sposób ciągły.
⠀ Ten potok jest obowiązkową ścieżką do środowiska produkcyjnego. Jeśli model nie przejdzie pomyślnie zautomatyzowanej kontroli na każdym etapie, linia montażowa zatrzymuje się. Zamiast próbować audytować chaotyczną mieszankę manualnych procesów, audytuje się jeden, zautomatyzowany system. Sam potok staje się głównym dowodem należytej staranności.
Od dokumentów z politykami do wykonywalnego kodu#
Governance-as-Code przekłada firmowe zasady z dokumentów papierowych na zautomatyzowane testy, które stoją na straży wewnątrz potoku MLOps. Zasady są proste i bezpośrednie.
Skodyfikowane: Polityki są zapisane w ustrukturyzowanym, czytelnym dla maszyn formacie, na przykład w pliku konfiguracyjnym. Eliminuje to niejednoznaczność języka naturalnego.
Wersjonowane: Te pliki z politykami są przechowywane w systemie kontroli wersji, takim jak GitHub. Każda zmiana jest śledzona, weryfikowana i audytowalna, co tworzy kompletną historię samego frameworku zarządczego.
Zautomatyzowane: Kontrole są uruchamiane automatycznie przez platformę taką jak GitLab CI/CD lub GitHub Actions za każdym razem, gdy deweloper próbuje wprowadzić zmianę. Egzekwowanie zasad jest natychmiastowe i spójne.
Audytowalne: Ponieważ polityki są kodem, a potok rejestruje każde działanie, kompletna i niezmienna ścieżka audytu jest generowana automatycznie. Zapewnia to weryfikowalny dowód, że mechanizmy kontrolne były stosowane.
Takie podejście zmienia governance z procesu reaktywnego, działającego po fakcie, w proces proaktywny i prewencyjny. Jest ono zintegrowane bezpośrednio z cyklem rozwoju oprogramowania, a nie „dokręcone” na siłę na samym końcu.
Zestaw narzędzi#
Solidna strategia Governance-as-Code wykorzystuje zestaw zautomatyzowanych narzędzi testujących. Działają one jak bramki jakości i zgodności. Jeśli polityka zostanie naruszona, potok kończy się niepowodzeniem. Oto cztery praktyczne przykłady.
- Pochodzenie i integralność danych Model jest tylko tak wiarygodny, jak dane, na których został wytrenowany. Ta bramka zapewnia, że „surowce” dla modelu pochodzą z zatwierdzonego źródła i nie zostały zmienione. Potok może kryptograficznie zweryfikować pochodzenie i integralność zbiorów danych za pomocą cyfrowo podpisanych metadanych. Jeśli podpis danych jest nieważny lub pochodzą one z niezaufanego źródła, potok kończy pracę niepowodzeniem jeszcze przed rozpoczęciem treningu. Tworzy to weryfikowalną ścieżkę audytu dla celów zgodności i chroni przed atakami sabotażu danych, które omawialiśmy w numerze #15.
- Zautomatyzowane testowanie sprawiedliwości i uprzedzeń W numerze #7 omawialiśmy zasady etycznego „papierka lakmusowego”. Model charakteryzujący się uprzedzeniami może spowodować znaczne szkody wizerunkowe i prowadzić do dyskryminujących wyników. Bramka kontrolna uprzedzeń stanowi pierwszą linię obrony. Potok uruchamia narzędzie, takie jak (open source’owa) biblioteka Fairlearn, aby przeanalizować predykcje modelu dla różnych grup demograficznych. Oblicza wskaźniki sprawiedliwości i porównuje je ze zdefiniowanym progiem. Na przykład, zasada „czterech piątych” (four-fifths rule) jest powszechnym benchmarkiem używanym do wykrywania negatywnego wpływu. Jeśli rozbieżność w wynikach między grupami przekracza ten próg, build kończy się niepowodzeniem. Automatyzuje to ogólną, ilościową część oceny etycznej, pozwalając ludzkim ekspertom skupić się na autentycznie złożonych przypadkach.
- Skanowanie podatności bezpieczeństwa Model AI to oprogramowanie, często oparte na dziesiątkach bibliotek open-source. Każda z nich może zawierać lukę w zabezpieczeniach. Zintegrowane skanery bezpieczeństwa automatycznie analizują zależności modelu w oparciu o bazę znanych błędów. Jeśli zostanie znaleziona krytyczna podatność, build kończy się niepowodzeniem. Łączy to ryzyko związane z AI bezpośrednio ze światem bezpieczeństwa łańcucha dostaw oprogramowania i zapewnia stosowanie higieny cyfrowej w rozwoju AI. Zapobiega to sytuacji, w której model staje się najsłabszym ogniwem bezpieczeństwa w firmie.
- Wymuszona transparentność Modelowi, którego nie można wyjaśnić, nie można ufać. „Karta modelu” (model card) to dokument opisujący przeznaczenie modelu, jego ograniczenia i metryki wydajności. W potoku można skonfigurować bramkę, która sprawdza, czy ten dokument istnieje i jest kompletny, zanim pozwoli na wdrożenie. Uzależniając wdrożenie od wypełnionej karty modelu, zmusza się zespół deweloperski do przeanalizowania kluczowych aspektów swojej pracy przed przekazaniem jej na produkcję. W ten sposób wspiera się kulturę transparentności.
Strategiczna wartość nieudanego „buildu”#
Rozważmy hipotetyczny przykład: bank detaliczny zaktualizował swój model zatwierdzania kredytów. Zespół data science, dążąc do poprawy dokładności, włączył nowy, zewnętrzny zbiór danych o wydatkach konsumenckich. Nowe dane miały jednak subtelne błędy w doborze próby. Nadreprezentowały wydatki w zamożnych dzielnicach, co spowodowało, że ponownie wytrenowany model nabrał ukrytych uprzedzeń. Niesłusznie karał wnioskodawców z obszarów o niższych dochodach z powodów niezwiązanych z ich osobistą zdolnością kredytową. Gdy nowy kod modelu został przekazany do wdrożenia, potok MLOps banku uruchomił się automatycznie. Uruchomiono zautomatyzowaną kontrolę fairness, obliczając wskaźniki zatwierdzeń kredytów w poszczególnych obszarach. Wykryła ona, że rozbieżność między „zamożnymi“ a „niezamożnymi“ obszarami przekroczyła 20% wariancję dozwoloną przez politykę sprawiedliwości banku. Potok zakończył się niepowodzeniem, build został zatrzymany. Wadliwy model nie został wdrożony w środowisky produkcyjnym. Dla inżyniera był to „nieudany build”. Dla Dyrektora ds. Ryzyka (Chief Risk Officer) — pełen sukces. Zautomatyzowany system zadziałał dokładnie tak, jak został zaprojektowany. Wykrył znaczące ryzyko compliance, które ludzie przeoczyli, i zneutralizował je. „Porażka” zapobiegła wypuszczeniu na rynek produktu, który mógłby zaszkodzić reputacji.
Pytania, które warto sobie zadać#
To podejście ma bezpośrednie implikacje dla zarządzania AI w organizacji. Przykładowe tematy do dyskusji:
Ile z naszych polityk ładu AI to dokumenty, a ile to zautomatyzowane, audytowalne bramki kontrolne w naszych potokach deweloperskich?
Czy możemy wskazać niezmienną ścieżkę audytu dla naszego najważniejszego modelu AI, od danych, na których był trenowany, aż do momentu wdrożenia?
Kiedy ostatni raz zautomatyzowana bramka kontrolna zatrzymała wadliwy model przed wdrożeniem na produkcję? Jeśli odpowiedź brzmi „nigdy”, to skąd pewność, że nasze manualne procesy wyłapują wszystko?
Zakończenie#
Ręczne zarządzanie w erze AI to anachronizm. Oparcie się na opracowanych przez prawników dokumentach w świecie ciągłego wdrażania oprogramowania jest jak postawienie inspektora wyposażonego tylko w kartkę i długopis we w pełni zautomatyzowanej fabryce. Jedynym sposobem na zarządzanie ryzykiem AI na dużą skalę jest traktowanie ładu (governance) jako problemu inżynierskiego. Wbudowując zautomatyzowane, audytowalne bramki kontrolne w potok MLOps, organizacje tworzą powtarzalne, weryfikowalne mechanizmy testowania modeli. Jest to jedyna pragmatyczna i wiarygodna ścieżka do skalowania zaufania przy obecnym tempie rozwoju AI.
Do następnego razu, Krzysztof