Blog / frontpage / Wpisy

Modele dojrzałości AI w firmach i organizacjach

Modele dojrzałości AI pomagają odróżnić realny rozwój organizacji od pozornej adopcji nowych narzędzi. Wokół AI bardzo łatwo zbudować fałszywe poczucie postępu.

W wielu organizacjach wygląda to podobnie:

  • pojawia się nowe narzędzie,
  • ludzie dostają dostępy,
  • część zespołu zaczyna generować kod szybciej niż wcześniej,
  • rośnie liczba eksperymentów, a wraz z nią przekonanie, że firma “wchodzi na wyższy poziom”.

Na poziomie codziennej obserwacji to może wyglądać imponująco:

  • szybciej powstają PR/MR (czyli pull requesty/merge requesty),
  • szybciej pojawiają się testy,
  • szybciej ktoś przygotowuje streszczenie wymagań albo draft dokumentacji.

Problem polega na tym, że szybsza aktywność nie musi jeszcze oznaczać dojrzalszego systemu delivery. Organizacja może szybciej generować kod, testy, dokumentację i pomysły, a jednocześnie zwiększać koszt walidacji, refaktoryzacji, ryzyko błędów i chaos decyzyjny.

DORA (DevOps Research and Assessment) pokazuje, że AI działa przede wszystkim jako amplifier, czyli wzmacnia istniejące mocne i słabe strony organizacji, a skuteczna adopcja AI jest bardziej problemem systemu organizacyjnego niż samego narzędzia. (dora.dev)

To ważne rozróżnienie.

Właśnie dlatego modele dojrzałości AI są przydatne. Pomagają sprawdzić, czy organizacja rozwija swoje zdolności, czy tylko zwiększa liczbę narzędzi, eksperymentów i wygenerowanych zmian.

Bo jeśli organizacja ma już mocne podstawy – dobre review, uporządkowane repozytoria, sensowny CI/CD, spójne standardy, czytelną dokumentację, dostęp do właściwych danych i kulturę pracy na małych batchach – AI może przyspieszyć i poprawić pracę. Ale jeśli organizacja działa chaotycznie, ma słabą dokumentację, niespójne praktyki, niejasne reguły i nie potrafi mierzyć jakości zmian, AI równie dobrze może tylko szybciej produkować więcej kodu, więcej zmian i więcej pozornie “dobrych” rezultatów. Ten kierunek bardzo mocno wspierają zarówno DORA, jak i nowsze materiały GitHub czy CircleCI, które podkreślają, że szybkość tworzenia kodu nie rozwiązuje automatycznie problemu walidacji, integracji i bezpiecznego dostarczania oprogramowania. (dora.dev)

I właśnie dlatego coraz częściej pojawia się pytanie nie tylko o to, czy organizacja używa AI, ale raczej o to, na ile robi to świadomie, bezpiecznie, powtarzalnie i w sposób przynoszący realną wartość. (services.google.com)

Jeśli chcesz praktycznie rozwijać umiejętności związane z AI w testowaniu, sprawdź też AI_Testers (aitesters.pl) – Program który został przygotowany z myślą o wykorzystaniu AI w pracy testerów, automatyzacji i nowoczesnym podejściu do jakości.

Czym są modele dojrzałości AI?

Czym są modele dojrzałości AI?

Model dojrzałości to nic skomplikowanego.

To po prostu sposób na opis tego, jak organizacja się rozwija w danym obszarze – od działań chaotycznych, przez pierwsze standardy, aż do czegoś bardziej systemowego. W praktyce taki model nie służy tylko do “nadania poziomu”. Jego wartość polega na tym, że pomaga organizacji odpowiedzieć na kilka prostych pytań:

  • gdzie jesteśmy dzisiaj,
  • czego nam jeszcze brakuje,
  • jakie ryzyka ignorujemy i
  • jakie kolejne kroki mają sens.

AWS opisuje swój model generative AI jako framework, który ma pomóc organizacjom ocenić bieżący poziom dojrzałości, zidentyfikować focus areas i zaplanować kolejne etapy adopcji. (AWS Documentation)

W kontekście AI takie modele są szczególnie potrzebne, bo bardzo łatwo pomylić widoczność AI z dojrzałością AI. Warto jednak uważać, bo pod hasłem model dojrzałości AI często mieszają się różne perspektywy:

  • AWS pomaga opisać etapy adopcji,
  • DORA pokazuje zdolności organizacyjne i inżynierskie, które wzmacniają efekt AI,
  • NIST daje ramę do zarządzania ryzykiem AI,
  • Microsoft szczególnie dobrze opisuje dojrzałość w kontekście agentic AI, czyli systemów AI działających z większą autonomią.

Dopiero połączenie tych perspektyw daje pełniejszy obraz dojrzałości.

Organizacja może mieć wiele promptów, wielu użytkowników, dużo eksperymentów, dużą liczbę generowanych zmian i sporo entuzjazmu – a jednocześnie nadal być mało dojrzała, jeśli brakuje jej zasad użycia, governance (czyli zasad zarządzania i nadzoru), uporządkowanych danych, dostępnego kontekstu, sensownego modelu operacyjnego i metryk pokazujących, czy AI poprawia wyniki. To dobrze współgra z podejściem AWS, DORA i NIST – sama adopcja narzędzia nie wyczerpuje pojęcia dojrzałości AI. (services.google.com)

Jak patrzeć na modele dojrzałości AI?

W praktyce modele dojrzałości AI warto traktować jak zestaw perspektyw, a nie jedną uniwersalną drabinę, po której każda organizacja wspina się w taki sam sposób. Gdy mówimy o dojrzałości AI, bardzo łatwo mieszamy różne pojęcia na raz.

Najlepiej zobaczyć to na trzech perspektywach.

Dojrzałość jako etapy wdrożenia

To najbardziej naturalne podejście. Organizacja przechodzi od pierwszej świadomości, przez eksperymenty, do realnych wdrożeń, aż wreszcie do skali. AWS opisuje to jako Envision → Experiment → Launch → Scale (czyli Wyobraźnia → Eksperyment → Wdrożenie → Skala). Microsoft w nowszym modelu adopcji agentic AI również pokazuje dojrzewanie etapowe. Warto jednak traktować go jako model dla organizacji, które przechodzą od prostego użycia asystentów AI do bardziej autonomicznych agentów AI osadzonych w różnych procesach biznesowych i technicznych. (AWS Documentation)

To podejście odpowiada na jedno proste pytanie:

“Na którym etapie ścieżki wdrażania AI jesteśmy?”

Dzięki niemu widać, czy dopiero eksplorujemy możliwości, czy już robimy piloty, czy mamy produkcyjne wdrożenia w działaniu. (AWS Documentation)

Dojrzałość jako zestaw zdolności

Ta perspektywa wygląda mniej oczywista, ale jest znacznie bardziej przydatna. Nie pyta o kolejny etap, tylko: czy mamy zdolności potrzebne do tego, żeby AI działało naprawdę dobrze?

DORA nie proponuje prostego modelu poziom 1–4. Zamiast tego pokazuje zestaw zdolności, które sprawiają, że AI może wzmacniać organizację. Wśród nich są między innymi:

  • jasna polityka AI,
  • zdrowy ekosystem danych,
  • dobra platforma wewnętrzna,
  • praca na małych zmianach,
  • skuteczny version control,
  • dostęp AI do właściwego kontekstu,
  • koncentracja na użytkowniku. (services.google.com)

To zmienia całą dyskusję z:

“Czy używacie AI?”

na:

“Czy zbudowaliście środowisko, w którym AI rzeczywiście może działać lepiej?”

I to jest ważne, bo zespoły wiele lat temu zdały sobie sprawę z czegoś oczywistego: narzędzia same nie naprawiają słabych procesów. Dobre CI/CD nie naprawi złej architektury. Dobry test runner nie naprawi słabych testów. I dokładnie tak samo – AI nie naprawi chaotycznego systemu pracy. Tylko go uwydatni. (services.google.com)

Dojrzałość jako governance, ryzyko i kontrola

Trzecia perspektywa nie patrzy na adopcję, tylko na zarządzanie ryzykiem i odpowiedzialnością. NIST AI Risk Management Framework rozbija zarządzanie ryzykiem AI na cztery funkcje: Govern, Map, Measure, Manage. Governance nie jest tam osobnym dodatkiem na końcu procesu, ale funkcją, która przenika sposób identyfikowania, mierzenia i zarządzania ryzykiem AI. (NIST)

Tu pytamy (Microsoft Learn):

  • czy rozumiemy zagrożenia związane z AI?
  • czy wiemy, jak nimi zarządzać?
  • czy governance jest wbudowany w decyzje, a nie tylko teoretyczny?
  • czy widać, co robi system AI i czy możemy go zmierzyć?
  • czy rosnąca autonomia idzie w parze z odpowiedzialnością?
Gdzie w modelach dojrzałości AI mieści się crawl, walk, run

Czy “crawl, walk, run” to model dojrzałości AI?

W rozmowach o wdrażaniu technologii często pojawia się prosta rama: crawl, walk, run. Dosłownie oznacza to: najpierw raczkujemy, potem chodzimy, a dopiero później biegniemy.

Ta metafora jest popularna, bo dobrze opisuje naturalny sposób dojrzewania organizacji. Firmy rzadko przechodzą od zera do pełnej transformacji jednym ruchem. Najpierw uczą się podstaw, później testują pierwsze przypadki użycia, następnie włączają nowe rozwiązania do realnych procesów, a dopiero na końcu próbują je skalować.

Warto jednak doprecyzować jedną rzecz: crawl, walk, run może być modelem dojrzałości w niektórych dziedzinach, ale w kontekście AI lepiej traktować go jako praktyczną ramę etapowej adopcji, a nie jako pełny model dojrzałości AI.

Przykładowo w FinOps rama crawl, walk, run jest używana wprost jako sposób opisu poziomów dojrzałości. Organizacja zaczyna od prostych działań, później rozwija procesy i odpowiedzialność, a następnie przechodzi do bardziej zaawansowanego, mierzalnego i zoptymalizowanego zarządzania. Więcej można przeczytać w dokumentacji FinOps Foundation: FinOps Maturity Model.

W obszarze AI sytuacja jest trochę inna. Sama metafora crawl, walk, run jest bardzo użyteczna, ale nie odpowiada na wszystkie pytania, które powinien obejmować model dojrzałości AI. Nie mówi wystarczająco dużo o jakości danych, governance, bezpieczeństwie, odpowiedzialności człowieka, obserwowalności agentów, ryzyku ani metrykach wpływu na delivery.

Dlatego w tym artykule traktuję crawl → walk → run → scale jako pomost między formalniejszymi modelami a codzienną pracą zespołów software’owych. AWS pomaga opisać etapy adopcji generative AI. DORA pokazuje zdolności organizacyjne, które wzmacniają albo osłabiają efekt AI. NIST porządkuje temat ryzyka i governance. Microsoft pomaga zrozumieć wyższy poziom dojrzałości związany z agentic AI i zarządzaniem bardziej autonomicznymi workflow.

W takim ujęciu crawl, walk, run nie zastępuje tych modeli. Pomaga je uprościć i przełożyć na język praktyki.

Można to rozumieć tak:

  • crawl – organizacja uczy się AI, testuje pierwsze narzędzia i szuka sensownych zastosowań,
  • walk – organizacja wybiera konkretne pilotaże, ustala pierwsze zasady i zaczyna mierzyć efekty,
  • run – AI trafia do realnego procesu delivery, ale nadal działa w ramach review, testów, quality gates i odpowiedzialności człowieka,
  • scale – AI staje się zdolnością organizacyjną, wspieraną przez standardy, governance, reusable patterns, monitoring i wspólne platformy.

To rozróżnienie jest ważne, bo chroni przed zbyt prostym myśleniem o dojrzałości AI. Organizacja może być na etapie “run”, jeśli chodzi o liczbę używanych narzędzi, a jednocześnie nadal być niedojrzała pod względem governance, jakości danych, odpowiedzialności i mierzenia wpływu.

Innymi słowy: można szybko biec, ale w złym kierunku.

Dlatego crawl, walk, run dobrze pokazuje tempo adopcji, ale nie wystarcza do pełnej oceny dojrzałości. Do tego potrzebne są dodatkowe pytania:

  • czy organizacja ma jasne zasady użycia AI?
  • czy wie, jakie dane mogą trafiać do modeli?
  • czy AI działa w ramach istniejących procesów jakości?
  • czy człowiek nadal odpowiada za ważne decyzje?
  • czy mierzymy wpływ AI na delivery, a nie tylko aktywność?
  • czy potrafimy zatrzymać, poprawić albo wycofać działanie agenta lub automatyzacji?
  • czy skala AI nie oznacza po prostu skali chaosu?

Dopiero połączenie tych perspektyw daje sensowny obraz dojrzałości.

Dlatego w dalszej części artykułu używam crawl → walk → run → scale jako praktycznej mapy dla zespołów software’owych, ale z ważnym zastrzeżeniem: każdy kolejny etap ma sens tylko wtedy, gdy za większą aktywnością AI idzie większa zdolność organizacji do kontroli, pomiaru i odpowiedzialnego dostarczania wartości.

Co łączy większość modeli dojrzałości AI?

Mimo różnych nazw, większość sensownych modeli mówi podobną rzecz: organizacje przechodzą od rozpoznania, przez piloty, do wdrażania, aż do powtarzalnej skali. AWS mówi to jasno. Microsoft mówi o dojrzewaniu równoległym. DORA pokazuje, że sam plan nie wystarczy bez odpowiednich zdolności. (AWS Documentation)

Prosty wniosek leży na powierzchni:

Dojrzałość AI to nie pytanie o samą obecność AI, tylko o jakość środowiska, w którym AI działa. (dora.dev)

Przykłady poziomów dojrzałości AI

Przykłady poziomów dojrzałości AI

Żeby modele dojrzałości AI nie zostały tylko teorią, warto przełożyć je na konkretne poziomy widoczne w codziennej pracy organizacji. Nie chodzi jednak o przepisanie jednego modelu od jednego dostawcy. Lepsze podejście to połączenie kilku perspektyw:

Dlatego poniższe poziomy warto traktować jako praktyczny, syntetyczny model dla organizacji software’owych, a nie jako kopię jednego frameworka.

Poziom 1: Świadomość i indywidualne eksperymenty

Na tym poziomie AI pojawia się głównie jako narzędzie pojedynczych osób. Developerzy używają asystentów do generowania kodu, testerzy proszą o szkice testów, PM-owie streszczają wymagania, a liderzy próbują zrozumieć, co AI może zmienić w pracy zespołów.

To etap potrzebny, ale jeszcze mało dojrzały. Organizacja często nie ma wspólnych zasad, metryk, polityki użycia AI ani jasnej odpowiedzialności za wyniki pracy wspieranej przez AI.

Z perspektywy AWS to przypomina etap Envision, czyli budowanie świadomości, poznawanie możliwości generative AI i identyfikowanie pierwszych use case’ów. Więcej: AWS – Level 1: Envision.

Z perspektywy DORA ważne jest jednak pytanie, czy organizacja ma już fundamenty, które pozwolą AI wzmacniać dobre praktyki, zamiast przyspieszać chaos. Więcej: DORA AI Capabilities Model.

Typowe sygnały tego poziomu:

  • dużo indywidualnych prób,
  • brak wspólnych zasad użycia AI,
  • brak jasnych ograniczeń dotyczących danych,
  • brak mierzenia wpływu,
  • entuzjazm większy niż kontrola.

Poziom 2: Pilotaże i pierwsze zasady

Na drugim poziomie organizacja zaczyna porządkować eksperymenty. Zamiast używać AI “do wszystkiego”, wybiera kilka konkretnych use case’ów: wsparcie code review, generowanie testów, analiza dokumentacji, triage błędów, praca z legacy albo wsparcie analizy wymagań.

Pojawiają się pierwsze zasady: czego nie wolno wysyłać do modeli, które zadania wymagają human review, jakie narzędzia są dopuszczone i kto odpowiada za efekt końcowy. To moment, w którym AI przestaje być tylko ciekawostką, a zaczyna być kontrolowanym eksperymentem.

AWS opisuje podobny etap jako Experiment, czyli pilotaże, budowanie pierwszych kompetencji i tworzenie podstaw governance. Więcej: AWS – Level 2: Experiment.

DORA dodałaby pytanie o zdolności: czy mamy dobre repozytoria, version control, małe zmiany, platformę wewnętrzną i dane, które pozwalają AI działać sensownie? Więcej: DORA State of AI-assisted Software Development 2025.

NIST dodałby pytanie o ryzyko: czy wiemy, jakie zagrożenia tworzą te use case’y i jak je mierzymy? Więcej: NIST AI RMF – Govern, Map, Measure, Manage.

Typowe sygnały tego poziomu:

  • wybrane use case’y zamiast chaotycznego użycia,
  • pierwsza polityka użycia AI,
  • pierwsze zasady pracy z danymi,
  • obowiązkowy human review dla wybranych zadań,
  • pierwsze próby mierzenia efektów.

Poziom 3: AI w realnym procesie delivery

Na trzecim poziomie AI staje się częścią codziennego procesu delivery. Nie działa już obok procesu, ale wewnątrz niego: w analizie wymagań, przygotowaniu testów, code review, pracy z dokumentacją, refaktoryzacji, triage błędów albo analizie ryzyka zmian.

Najważniejsze jest jednak to, że AI nie zastępuje procesu jakości. Wygenerowane zmiany przechodzą przez review, testy, quality gates, zasady bezpieczeństwa i odpowiedzialność człowieka. Organizacja zaczyna mierzyć nie tylko adopcję, ale wpływ na system: rework, defekty, czas review, stabilność wdrożeń, koszt AI i jakość decyzji.

AWS widziałby tu przejście do wdrożeń produkcyjnych, czyli poziom Launch. Więcej: AWS – Overview of maturity levels.

DORA patrzyłaby na to przez pryzmat wpływu na delivery i zdolności organizacyjne. Więcej: DORA State of AI-assisted Software Development 2025.

GitHub dobrze uzupełnia tę perspektywę w kontekście AI-assisted code review: AI może pomagać, ale odpowiedzialność za merge i decyzje architektoniczne zostaje po stronie człowieka. Więcej: GitHub – Code review in the age of AI.

Typowe sygnały tego poziomu:

  • AI działa w istniejącym workflow,
  • są quality gates dla zmian wspieranych przez AI,
  • review nie jest pomijane,
  • organizacja mierzy rework, defekty i stabilność,
  • zespoły wiedzą, gdzie AI pomaga, a gdzie zwiększa ryzyko.

Poziom 4: Standaryzacja i skala

Na czwartym poziomie organizacja przestaje wdrażać AI osobno w każdym zespole od zera. Pojawiają się wspólne standardy, reusable patterns, katalog sprawdzonych use case’ów, wewnętrzne platformy, wspólne guardrails, monitoring kosztów i jasne zasady odpowiedzialności.

AI staje się zdolnością organizacyjną. Zespoły nie wymyślają wszystkiego od nowa, tylko korzystają ze wspólnych wzorców, dokumentacji, polityk, narzędzi i mechanizmów kontroli.

AWS dobrze opisuje ten poziom jako Scale, czyli standaryzację, automatyzację, reużywalne komponenty i obserwowalność w skali. Więcej: AWS – Level 4: Scale.

DORA przypomina jednak, że skala bez zdrowych danych, dobrej platformy i małych zmian może tylko szybciej rozprzestrzeniać problemy. Więcej: DORA AI capabilities.

NIST dokłada tu wymiar governance: organizacja musi wiedzieć, jakie ryzyka skaluje razem z AI i jak nimi zarządza. Więcej: NIST AI Risk Management Framework.

Typowe sygnały tego poziomu:

  • wspólne wzorce promptów i workflow,
  • centralne standardy użycia AI,
  • katalog use case’ów i narzędzi,
  • monitoring kosztów i jakości,
  • powtarzalne guardrails,
  • jasna odpowiedzialność za rozwiązania AI.

Poziom 5: Agentic AI i zarządzana autonomia

Najwyższy poziom nie oznacza po prostu “więcej AI”. Oznacza, że organizacja potrafi bezpiecznie zarządzać bardziej autonomicznymi workflow. AI nie tylko podpowiada, ale może wykonywać zadania w narzędziach, analizować dane, proponować decyzje, uruchamiać procesy albo współpracować z innymi agentami.

To wymaga znacznie większej dojrzałości niż zwykłe korzystanie z asystenta AI. Potrzebne są: kontrola dostępu, audyt działań, obserwowalność, lifecycle management, klasyfikacja ryzyka, human oversight i możliwość szybkiego zatrzymania lub skorygowania działania systemu.

Tutaj szczególnie przydatny jest Microsoftowy model agentic AI, bo pokazuje, że im większa autonomia, tym ważniejsze stają się security, governance, operations, lifecycle management i odpowiedzialność. Więcej: Microsoft – Agentic AI Adoption Maturity Model.

Warto też uzupełnić ten poziom o perspektywę operations i lifecycle management dla agentów. Więcej: Microsoft – Agentic AI maturity model: Operations and lifecycle management.

Typowe sygnały tego poziomu:

  • agenci działają w jasno określonych granicach,
  • każdy agent ma właściciela i cel,
  • działania agentów są logowane i audytowalne,
  • istnieje lifecycle management dla agentów,
  • organizacja ma zasady wyłączania, poprawiania i monitorowania agentów,
  • większa autonomia idzie w parze z większą kontrolą.

Warto podkreślić: poziomy dojrzałości nie są konkursem na to, kto szybciej dojdzie do agentów. Dla wielu organizacji rozsądnym celem może być stabilny poziom 2 lub 3, jeśli AI wspiera konkretne procesy, daje mierzalną wartość i nie zwiększa niekontrolowanie ryzyka. Poziom 4 lub 5 ma sens dopiero wtedy, gdy organizacja ma wystarczająco dobre dane, standardy, governance, platformę i kulturę odpowiedzialności.

Jak przełożyć modele dojrzałości AI na realia zespołów software’owych?

Na poziomie zespołów software’owych model crawl → walk → run → scale jest nadal bardzo użyteczny – jako praktyczne przełożenie szerszych modeli na język delivery teams.

Crawl – eksploracja i pierwsze zastosowania

To etap, w którym zespół dopiero sprawdza, do czego AI może się przydać. Typowe przykłady:

  • generowanie prostych fragmentów kodu,
  • streszczanie dokumentacji,
  • propozycje refaktoryzacji,
  • szkice testów,
  • prototypy rozwiązań,
  • pierwsze podpowiedzi przy code review.

To etap poznawania możliwości i ograniczeń. AWS opisuje swój poziom Envision właśnie jako moment budowania świadomości, poznawania koncepcji generative AI i identyfikacji potencjalnych use case’ów. (AWS Documentation)

W realnym zespole ten etap wygląda często tak:

  • jeden developer testuje AI do generowania boilerplate,
  • ktoś używa modelu do zrozumienia starszego fragmentu kodu,
  • tester prosi AI o szkic scenariuszy testowych,
  • PM prosi model o skrót specyfikacji albo listę pytań do wymagań.

To jest potrzebne i wartościowe, ale jeszcze nie oznacza dojrzałości. To bardziej etap uczenia się, gdzie AI pomaga oswoić nowe możliwości, ale organizacja nie ma jeszcze spójnych reguł, standardów i oczekiwań. (AWS Documentation)

Dobrą praktyką na tym poziomie jest trzymanie się mocnych fundamentów: review, linting, testy, małe batch’e, CI i podstawowe quality gates. DORA nadal wskazuje version control, small batches i quality internal platforms jako praktyki, które wzmacniają efekt osiągane z AI. (services.google.com)

Warto też spojrzeć na ten temat z perspektywy strategii testowania. W artykule Piramida testów 2.0 – co AI zmienia w testowaniu? (Piramida testów 2.0) pokazuję, jak AI wpływa na podejście do testów, automatyzacji i jakości w nowoczesnym software delivery.

Walk – pilotaże, zasady i pierwsze ramy operacyjne

Na tym etapie organizacja zaczyna przechodzić od ciekawości do bardziej świadomego eksperymentowania. AWS opisuje poziom Experiment jako fazę pilot projects, budowania internal capabilities i governance frameworks. (AWS Documentation)

W praktyce może to wyglądać tak:

  • zespół wybiera 2–3 konkretne use case’y, zamiast używać AI “do wszystkiego”,
  • powstają pierwsze zasady: czego nie wrzucamy do modeli, jakie dane są zabronione, które zadania wymagają obowiązkowego human review,
  • ktoś zaczyna porządkować README, ADR-y i standardy kodu, żeby AI miało lepszy kontekst,
  • zespół porównuje, czy AI realnie skraca czas pracy lub poprawia jakość w wybranych obszarach.

To etap, w którym bardzo szybko wychodzi prawda o organizacji. Jeśli dokumentacja jest słaba, repozytoria niespójne, standardy niejawne, a wiedza ukryta w głowach ludzi, AI nie zrobi cudu. Co najwyżej szybciej wygeneruje więcej zmian, które potem trudniej zweryfikować. DORA dokładnie tak opisuje rolę AI jako wzmacniacza istniejących warunków. (dora.dev)

To także dobry moment na pierwsze mechanizmy kontrolne. GitHub w tekstach o jakości w erze AI i o code review podkreśla potrzebę clear guidelines, visible thinking, clear escalation paths i tego, by to ludzie nadal odpowiadali za merge button i decyzje architektoniczne. (The GitHub Blog)

Run – AI jako część realnego delivery

Na tym etapie AI przestaje być dodatkiem obok procesu i staje się częścią procesu. AWS opisuje poziom Launch jako fazę produkcyjnych wdrożeń, integracji, monitoringu oraz większej kontroli nad modelem, danymi i zachowaniem systemu. (AWS Documentation)

W praktyce software team może wtedy wykorzystywać AI do:

  • wsparcia tworzenia kodu i review,
  • analizy wymagań i wykrywania braków lub niejednoznaczności,
  • pomocy przy pracy z legacy,
  • generowania propozycji testów,
  • wspierania triage błędów,
  • przeszukiwania repo, wiki i dokumentacji w celu odnalezienia właściwego kontekstu.

Tu bardzo dobrze widać, że dojrzałość nie polega już na samym “używamy AI”, tylko na tym, czy AI:

  • działa w ramach ustalonych zasad,
  • ma dostęp tylko do potrzebnego kontekstu,
  • przechodzi przez istniejące quality gates,
  • zostawia ślad decyzji, rekomendacji lub wygenerowanych zmian,
  • jest monitorowane pod kątem jakości, kosztu, ryzyka i wpływu na delivery,
  • jest mierzone przez wartość, a nie tylko aktywność. (AWS Documentation)

Dobrym, konkretnym przykładem dojrzałego przejścia na tym etapie są praktyki typu AI-assisted code review z jasno ustawionymi regułami i odpowiedzialnością człowieka za decyzję końcową. GitHub opisuje, że AI review najlepiej sprawdza się jako wsparcie w pull request workflow, ale nadal wymaga jasnych wytycznych, zasad zaufania do feedbacku i ludzkiej odpowiedzialności za merge. GitHub podaje też, że Copilot code review jest osadzony bezpośrednio w istniejącym workflow pull requestów i ma pomagać w wykrywaniu błędów, poprawie czytelności i przyspieszeniu feedbacku. (The GitHub Blog)

Scale – AI jako zdolność organizacji, a nie pojedyncze wdrożenie

Na poziomie Scale organizacja wychodzi poza pojedyncze wdrożenia i zaczyna budować powtarzalny system. AWS opisuje ten etap jako moment tworzenia reużywalnych komponentów, wzorców, zautomatyzowanych procesów i frameworków wspomagających obserwowalność. (AWS Documentation)

W praktyce oznacza to na przykład:

  • wspólne wzorce promptów i review,
  • platformy z wbudowanymi guardrails,
  • centralne polityki i standardy,
  • zautomatyzowane monitorowanie jakości i kosztu,
  • reusable patterns dla typowych use case’ów,
  • lepsze zarządzanie cyklem życia agentów i AI workflows.

Microsoft w modelu agentic AI podkreśla, że wraz ze wzrostem autonomii i skali potrzebne są jednocześnie silniejsze mechanizmy kontroli i zarządzania. Wysoka dojrzałość oznacza tam między innymi obserwowalność zachowania agentów, jasno zdefiniowane prawa decyzyjne, nadzór człowieka i standardy obowiązujące w całej organizacji. (Microsoft Learn)

AI przestaje być zbiorem indywidualnych trików i staje się częścią systemu inżynierskiego.

UWAGA: Na tym poziomie pojawia się też nowe ryzyko: organizacja może zacząć tworzyć dziesiątki agentów, promptów, automatyzacji i integracji bez jasnego właściciela, cyklu życia, klasyfikacji ryzyka i kontroli dostępu. Dlatego skala AI wymaga nie tylko reużywalnych komponentów, ale też katalogu rozwiązań, zasad utrzymania, obserwowalności i jasnej odpowiedzialności za każdy workflow wspierany przez AI.
Jak to wygląda w zespole

Jak to wygląda w zespole?

Wyobraźmy sobie zespół produktowy rozwijający aplikację webową i API.

Wersja 1: wysoka aktywność AI, niska dojrzałość

Na pierwszy rzut oka wszystko wygląda nowocześnie:

  • większość developerów używa AI w IDE,
  • tester generuje szkice testów,
  • PM streszcza wymagania,
  • ktoś uruchamia agenta do draftu PR,
  • liczba zmian rośnie.

Ale gdy spojrzeć pod spodem:

  • standardy kodu są rozproszone,
  • dokumentacja nie nadąża,
  • brakuje jasnych reguł, co można wysyłać do narzędzi,
  • review stało się płytsze – “AI już sprawdziło”,
  • mierzy się głównie szybkość zmian,
  • nikt nie śledzi, czy rośnie rework, defekty czy niestabilność.

Dokładnie o tym mówią DORA, GitHub i CircleCI, że AI zwiększa aktywność, ale delivery automat nie staje się dojrzalsze. GitHub ostrzega – szybkość bez jasnych granic i dobrych praktyk to nie jest trwała poprawa. (dora.dev)

UWAGA: To jeden z najgroźniejszych antywzorców adopcji AI – automatyzacja zaczyna udawać odpowiedzialność. Zespół nie tyle poprawia jakość procesu, ile przenosi zaufanie na narzędzie, którego wyników często nie potrafi systematycznie zweryfikować.

Wersja 2: zespół dojrzewający operacyjnie

Ten sam zespół kilka miesięcy później może wyglądać całkiem inaczej:

  • ma zasady użycia AI,
  • wie, które use case’y są bezpieczne, a które ryzykowne,
  • poprawił dokumentację i standardy,
  • review checklist jest czytelny,
  • pracuje na mniejszych zmianach,
  • mierzy nie tylko szybkość, ale rework, quality i defekty,
  • zachował ludzką odpowiedzialność za decyzje.

Tu AI nie jest już “fajną funkcją”, tylko częścią zespołowej pracy. To jest właśnie przejście od samego używania AI do rzeczywistej dojrzałości.

Wersja 3: zespół i organizacja na wyższym poziomie

I na jeszcze wyższym poziomie:

  • guardrails są wbudowane w narzędzia,
  • widać, co robił każdy agent,
  • standardy obowiązują wiele zespołów,
  • reuse to norma,
  • governance nie blokuje – umożliwia,
  • feedback wraca do doskonaleniu procesów.

To już nie jest “zespół z AI”. To organizacja, która umie zarządzać AI jako rzeczywistą zdolnością. AWS i Microsoft dobrze to opisują: reusable patterns, lifecycle management, governance osadzone w prakty ce. (AWS Documentation)

Co odróżnia dojrzalsze organizacje

Co odróżnia dojrzalsze organizacje?

Tu jest najciekawszy wniosek – dojrzałość AI wcale nie wynika z zachwytu gadżetem. Wynika z kilku rzeczywistych zdolności.

Dojrzalsze organizacje odróżnia przede wszystkim to, że traktują AI jako część systemu pracy, a nie jako osobny gadżet obok procesu. To oznacza kilka bardzo konkretnych rzeczy:

  • jasne stanowisko wobec AI,
  • porządny version control,
  • dobra wewnętrzna platforma,
  • praca na małych zmianach,
  • zdrowe dane,
  • dostęp do danych dla AI,
  • governance wbudowany w pracę,
  • widoczność i kontrola zachowania AI,
  • odpowiedzialność człowieka tam, gdzie decyzje są ważne.
    (services.google.com)

Organizacje mają jasne stanowisko wobec AI. Zespoły wiedzą, do czego mogą używać AI, czego nie powinny robić, jakie dane są niedozwolone, które decyzje wymagają człowieka i kto odpowiada za efekt końcowy. Dzięki temu AI nie jest używane przypadkowo, tylko w ramach uzgodnionych granic.

Organizacje mają również mocne fundamenty inżynierskie. Dobre repozytoria, version control, code review, CI/CD, małe zmiany, automatyczne testy i quality gates sprawiają, że wynik pracy z AI może zostać zweryfikowany. Bez tych fundamentów AI może jedynie szybciej produkować kod, którego organizacja nie potrafi skutecznie ocenić.

AI działa lepiej wtedy, gdy ma dostęp do aktualnej dokumentacji, standardów, decyzji architektonicznych, opisów domeny i dobrych przykładów z kodu. Jeśli wiedza jest rozproszona, nieaktualna albo ukryta w głowach ludzi, AI będzie zgadywać, powielać stare błędy albo generować rozwiązania oderwane od realiów projektu.

Dojrzalsze organizacje mierzą wpływ AI na system, a nie tylko aktywność. Nie wystarczy wiedzieć, ile osób używa narzędzia albo ile wygenerowano kodu. Ważniejsze jest to, czy spada rework, czy review jest szybsze i głębsze, czy rośnie stabilność delivery, czy zmniejsza się liczba defektów, czy zespoły szybciej dochodzą do bezpiecznego wdrożenia.

Dojrzalsze organizacje mają governance wbudowany w codzienną pracę. To nie oznacza ciężkiej biurokracji. Chodzi o jasne zasady, klasyfikację ryzyka use case’ów, kontrolę dostępu do danych, monitoring kosztów, obserwowalność działania agentów i mechanizmy reagowania, gdy AI zaczyna działać poza oczekiwanym zakresem.

Właśnie dlatego modele dojrzałości AI powinny prowadzić organizację od pytania:

“Czy używacie AI?”

na:

“Czy macie organizację, w której AI rzeczywiście poprawia delivery?” (dora.dev)

Bez governance nie ma trwałej skali

Governance (czyli zarządzanie, nadzór i odpowiedzialność) nie jest dodatkiem na końcu. Powinno być zarazem przed, w trakcie i po każdej interakcji z AI. To jest kluczowy element dojrzałości, który odróżnia organizacje, które tylko “używają AI”, od tych, które potrafią z niego korzystać w sposób bezpieczny, powtarzalny i wartościowy.

W software development oznacza to:

  • polityka użycia AI,
  • reguły pracy z danymi i promptami,
  • klasyfikacja use case’ów po ryzyku,
  • dobór narzędzi i modeli,
  • human-in-the-loop dla ważnych decyzji,
  • monitoring jakości i kosztów,
  • odpowiedzialność za decyzje wspierane przez AI.

To nie jest tylko “bycie ostrożnym”. To kwestia realnej jakości.

Jakie praktyki pokazują, że modele dojrzałości AI działają

Jakie praktyki pokazują, że modele dojrzałości AI działają?

Kilka szczególnie dobrze ilustruje, że organizacja wychodzi poza samą adopcję.

Pierwsza: AI-assisted code review z zachowaniem ludzkiej odpowiedzialności. AI może pomagać w feedback, ale merge jest odpowiedzialnością człowieka. (The GitHub Blog)

Druga: agentic workflows z guardrails. Nie “dajmy agentowi więcej swobody”, tylko “jak zbudować automatyzację, która jest kontrolowana”. (The GitHub Blog)

Trzecia: operations i lifecycle management dla agentów. Dojrzałość nie kończy się na “zrobiliśmy agenta”. Zaczyna się na “wiemy jak nim zarządzać w czasie”. (Microsoft Learn)

Czwarta: reusable patterns i observability w skali. Organizacja przestaje budować każdy use case od zera, a zaczyna korzystać z gotowych wzorców i monitorować ich działanie w większej skali. (AWS Documentation)

Jak mierzyć postęp w modelach dojrzałości AI?

Wokół AI bardzo łatwo mierzyć to, co jest widoczne, a nie to, co ma realny wpływ. Organizacja może mieć dużo promptów, wiele wygenerowanych zmian i wysoki poziom entuzjazmu, a jednocześnie nie poprawiać jakości, stabilności ani przewidywalności pracy.

Dlatego modele dojrzałości AI powinny odróżniać metryki aktywności od metryk wpływu.

Fałszywe sygnały postępu to na przykład:

  • liczba promptów,
  • liczba linii wygenerowanego kodu,
  • liczba draftów PR z AI,
  • liczba commitów z AI,
  • liczba użytkowników narzędzia,
  • liczba eksperymentów z AI,
  • poziom entuzjazmu w zespole.

Te metryki pokazują aktywność, ale nic nie mówią o wartości. DORA jasno pokazuje napięcie między wzrostem throughput a ryzykiem instabil ności. (dora.dev)

Mogą być przydatne na początku, bo pokazują skalę adopcji. Problem zaczyna się wtedy, gdy organizacja traktuje je jako dowód skuteczności AI. Wysoka aktywność nie oznacza jeszcze, że AI poprawia delivery. Może równie dobrze oznaczać, że zespół szybciej produkuje więcej zmian, które później znacznie zwiększą koszty (rework, defekty, niestabilność).

Właśnie tu pojawia się największe ryzyko

AI może poprawić lokalną szybkość pracy pojedynczych osób, ale pogorszyć przepływ całego systemu. Bo:

  • developer może szybciej wygenerować kod,
  • tester może szybciej wygenerować scenariusze,
  • PM może szybciej przygotować draft wymagań,

ale jeśli rośnie liczba niejasności, poprawek, błędów i dyskusji po review, organizacja nie staje się dojrzalsza. Staje się bardziej chaotyczna, mniej przewidywalna i bardziej kosztowna w utrzymaniu.

Znacznie bardziej sensowne są metryki systemowe:

  • throughput (liczba wdrożeń, liczba zmian, czas od pomysłu do wdrożenia),
  • stabilność delivery,
  • change failure rate (procent zmian, które powodują defekt w produkcji),
  • liczba defektów po wdrożeniu,
  • rework po review,
  • latency review (czyli czas od otwarcia PR do merge),
  • koszt użycia AI na use case lub zespół,
  • czas od zmiany do bezpiecznego wdrożenia,
  • procent zmian wspieranych przez AI, które wymagają istotnej poprawy po review,
  • liczba rollbacków lub hotfixów po zmianach wspieranych przez AI,
  • liczba naruszeń zasad bezpieczeństwa, danych lub compliance związanych z użyciem AI.

Chodzi o efekt systemowy, nie tylko o aktywność.

Dobre modele dojrzałości AI nie powinny więc premiować samego entuzjazmu, liczby narzędzi ani liczby wygenerowanych zmian. Powinny pomagać ocenić, czy organizacja ma fundamenty, które pozwalają AI wzmacniać jakość, przewidywalność i bezpieczeństwo delivery.

Podsumowanie modeli dojrzałości AI

Podsumowanie

Najbardziej dojrzałe organizacje AI nie są tymi, które najszybciej wdrożyły nowe narzędzia. Są nimi te, które nauczyły się osadzać AI w realnym system delivery.

Dojrzałość AI to nie liczba wdrożeń, nie liczba użytkowników ani poziom entuzjazmu. To połączenie:

  • mocnych fundamentów inżynierskich,
  • porządnych danych i dokumentacji,
  • sensownego modelu operacyjnego,
  • świadomego governance,
  • odpowiedzialności za decyzje wspierane przez AI,
  • umiejętności mierzenia realnego wpływu.

Dlatego rozmowa powinina wychodzić poza:

“Czy używacie AI?”

I sięgać do ważniejszych pytań:

  • czy AI rozwiązuje rzeczywiste problemy?
  • czy ma dobry kontekst i jasne granice?
  • czy organizacja zarządza ryzykiem i odpowiedzialnością?
  • czy efekty widać w jakości delivery, nie tylko w aktywności?

Dojrzałość AI to zdolność organizacji do bezpiecznego, powtarzalnego, mierzalnego i odpowiedzialnego użycia AI w sposób, który poprawia delivery, a nie tylko zwiększa aktywność.

I to jedno pytanie zmienia wszystko:

Czy organizacja zbudowała warunki, w których AI wzmacnia delivery, a nie tylko generuje więcej zmian?

Źródła

Krzysiek Kijas
Senior Software Quality Engineer, Tech Lead, Mentor, Pelegent
Zwycięzca ogólnopolskiego plebiscytu
Ludzie Testowania 2024 (testerzy.pl)
Microsoft Most Valuable Professional (MVP)
profil na LinkedIn
Microsoft Most Valuable Professional (MVP)
  • Jako Tech Lead i Architekt QA projektuję strategie jakości i architekturę testów, które wspierają stabilność systemów, redukcję ryzyka i szybsze dostarczanie wartości biznesowej z wykorzystaniem różnych narzędzi (Playwright, CI/CD oraz rozwiązania oparte o AI).
  • Z obszarem jakości oprogramowania jestem związany od 2011 roku, pracując w projektach z różnych domen (finanse, transport, administracja, systemy enterprise).
  • Projektuję architekturę automatyzacji testów (od unit i API po E2E), dopasowaną do architektury systemu i kluczowych atrybutów jakościowych (np. wydajność, testowalność, niezawodność).
  • Buduję i optymalizuję procesy CI/CD (Jenkins, GitLab CI, Azure DevOps), gdzie automatyzacja testów pełni rolę mechanizmu kontroli jakości.
  • Od 2014 roku działam jako trener i prelegent (test:fest, TestWarez, ConSelenium i inne), dzieląc się praktyką z projektów i wspierając rozwój nowoczesnego podejścia do jakości.
  • Współtworzę jaktestowac.pl oraz AI_Testers, gdzie rozwijam materiały dla Nowoczesnych Testerów.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *