- Gdzie człowiek musi zatwierdzać decyzje agenta AI? Bramki akceptacji w agentic engineering - 16 października 2026
- Deterministic guardrails w agentic CRM – jak nie stracić kontroli nad autonomicznym agentem - 8 września 2026
- Headless CRM i integracje API – czy CRM przestaje być interfejsem, a staje się silnikiem danych dla agentów AI? - 7 września 2026
Bramki akceptacji to wyznaczone momenty w pracy agenta AI, w których człowiek sprawdza plan albo wynik i decyduje, czy agent może iść dalej. W agentic engineering agent AI samodzielnie planuje, pisze kod i testuje zmiany, ale decyzje trudne do odwrócenia albo zmieniające kierunek zadania zatwierdza człowiek. Pokazujemy, gdzie umieszczamy bramki akceptacji w naszym procesie wytwarzania oprogramowania, co w nich sprawdzamy i jak mogą zawieść.
Czym są bramki akceptacji w agentic engineering?
Bramka akceptacji to punkt w procesie, w którym agent AI zatrzymuje się, przedstawia człowiekowi swoją propozycję albo wynik pracy i czeka na decyzję. W naszym procesie, opartym na Claude firmy Anthropic, działają dwa rodzaje bramek akceptacji. Pierwszy to bramki stałe, wbudowane w proces: akceptacja planu implementacji, sprawdzenie zmiany przed commitem, code review i testy akceptacyjne. Drugi to zatrzymania inicjowane przez samego agenta, gdy napotyka niejasność albo nie potrafi rozwiązać problemu.
Bramki akceptacji odpowiadają na konkretny problem: kod generowany przez AI często wygląda poprawnie, ale nie jest. W badaniu Stack Overflow Developer Survey 2025 66% deweloperów wskazało jako główną frustrację rozwiązania AI, które są „prawie dobre, ale nie do końca” (Stack Overflow, 2025). Raport Google DORA 2025 wiąże z kolei adopcję AI z wyższą przepustowością zespołów, ale też z mniejszą stabilnością dostarczanego oprogramowania (Google DORA, 2025).
Czym różnią się bramki akceptacji od guardrails?
Guardrails to automatyczne ograniczenia, które blokują niedozwolone działania agenta AI bez udziału człowieka, a bramka akceptacji to moment, w którym decyzję podejmuje człowiek. Guardrail może na przykład zablokować zapis do określonej tabeli albo odrzucić odpowiedź spoza dozwolonego zakresu. Bramka akceptacji służy do ocen, których nie da się zapisać w regule: czy plan ma sens biznesowy, czy zmiana nie narusza architektury, czy agent dobrze zrozumiał User Story.
Oba mechanizmy się uzupełniają. Guardrails chronią przed znanymi, przewidywalnymi błędami i działają za każdym razem tak samo. Bramki akceptacji wyłapują błędy, których nikt wcześniej nie przewidział, ale zależą od uwagi człowieka. Dojrzały system agentowy potrzebuje obu warstw. Więcej o deterministycznych zabezpieczeniach w systemach CRM piszemy w artykule o guardrails w agentic CRM.
Które decyzje agenta AI wymagają zatwierdzenia człowieka?
Zatwierdzenia człowieka wymagają decyzji, które są trudne do odwrócenia, mają szeroki zasięg, dotyczą dostępu do danych i środowisk albo przesądzają o zgodności zmiany z intencją biznesową. Decyzje odwracalne, lokalne i łatwe do sprawdzenia testem agent AI może podejmować sam. To kryterium jest bliskie logice art. 14 AI Act, według którego nadzór człowieka ma być proporcjonalny do ryzyka, poziomu autonomii i kontekstu użycia systemu (AI Act, art. 14).
Przepis dotyczy systemów AI wysokiego ryzyka, a nie narzędzi deweloperskich, ale sama zasada proporcjonalności dobrze sprawdza się przy projektowaniu bramek akceptacji. Bramka przy każdej drobnej decyzji spowalnia pracę i uczy ludzi klikać „akceptuj” bez czytania. Brak bramki przy decyzji o dużym zasięgu oznacza, że błąd agenta przechodzi do kodu, testów i dokumentacji. Poniżej pokazujemy, jak ten podział wygląda w naszym procesie.
| Decyzja agenta AI | Agent sam czy bramka akceptacji | Dlaczego |
| Analiza User Story i kodu projektu | agent sam | brak skutków ubocznych |
| Pisanie i uruchamianie testów | agent sam | wynik jest weryfikowalny, działanie odwracalne |
| Poprawki w pętli testów | agent sam, do 3 prób, potem eskalacja | limit chroni przed krążeniem w kółko |
| Plan implementacji i zakres zmiany | bramka: deweloper | błąd planu powiela się w kodzie i testach |
| Decyzje architektoniczne | bramka: deweloper | wpływ na aktualizacje i utrzymanie systemu |
| Commit zmiany | bramka: deweloper | kod trafia do wspólnego repozytorium |
| Merge do gałęzi develop | bramka: senior po code review | wpływ na pracę zespołu i środowisko testowe |
| Połączenie z innym systemem lub instancją | decyzja człowieka | ryzyko pracy na niewłaściwych danych |
| Uznanie zmiany za gotową | bramka: tester | ostatnie słowo przed wydaniem |
Gdzie w procesie wytwarzania oprogramowania umieszczamy bramki akceptacji?
W naszym procesie wytwarzania oprogramowania z agentami AI są cztery stałe bramki akceptacji: plan implementacji, sprawdzenie zmiany przed commitem, code review i testy akceptacyjne. Każda ma właściciela i jasno określony przedmiot oceny. Kolejność kroków pilnuje orkiestrator, czyli skill Claude’a prowadzący zadanie od zgłoszenia w Redmine do środowiska testowego. Orkiestrator nie pozwala przeskoczyć bramki: agent nie zaczyna implementacji przed akceptacją planu. Cały proces opisujemy w artykule: https://evolpe.pl/wytwarzanie-oprogramowania-z-agentami-ai/.
| Bramka akceptacji | Kto decyduje | Co sprawdza | Co się dzieje przy odrzuceniu |
| Plan implementacji | deweloper | zakres zmiany, zgodność z User Story, wpływ na istniejące procesy, architekturę | agent poprawia plan, a decyzje trafiają do User Story w Redmine |
| Sprawdzenie przed commitem | deweloper | zgodność zmiany z planem, raport weryfikacji i wyniki testów | agent poprawia kod i ponownie uruchamia testy |
| Code review | senior deweloper | raport z automatycznego code review skonfrontowany z kodem | zgłoszenie w Redmine, implementator ocenia zasadność uwag |
| Testy akceptacyjne | tester | kompletność scenariuszy, działanie procesów powiązanych | błąd w Redmine, poprawka z testami regresji |
Dlaczego najważniejszą bramką akceptacji jest plan?
Najważniejszą bramką akceptacji jest akceptacja planu, bo błąd zatrzymany przed implementacją kosztuje najmniej. Każdy etap pracy agenta AI zostawia po sobie artefakty, czyli zapisane ślady pracy: plan, raport z weryfikacji, raport z code review i poprawki naniesione przez dewelopera. Analiza tych artefaktów z naszych projektów pokazuje, że plan zaproponowany przez agenta często wymaga korekty.
Bywa, że Claude proponuje zmianę bezpośrednio w plikach rdzenia systemu zamiast w warstwie rozszerzeń, przeznaczonej na modyfikacje. Rozwiązanie działałoby, ale zniknęłoby przy najbliższej aktualizacji. Agent bywa też zbyt zachowawczy albo zbyt ambitny: pomija element, który użytkownik uzna za oczywisty, albo rozszerza zmianę poza zakres User Story. Zdarza się wreszcie, że analiza kodu ujawnia, że zmiana zepsułaby dwa istniejące procesy, których nikt wcześniej nie zauważył.
Gdyby taki plan przeszedł bez akceptacji, agent AI napisałby do niego kod, testy i raport – wszystko spójne, ale oparte na błędnym założeniu. Testy by przechodziły, bo sprawdzają to, co agent zaplanował, a nie to, czego potrzebuje użytkownik. Dlatego w bramce planu deweloper nie sprawdza szczegółów kodu, tylko kierunek: czy agent dobrze zrozumiał zadanie i czy proponowana droga jest zgodna z architekturą systemu.
Kiedy agent AI powinien sam zatrzymać się i zapytać człowieka?
Agent AI powinien sam zatrzymać się, gdy brakuje mu informacji do podjęcia decyzji, gdy pojawia się konflikt między wymaganiami albo gdy nie potrafi rozwiązać problemu w ustalonym limicie prób. W naszym procesie Claude zadaje pytania już na etapie analizy User Story, ale może zatrzymać się w dowolnym momencie – na przykład, gdy po code review okazuje się, że zmianę trzeba wykonać zupełnie inaczej niż w zaakceptowanym planie.
Druga sytuacja to eskalacja. Weryfikacja kodu działa w pętli: agent pisze test, uruchamia go i poprawia kod, jeśli test nie przechodzi. Liczba prób jest ograniczona do trzech. Po trzeciej nieudanej próbie agent AI przerywa pracę i raportuje człowiekowi, co próbował i gdzie utknął. Bez takiego limitu agent mógłby krążyć w pętli bez końca albo „naprawić” test zamiast kodu.
Odpowiedzi człowieka nie mogą zostać tylko w rozmowie z agentem. Claude dopisuje decyzje podjęte w trakcie pracy do User Story w Redmine, także te ustalone z analitykiem na czacie. Dzięki temu po kilku miesiącach wiadomo, dlaczego zmiana wygląda tak, a nie inaczej, a kolejna bramka akceptacji – na przykład code review – ocenia kod na podstawie aktualnych wymagań.
Jak bramki akceptacji chronią przed błędami w dostępach i środowiskach?
Bramki akceptacji chronią przed sytuacją, w której agent AI działa na niewłaściwym systemie albo danych, bo decyzję o połączeniach podejmuje człowiek, a nie agent. W jednym z naszych projektów deweloper miał podłączony przez MCP dostęp do systemu, którego dotyczyło zadanie. Claude uznał, że może analizować dane w podłączonej instancji – tyle że była to wewnętrzna instancja produkcyjna eVolpe, a nie środowisko projektu. Deweloper zatrzymał agenta od razu.
Z tej sytuacji wyciągnęliśmy trzy zasady. Po pierwsze, minimalne uprawnienia: agent AI ma dostęp tylko do narzędzi i systemów potrzebnych do bieżącego zadania. Po drugie, rozdzielone środowiska: instancje produkcyjne nie powinny być podłączone tam, gdzie agent pracuje nad kodem. Po trzecie, każde nowe połączenie z systemem albo danymi to decyzja człowieka. Bramka akceptacji nie zastąpi tych zasad, ale wyłapuje przypadki, które je obeszły.
Na podstawie czego człowiek podejmuje decyzję w bramce akceptacji?
Człowiek podejmuje decyzję w bramce akceptacji na podstawie dowodów, a nie deklaracji agenta AI. W naszym procesie są to artefakty: plan implementacji, raport weryfikacji z wynikami testów jednostkowych i przeglądarkowych, raport z automatycznego code review oraz lista tego, czego agent nie sprawdził. Raport weryfikacji zawiera też informację, co agent świadomie pominął i dlaczego.
Przykład z code review: automatyczny przegląd kodu uruchamia się na osobnym serwerze, a senior dostaje gotowy raport. Nie zaczyna od zera, tylko konfrontuje raport z kodem i ocenia, czy agent był zbyt skrupulatny albo czy coś przeoczył. Potwierdzone uwagi trafiają do implementatora, który decyduje, które są zasadne. Czasem uwaga dotyczy zachowania zgodnego z założeniami User Story i wtedy poprawki nie ma.
Jak bramki akceptacji mogą zawieść?
Bramki akceptacji zawodzą najczęściej wtedy, gdy człowiek zatwierdza odruchowo. To zjawisko nazywa się automation bias, czyli skłonność do nadmiernego polegania na wynikach systemu automatycznego. AI Act wprost wymaga, by osoby sprawujące nadzór były świadome tego ryzyka (AI Act, art. 14 ust. 4 lit. b), a analizy prawne wskazują, że skuteczność nadzoru człowieka ograniczają m.in. właśnie automation bias i ograniczenia poznawcze (Fink, 2025).
Dwa pozostałe ryzyka to zbyt wiele bramek, które spowalniają pracę i zaczynają być traktowane jak formalność, oraz bramki bez jasnego kryterium, gdy człowiek nie wie, co właściwie ma sprawdzić. Dlatego umieszczamy bramki akceptacji tylko tam, gdzie decyzja ma znaczenie, każdej przypisujemy właściciela i przedmiot oceny, a raporty agenta skracamy do informacji potrzebnych do decyzji.
Najczęściej zadawane pytania
Bramka akceptacji to punkt w procesie, w którym agent AI zatrzymuje się i czeka na decyzję człowieka – na przykład akceptację planu implementacji albo zmiany przed commitem. Bez tej decyzji agent nie przechodzi do kolejnego etapu.
W naszym procesie nie. Agent AI planuje, pisze i testuje kod, ale plan akceptuje deweloper, kod ocenia senior w code review, a działanie potwierdza tester. Zmiana trafia do gałęzi develop dopiero po przejściu bramek akceptacji.
Tyle, ile jest decyzji trudnych do odwrócenia lub o szerokim zasięgu. U nas to cztery stałe bramki: plan, sprawdzenie przed commitem, code review i testy akceptacyjne. Zbyt wiele bramek prowadzi do odruchowego zatwierdzania.
Guardrails to automatyczne reguły blokujące niedozwolone działania agenta AI. Bramka akceptacji to decyzja człowieka w sprawach, których nie da się zapisać w regule, np. czy plan jest zgodny z architekturą systemu. Dojrzały proces potrzebuje obu mechanizmów.
Agent AI poprawia kod w pętli testów, ale liczba prób jest ograniczona do trzech. Po trzeciej nieudanej próbie przerywa pracę i raportuje człowiekowi, co próbował i gdzie utknął.
Na podstawie artefaktów: planu implementacji, raportu weryfikacji z wynikami testów, raportu z code review i listy tego, czego agent nie sprawdził. Człowiek ocenia dowody, a nie deklarację agenta, że kod działa.
Art. 14 AI Act wymaga nadzoru człowieka nad systemami AI wysokiego ryzyka, proporcjonalnego do ryzyka i poziomu autonomii. Narzędzia deweloperskie zwykle nie są systemami wysokiego ryzyka, ale ta zasada proporcjonalności dobrze sprawdza się przy projektowaniu bramek akceptacji.
Źródła
- Gdzie człowiek musi zatwierdzać decyzje agenta AI? Bramki akceptacji w agentic engineering - 16 października 2026
- Deterministic guardrails w agentic CRM – jak nie stracić kontroli nad autonomicznym agentem - 8 września 2026
- Headless CRM i integracje API – czy CRM przestaje być interfejsem, a staje się silnikiem danych dla agentów AI? - 7 września 2026
