WordPress AI z poziomami zaufania? Właściciel strony ma decydować, co agent może zrobić

Zespół Make WordPress AI podsumował spotkanie z 5 sierpnia 2026 r., na którym jednym z ważniejszych tematów była koncepcja tak zwanej drabiny zaufania dla agentów AI. Brzmi akademicko, ale chodzi o bardzo praktyczną rzecz: jeśli AI ma kiedyś wykonywać realne działania w WordPressie, właściciel strony musi móc jasno określić, co wolno automatowi, a czego absolutnie nie powinien dotykać.

To temat dla właścicieli stron, sklepów WooCommerce, administratorów i agencji utrzymujących serwisy klientów. Zwłaszcza jeśli ktoś myśli o AI nie tylko jako o generatorze tekstu, ale jako narzędziu do automatyzacji zaplecza.

Kluczowe wnioski

  • Zespół Make WordPress AI omawiał koncepcję poziomów zaufania dla agentów AI w WordPressie.
  • Pomysł zakłada cztery poziomy zaufania oraz poziom zero, czyli praktyczny kill-switch.
  • Właściciel strony mógłby ustawić próg zaufania decydujący, które funkcje AI są w ogóle dostępne dla agenta.
  • WordPress.com ma już podobne mechanizmy: granularne uprawnienia i obowiązkową zgodę na działania destrukcyjne.
  • To na razie wczesna dyskusja, a nie zapowiedziana funkcja do wdrożenia w Core.

AI jako użytkownik z uprawnieniami

W dyskusji pojawiła się analogia do ról użytkowników WordPressa. Tak jak subskrybent, redaktor czy administrator mają różne możliwości, tak agent AI mógłby działać z określonym poziomem zaufania.

Uczestnicy rozmowy zastanawiali się też, czy agent AI powinien być osobnym typem bytu, czy raczej nowym rodzajem użytkownika. Według podsumowania grupa skłaniała się ku drugiej opcji. To ma sens: jeśli coś może zmieniać treści, ustawienia albo dane sklepu, udawanie, że to tylko niewinna funkcja wtyczki, szybko robi się ryzykowne.

Jak miałaby działać drabina zaufania

Koncepcja zakłada cztery poziomy zaufania oraz poziom zero, pełniący rolę wyłącznika awaryjnego. Poszczególne możliwości, czyli abilities, mogłyby deklarować, jakiego poziomu zaufania wymagają.

Właściciel strony ustawiałby własny próg zaufania dla agenta. Jeśli dana funkcja wymagałaby wyższego poziomu niż ustawiony na stronie, po prostu nie byłaby agentowi udostępniona. W kontekście MCP robocza odpowiedź była taka, że abilities powyżej progu zaufania nie byłyby w ogóle rejestrowane dla agenta. Innymi słowy: AI nie tylko nie może kliknąć niebezpiecznego przycisku – ono może nawet nie wiedzieć, że taki przycisk istnieje.

Co już działa w WordPress.com

W podsumowaniu wskazano, że WordPress.com ma już mechanizmy podobne do tej koncepcji. Użytkownicy mogą tam włączać i wyłączać pojedyncze abilities, a dostęp zewnętrznych agentów ma granularne uprawnienia odczytu i zapisu.

Najważniejszy detal z punktu widzenia bezpieczeństwa: działania destrukcyjne wymagają wyraźnej zgody niezależnie od ustawień zaufania. To dobry kierunek, bo w realnym sklepie WooCommerce jedna źle wykonana automatyzacja może oznaczać usunięte produkty, popsute ceny, zmienione opisy albo chaos w zamówieniach. AI bywa pomocne, ale nadal potrafi działać z pewnością siebie stażysty po trzech kawach.

Dlaczego właściciel strony powinien to obserwować

Jeżeli WordPress pójdzie w stronę agentów AI z dostępem do funkcji strony, najważniejsze będą nie same fajerwerki, tylko kontrola. Kto nadaje uprawnienia? Czy ryzykowne akcje wymagają zatwierdzenia? Czy da się sprawdzić, co agent zrobił, kiedy i na czyje polecenie?

W dyskusji pojawiły się też wątki ścieżek audytu, przejrzystości oraz wymogów ujawniania treści generowanych przez AI w niektórych krajach. To nie są drobiazgi prawnicze na później. Dla firm oznaczają potencjalną odpowiedzialność za to, co automat opublikuje, zmieni albo usunie na stronie.

To jeszcze nie jest gotowa funkcja

Warto jasno powiedzieć: drabina zaufania dla agentów AI nie jest jeszcze zapowiedzianą funkcją WordPressa ani gotową propozycją wdrożeniową. To wczesna dyskusja w zespole Make WordPress AI, który zbiera dalsze opinie.

W tym samym podsumowaniu pojawiły się też inne tematy: planowanie stanowiska AI i prompt bar na WordCamp US, propozycja dotycząca structured content and abilities czekająca na szerszy przegląd oraz dalsze testy Embeddings i Streaming support. Te ostatnie mają szansę trafić do WordPressa 7.2 później w 2026 r., jeśli przejdą testy i review.

Co zrobić teraz

Na dziś nie ma jeszcze ustawienia do włączenia ani aktualizacji do instalacji. Warto jednak już teraz myśleć o AI w WordPressie jak o użytkowniku z uprawnieniami, a nie jak o magicznym asystencie bez konsekwencji.

Jeśli firma planuje automatyzację treści, SEO, supportu albo obsługi sklepu, rozsądne minimum to: testy poza produkcją, ograniczone uprawnienia, zatwierdzanie działań destrukcyjnych i historia zmian. Pełne podsumowanie spotkania zespołu Make WordPress AI można przeczytać u źródła: AI Contributor Weekly Summary – 5 August 2026.

Najczesciej zadawane pytania

Czym jest drabina zaufania dla agentów AI w WordPressie?

To wczesna koncepcja omawiana przez zespół Make WordPress AI, która ma opisywać poziomy autonomii agentów AI. Zakłada cztery poziomy zaufania oraz poziom zero działający jak wyłącznik awaryjny.

Czy agent AI w WordPressie miałby działać jak zwykły użytkownik?

W dyskusji porównano agenta AI do użytkownika z określonymi uprawnieniami, podobnie jak role w WordPressie. Grupa skłaniała się ku traktowaniu agenta jako nowego rodzaju użytkownika, ale nie jest to jeszcze gotowa propozycja wdrożeniowa.

Czy właściciel strony mógłby ograniczyć działania agenta AI?

Według omawianej koncepcji właściciel strony mógłby ustawić próg zaufania dla agenta. Funkcje wymagające wyższego poziomu nie byłyby agentowi udostępniane ani rejestrowane w kontekście MCP.

Czy ryzykowne działania AI wymagałyby zatwierdzenia?

Źródło wskazuje, że WordPress.com już teraz wymaga wyraźnej zgody na działania destrukcyjne niezależnie od ustawień zaufania. Dyskusja o podobnym modelu dla WordPress Core jest jednak nadal na wczesnym etapie.

Czy drabina zaufania ma trafić do WordPressa 7.2?

Źródło nie mówi, że drabina zaufania jest planowana dla WordPressa 7.2. Wspomina natomiast, że Embeddings i Streaming support mają szansę trafić do WordPressa 7.2 później w 2026 r., jeśli przejdą testy i review.