Jak poukładać odpowiedzialność za machine learning między IT, biznesem i działem bezpieczeństwa

Dlaczego odpowiedzialność za machine learning jest problemem organizacyjnym, a nie technicznym

Machine learning jako element procesu decyzyjnego, a nie gadżet technologiczny

Modele machine learning nie żyją w próżni. Każdy model staje się częścią jakiejś decyzji: czy przyznać kredyt, jaką cenę zaproponować klientowi, który lead przekazać sprzedawcy, który wniosek skierować do manualnej weryfikacji. Z technicznego punktu widzenia to tylko kod, dane i infrastruktura. Z punktu widzenia organizacji – to zmiana sposobu podejmowania decyzji i rozłożenia ryzyka między zespołami.

Jeśli zarząd traktuje machine learning jako „magiczny silnik z piwnicy IT”, pojawia się natychmiastowe zniekształcenie odpowiedzialności. IT jest postrzegane jako odpowiedzialne za „wynik modelu”, biznes zdejmuje z siebie odpowiedzialność, a dział bezpieczeństwa reaguje dopiero wtedy, gdy coś pójdzie nie tak. W efekcie modele ML wchodzą do procesów decyzyjnych bez realnej zgody i zrozumienia tych, którzy będą ponosić konsekwencje.

W praktyce zdrowe podejście zakłada, że ML to narzędzie decyzyjne w rękach biznesu, obsługiwane na platformie IT i nadzorowane przez bezpieczeństwo. Technologia jest tu środkiem do osiągnięcia celu, a nie podmiotem odpowiedzialnym za rezultat. To fundament, na którym buduje się sensowny podział ról.

Symptomy braku jasnego podziału odpowiedzialności za ML

Pewien poziom chaosu w początkowych eksperymentach z uczeniem maszynowym jest normalny. Problem pojawia się, gdy eksperymentalny tryb działania przenosi się na produkcję. Da się wtedy zaobserwować kilka powtarzalnych symptomów:

• „Sieroce” modele – działają w produkcji, ale nikt nie potrafi odpowiedzieć, kto jest ich właścicielem. Zespół data science twierdzi, że „tylko zrobił POC”, biznes zakłada, że „IT tym zarządza”, a IT widzi tylko kontener z aplikacją, bez kontekstu biznesowego.
• Konflikty o priorytety – biznes naciska na szybkie wdrożenia kolejnych modeli, IT blokuje wdrożenia z powodu braku standardów i zasobów, bezpieczeństwo domaga się analiz ryzyka, o których nikt nie pomyślał na początku.
• Brak spójnego procesu zmian – modele są „podmieniane” w tle, bo nowa wersja ma lepsze metryki, ale nikt formalnie nie zaakceptował zmiany wpływającej na proces biznesowy. Po kilku miesiącach nikt nie wie, który model działa w którym kanale.
• Rozjazd między deklaracjami a praktyką – oficjalnie firma ma „framework governance dla AI”, w praktyce większość modeli jest poza tym frameworkiem, bo powstały „na szybko” w oddziałach biznesowych.

Te symptomy nie są efektem złej woli poszczególnych zespołów, tylko braku czytelnego podziału: kto decyduje, kto odpowiada i kto ma prawo weto na danym etapie cyklu życia modelu.

Konsekwencje: nie tylko błędne decyzje, ale też ryzyka regulacyjne i reputacyjne

Niewłaściwie poukładana odpowiedzialność za machine learning prędzej czy później materializuje się w postaci konkretnych strat. W najłagodniejszej wersji kończy się na błędnych decyzjach biznesowych i stratach finansowych. Bardziej dotkliwe konsekwencje to:

• Ryzyka regulacyjne – w sektorach regulowanych (finanse, medycyna, ubezpieczenia, sektor publiczny) modele ML stają się obiektem zainteresowania nadzorców. Brak możliwości wyjaśnienia decyzji, brak śladu audytowego czy brak kontroli nad danymi wejściowymi to prosta droga do kar i nakazów zmian w procesach.
• Ryzyka reputacyjne – przypadki dyskryminacyjnych decyzji modelu, wycieków danych treningowych, błędnych decyzji na masową skalę (np. automatyczne odrzucenie całej grupy klientów) bardzo szybko stają się tematem publicznym.
• Ryzyka bezpieczeństwa – niekontrolowane integracje, brak segmentacji środowisk, brak przeglądów kodu i danych treningowych zwiększają powierzchnię ataku. Modele ML mogą być celem dla atakujących (np. wyciąganie informacji z modelu, poisoning danych).

Technicznie te problemy mogą wyglądać jak błędy w kodzie, błędne pipeline’y czy brak monitoringu. Organizacyjnie to jednak brak osoby, która ma formalny obowiązek zadać pytanie: „Czy akceptujemy takie ryzyko i na jakich warunkach?”.

Różnica między odpowiedzialnością za kod, dane i skutki decyzji

Przy rozdzielaniu odpowiedzialności wokół machine learning kluczowe jest odróżnienie trzech poziomów:

• Odpowiedzialność za kod i infrastrukturę – dotyczy poprawności implementacji, konfiguracji środowisk, zabezpieczeń technicznych, pipeline’ów CI/CD, monitoringu technicznego. To naturalny obszar IT i ML engineering.
• Odpowiedzialność za dane – obejmuje jakość danych, ich pochodzenie, legalność przetwarzania, zgodę klienta, retencję i anonimizację. Tu spotykają się biznes, właściciele danych, dział bezpieczeństwa i compliance.
• Odpowiedzialność za skutki decyzji modelu – to odpowiedź na pytania: kogo dotykają decyzje, jak są komunikowane, jak można je zakwestionować, jakie są konsekwencje dla klientów i firmy. Ten poziom musi leżeć po stronie biznesu, bo dotyczy strategii i polityki działania firmy.

Jeśli te trzy poziomy zlewają się w jedno („IT odpowiada za model”), organizacja traci zdolność do sensownej dyskusji o ryzyku i kompromisach. Jasne rozdzielenie umożliwia zbudowanie przejrzystego modelu governance: wiadomo, gdzie kończy się odpowiedzialność IT, a zaczyna odpowiedzialność biznesu i bezpieczeństwa.

Podstawowe role w projektach ML i ich naturalne interesy

Rola IT i działu technologii w inicjatywach ML

Dla działu IT machine learning jest kolejnym typem obciążenia, który trzeba utrzymać: aplikacje, usługi, pipeline’y danych, integracje, monitoringi. Naturalnym interesem IT jest stabilność, przewidywalność i kontrola kosztów. Modele, które „ktoś gdzieś wdrożył”, bez standardów, nadzoru i budżetu operacyjnego, są postrzegane jako ryzyko.

IT ma zwykle trzy podstawowe obszary odpowiedzialności w ML:

• zapewnienie infrastruktury (on-premise lub chmura), w tym bezpieczeństwa na poziomie sieci, kont, kluczy, uprawnień i kopii zapasowych,
• utrzymanie platformy danych (hurtownie, lakehouse, integracje, narzędzia ETL/ELT),
• budowanie i utrzymanie platformy ML/MLOps (repozytoria kodu, rejestr modeli, system monitoringu, procesy wdrożeniowe).

To powoduje, że IT dąży do standaryzacji: jednego rekomendowanego stosu technologicznego, jednego sposobu wdrożeń, jednego sposobu logowania i monitorowania. Z perspektywy biznesu bywa to postrzegane jako „hamowanie innowacji”, z perspektywy IT – jako jedyna metoda utrzymania porządku i bezpieczeństwa.

Biznes jako właściciel celu i konsekwencji decyzji modelu

Jednostki biznesowe – sprzedaż, marketing, ryzyko kredytowe, operacje, obsługa klienta – są zainteresowane przede wszystkim wynikiem biznesowym. Oczekują, że machine learning przełoży się na:

• wzrost przychodów (lepszy cross-sell, wyższa konwersja),
• obniżenie kosztów (automatyzacja decyzji, mniej manualnej pracy),
• lepsze doświadczenie klienta (personalizacja, szybsze decyzje).

Naturalnym podejściem biznesu jest gotowość na kontrolowane ryzyko, jeśli zwrot wydaje się atrakcyjny. Biznes chętnie akceptuje eksperymenty, A/B testy, pilotaże. Jednocześnie nie lubi długich cykli wdrożeniowych, złożonych procesów akceptacji i technicznych ograniczeń.

W dojrzałej organizacji biznes pełni rolę „product ownera” modeli ML – to po stronie biznesu leży zdefiniowanie:

• celu modelu (jak ma wpływać na KPI),
• zakresu użycia (w jakich kanałach, dla jakich klientów),
• akceptowalnych poziomów błędu (np. ile fałszywych pozytywów jest do zaakceptowania),
• reguł eskalacji (kiedy decyzja modelu wymaga weryfikacji człowieka).

Bez tej odpowiedzialności modele ML dryfują w stronę „technicznych zabawek”: metryki wyglądają dobrze, ale nikt nie rozlicza modelu z efektu biznesowego i wpływu na proces.

Dział bezpieczeństwa, compliance i prawnicy jako strażnicy ryzyka

Działy bezpieczeństwa informacji, ryzyka operacyjnego, compliance i prawne patrzą na machine learning zupełnie inaczej niż IT i biznes. W centrum ich uwagi jest pytanie: jakie nowe ryzyka tworzy wprowadzenie modelu ML i czy organizacja jest gotowa te ryzyka zaakceptować, kontrolować i raportować.

Do typowych obszarów zainteresowania tych funkcji należą:

• bezpieczeństwo danych – jakie dane trafiają do modelu, gdzie są przechowywane, czy są anonimizowane, jak długo są przetwarzane,
• zgodność z regulacjami – RODO, sektorowe regulacje (np. wytyczne nadzorców finansowych), w przyszłości regulacje dotyczące AI,
• ryzyko reputacyjne i etyczne – potencjalna dyskryminacja, brak możliwości wyjaśnienia decyzji, brak mechanizmów odwoławczych dla klientów,
• ślad audytowy – możliwość udokumentowania, jak model był trenowany, jakie dane wykorzystywał, jakie decyzje podejmował i dlaczego.

Naturalnym odruchem bezpieczeństwa jest ostrożność: preferencja dla sprawdzonych rozwiązań, silnych kontroli, ograniczania powierzchni ryzyka. Dla biznesu bywa to odbierane jako „blokowanie ciekawych projektów”. Kluczem jest włączenie bezpieczeństwa od początku cyklu życia modelu, zamiast traktować je jako punkt kontrolny „na końcu”.

Zderzenia interesów: szybkość, innowacja i bezpieczeństwo

Konflikty wokół machine learning narastają tam, gdzie organizacja nie potrafi nazwać i pogodzić naturalnych interesów poszczególnych ról. Najczęstsze napięcia:

• szybkość vs kontrola – biznes chce jak najszybciej przetestować nowy model, IT i bezpieczeństwo potrzebują czasu na przygotowanie środowisk, przeglądy i testy,
• eksperyment vs standard – zespoły data science chcą swobody w doborze narzędzi, bibliotek i platformy, IT oczekuje standaryzacji ze względu na koszty utrzymania i bezpieczeństwo,
• lokalne optymalizacje vs globalne ryzyko – lokalny zespół produktowy widzi tylko swój przypadek użycia, dział ryzyka analizuje wpływ kumulacji wielu modeli na ekspozycję całej organizacji.

Te zderzenia są normalne. Problem pojawia się dopiero wtedy, gdy nie ma jasno zdefiniowanych ról i procesów, które pozwalają przełożyć spór na konkretne decyzje: kto ma głos decydujący, na jakiej podstawie, z jaką odpowiedzialnością i jakie są kryteria akceptacji ryzyka.

Co to znaczy „odpowiadać za model ML” – trzy poziomy odpowiedzialności

Odpowiedzialność techniczna za model ML

Odpowiedzialność techniczna obejmuje wszystko, co powoduje, że model jest w stanie działać stabilnie w środowisku produkcyjnym. To obszar, w którym dominują zespoły IT, ML engineering i data science. Główne elementy:

• jakość kodu – standardy programistyczne, przeglądy kodu, testy jednostkowe, integracyjne, bezpieczeństwa,
• pipeline danych – definicja źródeł danych, transformacje, walidacja jakości, odporność na brakujące lub zmienione pola,
• procesy MLOps – automatyzacja trenowania, wersjonowanie modeli, testy przed wdrożeniem, roll-back, Canary Release,
• monitoring techniczny – dostępność endpointów, czasy odpowiedzi, błędy, zużycie zasobów, skalowanie.

Odpowiedzialność techniczna odpowiada na pytanie: czy model działa tak, jak został zaprojektowany od strony inżynierskiej. Jeśli przestaje działać (awaria, błędy, brak danych), to do IT/ML engineering należy reakcja operacyjna, eskalacja i naprawa.

Ten poziom nie obejmuje jednak odpowiedzi na pytanie, czy model powinien działać w dany sposób, czy jego zachowanie jest biznesowo akceptowalne ani czy jest zgodne z regulacjami. To już inne poziomy odpowiedzialności.

Odpowiedzialność biznesowa za cel i użycie modelu

Odpowiedzialność biznesowa dotyczy tego, po co model istnieje i jak jego wyniki są wykorzystywane w procesach. To rola właściciela biznesowego, który powinien:

• zdefiniować cel modelu (np. ograniczenie churnu, poprawa trafności ofert),
• ustalić, jak decyzje modelu wpływają na proces (np. automatyczna akceptacja wniosków poniżej określonego poziomu ryzyka),
• zdecydować, kiedy decyzja modelu wymaga interwencji lub zatwierdzenia przez człowieka,
• regularnie oceniać wpływ modelu na KPI biznesowe i korygować zasady jego użycia.

Odpowiedzialność za ryzyko, zgodność i etykę modelu

Trzeci poziom to odpowiedzialność za ryzyko generowane przez model – prawne, regulacyjne, reputacyjne i etyczne. To obszar, w którym pierwsze skrzypce grają bezpieczeństwo informacji, ryzyko, compliance i prawnicy, ale bez ścisłej współpracy z biznesem i IT ten poziom nie zadziała.

Ten zakres obejmuje m.in.:

• klasyfikację ryzyka modelu – określenie, czy model jest krytyczny (np. decyzje kredytowe, limity transakcyjne), istotny czy pomocniczy,
• ocenę wpływu na prawa klientów – czy model podejmuje decyzje wywołujące skutki prawne lub podobnie istotne, czy można się od nich odwołać,
• ocenę uprzedzeń i dyskryminacji – identyfikację grup, które mogą być nieproporcjonalnie dotknięte błędami modelu,
• wymagania dokumentacyjne – opis przeznaczenia modelu, danych treningowych, ograniczeń i znanych ryzyk,
• politykę retencji danych i modeli – jak długo przechowywane są dane treningowe, wersje modeli, logi decyzji.

To poziom, na którym kluczowe pytanie brzmi: czy jako organizacja godzimy się na taki poziom ryzyka i czy umiemy go pokazać nadzorcy, klientowi i audytowi. Formalnie zwykle odpowiada za to funkcja ryzyka/compliance, ale decyzje podejmowane są wspólnie z biznesem, który rozumie korzyści, i IT, które zna ograniczenia techniczne.

Jak te trzy poziomy się zazębiają

Trzy poziomy odpowiedzialności – techniczny, biznesowy i ryzyka – to nie są silosy, tylko nakładające się perspektywy. Ten sam incydent może mieć różne „warstwy”:

• awaria pipeline’u danych to problem techniczny,
• spadek skuteczności modelu i wzrost liczby odrzuconych wniosków kredytowych to problem biznesowy,
• brak możliwości wytłumaczenia decyzji klientowi i nadzorcy to problem ryzyka i zgodności.

Jeśli organizacja na poziomie governance ma jedynie ogólną formułę „za model odpowiada X”, to w kryzysie zaczyna się przerzucanie się winą. Jasny podział: kto pilnuje jakiego poziomu, ułatwia zarządzanie incydentami i podejmowanie decyzji, czy model zatrzymać, przełączyć, czy skorygować zasady użycia.

Mapa odpowiedzialności RACI dla cyklu życia modelu ML

Dlaczego modele ML potrzebują innej mapy RACI niż klasyczne aplikacje

Dla typowych systemów IT klasyczny RACI (Responsible, Accountable, Consulted, Informed) często da się zamknąć w prostym schemacie: IT jest odpowiedzialne i rozliczane, biznes konsultowany, reszta informowana. W modelach ML to się nie sprawdza, bo decyzja „uruchomić czy nie” jest wprost decyzją o akceptacji określonego ryzyka biznesowego.

Mapa RACI dla ML musi uwzględniać, że:

• model żyje – uczy się, degraduje, bywa retrenowany,
• decyzja modelu może mieć skutki prawne (np. odmowa kredytu),
• regulator może wymagać udokumentowania procesu powstawania i monitorowania modelu.

Dlatego sensowne jest rozpisanie RACI nie dla „modelu”, tylko dla etapów jego cyklu życia.

RACI dla etapu: identyfikacja i selekcja przypadków użycia

Na samym początku kluczowe pytanie brzmi: czy w ogóle warto użyć ML, czy wystarczy regułowy mechanizm, prosty scoring lub nawet ręczna analiza.

• Accountable (A): biznes – właściciel procesu, który ma zostać zautomatyzowany lub usprawniony.
• Responsible (R): product owner / lider inicjatywy – często po stronie biznesu, czasem w roli „AI product managera”.
• Consulted (C): data science, IT, bezpieczeństwo/compliance – data science ocenia wykonalność, IT – koszty i integracje, bezpieczeństwo – wstępne ryzyka.
• Informed (I): zarząd/komitet inwestycyjny – szczególnie dla krytycznych przypadków użycia.

Jeśli na tym etapie bezpieczeństwo jest jedynie informowane, a nie konsultowane, projekty potrafią zostać zablokowane bardzo późno, gdy ryzyka wychodzą na jaw dopiero przy przeglądzie dokumentacji przed wdrożeniem.

RACI dla etapu: pozyskanie i przygotowanie danych

Gdy przypadek użycia jest wybrany, pojawia się pytanie, na jakich danych model będzie się uczył i działał.

• Accountable (A): właściciel danych / data owner – to może być jednostka biznesowa lub IT, w zależności od modelu zarządzania danymi.
• Responsible (R): zespoły data engineering / data science – projektują pipeline, czyszczą dane, dokumentują źródła.
• Consulted (C): bezpieczeństwo informacji, DPO/RODO, architekci danych – ocena wrażliwości danych, zasad minimalizacji, zgód, transferów transgranicznych.
• Informed (I): biznes – rozumie, jakie dane będą używane i jakie z tego wynikają ograniczenia (np. brak pewnych atrybutów).

Typowy błąd to założenie, że jeśli dane są już „w systemie”, to można je bezpośrednio użyć do uczenia modelu. RACI zmusza do wskazania, kto formalnie odpowiada za zgodność tego użycia z politykami danych.

RACI dla etapu: trenowanie, walidacja i wybór modelu

Na tym etapie data science buduje modele, porównuje i wybiera wariant do dalszych testów. Kluczowe są: metryki, jakość walidacji i zrozumienie ograniczeń.

• Accountable (A): lider zespołu data science / ML – za to, że proces trenowania jest rzetelny i udokumentowany.
• Responsible (R): data scientists / ML engineers – implementują kod, przygotowują eksperymenty, opisują wyniki.
• Consulted (C): biznes, bezpieczeństwo/ryzyko – biznes pomaga dobrać metryki odpowiadające celom (np. koszty błędów), ryzyko – minimalne wymagania dla modeli krytycznych.
• Informed (I): IT infrastrukturalne – z wyprzedzeniem wie, jakie są wymagania obliczeniowe i planowane częstotliwości retreningu.

Warto, by w standardzie znajdowały się artefakty typu model card lub analogiczny dokument, którego przygotowanie leży po stronie data science, a zaakceptowanie – po stronie biznesu i ryzyka.

RACI dla etapu: wdrożenie do środowiska produkcyjnego

Przeniesienie modelu z laboratorium do produkcji to moment, w którym tradycyjnie najczęściej pojawiają się tarcia między IT a data science.

• Accountable (A): IT / właściciel platformy ML – za to, że wdrożenie spełnia standardy inżynierskie i bezpieczeństwa produkcji.
• Responsible (R): ML engineers / DevOps – przygotowują pipeline CI/CD, kontenery, konfiguracje, monitoring.
• Consulted (C): data science, biznes, bezpieczeństwo – data science weryfikuje, że model funkcjonalnie działa jak w testach; biznes – że scenariusze użycia są poprawnie odwzorowane; bezpieczeństwo – że kontrola dostępu, logi i szyfrowanie są zgodne z polityką.
• Informed (I): użytkownicy biznesowi, service desk – wiedzą, kiedy nastąpi przełączenie i jak reagować na problemy.

Jeśli Accountable za wdrożenie jest po stronie data science, w praktyce kończy się to „shadow IT”: modele działają poza oficjalnymi standardami, bez odpowiedniego monitoringu i wsparcia operacyjnego.

RACI dla etapu: monitorowanie, utrzymanie i retrening

Modele ML bez nadzoru ulegają degradacji. Zmieniają się dane wejściowe, zachowania klientów, procesy biznesowe. To, kto patrzy na jakie metryki i kto inicjuje działania korygujące, jest kluczowe.

• Accountable (A): wspólnie – biznes (za skuteczność) i IT/ML (za dostępność). Warto, aby było to formalnie zapisane, nawet jeśli w ramach jednego komitetu.
• Responsible (R): ML engineers / SRE dla modeli – za monitoring techniczny i metryki jakościowe modelu (drift, stabilność predykcji), oraz za proces retreningu.
• Consulted (C): data science, bezpieczeństwo/ryzyko – data science pomaga interpretować zmiany metryk, bezpieczeństwo ocenia incydenty wpływające na ryzyko.
• Informed (I): biznes, audyt wewnętrzny – otrzymują regularne raporty o stanie modeli, szczególnie krytycznych.

W praktyce sprawdza się podejście, w którym biznes ma KPI na efekty modelu (np. konwersja, wskaźnik złych długów), a IT/ML – SLA na dostępność i czas reakcji na incydenty. To wymusza wspólną rozmowę, gdy metryki zaczynają się rozjeżdżać.

RACI dla etapu: wyłączenie lub zastąpienie modelu

Każdy model prędzej czy później powinien zostać wyłączony lub zastąpiony. Kłopoty zaczynają się tam, gdzie trudno odpowiedzieć, kto ma prawo podjąć taką decyzję.

• Accountable (A): biznesowy właściciel procesu – to on musi zdecydować, że korzyści przestały uzasadniać używanie modelu w danym kształcie.
• Responsible (R): IT / ML engineers – za bezpieczne wyłączenie, przełączenie na nowy model, modyfikację integracji.
• Consulted (C): bezpieczeństwo/ryzyko, data science – ocena ryzyka nagłego wyłączenia vs stopniowego wygaszania, propozycja scenariusza przejścia.
• Informed (I): nadzór, audyt, kluczowi interesariusze – szczególnie jeśli model był krytyczny regulacyjnie.

Bez tej fazy w RACI organizacje gromadzą „martwe” lub zapomniane modele, które wciąż działają gdzieś w tle, nikt ich nie monitoruje, a przy audycie nikt nie jest w stanie jednoznacznie wskazać odpowiedzialnych.

Ustalenie właściciela modelu: biznes jako „accountable”, IT i bezpieczeństwo jako współtwórcy

Dlaczego właściciel powinien być po stronie biznesu, a nie IT

Jeśli decyzja modelu wpływa na KPI biznesowe i klientów, to ostatecznie za tę decyzję odpowiada biznes. Nawet jeśli model jest technicznie zarządzany przez IT, to argument „tak wyszło z algorytmu” nie działa ani wobec klienta, ani wobec regulatora.

Traktowanie IT jako właściciela modelu prowadzi do kilku wypaczeń:

• modele są optymalizowane pod kątem stabilności i kosztu, a nie wyniku biznesowego,
• biznes nie czuje się odpowiedzialny za jakość danych i decyzje o progu ryzyka,
• w razie incydentu IT jest „wciągane” w obronę decyzji, na które nie miało wpływu.

Dlatego sensownie jest przyjąć prostą zasadę: właścicielem (accountable) modelu jest ten, kto odpowiada za proces, na który model wpływa. W kredytach – ryzyko kredytowe, w marketingu – marketing, w operacjach – operacje itd.

Jak formalnie opisać odpowiedzialność biznesową za model

Aby odpowiedzialność biznesowa nie była jedynie deklaracją, warto ją uszczegółowić w formie dokumentu roli lub karty modelu. Taki opis powinien obejmować:

• zakres wpływu modelu – jakie decyzje wspiera lub automatyzuje, w jakich kanałach, dla jakich segmentów klientów,
• poziom automatyzacji – gdzie jest „człowiek w pętli”, a gdzie decyzja jest w pełni automatyczna,
• progowe parametry ryzyka – np. minimalna akceptowalna precyzja, maksymalny odsetek negatywnie dotkniętych klientów,
• procedury eskalacji – kto podejmuje decyzję o tymczasowym wyłączeniu modelu, gdy metryki wychodzą poza tolerancję.

Tak opisany właściciel biznesowy ma jasny mandat do podejmowania decyzji o rozwoju modelu, jego parametryzacji i ostatecznie o jego zatrzymaniu. Jednocześnie staje się pierwszym adresatem pytań przy incydentach.

Rola IT jako współtwórcy i strażnika standardów technicznych

IT nie jest „kontrahentem” biznesu, tylko współwłaścicielem odpowiedzialności na poziomie technicznym. Oznacza to, że:

• IT definiuje minimalne standardy techniczne dla modeli (logowanie, monitoring, testy, sposób wdrożenia),
• IT utrzymuje platformę, która umożliwia bezpieczne i powtarzalne wdrażanie oraz retrening modeli,
• IT ma prawo weta dla rozwiązań, które nie spełniają krytycznych wymogów bezpieczeństwa lub stabilności.

Kluczem jest uświadomienie biznesowi, że zgoda na model, który łamie te standardy, to w praktyce zgoda na niekontrolowane ryzyko operacyjne. Dobrą praktyką jest powiązanie tego z procesem zarządzania ryzykiem technologicznym: odstępstwo od standardu wymaga formalnej decyzji na odpowiednim poziomie zarządzania.

Rola bezpieczeństwa i ryzyka jako partnera, nie „hamulcowego”

Jak włączyć bezpieczeństwo i ryzyko w cykl decyzyjny modelu

Zespół bezpieczeństwa i ryzyka ma zwykle mandat do blokowania inicjatyw, ale rzadko do aktywnego współprojektowania modeli. W ML taka „policyjna” rola przynosi więcej szkody niż pożytku, bo modele łatwo wypchąć do szarej strefy – prototypy działają na produkcji „tymczasowo”, bez przeglądów ryzyka.

Bezpieczeństwo i ryzyko powinny być stałym uczestnikiem cyklu życia modelu, a nie tylko bramką na końcu. W praktyce oznacza to kilka konkretnych mechanizmów:

• checklisty ryzyka modelu – krótkie, ale obowiązkowe listy kontrolne dla nowych i zmienianych modeli (np. kategorie danych, ryzyka dyskryminacji, odporność na manipulację danych wejściowych),
• kryteria klasyfikacji modeli – prosta macierz, która oznacza model jako wysoki / średni / niski poziom ryzyka regulacyjnego i reputacyjnego; od tej klasy zależy głębokość przeglądu,
• regularne przeglądy ryzyka modeli – np. kwartalne, na których omawiane są incydenty, przekroczenia limitów i plany zmian; uczestniczą biznes, IT/ML i bezpieczeństwo,
• jasne progi eskalacji – opisane z góry sytuacje, w których bezpieczeństwo ma prawo (a czasem obowiązek) zażądać wstrzymania modelu lub jego ograniczenia.

Przykład: model oceny transakcji antyfraudowej. Zespół bezpieczeństwa nie decyduje o konkretnej wartości progu odrzucania transakcji, ale definiuje ramy: maksymalny akceptowalny odsetek fałszywych pozytywów i minimalne wymagania dotyczące śledzenia decyzji. W ramach tych ram biznes i data science optymalizują model.

Bezpieczeństwo modeli a klasyczne bezpieczeństwo IT

Modele przynoszą nowe typy ryzyka, których nie obejmują standardowe polityki bezpieczeństwa. Klasyczne IT skupia się na poufności, integralności i dostępności. W ML dochodzą m.in.:

• ryzyko manipulacji danymi wejściowymi (adversarial examples, fraud),
• ryzyko przeuczenia na wrażliwych danych i wycieku informacji o konkretnych osobach,
• ryzyko niezamierzonej dyskryminacji ze względu na cechy chronione,
• ryzyko nieinterpretowalności w procesach regulowanych.

To ryzyka, które nie zostaną obsłużone samą kontrolą dostępu czy firewallami. Potrzebne są specyficzne kontrole, np. testy stabilności predykcji, analizy wpływu cech (feature importance), walidacja biasu.

Dlatego dział bezpieczeństwa powinien współtworzyć z data science minimalny zestaw testów „ML security”, które przechodzą wszystkie modele produkcyjne określonej klasy ryzyka. Własność techniczna testów może leżeć po stronie ML engineering, ale standard i akceptacja – po stronie bezpieczeństwa.

Jak podzielić odpowiedzialność między IT a data science / ML engineering

Granica między eksperymentem a systemem produkcyjnym

Większość konfliktów IT–data science wynika z rozbieżnych oczekiwań co do tego, kiedy eksperyment staje się systemem, który musi spełnić pełne standardy IT. Jeśli nie ma jednoznacznego „progu wejścia”, data science zarzuca IT biurokrację, a IT zarzuca data science „partyzantkę”.

Warto zdefiniować formalnie etap pośredni: model pilotażowy / ograniczona produkcja. Każdy poziom ma inne wymagania:

• eksperyment – działa w środowisku testowym, brak dostępu do danych produkcyjnych, minimalne wymagania inżynierskie; odpowiedzialność leży głównie po stronie data science, IT zapewnia tylko podstawową infrastrukturę,
• pilotaż – ograniczona grupa użytkowników lub niewielki segment danych produkcyjnych; wymagane są już podstawowe logi, monitoring i procedura wycofania, odpowiedzialność dzielona,
• pełna produkcja – pełne standardy IT (backup, HA, monitoring, bezpieczeństwo); IT przejmuje odpowiedzialność za środowisko i stabilność, data science odpowiada za jakość predykcji i poprawność logiki modelu.

Kluczowe jest spisanie kryteriów przejścia między poziomami. Jeśli model ma wpływać na decyzje finansowe lub regulowane, „skrót” z eksperymentu do pełnej produkcji bez pilotażu powinien być wyjątkiem, a nie normą – i wymagać zgody odpowiedniego poziomu zarządzania.

Podział obowiązków w warstwie danych

Dane to obszar, gdzie kompetencje IT i data science nachodzą na siebie najmocniej. Bez jasnego podziału powstaje chaos: data science tworzy własne kopie danych, IT próbuje „posprzątać” hurtownię, nikt nie odpowiada za jakość źródeł.

Praktyczny schemat podziału wygląda często tak:

• IT / zespoły danych (data platform, data engineering):
  • odpowiadają za infrastrukturę danych (hurtownia, lake, strumienie),
  • zapewniają jakość techniczną – kompletność, spójność, SLA dostarczania,
  • zarządzają dostępem i katalogiem danych (data catalog, lineage),
  • wymuszają zgodność ze standardami modelowania danych (np. schematy domenowe).
• Data science / ML engineering:
  • projektują cechy (features) na bazie istniejących zbiorów,
  • odpowiadają za logikę przygotowania danych treningowych (np. okna czasowe, filtracje, target leakage),
  • prowadzą eksploracyjną analizę danych i sygnalizują problemy biznesowi oraz IT,
  • współprojektują z IT warstwę feature store, jeśli taka jest tworzona.

Istotne, aby nie tworzyć „dzikich” pipeline’ów danych poza kontrolą IT. Jeśli data science potrzebuje większej swobody, dobrym kompromisem bywa „piaskownica danych” (sandbox): środowisko, w którym zespoły analityczne mogą tworzyć własne przekształcenia, ale każdy artefakt, który trafia do produkcyjnych modeli, musi przejść proces formalizacji i przejęcia przez data engineering.

Kto odpowiada za kod i środowisko uruchomieniowe modeli

Model to nie tylko plik z wagami, lecz cały łańcuch: kod przetwarzania, zależności, kontenery, konfiguracje. Jeśli odpowiedzialność jest niejasna, kończy się to sytuacją, w której nikt nie czuje się zobowiązany do utrzymywania „nudnych” części systemu.

Przejrzysty podział może wyglądać następująco:

• Data science:
  • pisze i utrzymuje kod logiki modelu (trening, ewaluacja, inferencja na poziomie funkcjonalnym),
  • odpowiada za replikowalność eksperymentów (notebooki, skrypty, konfiguracje treningu),
  • definiuje metryki jakościowe i testy walidujące poprawność predykcji.
• ML engineering / IT:
  • zarządza repozytoriami kodu, procesami code review, branchingiem,
  • buduje i utrzymuje pipeline CI/CD dla modeli,
  • przygotowuje i aktualizuje obrazy kontenerów, bibliotek, konfiguracje środowisk,
  • odpowiada za monitoring techniczny (czas odpowiedzi, błędy, zasoby).

Napięcia zmniejszają się, jeśli data science przyjmuje kilka zasad inżynierskich (testy jednostkowe krytycznych funkcji, trzymanie kodu w repozytoriach, minimalne standardy stylu), a IT akceptuje, że część eksperymentalna będzie naturalnie mniej „czysta” – ale do produkcji trafia tylko to, co przeszło pełny proces inżynierski.

Odpowiedzialność za monitoring jakości modeli

Monitoring modeli ma dwa wymiary: techniczny (czy system odpowiada, czy działa w SLA) i merytoryczny (czy model nadal ma sens biznesowy). Jeśli jeden z tych wymiarów zostanie opuszczony, problemy będą wychodzić dopiero przy skargach klientów lub audycie.

Przejrzysty podział ról może przyjąć formę „dwóch warstw” monitoringu:

• Warstwa techniczna – odpowiedzialność IT / ML engineering:
  • monitoring czasów odpowiedzi, błędów, dostępności endpointów,
  • alerty na poziomie infrastruktury (CPU, pamięć, kolejki),
  • zgodność z SLA, integracja z service desk i on-call.
• Warstwa merytoryczna – odpowiedzialność data science / biznes:
  • monitoring driftu danych i rozkładów predykcji,
  • regularne backtesty (porównanie predykcji z rzeczywistością),
  • analiza wpływu modelu na KPI biznesowe i wskaźniki ryzyka.

Dobrym rozwiązaniem jest wspólna tablica (dashboard) modeli, widoczna zarówno dla IT, jak i biznesu: w jednym miejscu widać stan techniczny, metryki modelu oraz KPI. Dzięki temu, jeśli np. spada skuteczność modelu, a infrastruktura działa poprawnie, rozmowa szybko przechodzi w stronę jakości danych, zmiany zachowań klientów i potrzeby retreningu – zamiast wzajemnego obwiniania się działów.

Proces decyzyjny przy incydentach związanych z modelem

Modele ML generują specyficzne incydenty: nagły spadek skuteczności, wzrost reklamacji klientów, podejrzenie biasu w decyzjach. Jeśli nie ma z góry określonego procesu, każda poważniejsza sytuacja kończy się ad hoc-ową „naradą kryzysową” i przerzucaniem się odpowiedzialnością.

Przejrzysty proces zwykle obejmuje kilka kroków:

1. Detekcja – alert pochodzi z monitoringu (technicznego lub merytorycznego) albo z kanałów biznesowych (np. skargi klientów). Ważne, aby punkt zgłoszenia był jeden – np. service desk, który klasyfikuje incydent jako „ML-model”.
2. Klasyfikacja – z góry zdefiniowane poziomy: np. incydent krytyczny (wpływ na regulacje, dużą grupę klientów), wysoki, średni, niski. Za klasyfikację odpowiada wspólnie przedstawiciel biznesu i IT, korzystając z prostych kryteriów opisanych w polityce modeli.
3. Decyzja o reakcji – kto może:
   • tymczasowo ograniczyć zakres modelu (np. tylko do części klientów),
   • wyłączyć model i przełączyć na rozwiązanie zastępcze (np. reguły),
   • zatwierdzić szybki hotfix modelu bez pełnego cyklu SDLC.

   Dobrze, jeśli istnieje „playbook incydentów ML” – proste scenariusze typu: „co robimy przy utracie danych treningowych”, „co robimy przy wykryciu silnego biasu”.

4. Post-mortem – po incydencie zespół mieszany (biznes, IT, data science, bezpieczeństwo) dokonuje analizy przyczyn, aktualizuje procedury i, jeśli trzeba, modyfikuje podział odpowiedzialności.

Przykład: po wykryciu, że model rekomendujący limity kredytowe działał przez kilka dni na niekompletnych danych dochodowych, firma analizuje, czemu monitoring nie złapał nagłej zmiany rozkładu danych. Efektem jest dopisanie dodatkowego alertu na brakujące pola kluczowe oraz doprecyzowanie, że data engineering ma obowiązek zgłaszać zmiany w źródłach do właścicieli modeli z wyprzedzeniem.

Model operacyjny: centralny zespół ML czy zespoły produktowe

Podział odpowiedzialności między IT a data science zależy również od modelu organizacyjnego. Inaczej działa firma z centralnym „centrem kompetencji ML”, a inaczej organizacja, w której modele są rozwijane w zespołach produktowych („squady”).

Można wyróżnić dwa skrajne podejścia:

• Model centralny:
  • istnieje dedykowany zespół ML w IT lub w pionie danych,
  • biznes zgłasza potrzeby, a zespół ML buduje modele i utrzymuje je,
  • łatwiej standaryzować narzędzia i procesy, ale trudniej o szybkość i dopasowanie do specyfiki produktów.
• Model zdecentralizowany (produktowy):
  • data scientists i ML engineers są częścią zespołów produktowych,
  • odpowiedzialność za modele jest bliżej biznesu i bieżących decyzji,
  • ryzyko duplikacji rozwiązań i braku spójnych standardów technicznych.

W praktyce najlepiej sprawdza się hybryda: centralny zespół ML/Platform, który:

• ustala standardy, procesy, narzędzia (plattformę MLOps, wspólne biblioteki),
• odpowiada za „ciężką” infrastrukturę (cluster, feature store, monitoring),
• wspiera zespoły produktowe w trudniejszych tematach (model governance, regulacje),

Najważniejsze punkty

• Machine learning to element procesu decyzyjnego biznesu, a nie „magiczny silnik IT” – technologia jest tylko narzędziem, a odpowiedzialność za decyzje i ryzyko musi być po stronie biznesu.
• Brak jasnego właściciela modeli prowadzi do „sierocych” rozwiązań w produkcji, konfliktów o priorytety między IT, biznesem i bezpieczeństwem oraz chaotycznych zmian modeli bez formalnej akceptacji.
• Źle poukładana odpowiedzialność za ML generuje nie tylko błędne decyzje biznesowe, lecz także poważne ryzyka regulacyjne, reputacyjne i bezpieczeństwa (np. brak wyjaśnialności, śladów audytowych, kontroli nad danymi).
• Trzeba rozróżnić trzy poziomy odpowiedzialności: za kod i infrastrukturę (IT/ML engineering), za dane (biznes, właściciele danych, bezpieczeństwo, compliance) oraz za skutki decyzji modelu (biznes i strategia firmy).
• Jeśli wszystkie te poziomy są wrzucone do „IT odpowiada za model”, organizacja traci możliwość sensownej dyskusji o ryzyku, kompromisach i zasadach akceptacji decyzji podejmowanych przez modele.
• Zdrowy model governance zakłada: ML jako narzędzie decyzyjne w rękach biznesu, utrzymywane i standaryzowane przez IT, z nadzorem bezpieczeństwa nad ryzykiem, integracjami i ochroną danych.
• Dla IT modele ML są kolejnym typem obciążenia operacyjnego, więc bez standardów, budżetu i jasnych ról powstają rozwiązania „na dziko”, które są trudne do utrzymania i zwiększają powierzchnię ataku.

Źródła

• OECD Principles on Artificial Intelligence. Organisation for Economic Co-operation and Development (2019) – Zasady odpowiedzialnego AI, governance, rola interesariuszy
• Ethics Guidelines for Trustworthy AI. European Commission High-Level Expert Group on AI (2019) – Wytyczne dot. odpowiedzialności, nadzoru i ryzyka systemów AI/ML
• The EU Artificial Intelligence Act. European Union (2024) – Ramy regulacyjne, odpowiedzialność biznesu, IT i compliance za systemy AI
• NIST AI Risk Management Framework. National Institute of Standards and Technology (2023) – Zarządzanie ryzykiem AI, role organizacyjne, lifecycle modeli
• ISO/IEC 22989: Artificial intelligence — Concepts and terminology. International Organization for Standardization (2022) – Podstawowe pojęcia AI/ML, kontekst decyzyjny i organizacyjny
• Model Risk Management Guidance. Board of Governors of the Federal Reserve System (2011) – Zarządzanie ryzykiem modeli, właścicielstwo, walidacja, nadzór