ML/AIOps. Pięknie brzmi, i tak mądrze. Tak po IT-owemu. Ale co to właściwie znaczy?
To coś, co musimy uwzględnić z perspektywy architektury IT, data pipeline’ów, DevSecOps, compliance czy security
Monitorowanie systemów AI. Brzmi sexy?
Raczej nie i dlatego używamy magicznego „MLOps” albo „AIOps”, aby nadać znaczenie i rangę czemuś, co wbrew pozorom jest nudnym, powtarzalnym, ale szalenie istotnym aspektem zarządzania inicjatywami AI & Data.
Według Wikipedii:
MLOps lub ML Ops to paradygmat, którego celem jest niezawodne i efektywne wdrażanie oraz utrzymywanie modeli uczenia maszynowego w środowisku produkcyjnym. Łączy on rozwój modeli uczenia maszynowego z operacjami produkcyjnymi, zapewniając, że modele są solidne, skalowalne i zgodne z celami biznesowymi.
Brak właściwego nadzoru nad tym jak działają agenci czy jak performuje nasz model scoringu dla klientów może być źródłem wielu nieciekawych problemów i w niektórych przypadkach skończyć się nie tylko wycofaniem rozwiązania, ale wręcz skutkować karami, utratą reputacji czy koniecznością zapłaty lub wypłaty.
Ale jeszcze jedno – to musi działać dobrze, bo za dużo fałszywych alarmów, to koszt dla organizacji. Niewyłapanie dużych f**kup’ów też.
No, ale nie może to też zabić naszych możliwości w zakresie przetwarzania danych. Przepustowość ma znaczenie. Damn, łatwo już było, prawda?
Kojarzycie kejs AWS, gdzie doszło do przypadku usunięcia bazy danych przez AI?
Może na razie są to odosobnione przypadki (albo nikt się nimi nie chwali), ale wraz ze wzrostem zastosowań AI/ML/Agentów potencjalnych incydentów może być znacznie więcej.
A przecież fakt tworzenia halucynacji też musi podlegać jakiemuś mechanizmowi kontroli. Takiemu swoistemu systemowi zarządzania jakością.
Panowie, którzy na reddicie (powyżej) przeanalizowali OpenClaw – cudowne dziecko Petera Steinbergera, które okazało się rzeczywiście mocno otwarte – wręcz rozwarte. I to też przykład niedopilnowania.
ML/AIOps to te działania, które podejmujemy w ramach naszego codziennego (albo i nie) badania czy wszystko działa, jak trzeba. Drift modelu, niedokładne wyniki, nadmierne poleganie na wynikach AI przez ludzi czy też podatności o bezpiecznikowym rodowodzie.
A jeżeli nie działa, to trzeba to naprawić. Bez wiedzy na temat niewłaściwego działania czy incydentu nie mamy możliwości poprawy i zabezpieczenia się przed materializacją ryzyk. Proste jak drut.
Tyle, że MLOps zaczyna się znacznie wcześniej, bo już na etapie planowania, o czym łatwo zapomnieć. Jeżeli nie uświadomimy sobie na etapie koncepcyjnym, że takie coś musimy wdrożyć, aby nie wylać dziecka z kąpielą, to później może okazać się, że projekt jest not-feasible i trafi do przysłowiowego kosza.
Zarówno ISO 42001, czyli złoty standard dla AI Governance, jak i AI Act wyraźnie od nas tego oczekują – i żeby nie być gołosłownym to kilka wyraźnych odniesień:
ISO 42001: rekomendacja. A.6.2.6 [AI system operation and monitoring]: Organizacja powinna zdefiniować i udokumentować niezbędne elementy bieżącego funkcjonowania systemu AI. Co najmniej powinno to obejmować monitorowanie systemu i jego wydajności, naprawy, aktualizacje oraz wsparcie.
AI Act: art. 12 [Systemy AI wysokiego ryzyka muszą dysponować technicznymi możliwościami automatycznego rejestrowania zdarzeń].
To w ogóle dość ciekawy wątek, bo w zasadzie to on stoi na przeszkodzie wielu wdrożeniom, które działają w oparciu o zewnętrznych dostawców – jeżeli nie możesz czegoś kontrolować, to jak możesz brać za to odpowiedzialność? A przecież logi są nam potrzebne nie tylko ze względu na audyty.
AI Act: art. 13 [systemy AI wysokiego ryzyka projektuje się i rozwija w sposób zapewniający wystarczającą przejrzystość ich działania, umożliwiającą podmiotom stosującym interpretację wyników systemu i ich właściwe wykorzystanie].
Ten wątek łączymy też z wyjaśnialnością, która jest szczególnie istotna w tych przypadkach użycia, gdzie AI podejmuje decyzje. Choć dzisiaj są to jeszcze rzadkie przypadki w bardziej regulowanych sektorach, to o tym fakcie nie możemy zapominać. Stąd ja sam rekomenduję klientom ustanowienie OKREŚLONEJ PROCEDURY działania w kontekście pozyskiwania logiki decyzji, jej interpretacji i przełożenia na ludzki język.
AI Act: art. 17 i 72 [W ramach systemu monitorowania po wprowadzeniu do obrotu w aktywny i systematyczny sposób zbiera się, dokumentuje i analizuje stosowne dane dotyczące skuteczności działania systemów AI wysokiego ryzyka w całym cyklu ich życia, które to dane mogą być przekazywane przez podmioty stosujące lub mogą być zbierane z innych źródeł].
Możemy do tego dołożyć NIST AI Risk Management Framework, który równie często odnosi się do kwestii monitorowania pod kątem charakterystycznych dla AI ryzyk.
Czytaj także: Dlaczego projekty AI nie są „normalne”? Zrozumieć cykl życia inicjatyw, część 2. Potwierdzamy hipotezę i bierzemy ryzyka prawne
I mógłbym tak jeszcze długo, ale nie o tym jest post
Wprowadzenie mechanizmów obsługi po-wdrożeniowej dla projektów AI & Data musi być ważną częścią naszego podejścia.
O ile w przypadku tradycyjnego soft’u można w zasadzie puścić na produkcję, doglądać aktualizacji i kontrolować zmiany, tak ML/AIOps wymaga od nas czegoś więcej. To też nie jest zwykłe CI/CD.
Problemem, z którym będziemy się mierzyć jest to, że to wątek wybitnie interdyscyplinarny. Ryzyka i będące ich pochodną incydenty będą miały charakter:
– technologiczny, w tym infrastrukturalny (np. chmura);
– bezpieczeństwa (nowe rodzaje ataków, jak np. memory poisoning);
– etyczny i prawny, np. w zakresie biasów i dyskryminacji;
– stricte „danowy” – stąd Collibra i data lineage;
– ludzki, bo człowiek jest omylny;
– finansowy, bo wykorzystaniem infrastruktury też trzeba zarządzać budżetowo.
Stworzenie dobrych procedur i procesów jest tutaj równie ważne jak wybór narzędzi. Co ważne, musimy mieć też ludzi, którzy będą chcieli tym zarządzać (lub będą musieli).
No, a skoro potencjalne pitfall’e mogą wynikać z różnych obszarów, to jak jednoznacznie nakreślić linię odpowiedzialności?
To nie jest easy task. Stworzenie takich mechanizmów w dobie potrzeby orkiestracji agentów powinno być naszym (jednym z) priorytetów. Tym bardziej, że wiele projektów wykłada się właśnie na tym – na braku możliwości skutecznego monitorowania. Dobrym podejściem jest rozpoczęcie od próby uchwycenia rodzajów ryzyk, z którymi będziemy się mierzyć przy naszych wdrożeniach.
W zasadzie bez tego nie pójdziemy dalej. A to wymaga już pewnej dojrzałości i umiejętności nazwania tego, co budzi strach.
I wracamy do punktu wyjścia czyli ryzyka. Jest ono centralnym punktem każdej polityki AI Governance. To czy jest ono zarządzane jak dawniej, ale z dodatkowymi bonusami, czy też jest to zupełnie nowa działka w organizacji – jest szczegółem. Kluczem musi być zrozumienie po co to robimy, czyli musimy odpowiedzieć sobie na jedno [***] ważne pytanie – co chcemy robić i zacząć to robić.
Czy więc się da? No da się, ale okienko kontekstowe już nie pozwala na więcej. Zainteresowani pogłębieniem tematu? A może potrzebujecie wsparcia? To pogadajmy, bo czas, bo warto złapać pomocną dłoń 🙂
Michał Nowakowski – doktor nauk prawnych i radca prawny z 13-letnim doświadczeniem w obszarze innowacji finansowych oraz nowych technologii. Specjalizuje się w zagadnieniach związanych z wdrażaniem przepisów i regulacji dotyczących danych, AI oraz budowaniu w organizacjach rozwiązań data governance i data management. Od 2022 roku jest prezesem zarządu PONIP. Pracował zarówno w sektorze publicznym, jak i prywatnym, gdzie zdobywał doświadczenie przy realizacji projektów uwzględniających szeroko rozumiane ryzyka ICT oraz outsourcing i ochronę prywatności. Był związany także z instytucjami finansowymi, w tym z bankami, gdzie doradzał m.in. zespołom R&D, bezpieczeństwa oraz IT. Autor książek, artykułów naukowych i prelegent na konferencjach i wydarzeniach branżowych. Prywatnie miłośnik kodowania i ML. Współzałożyciel i prezes zarządu spółki GovernedAI, zajmującej się tworzeniem i wdrażaniem bezpiecznego oprogramowania wykorzystującego systemy uczenia maszynowego i głębokiego, w tym tzw. generatywną sztuczną inteligencję.
Profil na linkedin: https://www.linkedin.com/in/mjnowakowski/?originalSubdomain=pl
