ENISA o SDLC z użyciem AI. Jak robić dobry kod?

Michał Nowakowski · 18 września 2026

ENISA opublikowała dokument o wytwarzaniu oprogramowania z użyciem AI i w kontekście bezpieczeństwa. Co tam znajdziemy?

Claude, napisz kod tak, żeby był bezpieczny. Uwzględnij wszystkie aspekty bezpieczeństwa. No i fru, na produkcję. Czy prawnicy, ludzie od ryzyka i bezpieczeństwa informacji powinni wiedzieć co dzieje się w IT?

IT powie, że nie. Ryzyko powie, że tak, ale... A ENISA mówi wprost - musi być jakiś governance, a agenci AI i rozwiązania asystujące przy tworzeniu kodu czy development'cie nie mogą być pozbawione kontroli. Ba, powinny podlegać surowym regułom, jeżeli chcemy, aby były bezpieczne.

Dokument ENISA Technical Advisory on AI-assisted software development ma dopiero numerek 0.4, ale już czuje, że będzie czymś naprawdę ważnym w kontekście zarządzania rozwojem IT, nie tylko AI. Ma on szerszy charakter niż projekty "ejajowe", po prostu wskazuje jak powinien wyglądać modelowy proces SDLC (wytwarzania oprogramowania) wspomagany różnymi rozwiązaniami AI.

Znajdziemy tam zarówno wątki techniczne, jak i te prawne, w tym wprost wskazanie, że takie podejście to de facto zapewnienie zgodności z CRA, czyli rozporządzeniem określającym wymogi cyberbezpieczeństwa dla produktów z elementami cyfrowymi, w tym oprogramowania. No i jest ta warstwa governance, która coraz bardziej zyskuje na znaczeniu.

Dokument jest więc zarówno dla "technicznych, jak i zespołów wsparcia. Ja, jak dobrze wiecie, dużo mówię i piszę o SDLC w kontekście AI Governance, więc szczerze ucieszyła mnie ta publikacja.

Co możemy z niej wyciągnąć (szykuję też felieton, gdzie wejdziemy w większe szczegóły):

✅ kod, który tworzymy z użyciem lub wsparciem AI musi podlegać takim samym regułom jak ten ludzki, nie ma tutaj taryfy ulgowej.

✅ wszystko co wykorzystujemy w kontekście "AI-assisted development", a więc np. "skille" czy MCP (protokoły do komunikacji) są elementem łańcucha dostaw (tutaj kłania się też ustawa o krajowym systemie cyberbezpieczeństwa) i muszą podlegać weryfikacji pod kątem zaufania, zatwierdzania i przeglądu,

✅ możemy sobie prosić o potwierdzenia bezpieczeństwa, które generują nam narzędzia, ale jeżeli nie mamy na to dowodów, to jest to "oświadczenie" bez realnego pokrycia,

Realizując zalecenia ENISA powinniśmy opierać się na czteroetapowym schemacie działania, tj. IDENTYFIKACJA (proces, problem, wymagania), SPECYFIKACJA (jawnie i powtarzalnie), WERYFIKACJA (przegląd, zatwierdzenie i kontrolki adekwatne do ryzyk) oraz UTRWALANIE (zebranie i przechowywanie dowodów).

Tak więc bez zrozumienia procesów wytwórczych (czym są commity, pull requesty etc.) trudno może być nam dobrze doradzać i zachować kontrolę. Oczywiście IT, potencjalnie, lepiej pracuje jak się nie przeszkadza, ale jeżeli bierzemy pod uwagę ryzyko dla organizacji, które generują systemy agentowe i asystenci, to sprawa robi się "systemowa".

Pytanie do Was - czy ta tematyka jest dla Was na tyle ciekawa, abyście chcieli o niej posłuchać w duecie prawnik-inżynier? Czy może znowu moje wyobrażenia o potrzebach kompetencyjnych są dalekie od rzeczywistości?