Bezpieczne wdrożenie WordPress 7.0 w agencji interaktywnej – uprawnienia i koszty

Największy błąd przy wdrażaniu WordPressa 7.0 nie polega na samej aktualizacji. Błąd zaczyna się wtedy, gdy agencja traktuje nowe funkcje AI jak zwykłą wtyczkę do treści: podłączamy klucz, dajemy dostęp autorom, sprawdzimy później. Przy stronach klientów „później” zwykle oznacza już po pierwszym incydencie: wycieku klucza API, niekontrolowanych kosztach albo asystencie, który dostał więcej praw niż junior developer.

WordPress 7.0 „Armstrong” został wydany 20 maja 2026 r. i wprowadził nie tylko zmiany edytora czy panelu, ale też fundament pod funkcje AI: WP AI Client, Abilities API po stronie klienta oraz ekran Settings → Connectors do obsługi połączeń z dostawcami AI. To nie jest gotowy chatbot w rdzeniu. To infrastruktura, przez którą wtyczki i własny kod mogą korzystać z modeli, dostawców i zarejestrowanych „abilities” w bardziej przewidywalny sposób.

Dla agencji interaktywnej oznacza to zmianę podejścia do utrzymania stron. Aktualizacja przestaje być wyłącznie zadaniem technicznym. Trzeba zaprojektować model uprawnień, przechowywanie sekretów, limity kosztów, procedurę rollbacku i jasny podział: co może robić AI, co może robić autor, a co zostaje wyłącznie po stronie administratora lub DevOpsa.

Zarządzanie uprawnieniami (Capabilities) dla sztucznej inteligencji

W WordPressie 7.0 trzeba rozdzielić dwa pojęcia, które w rozmowach zespołów często lądują w jednym worku. Capabilities to klasyczne uprawnienia użytkownika, takie jak edit_posts, publish_posts, manage_options, activate_plugins czy delete_plugins. Abilities to natomiast zarejestrowane jednostki funkcjonalności, które mogą być odkrywane i wykonywane przez kod, automatyzacje albo agentów AI. Abilities API opisuje takie akcje przez nazwę, schemat wejścia, schemat wyjścia, callback wykonujący i callback uprawnień.

Praktyczna zasada jest prosta: AI nie dostaje roli administratora. Nigdy. Asystent autora nie powinien mieć dostępu do instalowania wtyczek, edycji motywów, zmiany ustawień strony, zarządzania użytkownikami ani wykonywania zapytań SQL. To nie jest kwestia zaufania do modelu, tylko ograniczenia pola szkody, gdy prompt zostanie źle zinterpretowany, użytkownik poda złośliwe polecenie albo wtyczka źle opisze własną funkcję.

Najbezpieczniejszy model dla agencji to allow-list, czyli lista dozwolonych działań. Nie pytamy: „czego AI ma nie robić?”. Pytamy: „jakie dokładnie akcje wolno uruchomić?”. Dla asystenta autora sensowny zestaw wygląda tak:

• generowanie szkicu wpisu,
• poprawa leadu,
• propozycje śródtytułów,
• streszczenie tekstu,
• sugestie tagów i kategorii,
• opis alternatywny obrazka,
• analiza czytelności,
• przygotowanie wersji roboczej meta title i meta description.

Poza listą zostają działania administracyjne:

• install_plugins,
• activate_plugins,
• delete_plugins,
• update_plugins,
• edit_plugins,
• edit_theme_options,
• manage_options,
• edit_users,
• promote_users,
• unfiltered_html,
• własne akcje typu run_sql, flush_cache_global, sync_production_database.

Jeżeli asystent ma pracować tylko na treści autora, dobrym punktem startowym jest osobna rola, na przykład ai_content_assistant, z minimalnym zestawem praw:

add_action( 'init', function () {
    if ( ! get_role( 'ai_content_assistant' ) ) {
        add_role(
            'ai_content_assistant',
            'AI Content Assistant',
            array(
                'read'       => true,
                'edit_posts' => true,
                'upload_files' => true,
            )
        );
    }
} );

Ten przykład celowo nie dodaje publish_posts. Asystent może przygotować szkic, ale nie publikuje. Publikacja zostaje po stronie człowieka z rolą Author, Editor albo inną rolą ustaloną w procesie redakcyjnym. To usuwa jeden z najczęstszych problemów: automatyczne wypchnięcie tekstu na produkcję bez kontroli redaktora.

Drugi poziom kontroli powinien siedzieć w permission_callback. Sam fakt, że ability istnieje, nie oznacza, że każdy użytkownik może ją wykonać. WordPressowy current_user_can() sprawdza, czy aktualny użytkownik ma wskazaną capability, również w kontekście konkretnego obiektu, na przykład wpisu.

Przykład sensownej kontroli dla AI, które może edytować wyłącznie własny wpis autora:

wp_register_ability(
    'agency-ai/improve-author-draft',
    array(
        'label'       => 'Improve author draft',
        'description' => 'Improves a draft owned by the current author without publishing it.',
        'category'    => 'agency-ai',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'post_id' => array(
                    'type' => 'integer',
                ),
                'task' => array(
                    'type' => 'string',
                    'enum' => array( 'rewrite_intro', 'suggest_headings', 'summarize' ),
                ),
            ),
            'required' => array( 'post_id', 'task' ),
        ),
        'permission_callback' => function ( $input ) {
            $post_id = absint( $input['post_id'] ?? 0 );
            $post    = get_post( $post_id );

            if ( ! $post ) {
                return false;
            }

            if ( (int) $post->post_author !== get_current_user_id() ) {
                return false;
            }

            return current_user_can( 'edit_post', $post_id );
        },
        'execute_callback' => function ( $input ) {
            // Tu wywołanie WP AI Client i zapis wyłącznie do wersji roboczej.
        },
        'meta' => array(
            'annotations' => array(
                'readonly'    => false,
                'destructive' => false,
                'idempotent'  => false,
            ),
        ),
    )
);

Adnotacje readonly, destructive i idempotent pomagają opisać zachowanie ability, ale nie zastępują sprawdzania uprawnień. Bez permission_callback bezpieczeństwo jest teatralne: wygląda dobrze w dokumentacji, ale realnie nie blokuje wykonania akcji. WordPress 7.0 wykorzystuje te adnotacje także do doboru metod REST, gdzie akcje tylko do odczytu mogą iść przez GET, destrukcyjne i idempotentne przez DELETE, a pozostałe przez POST.

W agencji sprawdza się jeszcze jedna reguła: abilities techniczne i redakcyjne muszą być rozdzielone. Wtyczka SEO może mieć ability do „zaproponuj opis meta”, ale nie powinna przy okazji rejestrować ability „zmień ustawienia indeksacji całego serwisu”. Takie działania idą do osobnego panelu, z osobną capability, na przykład manage_agency_ai_settings, przyznawaną tylko administratorom technicznym.

Przed wdrożeniem na produkcję trzeba przejść krótką listę kontrolną:

• wypisać wszystkie ability rejestrowane przez własny kod i wtyczki,
• oznaczyć je jako read-only, content-write, settings-write albo destructive,
• usunąć lub wyłączyć ability, których klient nie potrzebuje,
• sprawdzić, czy każda ability z zapisem ma permission_callback,
• przetestować wykonanie jako Administrator, Editor, Author i Subscriber,
• sprawdzić logi REST API i AJAX po próbie wykonania niedozwolonych akcji.

Największy priorytet ma blokada akcji administracyjnych. Drugi priorytet to ograniczenie AI do konkretnych obiektów, na przykład jednego wpisu. Dopiero trzeci to wygoda redakcji. Odwrócenie tej kolejności kończy się rolą „Author plus kilka wyjątków”, która po trzech miesiącach przypomina administratora w przebraniu.

Bezpieczne przechowywanie kluczy API i ochrona przed wyciekiem

W WordPressie 7.0 ekran Settings → Connectors porządkuje konfigurację dostawców AI. Connectors API obsługuje połączenia z zewnętrznymi usługami, początkowo głównie z dostawcami AI, i standardyzuje metadane, link do uzyskania poświadczeń oraz status połączenia. W rdzeniu znalazły się trzy wyróżnione konektory: Anthropic, Google i OpenAI.

Najważniejszy szczegół dla bezpieczeństwa jest mało efektowny, ale bardzo konkretny: dla konektorów typu api_key WordPress sprawdza klucz w kolejności zmienna środowiskowa → stała PHP → baza danych. Klucze zapisane w bazie są maskowane w interfejsie, ale nie są szyfrowane.

To ustawia hierarchię decyzji:

1. Najlepiej: klucz jako zmienna środowiskowa na serwerze.
2. Dopuszczalnie: klucz jako stała PHP w wp-config.php, ale poza repozytorium.
3. Awaryjnie: klucz w bazie przez panel, tylko dla małych stron bez dostępu do konfiguracji serwera.

Dla agencji obsługującej klientów trzeci wariant powinien być wyjątkiem, nie standardem. Backup bazy, eksport stagingu, zrzut wykonany przez wtyczkę migracyjną albo dostęp do phpMyAdmin mogą wtedy przenieść sekret dalej, niż planowano.

Poprawny wzorzec w wp-config.php wygląda tak:

define( 'OPENAI_API_KEY', getenv( 'OPENAI_API_KEY' ) ?: '' );
define( 'ANTHROPIC_API_KEY', getenv( 'ANTHROPIC_API_KEY' ) ?: '' );
define( 'GOOGLE_API_KEY', getenv( 'GOOGLE_API_KEY' ) ?: '' );

Jeszcze lepiej, gdy zmienne są wstrzykiwane przez panel hostingu, Docker secrets, konfigurację serwera albo system CI/CD. Wtedy wp-config.php nie zawiera realnego klucza. Zawiera tylko odwołanie. To drobna różnica w kodzie, ale duża różnica przy incydencie.

Nie należy robić tego tak:

define( 'OPENAI_API_KEY', 'sk-proj-prawdziwy-klucz-wklejony-do-pliku' );

Taki klucz prawie zawsze skończy w jednym z trzech miejsc: repozytorium, kopii stagingu albo archiwum wysłanym klientowi. Maskowanie w panelu nie pomoże, jeśli sekret już został skopiowany do Gita.

Procedura agencyjna powinna być bezlitosna:

• każdy klient dostaje osobny klucz API,
• produkcja i staging mają osobne klucze,
• klucze nie są współdzielone między projektami,
• dostęp do kluczy ma tylko zespół techniczny,
• rotacja następuje po odejściu pracownika, zmianie wykonawcy, wycieku backupu albo przeniesieniu hostingu,
• w repozytorium działa skanowanie sekretów,
• logi nie zapisują pełnych promptów zawierających dane klientów.

Przy konfiguracji kosztów nie wystarczy wpisać klucz i uruchomić funkcję. Trzeba ustawić limit wydatków po stronie dostawcy oraz limit po stronie aplikacji. Minimum to dzienny i miesięczny bezpiecznik. Dla małej strony contentowej rozsądny start to limit 10–30 USD miesięcznie na testy i redakcję. Dla sklepu z opisami produktów — osobny budżet, bo 10 000 produktów potrafi zjeść budżet szybciej niż kampania PPC źle ustawiona na frazy broad match.

Przykład kosztowy dla asystenta redakcyjnego: 10 000 żądań miesięcznie, każde średnio 1 500 tokenów wejściowych i 500 tokenów wyjściowych. To daje 15 mln tokenów wejściowych i 5 mln tokenów wyjściowych miesięcznie. Przy stawkach standardowych:

OpenAI publikuje ceny za 1 mln tokenów dla modeli gpt-5.4-mini i gpt-5.4-nano, Google podaje stawki Gemini 3 Flash Preview za tekst, obraz i wideo, a Anthropic rozlicza Claude Haiku 4.5 oraz Sonnet 4.6 w MTok, czyli milionach tokenów.

Wniosek dla agencji: domyślny model nie powinien być „najmocniejszy”. Domyślny model powinien być najtańszy, który przechodzi test jakości. Dla korekty tekstu, tagów, streszczeń i altów zwykle zaczyna się od modelu ekonomicznego. Droższy model dostaje tylko zadania wymagające dłuższego rozumowania, analizy regulaminów, złożonego kodu albo dużego kontekstu.

Jest jeszcze koszt ukryty: routing regionalny i wymagania dotyczące lokalizacji przetwarzania danych. OpenAI dolicza 10% do regional processing endpoints dla wybranych modeli, a Anthropic dla US-only inference stosuje mnożnik 1,1x przy wskazanych modelach. Jeżeli klient wymaga konkretnej lokalizacji przetwarzania, nie wolno porównywać samych stawek bazowych.

Wdrożenie bezpieczne ma więc trzy poziomy zabezpieczeń:

• sekret poza bazą — najlepiej zmienna środowiskowa;
• limit budżetu — po stronie dostawcy i w kodzie;
• filtr danych — brak pełnych danych osobowych, haseł, tokenów, prywatnych notatek klienta i dumpów bazy w promptach.

Nie da się zagwarantować, że model nigdy nie wygeneruje błędnej treści. Da się natomiast ograniczyć szkody: nie dać mu dostępu do panelu administracyjnego, nie wysyłać mu sekretów, nie pozwolić mu działać poza konkretną listą zadań i nie zostawić otwartego rachunku API.

Jak agencje mogą monetyzować nowe funkcje WordPressa 7.0?

WordPress 7.0 daje agencjom nową kategorię usług, ale tylko wtedy, gdy oferta nie brzmi jak „dodamy AI do strony”. Klient za to nie płaci długo. Klient płaci za konkretny rezultat: mniejsze ryzyko wdrożenia, niższy koszt generowania treści, kontrolę nad danymi albo szybszą pracę redakcji.

Pierwsza usługa, którą można sprzedawać od razu, to audyt gotowości AI dla WordPressa 7.0. Nie jest to audyt SEO w nowej etykiecie. Zakres powinien obejmować:

• wersję PHP i bazy danych,
• zgodność hostingu z rekomendacjami WordPressa,
• listę wtyczek rejestrujących abilities lub korzystających z AI,
• role i capabilities użytkowników,
• sposób przechowywania kluczy API,
• politykę backupów i stagingu,
• miejsca, w których prompt może zawierać dane klienta,
• miesięczny limit kosztów API,
• procedurę wyłączenia AI jednym przełącznikiem.

WordPress rekomenduje dziś PHP 8.3 lub nowsze, MariaDB 10.6+ albo MySQL 8.0+, HTTPS oraz uruchamianie aplikacji PHP na koncie użytkownika, a nie na wspólnym użytkowniku serwera. Jednocześnie WordPress 7.0 utrzymuje minimalne wsparcie dla PHP 7.4, ale starsze wersje PHP są poza bezpiecznym minimum operacyjnym.

Cennik audytu można ustawić prosto:

Druga usługa to wdrożenie bezpiecznego AI Content Assistant. Tutaj klient nie kupuje modelu. Kupuje proces redakcyjny:

• AI tworzy szkic,
• autor poprawia,
• redaktor zatwierdza,
• system zapisuje wersję roboczą,
• publikacja zostaje ręczna,
• log zawiera identyfikator zadania, model i koszt, ale nie musi trzymać pełnego promptu.

Taka usługa ma sens dla blogów firmowych, portali, e-commerce i stron z dużą liczbą landing page’y. Cennik wdrożenia można oprzeć na liczbie typów treści:

Trzecia usługa to konfiguracja Connectors i zarządzanie kluczami API. Dla klienta brzmi mało sexy, ale jest łatwa do uzasadnienia po pierwszym pytaniu: „Kto ma dostęp do klucza i co się stanie, gdy ktoś go wklei do stagingu?”. Pakiet powinien obejmować:

• osobne klucze dla produkcji i stagingu,
• konfigurację wp-config.php albo zmiennych środowiskowych,
• limity kosztów u dostawcy,
• rotację kluczy,
• dokumentację dla klienta,
• procedurę awaryjnego wyłączenia konektora.

Cena: 600–1 500 zł netto za dostawcę na stronę, więcej przy niestandardowym hostingu, multisite albo CI/CD.

Czwarta usługa to lokalne modele przez Ollama. Tu trzeba mówić klientowi prawdę: lokalny model nie jest magicznie darmowy. Samo uruchamianie na własnym sprzęcie może nie mieć kosztu tokenów, ale dochodzi sprzęt, energia, administracja, monitoring, aktualizacje modeli i niższa jakość w części zadań. Ollama ma plan Free za 0 USD, pozwala uruchamiać modele na własnym sprzęcie, a w chmurze oferuje Pro za 20 USD miesięcznie lub 200 USD rocznie oraz Max za 100 USD miesięcznie. Lokalne uruchamianie na własnym sprzęcie jest opisane jako nielimitowane, a limity chmurowe zależą od planu i wykorzystania GPU.

Wdrożenie Ollama opłaca się szczególnie wtedy, gdy:

• klient nie chce wysyłać treści roboczych do zewnętrznego API,
• zadania są powtarzalne i nie wymagają topowego modelu,
• chodzi o klasyfikację, streszczanie, ekstrakcję, tagowanie,
• zespół ma własny serwer albo mocne stacje robocze,
• akceptowalna jest wolniejsza odpowiedź niż w chmurze.

Nie opłaca się, gdy klient oczekuje najwyższej jakości copywritingu, wielojęzycznej korekty prawnej, rozumowania na długich dokumentach albo działania bez administracji technicznej. Wtedy tańszy jest model API z twardym limitem miesięcznym.

Realna oferta agencyjna dla Ollama:

Piąta usługa to AI Cost Control. Mały plugin albo moduł MU-plugin może zapisywać:

• dostawcę,
• model,
• użytkownika,
• typ zadania,
• liczbę tokenów wejściowych i wyjściowych,
• koszt,
• status błędu,
• czas odpowiedzi.

Nie trzeba przechowywać pełnej treści promptu. W wielu projektach lepiej tego nie robić. Do rozliczeń wystarczą metadane. Klient dostaje miesięczny raport: ile kosztowały opisy produktów, ile korekty wpisów, ile błędnych wywołań i który dział zużywa budżet.

Najbardziej sensowna kolejność monetyzacji wygląda tak:

1. Audyt gotowości AI — najłatwiejszy do sprzedania obecnym klientom.
2. Bezpieczna konfiguracja Connectors i kluczy — szybka usługa techniczna.
3. Asystent redakcyjny z ograniczonymi abilities — wyższa marża, widoczny efekt.
4. Monitoring kosztów API — retainer i stały kontakt z klientem.
5. Ollama lokalnie — tylko dla klientów z realnym powodem: prywatność, wolumen, własna infrastruktura.

Nie zaczynałbym od „agentów, którzy robią wszystko”. To brzmi dobrze na demo, ale w utrzymaniu agencyjnym oznacza dużo odpowiedzialności i mało kontroli. Lepiej sprzedać trzy nudne, odporne procesy niż jednego efektownego agenta z prawami administratora.

FAQ: WordPress 7.0, AI, uprawnienia i koszty

Czy WordPress 7.0 sam wysyła dane do OpenAI, Google albo Anthropic?
Nie. Rdzeń daje infrastrukturę, ale do wywołań AI potrzebne są konfiguracja dostawcy, klucz i kod lub wtyczka, która faktycznie wysyła prompt. Projekt WP AI Client zakłada brak automatycznie włączonych wywołań bez jawnej konfiguracji.

Czy klucz API można trzymać w bazie danych WordPressa?
Można, ale to najsłabszy wariant. WordPress maskuje klucz w interfejsie, lecz nie szyfruje go w bazie. Dla agencji standardem powinny być zmienne środowiskowe albo stałe PHP poza repozytorium.

Jakie uprawnienie jest najbardziej niebezpieczne dla asystenta AI?
manage_options, install_plugins, activate_plugins, delete_plugins, edit_users i każde własne uprawnienie pozwalające wykonywać SQL albo zmieniać konfigurację. Asystent autora powinien pracować na wpisie, nie na konfiguracji strony.

Czy Author może korzystać z AI bez ryzyka?
Tak, pod warunkiem że AI działa w kontekście tego autora, sprawdza current_user_can( 'edit_post', $post_id ), nie publikuje automatycznie i nie ma dostępu do abilities administracyjnych.

Czy Ollama zawsze obniży koszty?
Nie. Przy małym wolumenie tańsze i prostsze bywa API z limitem 10–30 USD miesięcznie. Ollama wygrywa tam, gdzie liczy się prywatność, lokalne przetwarzanie, powtarzalne zadania i własna infrastruktura.

Od czego agencja powinna zacząć wdrożenie WordPressa 7.0 u klienta?
Od audytu ról, abilities i kluczy API. Najpierw usuń nadmiarowe uprawnienia i przenieś sekrety poza bazę. Dopiero potem uruchamiaj asystenta redakcyjnego, generowanie treści albo lokalne modele.