AI SDLC, czyli jak wytwarzać AI bezpiecznie i efektywnie

Michał Nowakowski · 10 sierpnia 2026

Dość często w swoich szkoleniach mówię o czymś takim jak Software Development Life Cycle, czyli właśnie ⚠️ SDLC ⚠️ . A czym to właściwie jest?

AI SDLC. Uczę tego w szkole i na studiach, a wszystko to jak krew w piach... SDLC or not to SDLC.

Mocno zacząłem, ale już łagodzę. Dość często w swoich szkoleniach mówię o czymś takim jak Software Development Life Cycle, czyli właśnie ⚠️ SDLC ⚠️ . Budzi to zazwyczaj ciekawość, trochę strach (szczególnie, jeżeli jesteśmy nieco mniej "techniczni), czasami prawdziwą ekscytację (jeżeli jednak bliżej nam do inżyniera).

Warto więc, żebyśmy spróbowali przez to przebrnąć i umiejscowić w "przestrzeni" AI Governance. A dlaczego? Dlatego, że to właściwie kluczowy element całego procesu, który obsługujemy zarządzając projektowaniem, rozwijaniem i stosowaniem różnych rozwiązań AI & Data w naszej organizacji. I dlatego, że prawidłowe zarządzanie ryzykiem AI od nas tego wymaga.

Typowy proces SDLC 👨🏻‍💻 zakłada, że wykonujemy "jakieś" działania w ramach 5-8 typowych faz, z których każda ma swoją specyfikę, ale też interesariuszy i osoby odpowiedzialne (w idealnym stanie jest to spięte z matrycą SDLC). Każda też sprowadza na nas inne problemy i wyzwania, które nie zawsze udaje się nam rozwiązać.

💥 Co ciekawe 💥, wielu developerów jako jeden z głównych blokerów realizacji inicjatyw wskazuje słabo przygotowane wymagania biznesowe i projektowe, bo najczęściej ludzie z biznesu przychodzą do IT i mówią "weź i zrób". No, a tak to nie działa. No może czasami, ale słabo.

W każdym razie każdy etap powinien mieć przypisane konkretne zadania i osoby, które je wykonują. Ktoś powinien z kolei weryfikować czy jest to rzeczywiście realizowane, choć - w praktyce - jest to dość często wolna amerykanka. Winę za to ponosić może wiele stron, więc nie szukajmy zbyt długo.

I teraz pojawia się AI Governance. W modelowym podejściu wzmocnionym o aspekty AI wymagamy więcej. Nie ma znaczenia czy patrzymy na ISO 42001 czy AI Act, albo nawet na oba "standardy". Nasz proces wytwórczy musi zwiększyć się o kolejne AI checkpoints ✅ ❌. Te punkty stają się o tyle istotne, że mogą jednocześnie stanowić bramki decyzyjne, ergo "niezaliczenie" może doprowadzić do tego, że projekt nie przejdzie do kolejnej fazy. I dlatego często w powietrzu czuć opór.

No bo jak to? Kolejne utrudnienia, jak chociażby checklisty AI Act? Dodatkowe wymagania w zakresie ryzyk (AI)? Kolejne mapowanie zasobów? Ehh, komu by się chciało.

No właśnie, tylko że AI Governance w sensie operacyjnym wymaga, aby nie ograniczać się tylko do modyfikacji dokumentu i procesu, ale też kontroli nad realizacją. Osoba wyznaczona do koordynacji, np. AI Steward, będzie tutaj czuwała nad tym czy 🎯 wszyscy wszystko 🎯 zrobili, a jeżeli nie to przyciśnie.

Mało tego - AI Governance będzie kładło nacisk na weryfikację tego z czego korzystamy tworząc kod, integrując go z systemami czy w inny sposób wspomagając się w przygotowywaniu rozwiązań - czyli taka kontrola Shadow AI. A tego to już za wiele...

Zainteresowani pogłębieniem? Dajcie znać!

Grafika przygotowana na bazie własnych materiałów i przy wsparciu Sonnet 5.0.