Źródła danych w artykule: CodeRabbit 2025.12 / New Relic 2026, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. Przykłady to uogólnione scenariusze reprezentatywne, nie odnoszą się do konkretnych firm.

Twój największy błąd to nie brak narzędzi, tylko brak pliku CLAUDE.md

CIO jednego z banków komercyjnych narzekał mi się: narzędzia AI kupione, modele wdrożone, ludzie przeszkoleni – a w całym pierwszym półroczu 2026 czas dostarczania oprogramowania praktycznie się nie zmienił. Szef zespołu systemów core bankingowych poszedł dalej: „Kod generowany przez AI nadaje się do użycia, ale i tak trzeba go za każdym razem pisać od nowa – bo model nie zna naszych reguł bankowych, nie zna wymogów regulacyjnych i nie wie, jak się integrować z tym 30-letnim systemem legacy.”

Problem nie leży w tym, że AI nie jest wystarczająco dobre — chodzi o to, że nie spisaliście zasad. Analiza 470 open-source’owych PR-ów przeprowadzona przez CodeRabbit w grudniu 2025 r. dostarczyła zestawu liczb, które szeroko cytowano: PR-y tworzone przy współpracy z AI zawierają średnio 10,83 problemów, podczas gdy PR-y czysto ludzkie — 6,45. To 1,7 raza więcej, czyli o 70% więcej bugów niż w przypadku pracy człowieka. W 2026 r. obraz się nie odwrócił: New Relic w swoim 2026 State of AI Coding Report wykazał, że 78% zespołów raportuje więcej incydentów po wdrożeniu kodu generowanego przez AI, a 62% liderów technicznych przyznaje, że ich zespoły „z pełnym przekonaniem wdrażają kod od AI bez przeglądu linia po linii” (oficjalny raport New Relic 2026, wynik 0,866, źródło pierwszorzędne). Obie grupy danych mówią o tym samym — AI nie brakuje możliwości, brakuje mu kontekstu.

W sierpniu 2026 r. każdą narrację o „przyspieszaniu transformacji AI” trzeba rozpatrywać w kontekście jednego zestawienia:

| Obóz | Postępy (H1 2026) | Kontrprzykłady (H1 2026) |
|—|—|—|—|
| EY | Microsoft 365 Copilot wdrożony dla 150 000 pracowników, oszczędność 2,5 mln godzin / 250 mln USD; planowana ekspansja do 400 000 pracowników na świecie | Jednocześnie przyznają, że 95% przyspieszenia i 37% redukcji kosztów operacyjnych w finansach jest możliwe tylko przy „najpierw standaryzacja procesów” |
| Atos | Wdrożenie w 54 krajach / dla 56 000 pracowników; równolegle działa 19 000 agentów AI pod wspólną warstwą kontroli tożsamości, bezpieczeństwa, zgodności i ładu korporacyjnego | Świadomie trzymają się zasady „najpierw dojrzałe mechanizmy zarządzania Agent 365, potem skalowanie” |
| Samo Microsoft | Work Trend Index 2026: 82% liderów planuje w ciągu 12–18 miesięcy rozszerzyć siłę roboczą o agentów AI | W tym samym raporcie przyznają, że „tempo zmian organizacyjnych nie nadąża za adopcją indywidualną” — to sedno sprzeczności w koncepcji Frontier Firm |

Źródło: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

To zestawienie pokazuje jedną rzecz: bez reguł, skalowanie to mnożenie ryzyka przez N. „Szybkość” EY/Atos/Microsoft nie wynika z modeli — wynika z tego, że „organizacja najpierw odpowiedziała sobie na pytanie, jak używać AI”. To właśnie dlatego Spec-Driven Development (SDD) stał się w H1 2026 naprawdę mainstreamowy — nie dlatego, że inżynierowie lubią dokumentację, ale dlatego, że bez specyfikacji nie da się już przetrwać w środowisku z 19 000 agentów.

Ten artykuł wyjaśnia trzy rzeczy: 1) dlaczego defekty w kodzie generowanym przez AI są ponad 1,7 razy poważniejsze niż te pisane przez ludzi; 2) jak pięć platform — GitHub, AWS, OpenAI, Anthropic, Alibaba — w H1 2026 zmierza do tego samego paradygmatu: ograniczania zachowań AI za pomocą dokumentacji; 3) dlaczego spec-driven development to kompetencja organizacyjna, a nie wybór narzędzia — oraz trzy fazy wdrożenia w H1 2026.

Długość słupka = krotność defektów AI względem ludzkich; linia bazowa 1.0× = poziom ludzki

Linia bazowa 1.0×

Łączna liczba problemów

1.7×
AI 10.83 vs człowiek 6.45 / PR

Błędy logiczne / poprawnościowe

1.75×

Jakość kodu / utrzymywalność

1.64×

Znaleziska bezpieczeństwa (łącznie)

1.57×

Nieprawidłowe obsługiwanie haseł

1.88×

Podatność XSS

2.74×
↑ Najwyżej

Kod AI bez ograniczeń normatywnych wypada gorzej w każdym wymiarze
Finanse / telekom = zgodność, hasła, szyfrowanie pól wrażliwych — AI tego nie widzi

I. Wysoki wskaźnik błędów AI to nie problem modelu, tylko problem kontekstu

W raporcie CodeRabbit jedno zdanie jest cytowane szczególnie często: „AI nie zna logiki biznesowej: model wnioskuje o wzorcach kodu na podstawie statystyk, a nie rozumienia semantyki. Bez ścisłych ograniczeń pomija reguły systemowe, które starsi inżynierowie mają zinternalizowane.”

To zdanie wyjaśnia, dlaczego platforma programistyczna CodeRabbit (firma specjalizująca się w przeglądach kodu przez AI) zobaczyła te dane wcześniej niż inni — codziennie analizują tysiące pull requestów i widzą, jak wygląda kod pisany przez AI. „Najważniejsze” odkrycie to nie suma, ale rozkład:

Logika/poprawność +75%: błędy logiki biznesowej, błędne zależności, błędy przepływu sterowania, błędy konfiguracji — tego typu problemy nie zawsze wychodzą w testach, ale w produkcji potrafią skończyć się awarią.
Jakość kodu +64%: niespójne nazewnictwo, nieczytelna struktura, łamanie wzorców projektowych — to „kategoria o największych różnicach”. Starszy inżynier od razu widzi: „to nie jest styl, w jakim piszemy u nas”.
Bezpieczeństwo +57% (XSS najwyższe, 2,74×): nieprawidłowe obsługiwanie haseł (1,88×), niebezpieczne odwołania do obiektów (1,91×), wycieki wrażliwych informacji, niebezpieczna deserializacja (1,82×) — w sektorze finansowym to nie jest kwestia „czy się nada”, tylko „czy można to w ogóle wypuścić”.

Problem nie w tym, że AI nie jest wystarczająco dobre. Problem w tym, że nie widzi.

Wracając do realnego punktu zapalnego tego CIO – trzy konkretne awarie AI w systemach rdzenia finansowego:

Po pierwsze, AI nie widzi 30-letniej logiki uzgodnień. Reguły ryzyka w banku są zapisane w procedurach składowanych systemu rdzenia – napisane 30 lat temu, nikt ich już nie pamięta w całości. Wygenerowany przez AI kod logicznie wygląda poprawnie, ale w środowisku produkcyjnym wyzwala tę zapomnianą kontrolę uzgodnień, co powoduje odrzucenie całej partii transakcji.

Po drugie, AI nie widzi ograniczeń compliance. Hasła muszą przechodzić przez system zarządzania kluczami, wrażliwe pola muszą być szyfrowane, logi nie mogą zawierać danych klientów – to twarde wymogi regulacyjne, zapisane w wewnętrznych politykach. AI o nich nie wie – kod, który generuje, działa, ale nie przechodzi przeglądu zgodności.

Po trzecie, AI nie widzi twojego długu technicznego. Ten 30-letni system hostowy używa własnego protokołu interfejsowego, a dokumentacja dawno zaginęła. AI pisze kod według standardowego RESTful – po wdrożeniu okazuje się, że interfejsy nie pasują. Dwa tygodnie przeróbek.

Wracając do drugiego zestawu liczb z New Relic: 62% zespołów „z pewnością siebie wdraża kod AI bez przeglądu”, a 78% raportuje więcej incydentów po wdrożeniu. Te dwie liczby razem mówią wprost – problemem nie jest sam wskaźnik defektów w kodzie AI, tylko to, że „nie wiem, jakie defekty ma kod AI”.

Typowy scenariusz: pewien bank akcyjny wdrożył wspomagane przez AI tworzenie modułu kontroli ryzyka w systemie core banking. W ciągu trzech miesięcy odsetek odrzuceń w przeglądzie zgodności znacząco wzrósł. Głównym problemem były wewnętrzne zasady dotyczące zarządzania hasłami, szyfrowania pól wrażliwych, zgodności logów itp. Zasady te były opisane w wewnętrznej dokumentacji, ale AI ich nie widziała. Gdy zespół zapisał kluczowe reguły w pliku CLAUDE.md, odsetek odrzuceń wyraźnie spadł.

Dwa. Pięć głównych platform w 2026 H1: różne drogi, wspólny cel — „sterowanie regułami”

W lipcu 2025 GitHub wydał Spec Kit, a na początku 2026 AWS Kiro, OpenAI Codex i Anthropic Claude Code uzupełniły swoje funkcje; w maju 2026 Alibaba Qoder wpisał „Spec-Driven Workflow” w swoją pozycję produktową. Pięć głównych platform w 2026 H1 osiągnęło ten sam paradygmat — używanie dokumentacji do ograniczania zachowań AI. To nie jest wynalazek jednej firmy, ale zbiorowa odpowiedź branży na „kryzys jakości kodu generowanego przez AI”.

Przyjrzyjmy się najnowszym działaniom każdej platformy w 2026 H1:

GitHub Spec Kit: implementacja referencyjna, pięcioetapowa brama kontroli. Udostępniony jako open source we wrześniu 2025 r., do pierwszej połowy 2026 r. stał się de facto implementacją referencyjną w branży. 5 podstawowych komend + 2 uzupełniające: /speckit.constitution (zasady niepodlegające negocjacjom), /speckit.specify (co i dlaczego), /speckit.plan (jak zmienić), /speckit.tasks (podział na zadania), /speckit.implement (wykonanie), plus /clarify i /analyze. Kluczową cechą projektu jest niezależność od modelu — te same pliki spec/plan/tasks nie są przypisane do żadnego konkretnego agenta wykonawczego. Mogą z nich korzystać Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf i Qwen Code. Dzięki temu Spec Kit stał się „protokołem SDD na poziomie organizacji”, a nie produktem zamkniętym w ekosystemie GitHuba (wg vibecoding.app, czerwiec 2026, wynik 0,816, źródło drugorzędne).

AWS Kiro: Wpisz specyfikację wprost do IDE. Premiera w lipcu 2025, a w H1 2026 ewolucja do pełnoprawnego agentowego IDE. Praca przebiega w trzech fazach: wymagania → projekt → zadania. Różnica względem Spec Kit leży w „hakach” – pliki spec w Kiro potrafią wyzwalać zdefiniowane wcześniej akcje agenta, wbudowując kroki wymagające systemów zewnętrznych (zgodność, audyt, wdrożenie) bezpośrednio w przepływ pracy. Jeśli chcesz zmusić zespół do pisania specyfikacji, wybierz Kiro – bo bez pliku spec Kiro po prostu nie wystartuje (oficjalne materiały AWS Kiro, lipiec 2025; dokumentacja Kiro.dev, 2026).

OpenAI Codex: AGENTS.md + komponowalne Skills. W latach 2025–2026 to właśnie AGENTS.md wysunęło się na centrum całego ekosystemu. Kluczowym rozszerzeniem pierwszej połowy 2026 roku są Skills – czyli gotowe, złożone z mniejszych kroków procedury, takie jak „odczyt pliku Excel”, „wygenerowanie zapytania SQL” czy „przeprowadzenie migracji danych”, które można wywoływać jak klocki LEGO. Tygodniowa liczba aktywnych użytkowników Codexa przekroczyła w czerwcu 2026 roku 5 milionów, z czego 20% to osoby niebędące programistami – to często pomijany sygnał: podejście oparte na specyfikacjach przestało być domeną wyłącznie zespołów inżynierskich. Stało się sprawą całej organizacji – product managerowie, zespoły operacyjne i compliance również piszą własne pliki AGENTS.md (ogłoszenie OpenAI z 2.06.2026; recenzja thebcms.com, 2026, wynik 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic nazywa swój plik z instrukcjami projektu CLAUDE.md (wprowadzony na oficjalny rynek w lutym 2026), .claude/rules/ (reguły podzielone według katalogów) oraz Skills (współdzielone przepływy pracy). Claude Code to narzędzie o najwyższym wskaźniku zadowolenia deweloperów w pierwszej połowie 2026 roku — badanie JetBrains 2026.1 podaje CSAT na poziomie 91% i NPS 54, co potwierdzają dwa niezależne raporty (Pragmatic Engineer 2026.2). To obecnie najwyższy wynik w branży narzędzi AI do programowania (uvik.net 2026.5, wynik 0,956, agregacja źródeł pierwszego rzędu). Claude Code osiągnął w 9 miesięcy przychód roczny w wysokości 2,5 miliarda dolarów (dane z rundy G Anthropic, 2026.2), a repozytorium Skills ma 112 tysięcy gwiazdek na GitHubie — deweloperzy głosują portfelem, co pokazuje realną wartość podejścia opartego na regułach.

Alibaba Qoder: napędzany regulacjami gracz na chińskim rynku. Premiera w sierpniu 2025 r., a 15 maja 2026 r. narzędzie doczekało się wersji 1.0, przechodząc oficjalnie z kategorii „AI IDE” do „Autonomous Agent Development Workbench”. Jego flagowy Spec-Driven Workflow zadebiutował wraz z trybem Quest Mode (autonomiczne zadania wieloplikowe), Expert Mode (równoległa praca zespołu agentów) oraz RepoWiki (grafu wiedzy repozytorium). 28 maja 2026 r. udostępniono Cloud Agents (w pełni zarządzane środowisko uruchomieniowe dla agentów), 21 lipca – Qoder Security (funkcje zgodności i bezpieczeństwa), a w tym samym miesiącu pojawiła się wersja mobilna (Android/iOS/HarmonyOS). Do maja 2026 r. z narzędzia korzystało na świecie ponad 5 mln użytkowników, a CLI DingTalk wymienia Qoder jako jedno z obsługiwanych środowisk wykonywania agentów (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Wspólny paradygmat: jawnie zapisać „jak współpracujemy z AI” w dokumencie, umieścić go w repozytorium i sprawić, by wszyscy — ludzie i agenci AI — pracowali w oparciu o ten sam standard. Szczegóły implementacji różnią się między platformami (nazwy plików / liczba etapów / mechanizmy hooków), ale cel jest identyczny.

Dlaczego to wszystko dzieje się właśnie w H1 2026? Ponieważ próg możliwości AI został już przekroczony — autonomiczni agenci Claude Code, równoległa praca wielu agentów w Codex, refaktoryzacja wielu plików w Cursorze. AI przestało być „narzędziem do autouzupełniania”, a stało się „współpracownikiem”. Dokumenty wdrożeniowe, które dajesz nowemu pracownikowi, muszą być zrozumiałe także dla AI.

III. Sterowanie standardami to kompetencja organizacyjna, nie wybór narzędzia

To najważniejszy punkt dla decydentów. Sterowanie standardami to nie wybór narzędzia, tylko zdefiniowanie „jak nasza organizacja współpracuje z AI”. To, czy wybierzesz GitHub Spec Kit, czy Claude Code, nie ma znaczenia. Liczy się to, czy spisałeś standardy w dokumencie, umieściłeś je w repozytorium i sprawiłeś, że zarówno ludzie, jak i AI pracują w oparciu o nie.

Bez tego nawet najlepsze narzędzia sprawią tylko, że zespół będzie szybciej generować jeszcze więcej długu technicznego.

Umieszczając to w kontekście wdrożeń na szeroką skalę w I połowie 2026 roku, dowody są jeszcze mocniejsze. W retrospektywie fiskalnej za lipiec 2026 roku Microsoft opisał przypadki EY i Atos jako szablon „Frontier Firm” – nie dlatego, że modele są nowe, ale dlatego, że obie firmy najpierw odpowiedziały sobie na pytanie „jak właściwie używać AI”:

EY: najpierw zasady, potem skala. W latach 2024–2025 EY wdrożyło Microsoft 365 Copilot dla 150 tysięcy pracowników, oszczędzając 2,5 miliona godzin i około 250 milionów dolarów. Warunkiem było wcześniejsze zbudowanie ram zarządzania AI: EY zbudowało jednolite środowisko narzędziowe oparte na Power Platform, Copilot Studio, Azure, Foundry i Fabric, osadzając standardy, zgodność i audyt we wspólnej podstawie. Dopiero to umożliwiło późniejsze przyspieszenie o 95%, redukcję kosztów operacji finansowych o 37% i zmniejszenie nawet o 90% pracy ręcznej. Wiceprezes EY podczas AI Tour 2026 ujął to wprost: „Nie wdrażamy AI, żeby potem nadrabiać zarządzanie – najpierw budujemy zarządzanie, a potem wdrażamy AI”.

Atos: jeden płaszczyzna kontroli dla 19 000 agentów. Atos to jedna z pierwszych organizacji na świecie, która wdrożyła Microsoft 365 E7 (Frontier Suite), udostępniając Copilota 56 000 pracowników w 54 krajach. Jednocześnie działa tam 19 000 agentów AI — od wewnętrznego IT, przez jednostki biznesowe, po projekty klienckie — wszystkie budowane na Foundry i Copilot Studio. Kluczem do sukcesu Atos jest „jedna płaszczyzna kontroli”: Entra (tożsamość) + Defender (bezpieczeństwo) + Intune (urządzenia) + Purview (zgodność) + Agent 365 (zarządzanie agentami) — pięć elementów spiętych w jedną całość. To podejście w sektorze finansowym odpowiada połączeniu wymogów typu „MLPS (chiński system klasyfikacji ochrony bezpieczeństwa informacji) + ocena transferu danych za granicę + rejestracja algorytmów + audyt + zarządzanie modelami” — czyli architekturze zarządzczej, a nie zwykłemu narzędziu AI.

Paradoks zmiany organizacyjnej w Microsoft. W raporcie 2026 Work Trend Index Microsoft sam przyznaje: „tempo zmian organizacyjnych pozostaje w tyle za tempem adopcji na poziomie indywidualnym”. Spośród 20 000 ankietowanych użytkowników AI, 82% liderów planuje w ciągu 12–18 miesięcy rozszerzyć siłę roboczą o agentów AI, ale tylko 24% wdrożyło ich już na poziomie całego przedsiębiorstwa. 81% liderów spodziewa się, że agenci AI zostaną w średnim lub dużym stopniu zintegrowani ze strategią AI — ale ponownie tylko 24% już to zrobiło. Oznacza to, że większość firm dzieli od celu 12–18 miesięcy różnicy między „przygotowaniem” a „wdrożeniem”. Kluczowym elementem wypełnienia tej luki jest podejście oparte na regulacjach i standardach (governance).

Źródła: Microsoft FY26 retrospective, 28.07.2026; Microsoft 2026 Work Trend Index Annual Report, 5.05.2026 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, źródło pierwotne PDF); analiza Futurum Group z 26.01.2026 (źródło wtórne).

Wniosek pierwszy: inwestycja w governance to wysoki zwrot z inwestycji.

CodeRabbit dostarcza konkretnych danych do wyliczenia ROI: wskaźnik problemów w kodzie generowanym przez AI jest ok. 1,7× wyższy, a liczba luk bezpieczeństwa spada 2,74×. Co to oznacza w praktyce:

Mniej poprawek (w sektorze finansowym jeden przegląd zgodności regulacyjnej to 2–4 tygodnie pracy)
Mniej incydentów bezpieczeństwa (kara regulacyjna i utrata reputacji po jednym wycieku danych)
Niższe koszty utrzymania (redukcja długu technicznego o 40% to typowa wartość)

Napisanie dobrego pliku CLAUDE.md/AGENTS.md z zasadami projektu to najwyżej oprocentowana inwestycja inżynierska w erze AI. Przykład EY pokazuje to w realnych liczbach — 150 tys. osób korzystających z Copilota przyniosło oszczędności rzędu 250 mln USD. Warto zauważyć: EY nie zaoszczędziło dlatego, że „narzędzie jest świetne”, tylko dlatego, że „dobre praktyki pozwoliły wykorzystać jego potencjał”.

Wniosek drugi: zasady trzeba wpisać w proces organizacyjny, a nie opierać na jednostkach.

Jeśli dobre praktyki siedzą tylko w głowie jednego senior developera, znikną wraz z jego odejściem z zespołu. Trzeba je osadzić w:

dokumentacji repozytorium (AGENTS.md / CLAUDE.md / constitution.md)
bramkach CI (automatyczna weryfikacja zgodności z zasadami)
współdzielonej konfiguracji zespołu (system Skills, który udostępnia je całemu zespołowi)

Niech standardy staną się aktywem organizacji, a nie umiejętnością jednostki. To szczególnie istotne w sektorze finansowym — wymogi compliance, reguły bezpieczeństwa i zasady biznesowe to aktywa na poziomie organizacji, a nie „doświadczenie” pojedynczego inżyniera. 19 000 agentów Atos działa w 54 krajach, ponieważ governance nie polega na tym, że „ktoś to rozumie”, ale na tym, że „system wymusza”.

Wniosek trzeci: bramki kontrolne są ważniejsze niż szybkość.

Pięcioetapowe bramki GitHub Spec Kit (constitution → specify → plan → tasks → implement), zasada Claude Code „nie pisz kodu, zanim testy nie zawiodą” oraz Kiro, które nie wystartuje bez specyfikacji, robią dokładnie to samo: dodają „hamulec” między AI a finalnym rezultatem. Każdy krok pozostawia weryfikowalny artefakt (spec.md, plan.md, tasks.md), który można odrzucić lub zmodyfikować, zanim powstanie kod.

Im bardziej autonomiczne AI, tym bardziej potrzebuje bramek. W sektorze finansowym Change Advisory Board (CAB), procesy rejestracji algorytmów czy oceny bezpieczeństwa (等保测评) to w istocie bramki dodawane przed wdrożeniem produkcyjnym. Kod generowany przez AI również wymaga podobnych bramek — tyle że w innej formie. Te 62% zespołów z raportu New Relic 2026, które „pewnie wdrażają bez przeglądu”, płaci za tę pewność wyższą liczbą incydentów (78%).

Pierwszy etap jest najbardziej czasochłonny, ale ROI jest najwyższy
W większości instytucji finansowych zasady są rozproszone w dokumentach/e-mailach/umysłach ludzi; pierwsza konsolidacja to nakład 3–8 tygodni

Cztery. Realne trzy fazy wdrożenia w H1 2026

Poniżej ścieżka trzech faz na przykładzie sektora finansowego — pozostałe branże silnie regulowane mogą ją potraktować jako punkt odniesienia. Praktyki EY i Atos z H1 2026 dokładnie odpowiadają tym trzem fazom.

Faza pierwsza: inwentaryzacja reguł (2–4 tygodnie).

To etap najbardziej czasochłonny, ale o najwyższym zwrocie z inwestycji. Polega na zebraniu reguł rozproszonych po całej organizacji:

Wymogi compliance: dla sektora finansowego minimalny baseline = klasyfikacja bezpieczeństwa MLPS (chiński system oceny ochrony danych, odpowiednik równoważnych wymogów sektorowych w UE) + ocena transgranicznego transferu danych (odpowiednik mechanizmu z RODO) + rejestracja algorytmów (chiński odpowiednik wymogu przejrzystości algorytmicznej) — jeśli brak któregokolwiek z tych elementów, nie należy wdrażać AI; powyżej tego minimum dochodzą wymogi sprawozdawczości regulacyjnej, ochrona danych klientów, ograniczenia przepływu danych transgranicznych oraz określenie, które dane mogą być udostępniane modelom AI
Reguły bezpieczeństwa: zarządzanie hasłami, standardy szyfrowania, obsługa pól wrażliwych, wymogi dot. logów
Reguły biznesowe: progi ryzyka, warunki wypłaty odszkodowań, limity transakcyjne, logika rozliczeń
Ograniczenia techniczne: interfejsy systemów legacy, nazewnictwo baz danych, wersje frameworków
Zarządzanie dostawcami: jak w umowach wymagać od dostawców stosowania naszych standardów i jak audytować ich wykorzystanie AI

Typowy scenariusz: w fazie inwentaryzacji firma maklerska odkrywa, że zasady są rozproszone po dziesiątkach dokumentów Word, wiki w JIRA, prywatnych mailach i arkuszach Excel — dopiero po uporządkowaniu powstaje ustrukturyzowana lista reguł. Atos podchodzi do tego bardziej systematycznie — dzieli zasady na pięć kategorii: „zgodność, bezpieczeństwo, biznes, technologia, dostawcy”, każda z osobnym workflowem zarządzania, wszystkie podpięte do płaszczyzny kontrolnej Agent 365.

To nie jest zadanie techniczne, tylko organizacyjne — musisz posadzić przy jednym stole dział zgodności, bezpieczeństwa i biznesu, a następnie spisać zasady, które wszyscy akceptują. Za pierwszym razem organizacje z sektora finansowego zwykle potrzebują na to 3–8 tygodni — ale to trwały atut organizacji.

Etap drugi: umieszczenie w repozytorium (1–2 tygodnie).

Zasady zebrane w pierwszym etapie zapisujesz w dokumentach i umieszczasz w repozytorium. GitHub Spec Kit używa pliku constitution.md, Claude Code — CLAUDE.md, OpenAI Codex — AGENTS.md, a Alibaba Qoder — Spec Workflow. Nazwy plików są różne, cel jest ten sam — AI ma je załadować w momencie otwarcia repozytorium.

Struktura rekomendowana (główny trend w I połowie 2026 r.):

Opis projektu: czym jest ten system, komu służy
Zasady niepodlegające negocjacjom: granice bezpieczeństwa, granice zgodności regulacyjnej, granice biznesowe
Stack technologiczny i ograniczenia: jaki framework, jaka baza danych, jakie standardy interfejsów
Standardy kodowania: konwencje nazewnictwa, struktura katalogów, minimalne wymagania dotyczące pokrycia testami (bez narzucania rytmu TDD — wystarczy jasno określić poziom pokrycia, ścieżki obowiązkowe i ścieżki zabronione; TDD to opcjonalny rytm organizacyjny, a nie twardy wymóg narzucony przez standardy)
Reguły biznesowe: logika zarządzania ryzykiem, zasady transakcyjne, zasady rozliczeń
Wymagania zgodności: ocena bezpieczeństwa (Dengbao), transfer danych za granicę, raportowanie regulacyjne, czy algorytmy generujące AI wymagają rejestracji
Zasady korzystania z AI: w jakich scenariuszach można używać AI, w jakich wymagany jest przegląd manualny, zasady transferu danych za granicę
Zarządzanie dostawcami: postanowienia umowne, mechanizmy audytu, podział odpowiedzialności

Załącznik: szkielet CLAUDE.md dla sektora finansowego (ok. 200 linii, gotowy do forka i adaptacji)

Poniżej znajduje się szkielet CLAUDE.md dla modernizacji systemu centralnego banku komercyjnego, zorganizowany według kolejności: „zasady niepodlegające negocjacjom → wymagania zgodności → zasady korzystania z AI → reguły biznesowe → ograniczenia inżynieryjne”. Państwa firma nie musi zaczynać od zera — wystarczy uzupełnić puste pola swoimi konkretnymi zasadami.

# CLAUDE.md — <nazwa systemu> — specyfikacja współpracy z AI

> Zakres: <nazwa systemu> v<wersja>, wszyscy agenci AI (Claude Code / Cursor / Copilot / Codex)
> pracujący w tym repozytorium muszą przestrzegać niniejszej specyfikacji. Dokument jest utrzymywany przez <komitet zarządzania>, przegląd kwartalny.
> Ostatnia aktualizacja: YYYY-MM-DD

## 1. Przegląd projektu
- **Pozycjonowanie biznesowe**: nazwa systemu core / segmenty klientów / główne typy transakcji
- **Kluczowy łańcuch**: transakcja → kontrola ryzyka → rozliczenie → uzgodnienie → raportowanie
- **Okno niedostępności**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (żadne zmiany nie mogą być wprowadzane)
- **Zależności krytyczne**: system <X> upstream, system <Y> downstream, platforma raportowania regulacyjnego

## 2. Zasady nienegocjowalne (czerwone linie — naruszenie = odmowa merge)

### 2.1 Czerwone linie bezpieczeństwa
- Hasła, klucze i tokeny muszą zawsze przechodzić przez KMS (Key Management Service) — **zakaz hardkodowania**, **zakaz drukowania w logach**
- Wrażliwe pola klienta (numer dowodu tożsamości / numer karty / CVV / telefon) **muszą być szyfrowane przy zapisie**; tekst jawny jest zakazany w bazie
- W logach nie mogą się pojawiać: pełny numer dowodu, pełny numer karty, hasło w jawnej postaci, kombinacja imienia i nazwiska klienta z numerem telefonu
- Wywołania interfejsów zewnętrznych muszą przechodzić przez bramkę API; połączenia bezpośrednie są zabronione

### 2.2 Czerwone linie zgodności
- Kod wygenerowany przez AI, który dotyczy dostępu do danych klientów, musi w opisie PR zawierać adnotację „dostęp do danych: <pole>”
- Transgraniczny transfer danych jest zabroniony; **każde wyprowadzenie danych za granicę wymaga oceny transgranicznego transferu danych** (kontakt z działem zgodności)
- Decyzje algorytmiczne (kredyt / taryfikacja ubezpieczeń / antyfraud) muszą zachować ścieżkę przeglądu ludzkiego
- Zmiana modelu wymaga rejestracji algorytmów; numer rejestracji musi być przywołany w opisie PR

### 2.3 Czerwone linie biznesowe
- Zmiana progów kontroli ryzyka wymaga podwójnego podpisu szefa ryzyka i szefa biznesu
- Operacje dotyczące środków klienta muszą mieć projekt idempotentny + mechanizm rollbacku w razie niepowodzenia
- Limity transakcji, taryfy i parametry produktu przechodzą przez platformę zarządzania parametrami; zakaz hardkodowania w kodzie

## 3. Stos technologiczny i ograniczenia
- **Języki**: Java 17 (core) / Kotlin (nowe moduły) / SQL (baza danych)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Baza danych**: OceanBase 4.x (tryb kompatybilności MySQL), **klucze obce zabronione**
- **Standardy interfejsów**: wewnętrznie wyłącznie gRPC; interfejsy zewnętrzne w OpenAPI 3.0; RESTful tylko dla interfejsów administracyjnych
- **Konwencje nazewnictwa**: klasy Java PascalCase, metody camelCase, stałe UPPER_SNAKE; nazwy tabel `t_<domena>_<encja>`; indeksy `idx_<tabela>_<kolumna>_<kolejność>`
- **Struktura pakietów**: `com.<firma>.<domena>.<pod-domena>.<warstwa>` (np. `com.bank.pay.tx.core.service`)

## 4. Standardy kodu
- **Minimalne pokrycie testami**: łańcuch krytyczny ≥ 80%, klasy narzędziowe ≥ 60%, każdy nowy kod w PR musi zawierać testy
- **Ścieżki obowiązkowo testowane**: wszystkie kontrolery muszą mieć testy integracyjne (w tym ścieżki awarii); wszystkie gałęzie enum muszą mieć testy jednostkowe
- **Ścieżki zabronione**: zakaz modyfikacji katalogu `<historyczne moduły obciążone>` — najpierw utworzyć warstwę adaptacyjną
- **Zarządzanie zależnościami**: każde dodanie zależności zewnętrznej wymaga skanowania SCA + zatwierdzenia bezpieczeństwa

## 5. Zasady biznesowe (wg domeny)
### 5.1 Transakcje
- Limit pojedynczej transakcji: <kwota>; limit dzienny: <kwota>; przekroczenie wymaga zatwierdzenia manualnego
- Okno czasowe transakcji: <HH:MM> ~ <HH:MM>
- Detekcja duplikatów: w <okno czasowe> ten sam <pole> = duplikat

### 5.2 Kontrola ryzyka
- Priorytet dopasowania blacklisty: lista wewnętrzna → lista przekazana przez regulatora → zamrojenie sądowe
- Próg wyjścia modelu antyfraud: <wynik>; powyżej wymagana manualna weryfikacja drugiego poziomu

### 5.3 Rozliczenia
- Każda zmiana taryfy musi mieć numer wersji + datę wejścia w życie
- Zamówienia historyczne rozliczane wg taryfy obowiązującej w dacie wejścia w życie, bez retroaktywności

## 6. Wymagania zgodności
- MLPS poziom 3 (等保三级): <organ regulacyjny>, <data następnej oceny>
- Ocena transgranicznego transferu danych: zakres (tylko moduły działalności transgranicznej)
- Rejestracja algorytmów (算法备案): zakres (kredyt / taryfikacja ubezpieczeń i inne algorytmy krytyczne), numer rejestracji `<nr rejestracji>`
- Raportowanie regulacyjne: tabela mapowania pól <CBIRC / Ludowy Bank Chin> w `<ścieżka>`

## 7. Standardy użycia AI
- **Scenariusze dozwolone dla AI**: szablony CRUD, generowanie testów jednostkowych, wersje robocze dokumentacji, sugestie optymalizacji SQL
- **Scenariusze wymagające przeglądu ludzkiego**: logika kontroli ryzyka, zasady rozliczeń, kontrola uprawnień, szyfrowanie/deszyfrowanie, dane transgraniczne
- **Scenariusze zabronione do samodzielnego wykonania przez AI**: materiały do zatwierdzenia CAB, wykonanie zmian produkcyjnych, reagowanie awaryjne
- **Zasady wyprowadzania danych**: dane treningowe / prompty / logi wyjściowe — żadne nie opuszczają kraju; preferowane wdrożenia lokalne (<dostawca>)
- **Wymagania audytowe**: każdy kod wygenerowany przez AI musi w opisie PR zawierać oznaczenie „AI wspomagane: <nazwa narzędzia>”

## 8. Zarządzanie dostawcami
- **Kwalifikacja dostawców**: wymagane raporty SOC 2 / ISO 27001; modele AI muszą mieć kartę modelu
- **Klauzule umowne**: własność danych, wyjaśnialność modelu, klauzula wyjścia, prawo audytu
- **Mechanizm audytu**: kwartalny audyt użycia AI przez dostawców; miesięczny audyt dostawców wysokiego ryzyka

## 9. Zarządzanie i aktualizacje
- **Właściciel**: <komitet zarządzania> (zgodność + bezpieczeństwo + architektura + biznes)
- **Częstotliwość aktualizacji**: przegląd kwartalny; zmiany awaryjne w trybie ekspresowym (podwójny podpis + ogłoszenie 24h)
- **Dziennik zmian**: zobacz `CLAUDE_CHANGELOG.md`
- **Obsługa naruszeń**: pierwsze naruszenie = ostrzeżenie + obowiązkowe szkolenie; drugie naruszenie = zawieszenie użycia narzędzi AI; trzecie = cofnięcie uprawnień

Ten szkielet to nie „gotowa odpowiedź”, tylko „szablon do wypełnienia”. Ważniejsze od tego, ile napiszesz, jest to, czym wypełnisz każdą rubrykę — puste miejsca ujawniają dokładnie to, czego wasza firma „nie przemyślała”.

Typowy przykład: w jednym z banków komercyjnych plik CLAUDE.md definiuje konkretne zasady obsługi haseł — gdy AI generuje kod, który dotyka haseł, musi wywoływać wewnętrzne API do zarządzania kluczami, a hardkodowanie jest zabronione. Tego typu reguły stanowią znaczną część powodów zwrotów w przeglądach compliance.

Ważnym nowym elementem w H1 2026 są Skills/definicje workflow — to nie tylko dokumentacja, ale łańcuchy narzędzi, które AI może faktycznie wywoływać. System Skills w Claude Code (trafił do oficjalnego marketplace Anthropica w lutym 2026, 112 tys. gwiazdek na GitHubie) zamienia czynności takie jak „odczyt pliku Excel”, „generowanie SQL” czy „przeprowadzanie migracji danych” w współdzielone workflow. To kluczowa ewolucja podejścia opartego na standardach w H1 2026: standard to nie tylko ograniczenie, ale wykonywalny workflow.

Etap trzeci: instytucjonalizacja (ciągła).

Samo napisanie standardów to nie koniec, to dopiero początek. Trzeba je wbudować w procesy organizacyjne:

Bramki CI: automatyczne sprawdzanie, czy kod jest zgodny ze standardami (np. wykrywanie zahardkodowanych haseł, niezaszyfrowanych pól wrażliwych)
Współdzielona konfiguracja zespołowa: wykorzystanie systemu Skills, aby cały zespół korzystał z tych samych standardów
Mechanizm regularnej aktualizacji: gdy zmieniają się reguły, standardy muszą się zmieniać razem z nimi (przegląd kwartalny)
Metryki i informacja zwrotna: śledzenie wskaźnika defektów w kodzie generowanym przez AI, odsetka przejść przeglądów zgodności, wskaźnika poprawek
Zarządzanie agentami: rozszerzenie ładu korporacyjnego z ludzi na agentów AI — to, co robi Atos w ramach Agent 365, polega na przeniesieniu tego z poziomu „indywidualnego” na „systemowy”

EY i Atos w H1 2026 obie uczyniły trzeci etap „kompetencją organizacyjną”. Oszczędność 2,5 miliona godzin w EY to zasługa dobrze wykonanego pierwszego i trzeciego etapu — drugi etap to tylko przetłumaczenie reguł na dokumenty czytelne dla AI.

5. Wariant dla branż silnie regulowanych: trzy inżynieryjne podejścia do wbudowania zgodności

W branżach silnie regulowanych — finansach, telekomunikacji, ochronie zdrowia — wdrożenie oparte na standardach ma dodatkowy próg: zgodność nie jest dodatkiem do procesu, lecz elementem wbudowanym w kod. Poniższe trzy podejścia to sprawdzone w H1 2026 sposoby wbudowania zgodności, które CIO i osoby odpowiedzialne za transformację cyfrową mogą wprost wykorzystać przy projektowaniu organizacji.

5.1 Wbudowanie przedstawiciela ds. zgodności w zespół strumieniowy: zgodność „obecna w procesie”, a nie „na końcu procesu”

Tradycyjne podejście: zespół produktowy pisze kod, zespół ds. zgodności przeprowadza kontrolę po fakcie — gdy problem zostaje wykryty, kod jest już w produkcji od dwóch tygodni, a koszt poprawek to 2–4 tygodnie. Sedno problemu: zgodność jest na końcu procesu.

Nowe podejście: w każdym zespole strumieniowym (stream-aligned team) osadzamy przedstawiciela ds. zgodności, w modelu podwójnego raportowania: „liniowo” do działu compliance, „macierzowo” do zespołu biznesowego. Konkretne założenia:

Struktura etatowa: 1 przedstawiciel ds. zgodności na 6–8 zespołów strumieniowych; etat należy do działu compliance, ale fizycznie pracuje w zespole biznesowym — to nie jest „delegacja” na zasadzie wyjazdów
KPI w linii macierzowej: 50% wagi oceny przedstawiciela ds. zgodności opiera się na „wskaźniku defektów compliance” i „odsetku przejść przeglądu za pierwszym razem” w zespole biznesowym — a nie wyłącznie na „pokryciu audytowym” wg działu compliance
Zaangażowanie z wyprzedzeniem: przedstawiciel ds. zgodności uczestniczy w codziennych stand-upach (wystarczy raz w tygodniu), przeglądach PR; kod generowany przez AI musi przejść przez niego przed mergem — a nie być wykryty po fakcie
Wsparcie narzędziowe: przedstawiciel ds. zgodności korzysta z list kontrolnych jako Skills (wywołań narzędziowych), zamiast ręcznego odhaczania pozycji

Typowy scenariusz: w pierwszej połowie 2026 roku pewien ogólnokrajowy bank akcyjny wdrożył pilotażowo trzy zespoły streamingowe z wbudowanymi przedstawicielami compliance, obniżając wskaźnik odrzuceń kodu AI pod względem zgodności z 35% do 8% — kluczem nie jest to, że compliance „patrzy surowiej”, ale że „patrzy wcześniej”. Sednem tego podejścia jest to, aby raportowanie pośrednie przedstawicieli compliance było wyrównane z celami biznesowymi — jeśli ich KPI nadal opierają się wyłącznie na zadaniach z działu compliance, osadzenie z góry skazane jest na porażkę.

5.2 Compliance jako enabling team: zamiana ograniczeń w affordance

Tradycyjne podejście: zespół compliance pełni rolę „bramkarza”, a zespoły biznesowe postrzegają go jako „utrudniacza”. Obie strony grają w grę o sumie zerowej.

Nowe podejście: zespół compliance zostaje przebudowany zgodnie z modelem enabling team z Team Topologies — nie pisze kodu, nie przegląda bezpośrednio pull requestów, ale dostarcza trzy rzeczy, które umożliwiają zespołom biznesowym „samodzielne przestrzeganie zgodności”:

Kontrola zgodności w pipeline CI: Wysokoczęstotliwościowe punkty zgodności, takie jak twarde kodowanie haseł, przechowywanie danych wrażliwych w postaci jawnej, transgraniczny transfer danych oraz punkty decyzyjne algorytmów, zamieniane są w obowiązkowe bramki w GitHub Actions / GitLab CI. Pull request od zespołu biznesowego automatycznie wyzwala kontrolę — brak zgodności oznacza natychmiastowe odrzucenie, bez konieczności ręcznego przeglądu przez przedstawiciela ds. zgodności.
Wymogi regulacyjne jako affordance (ograniczenia reagujące na kontekst): Na przykład podczas tworzenia funkcji korzystających z danych klientów wtyczka IDE podpowiada: „To pole zaleca wywołanie KMS”; podczas pisania logów system automatycznie wykrywa, czy zawierają informacje wrażliwe, i generuje alert. Wymogi zgodności stają się „naturalnym elementem procesu tworzenia oprogramowania”, a nie „informacją o naruszeniu na etapie wdrożenia”.
Współdzielona biblioteka Skills + szkolenia z zakresu zgodności: Zespół ds. zgodności utrzymuje zestaw „Skills zgodności”, z którego można korzystać podczas onboardingu nowych pracowników lub przy zmianie zespołu — wiedza o zgodności przestaje być „dokumentacją”, a staje się „narzędziem wykonywalnym”.

Typowy scenariusz: pewien bank regionalny wdrożył w H1 2026 bramki zgodności w CI oraz podpowiedzi zgodności w IDE, skracając średni czas przeglądu zgodności kodu AI z 45 minut na 8 minut na przypadek. Kluczowe nie jest to, że „przegląd zgodności stał się szybszy”, ale to, że kod generowany przez AI „od razu jest poprawny”.

5.3 Zgodność dwubiegowa: dopasowanie do tempa biznesu

Ostatni szczegół: compliance nie może być „szyte na jedno kopyto”. Podziel reguły na dwa poziomy ryzyka:

Reguły wysokiego ryzyka (dotyczące środków klientów / decyzji algorytmicznych / danych transgranicznych / twardych wymogów bezpieczeństwa) objęte ścisłą kontrolą dostępu: wymagany przegląd manualny + weryfikacja przez AI + wpis do rejestru CAB (Change Advisory Board)
Reguły niskiego ryzyka (standardowy CRUD / kod narzędziowy / generowanie dokumentacji) objęte samoobsługową kontrolą dostępu: wystarczy automatyczna weryfikacja w CI, bez przeglądu manualnego

Płaszczyzna kontrolna Agent 365 w Atos to w istocie ten sam model warstwowy — agenci na różnych poziomach mają przypisane różne wymagania governance. Podział reguł compliance według poziomu ryzyka sprawia, że zespoły biznesowe czują: „compliance nie blokuje mnie na każdym kroku”.

Łączny wniosek z tych trzech kwestii: wbudowanie compliance to nie dodanie kolejnego procesu, tylko przeprojektowanie struktury i mechanizmów motywacyjnych zespołu. Jeśli Twój dział compliance wciąż działa w trybie „kontroli po fakcie”, wdrożenie sterowania regułami utknie na najtrudniejszym etapie — „instytucjonalizacji”. Najpierw compliance musi przejść transformację, żeby zespoły biznesowe mogły płynnie działać w modelu sterowania regułami.

6. Pytania, które możesz sobie zadać

„Mamy już standardy kodowania — czym to się różni?”

Standardy kodowania określają „jak pisać kod”, a sterowanie regułami określa „jak współpracować z AI”. Standardy kodowania nie obejmują: reguł biznesowych, wymogów compliance ani polityk korzystania z AI. Sterowanie regułami to ujęcie w jawną formę całego procesu współpracy człowieka z AI — a nie stylistyczny przewodnik po kodzie.

„Czy pisanie standardów spowolni tempo prac developerskich?”

Krótkoterminowo – tak, długoterminowo – nie. Dane CodeRabbit dają jednoznaczną odpowiedź: nieograniczony regulacjami kod generowany przez AI niesie ze sobą ok. 1,7-krotnie wyższe ryzyko wystąpienia defektów oraz 2,74-krotnie wyższe ryzyko podatności bezpieczeństwa. W sektorze finansowym jeden cykl poprawek po audycie zgodności to 2–4 tygodnie pracy – oszczędzisz sobie jednego takiego cyklu, a zyskany czas wystarczy na spisanie standardów na cały miesiąc. Oszczędności rzędu 250 mln USD w EY to dowód, że wdrożenie tych praktyk na poziomie całej organizacji realnie przekłada się na wyniki biznesowe.

„A co, jeśli w naszym zespole nikt nie umie pisać standardów?”

Nie musisz zaczynać od zera. GitHub Spec Kit, Claude Code Superpowers czy AWS Kiro oferują gotowe szablony. Wystarczy uzupełnić je o reguły specyficzne dla Waszej organizacji – w większości będą to zasady compliance i bezpieczeństwa, które Wasze działy prawne i bezpieczeństwa już dawno spisały. Problem w tym, że nikt dotąd nie umieścił ich w miejscu, do którego AI ma dostęp.

„Na rynku jest tyle narzędzi AI – które wybrać?”

Nieważne. Wybierzcie to, czego już używacie. Reguły są ważniejsze niż narzędzia — CLAUDE.md działa w Claude Code, Cursor i Codex; AGENTS.md zadziała w ekosystemie OpenAI; constitution.md jest niezależny od modelu. Klucz to spisać zasady, a nie zmieniać narzędzia. EY wdraża to w ekosystemie Microsoft, Atos też — różnice w wyborze narzędzi są tylko powierzchowne, liczy się spójne zarządzanie governance.

“W sierpniu 2026 r. w pełni wchodzi w życie unijny akt o sztucznej inteligencji (EU AI Act) — czy to nas dotyczy?”

Tak. EU AI Act wchodzi w pełną fazę egzekwowania 2 sierpnia 2026 r., nakładając obowiązkowe wymogi zgodności na systemy AI wysokiego ryzyka (w tym scoring kredytowy, wyceny ubezpieczeń, selekcję kandydatów do pracy oraz infrastrukturę krytyczną) — zarządzanie ryzykiem (art. 9), governance danych (art. 10), przejrzystość dokumentacji (art. 11–13), nadzór człowieka (art. 14), dokładność/odporność (art. 15). Maksymalne kary sięgają 35 mln EUR lub 7% globalnych przychodów. Dla chińskich firm ekspandujących za granicę rynek UE to obowiązkowy sprawdzian; dla firm działających lokalnie ramy EU AI Act są też najczęściej punktem odniesienia na świecie — możesz nie podlegać im bezpośrednio, ale trudno uniknąć ich wpływu pośredniego na Twoich dostawców, partnerów i działalność transgraniczną (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

„Odpowiednik w Chinach: UE reguluje AI, a co my?”

Krajowe podejście do generatywnej AI opiera się na trzech filarach: „rejestracja algorytmów + kontrola korpusów treningowych + ocena bezpieczeństwa”. Kluczowym aktem prawnym są tymczasowe środki zarządzania usługami generatywnej sztucznej inteligencji, obowiązujące od sierpnia 2023 r. Największa różnica między oboma systemami nie leży w szczegółowości przepisów, ale w filozofii legislacyjnej:

Wymiar	EU AI Act	Chińskie „Środki zarządzania usługami generatywnej AI”
Charakter prawny	Regulacja horyzontalna (obejmuje wszystkie systemy AI)	Regulacja sektorowa (koncentruje się na usługach generatywnej AI)
Klasyfikacja ryzyka	4 poziomy (niedopuszczalne / wysokie / ograniczone / minimalne)	2 poziomy (dotyczące bezpieczeństwa opinii publicznej / ogólne zastosowanie komercyjne)
Moment nadzoru	Ex ante (rejestracja już na etapie opracowywania)	Ex post (rejestracja po wdrożeniu + rejestracja algorytmów)
Transparentność	Wysoka (obowiązek publikacji streszczenia źródeł danych treningowych, karty modelu)	Średnia (wymóg zgodności korpusów danych, ale bez obowiązku ujawniania źródeł)
Maksymalne kary	7% globalnego przychodu lub 35 mln EUR	Zawieszenie usługi / grzywna (zwykle wielokrotność bezprawnego zysku)
Zakres stosowania	Wszystkie przedsiębiorstwa powyżej progu globalnego przychodu	Wszystkie podmioty świadczące usługi na terytorium Chin

W praktyce systemy AI w chińskich instytucjach finansowych podlegają zwykle trzem równoległym reżimom regulacyjnym — „Środkom zarządzania generatywną AI” (warstwa podstawowa) + „Środkom zarządzania bankowością internetową banków komercyjnych” (warstwa biznesowa) + 等保 (klasyfikacja ochrony bezpieczeństwa informacji) + algorytmiczna rejestracja (warstwa zgodności). To oznacza, że w Chinach nie można mechanicznie przenieść ram EU AI Act — trzy lokalne osie, czyli „zgodność korpusów treningowych + rejestracja algorytmów + raportowanie regulacyjne”, trzeba w całości zapisać w pliku CLAUDE.md.

Dla firm wchodzących na rynek globalny: cztery filary EU AI Act — „zarządzanie ryzykiem + ład danych + przejrzystość dokumentacji + nadzór człowieka” — to kierunek, do którego stopniowo zbliżają się także chińscy regulatorzy. Już w 2025 roku kilka odpowiedzi na zgłoszenia rejestracyjne generatywnej AI wydanych przez Cyberspace Administration of China wyraźnie czerpało z poziomu szczegółowości rozwiązań unijnych. Jeśli dziś piszesz specyfikacje zgodne z EU AI Act, z dużym prawdopodobieństwem będą one kompatybilne również z zaostrzającym się reżimem w Chinach w ciągu najbliższych 3 lat (ogłoszenia o rejestracji CAC 2025–2026; zgodność z EU AI Act czerwiec 2026).

7. Wnioski dla decydentów

Wniosek pierwszy: napisanie specyfikacji projektowej CLAUDE.md/AGENTS.md to najwyższy zwrot z inwestycji w inżynierii w erze AI.

Jego nakładem jest 3–8 tygodni porządkowania + 1–2 tygodnie dokumentacji. Zwrot: górna granica ryzyka defektów ok. 1,7×, luki bezpieczeństwa mniejsze 2,74×, spadek liczby poprawek o 40%+. W sektorze finansowym jedno uniknięcie powtórnego przeglądu compliance (2–4 tygodnie) pokrywa ten koszt. EY wdrożyło Copilota dla 150 tys. osób i zaoszczędziło 250 mln USD — ale pod warunkiem, że najpierw miało uporządkowane standardy.

Wniosek drugi: standaryzacja to kompetencja organizacji, nie wybór narzędzia.

Nieważne, czy wybierzesz GitHub Spec Kit, czy Claude Code. Liczy się to, czy masz zdefiniowane „jak nasza organizacja współpracuje z AI”. Bez tego nawet najlepsze narzędzie sprawi tylko, że zespół będzie szybciej generować dług techniczny.

Wniosek trzeci: zapisz standardy w procesach organizacji, nie polegaj na jednostkach.

Jeśli standardy żyją tylko w głowie jednego seniora, znikną, gdy on odejdzie. Trzeba je osadzić w dokumentacji repozytorium, bramkach CI, współdzielonej konfiguracji zespołu i platformie zarządzania agentami. Standardy mają być aktywem organizacji, nie umiejętnością jednostki. Atos uruchamia 19 000 agentów w 54 krajach, bo governance to nie „ktoś to rozumie”, tylko „system to wymusza”.

Wniosek czwarty: bramki jakości są ważniejsze niż szybkość.

GitHub Spec Kit z pięcioma bramkami etapowymi, zasada Superpowers „nie pisz kodu, dopóki test nie zakończy się porażką”, wymóg Kiro „nie zaczniesz bez specyfikacji” — wszystko to sprowadza się do jednego: hamulec między AI a finalnym rezultatem. Im silniejsze możliwości AI, tym wcześniej musi pojawić się governance. Te 78% awarii z raportu New Relic 2026 to cena, jaką płaci 62% zespołów, które „wdrażają bez przeglądu”. CIO w sektorze finansowym rozumieją to najlepiej: wasz Change Advisory Board (CAB), proces rejestracji algorytmów, ocena zgodności z wymogami bezpieczeństwa — wszystko to są bramki przed wdrożeniem produkcyjnym. Kod generowany przez AI wymaga podobnych bramek, tyle że postawionych znacznie wcześniej.

Szybki test kontrolny (bez upiększania): czy przegląd zgodności kodu generowanego przez AI często kończy się poprawkami? Jaki był ostatni problem spowodowany przez kod z AI? Jeśli zapytasz lidera technicznego „jak współpracujemy z AI”, czy pokaże ci dokument? Jeśli choć na jedno z trzech pytań nie znasz odpowiedzi, to znak, że podejście oparte na specyfikacjach jeszcze nie wdrożyło się w życie — najpierw specyfikacje, potem narzędzia.

Trzy pytania coachingowe dla decydentów

Na koniec trzy pytania — to nie lista kontrolna, tylko gotowe punkty wyjścia do rozmowy z zespołem:

„Gdyby jutro wszystkie narzędzia AI zniknęły, o ile spadłaby jakość kodu w waszym zespole?” — to pytanie ujawnia realną wartość podejścia sterowanego specyfikacjami. Jeśli odpowiedź brzmi „znacząco”, Twoje standardy nie są jeszcze wystarczająco ugruntowane. Jeśli brzmi „prawie wcale” — specyfikacje już realnie napędzają pracę zespołu.
„Czy w Waszym projekcie opartym na specyfikacjach dział compliance jest ’bramkarzem’ czy ’enablerem’?” — jeśli odpowiedź to „bramkarz”, tempo wdrażania rozwiązań będzie blokowane przez wąskie gardła w procesach zatwierdzania. Jeśli „enabler” — jesteście już na właściwej ścieżce opisanej w sekcji 5.2.
„Jak zmieni się wielkość Waszego zespołu w perspektywie 12–18 miesięcy?” — według raportu Microsoft WTI 2026, 82% liderów planuje „skalować” siłę roboczą za pomocą agentów AI. Jeśli Twoja odpowiedź to „bez zmian”, oznacza to albo brak wzrostu biznesu, albo organizację, która nie nadąża za korzyściami płynącymi ze specyfikacji.

Na te trzy pytania nie ma jednej słusznej odpowiedzi. Ale kierunek, w którym zmierzają Twoje odpowiedzi, jest ważniejszy niż same odpowiedzi.

Co dalej

To szósta część serii o transformacji inżynierii oprogramowania w erze AI. Zaczęliśmy od prawa Conwaya (struktura organizacji determinuje architekturę), przeszliśmy przez Team Topologies (jak projektować zespoły), następnie omówiliśmy przesunięcie wąskiego gardła (z kodowania na walidację), a dziś skupiliśmy się na sterowaniu specyfikacjami (używaniu dokumentacji do kierowania zachowaniem AI).

Następny artykuł (siódmy) przyjrzymy się fundamentowi, na którym to wszystko się opiera — protokołowi MCP (Model Context Protocol): dlaczego otwarty standard od Anthropic nazywany jest „USB-C dla AI”, dlaczego OpenAI, Google i Microsoft wszyscy za nim podążają, oraz jak umożliwia interoperacyjność wielu narzędzi i wielu agentów.

Chcesz wdrożyć to podejście w swojej firmie?

Gdy standardy oparte na regułach trafiają do przedsiębiorstwa, zwykle trzeba rozwiązać kilka konkretnych problemów: jak ująć kluczowe zasady w plikach CLAUDE.md / AGENTS.md, jak uzupełnić standardy w istniejącym kodzie, jak wbudować zgodność z regulacjami oraz jakie wskaźniki przyjąć do oceny pilotażu.

Obecnie oferujemy trzy formy współpracy:

Szkolenia wewnętrzne: w oparciu o rzeczywiste projekty w Twojej firmie — opracowanie dokumentacji standardów, zaprojektowanie bramek CI, ścieżki wbudowania zgodności oraz budowa mechanizmów zarządczych.
Konsultacje specjalistyczne: skupione na konkretnej decyzji, np. „czy nasza firma powinna najpierw napisać CLAUDE.md / AGENTS.md” lub ustalenie priorytetów dostosowania istniejącego kodu do wymogów.
Sesje dla kadry zarządzającej i wystąpienia branżowe: wokół narzędzi AI do programowania, standardów opartych na regułach, zarządzania organizacją oraz firm z czołówki rynku (Frontier Firms).

Artykuł dostarcza uniwersalnych ram, ale konkretne wdrożenie wymaga przeprojektowania w oparciu o wymogi compliance, granice regulacyjne, dojrzałość inżynieryjną i istniejące procesy dostarczania oprogramowania w danej organizacji. Współpraca: coach@iaiuse.com.

Polecana lektura: „Metodologia Znaku Firmowego v1.0” (Learn AI Slowly 187) — systematyczne omówienie 7-etapowych ram transformacji AI w przedsiębiorstwie.

O serii

„Transformacja inżynierii oprogramowania w erze AI” to seria badawcza skierowana do CIO, CDO, CTO oraz liderów transformacji cyfrowej w branżach telekomunikacyjnej, finansowej, produkcyjnej i e-commerce. Cykl obejmuje 18 artykułów, koncentrując się na wpływie narzędzi AI do programowania, podejścia opartego na specyfikacjach oraz ładu organizacyjnego na procesy dostarczania oprogramowania, strukturę organizacyjną i dojrzałość inżynieryjną.

Seria na bieżąco śledzi publikacje naukowe, materiały producentów i raporty branżowe. Baza badawcza obejmuje ponad 200 pozycji, a kluczowe wnioski są opatrzone poziomem dowodowości, aby odróżnić zweryfikowane fakty, deklaracje producentów, obserwacje branżowe od autorskich analiz.

Mam ponad 8 lat doświadczenia w doradztwie dla dużych przedsiębiorstw i analityce biznesowej. Pracowałem w IBM, uczestnicząc w projektach dla sektora telekomunikacyjnego, finansowego, ubezpieczeniowego i produkcyjnego. Następnie rozwijałem się na pierwszej linii — w produktach operatorskich, internetowych i aplikacjach AI — zajmując się analizą wymagań, projektowaniem produktów i wdrożeniami międzyzespołowymi.

Ten artykuł to seria przemyśleń na temat podejścia opartego na regulacjach, ładu organizacyjnego i inżynierii — wywodzących się z praktyki, weryfikowanych krzyżowo z publicznymi badaniami i case studies z branży. Wszystkie treści dotyczące konkretnych projektów zostały zanonimizowane; część scenariuszy branżowych to analiza typowych przypadków, a źródła podano na końcu artykułu.

Za tym blogiem stoi właściwie mały zespół — ja i 1–2 osoby, z którymi długoterminowo współpracuję. Każde z nas odpowiada za inny obszar: badania nad narzędziami AI do programowania, analiza case studies z zakresu ładu organizacyjnego, rozmowy coachingowe. Większość projektów, o których piszemy, że „przeprowadziliśmy firmy przez nie”, to projekty, które realizowaliśmy wspólnie. Nadal nie ujawniamy nazw klientów ani osób — ze względu na granice zgodności i prywatności; anonimowość zostawiamy też jako przestrzeń dla przyszłych współpracowników.

Źródła (zweryfikowane, z określeniem poziomu dowodów dla każdej pozycji)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. Kod generowany przez AI zawiera 1,7× więcej problemów niż kod pisany przez człowieka (10,83 vs 6,45 problemów na PR), w tym: logika/poprawność 1,75×, jakość kodu 1,64×, bezpieczeństwo 1,57×, obsługa haseł 1,88×, XSS 2,74×. Poziom dowodów: pierwszy. Źródło: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (2025.12.17). Relacja z pełnego raportu CodeRabbit: analiza 470 open-source’owych PR-ów wykazała, że PR-y tworzone przy współpracy z AI zawierają średnio 10,83 problemów, podczas gdy w przypadku czysto ludzkiej pracy jest to 6,45. Poziom dowodów: drugi. Źródło: jak wyżej.
CodeRabbit / David Loker (2026.1). „2026 Predictions: The Speed Trap” – rok 2026 to punkt zwrotny: od „szybkości generowania kodu” do „jakości kodu i zarządzania ryzykiem”. Poziom wiarygodności: drugi. Źródło: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. 78% zespołów zgłasza więcej incydentów po wdrożeniu kodu napisanego przez AI; 62% liderów technicznych przyznaje, że ich zespoły „z pełnym przekonaniem wdrażają kod AI bez przeglądu”; 96% uważa obserwowalność za niezbędną. Poziom wiarygodności: pierwszy (raport producenta). Źródło: https://newrelic.com/resources/report/2026-state-of-ai-coding
Raport roczny Microsoft 2026 Work Trend Index (5.05.2026). Badanie objęło 20 000 pracowników korzystających z AI w 10 krajach; 82% liderów planuje w ciągu 12–18 miesięcy rozszerzyć siłę roboczą o agentów AI; 81% spodziewa się średniego lub dużego stopnia integracji agentów; 24% wdrożyło je już na poziomie całego przedsiębiorstwa; 49% rozmów z Copilot wspiera pracę poznawczą; 58% użytkowników AI twierdzi, że robi rzeczy, które rok wcześniej były poza ich zasięgiem, a wśród profesjonalistów z czołówki (Frontier Professionals) odsetek ten wzrasta do 80%. Poziom wiarygodności: pierwszy. Źródło: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Retrospektywa Microsoft FY26: od eksperymentów z AI do transformacji na miarę granic możliwości (28.07.2026). Firma EY wdrożyła Microsoft 365 Copilot dla 150 000 pracowników, oszczędzając 2,5 miliona godzin i około 250 milionów dolarów; następnie rozszerzyła wdrożenie na 400 000 pracowników na całym świecie, osiągając 95% przyspieszenia pracy, 37% redukcji kosztów operacyjnych w finansach i nawet 90% redukcji ręcznych przepływów pracy. Atos wdrożył Copilot dla 56 000 pracowników w 56 krajach oraz 19 000 agentów AI, z ujednoliconą płaszczyzną kontroli tożsamości, bezpieczeństwa, zgodności i ładu korporacyjnego. Poziom dowodów: pierwszy (oficjalna retrospektywa Microsoft). Źródło: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Współpraca strategiczna Atos Group i Microsoft (2026.06.09). Atos wdraża Microsoft 365 E7 (Frontier Suite) dla 56 000 pracowników w 56 krajach oraz 19 000 agentów AI; ujednolicona płaszczyzna zarządzania Entra/Defender/Intune/Purview/Agent 365. Poziom wiarygodności: pierwszy (wspólny komunikat prasowy obu firm). Źródło: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (open-source 2025.9, evolving through 2026 H1). A 5-stage gated workflow /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; model-agnostic (works with Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Evidence level: primary. Source: https://github.com/github/spec-kit
AWS Kiro (released 2025.7, evolving through 2026 H1). A three-stage workflow: requirements → design → tasks; the spec triggers predefined agent actions; without a spec, the workflow won’t start. Evidence level: primary. Source: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025–2026). Codex w czerwcu 2026 r. przekroczył 5 mln aktywnych użytkowników tygodniowo, z czego 20% to osoby niebędące programistami; AGENTS.md + Skills tworzą komponowalny zestaw instrukcji. Poziom wiarygodności: pierwszy (oficjalne ogłoszenie OpenAI). Źródło: https://developers.openai.com/codex/skills
Claude Code (Anthropic, I poł. 2026). System oparty na CLAUDE.md + .claude/rules/ + Skills; w lutym 2026 r. trafił do oficjalnego marketplace Anthropica; repozytorium Skills na GitHubie zdobyło 112 tys. gwiazdek; w lutym 2026 r. ujawniono w ramach rundy G 2,5 mld USD rocznych przychodów. Poziom wiarygodności: pierwszy. Źródło: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). Badanie obejmujące ponad 10 000 profesjonalnych programistów na całym świecie, zlokalizowane na 8 języków; Claude Code CSAT 91% / NPS 54 (najwyższe w branży); wskaźnik adopcji Claude Code w miejscu pracy 18% (wzrost 6-krotny z 3% w ciągu 9 miesięcy), w Ameryce Północnej 24%; Copilot 29% adopcji w miejscu pracy, ale wzrost zatrzymany; Cursor 18%. Poziom dowodów: pierwszy. Źródło: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). Badanie 15 000 programistów; 46% wybrało Claude Code jako “najbardziej lubiane narzędzie”, Cursor 19%, Copilot 9%. Poziom dowodów: pierwszy. Źródło: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). W sierpniu 2025 r. Alibaba wypuściło Qoder; 15 maja 2026 r. Qoder 1.0 ewoluował do Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; 28 maja 2026 r. Cloud Agents (zarządzane środowisko uruchomieniowe dla agentów); 21 lipca 2026 r. Qoder Security; w maju 2026 r. ponad 5 mln użytkowników na świecie; integracja z CLI w DingTalk; 20 maja 2026 r. Tongyi Lima została przemianowana na Qoder CN. Poziom wiarygodności: pierwszy. Źródła: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (2026 H1). Polecenia pięcioetapowego Spec Kita, porównanie narzędzi SDD, notacja EARS. Poziom dowodów: drugi (oceny zewnętrzne). Źródło: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (pełne wdrożenie od 2.08.2026). Termin zgodności dla systemów AI wysokiego ryzyka upływa 2.08.2026; istniejące modele GPAI mają czas do 2.08.2027; maksymalne kary to 35 mln EUR lub 7% globalnego przychodu; art. 9–15 obejmują zarządzanie ryzykiem, zarządzanie danymi, przejrzystość dokumentacji, nadzór człowieka oraz dokładność i solidność. Poziom dowodów: pierwszy (rozporządzenie + analiza zgodności drugiego poziomu). Źródło: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). 44% problemów wynika z braku kontekstu. Poziom dowodów: drugi (raport dostawcy). Źródło: https://www.qodo.ai/reports/state-of-ai-code-quality/

Czytaj AI Slowly 001: AI w sektorze telekomunikacji

W dzisiejszym świecie, gdzie technologie AI są coraz bardziej powszechne, CIO i decydenci z sektora telekomunikacji muszą być świadomi możliwości i wyzwań związanych z implementacją AI w swoich organizacjach.

W tym artykule, będziemy omawiać najważniejsze aspekty implementacji AI w sektorze telekomunikacji, w tym:

Ocena ryzyka: Jak ocenić ryzyko związane z implementacją AI w swojej organizacji?
Zarządzanie danymi: Jak zapewnić bezpieczeństwo i prywatność danych w czasie implementacji AI?
Wdrożenie: Jak wdrożyć AI w swojej organizacji, aby osiągnąć oczekiwane wyniki?

Przykład: AT&T, jeden z największych operatorów telekomunikacyjnych na świecie, wykorzystuje AI w swojej sieci do poprawy jakości usług i zwiększenia efektywności.

Zarządzanie ryzykiem: Jak ocenić ryzyko związane z implementacją AI w swojej organizacji?

Wdrożenie AI w organizacji wiąże się z pewnymi ryzykami, takimi jak:

Ryzyko technologiczne: Jak zapewnić, że AI będzie działać sprawnie i bezawaryjnie?
Ryzyko biznesowe: Jak zapewnić, że AI będzie przynosić korzyści finansowe organizacji?

Zarządzanie danymi: Jak zapewnić bezpieczeństwo i prywatność danych w czasie implementacji AI?

AI wymaga dostępu do dużych ilości danych, aby działać efektywnie. Jednak, aby zapewnić bezpieczeństwo i prywatność danych, należy:

Zapewnić bezpieczeństwo danych: Jak zapewnić, że dane będą chronione przed nieuprawnionym dostępem?
Zapewnić prywatność danych: Jak zapewnić, że dane będą przetwarzane zgodnie z prawem?

Wdrożenie: Jak wdrożyć AI w swojej organizacji, aby osiągnąć oczekiwane wyniki?

Wdrożenie AI w organizacji wymaga:

Planowanie: Jak zaplanować wdrożenie AI w swojej organizacji?
Koordinacja: Jak zapewnić, że wszystkie zespoły będą współpracować w celu wdrożenia AI?
Monitorowanie: Jak monitorować postępy wdrożenia AI i dostosowywać go do potrzeb organizacji?

Wdrożenie AI w organizacji może przynieść wiele korzyści, takich jak:

Poprawa efektywności: Jak AI może pomóc w poprawie efektywności organizacji?
Poprawa jakości usług: Jak AI może pomóc w poprawie jakości usług w organizacji?
Zwiększenie zysków: Jak AI może pomóc w zwiększeniu zysków organizacji?

W tym artykule, omówiliśmy najważniejsze aspekty implementacji AI w sektorze telekomunikacji. Pamiętaj, że AI może przynieść wiele korzyści, ale również wiąże się z pewnymi ryzykami. Dlatego, aby osiągnąć oczekiwane wyniki, należy odpowiednio ocenić ryzyko, zapewnić bezpieczeństwo i prywatność danych, a także wdrożyć AI w swojej organizacji.