Integracja AI w Warszawie

#AI w WordPressie: co naprawdę działa, a co jest pokazem slajdów

Warszawa prowadzi dziś dwie równoległe rozmowy o AI. Pierwsza toczy się na konferencjach i w prezentacjach zarządowych, gdzie sztuczna inteligencja zmienia wszystko i wszędzie. Druga toczy się w redakcjach przy Czerskiej i Domaniewskiej, w zespołach e-commerce i w działach prawnych przy Rondzie Daszyńskiego, gdzie pytanie brzmi znacznie konkretniej: który fragment naszej codziennej pracy model językowy wykona szybciej, taniej i bez kompromitacji, i kto za to odpowiada, kiedy się pomyli.

Ta strona jest o tej drugiej rozmowie. Integrujemy modele językowe z WordPressem od strony, która daje się zmierzyć: automatyzacja powtarzalnej pracy redakcyjnej z obowiązkowym zatwierdzeniem przez człowieka, chatboty i wyszukiwarki odpowiadające wyłącznie na podstawie treści serwisu, personalizacja oparta o dane, które firma naprawdę ma, oraz udostępnienie WordPressa agentom AI przez Model Context Protocol. Do tego warstwa, którą warszawskie firmy traktują poważniej niż ktokolwiek inny w Polsce: zgodność z AI Act i RODO, z dokumentacją, którą dział prawny może podpisać.

Nie sprzedajemy przy tym magii. WordPress pozostaje systemem redakcyjnym, WooCommerce pozostaje sklepem, a model językowy jest narzędziem podpiętym przez API, wymiennym i mierzalnym. Jeśli po audycie okazuje się, że problem klienta rozwiązuje lepsza taksonomia albo dwie osoby na etacie, mówimy to wprost. Szczegóły naszego podejścia opisuje pillar o integracji AI z WordPressem, tutaj skupiamy się na tym, jak wygląda to w warszawskiej praktyce.

#Automatyzacja pracy redakcji: opisy, tagowanie, tłumaczenia

Największy i najbardziej niedoceniany obszar integracji AI w WordPressie to nie chatbot na stronie głównej, tylko zaplecze redakcyjne. Warszawa jest naturalnym rynkiem dla tego typu wdrożeń, bo tu koncentrują się polskie media i duże zespoły contentowe: wydawnictwa prasowe, portale, działy komunikacji korporacji. Te zespoły od lat toczą tę samą wojnę z powtarzalną pracą, której nikt nie chce robić, a którą ktoś robić musi.

Trzy przepływy wracają w projektach najczęściej. Pierwszy to opisy: produktów w sklepie, materiałów w archiwum, metadane SEO dla tysięcy podstron. Model dostaje ustrukturyzowane dane wejściowe, na przykład atrybuty produktu z systemu PIM albo treść artykułu, i zwraca szkic opisu w zdefiniowanym stylu. Szkic, nie publikację: każdy wynik trafia do kolejki w panelu WordPressa, gdzie redaktor zatwierdza, poprawia lub odrzuca. Ten etap human review nie jest ozdobnikiem dla prawników, tylko mechanizmem kontroli jakości, bez którego automatyzacja treści degeneruje się w publikowanie szumu.

Drugi przepływ to tagowanie i klasyfikacja. Archiwum wydawnicze liczące dziesiątki tysięcy tekstów z niespójną taksonomią to problem, którego nie rozwiąże żaden stażysta, bo praca jest zbyt monotonna, by wykonać ją rzetelnie. Model klasyfikacyjny proponuje tagi i kategorie według zdefiniowanego słownika, redakcja akceptuje je seryjnie w interfejsie, a spójna taksonomia przekłada się na działające strony tagów, lepsze linkowanie wewnętrzne i sensowne polecane artykuły.

Trzeci przepływ to tłumaczenia robocze. Serwisy wielojęzyczne, których w Warszawie ze względu na regionalne centrale firm jest wyjątkowo dużo, potrzebują szybkich szkiców tłumaczeń, które native speaker doprowadza do stanu publikowalnego. Model skraca ten cykl, ale go nie zastępuje: wiemy z własnej praktyki, jak systematycznie modele gubią niuanse i jak bardzo tłumaczenie bez weryfikacji potrafi zaszkodzić marce.

#LLM przez API: wyszukiwarka, chatbot, personalizacja

Druga grupa wdrożeń działa od frontu, tam gdzie z modelem styka się użytkownik serwisu. Fundamentem jest tu jedna zasada: model odpowiada wyłącznie na podstawie treści, które mu dostarczymy, a nie z ogólnej wiedzy wytrenowanej na internecie. Technicznie oznacza to indeksowanie treści serwisu, wyszukiwanie odpowiednich fragmentów pod każde pytanie i przekazywanie ich modelowi jako jedynego źródła. Odpowiedź zawiera odesłanie do strony źródłowej, a pytanie spoza korpusu kończy się odmową i kontaktem do człowieka.

Tak zbudowana wyszukiwarka zmienia sposób korzystania z rozbudowanych serwisów. Klasyczne wyszukiwanie pełnotekstowe w WordPressie zawodzi przy pytaniach zadawanych naturalnym językiem, a właśnie tak pytają użytkownicy przyzwyczajeni przez ChatGPT. Warstwa LLM rozumie pytanie, znajduje właściwe treści i streszcza je z linkami, co dla serwisu z setkami poradników albo dokumentacją produktową jest różnicą między znalezieniem odpowiedzi a wyjściem do Google.

Chatbot na treści serwisu to ta sama architektura w formie konwersacyjnej. Uczciwie: to wdrożenie ma sens tylko wtedy, gdy serwis ma dość treści, by chatbot miał z czego odpowiadać. Bot na stronie z pięcioma podstronami będzie parodią. Bot na serwisie z bogatą bazą wiedzy, dokumentacją techniczną albo rozbudowanym FAQ odciąża obsługę klienta z pytań, które powtarzają się setny raz.

Warszawska odmiana chatbota, którą widzimy coraz częściej, działa nie na zewnątrz, lecz do wewnątrz: dla regionalnych central obsługujących rynki Europy Środkowo-Wschodniej. Wewnętrzna baza wiedzy, procedury, polityki kadrowe i instrukcje, prowadzona jest zwykle po polsku lub angielsku, a model odpowiada pracownikowi w języku, w którym ten zadał pytanie. Rozmowa toczy się za logowaniem, dane wrażliwe wyłączamy z promptów i logów, a efektem jest odciążenie działów kadr i wsparcia z pytań wracających w każdym kraju osobno, za każdym razem w lokalnym języku.

Personalizacja jest trzecim elementem i celowo wymieniamy ją ostatnią. Rekomendacje treści i produktów oparte o zachowanie użytkownika wymagają danych, zgód i ruchu, które trzeba najpierw zmierzyć. Dla sklepów WooCommerce, które prowadzimy w stolicy w ramach rozwoju WooCommerce w Warszawie, zaczynamy od prostych, deterministycznych rekomendacji i dopiero na zmierzonym gruncie dokładamy warstwę modelową.

#MCP: WordPress jako narzędzie dla agentów AI

Osobnym, coraz ważniejszym kierunkiem jest odwrócenie ról: zamiast wbudowywać AI w WordPressa, udostępnić WordPressa systemom AI. Model Context Protocol, otwarty standard zapoczątkowany przez Anthropic, pozwala wystawić treści i operacje serwisu jako narzędzia, z których agent AI korzysta w kontrolowany sposób: przeszukuje ofertę, sprawdza dostępność, tworzy szkic wpisu, zawsze w granicach nadanych uprawnień.

Dla warszawskich firm to temat o dwóch twarzach. Pierwsza jest wewnętrzna: zespoły, które pracują z Claude albo ChatGPT, mogą przez serwer MCP połączyć asystenta z własnym WordPressem i zamiast kopiować treści między oknami, operować na serwisie bezpośrednio z rozmowy. Druga jest rynkowa: ruch agentowy w internecie rośnie, a serwis, który agenci potrafią czytelnie odpytać, będzie w tym ruchu widoczny. Budujemy takie serwery w ramach usługi MCP server development, łącznie z warstwą uprawnień, bo agent z dostępem do checkoutu bez ograniczeń to nie innowacja, tylko incydent bezpieczeństwa czekający na termin.

#AI Act i RODO: w Warszawie to temat zarządu, nie tylko prawników

W żadnym innym polskim mieście pytanie o zgodność nie pada tak wcześnie jak w Warszawie, i słusznie. Tu mieszczą się centrale banków i ubezpieczycieli, regionalne biura międzynarodowych korporacji, kancelarie obsługujące te podmioty oraz Urząd Ochrony Danych Osobowych. Wdrożenie AI, które nie przejdzie przez dział prawny, po prostu nie wystartuje, więc zgodność projektujemy od pierwszego dnia, a nie doklejamy przed odbiorem.

Dwie regulacje wyznaczają ramy. RODO dotyczy danych osobowych w promptach i logach: klasyfikujemy, co w ogóle trafia do modelu, konfigurujemy umowy powierzenia i region przetwarzania u dostawcy API, wyłączamy wykorzystanie danych do treningu i ustalamy retencję logów. Dla większych wdrożeń przygotowujemy materiał pod ocenę skutków dla ochrony danych, w formie, którą inspektor ochrony danych klienta może przejąć i rozwijać.

AI Act dokłada obowiązki przejrzystości: zgodnie z art. 50 rozporządzenia interakcja z systemem AI musi być dla użytkownika rozpoznawalna, a określone treści generowane maszynowo wymagają oznaczenia. Te obowiązki stosuje się od 2 sierpnia 2026 roku, więc dla wdrożeń projektowanych dzisiaj to nie jest przyszłość, tylko wymaganie startowe. Sami prowadzimy opublikowaną politykę AI i oznaczamy treści wspierane modelami w metadanych własnego serwisu, więc klientom wdrażamy praktykę, którą stosujemy u siebie, a nie teorię z webinaru.

#Koszty API i model rozliczeń: policzalne, ale trzeba je policzyć

Koszty integracji AI mają dwie odrębne warstwy i mieszanie ich jest źródłem większości nieporozumień budżetowych. Pierwsza to koszt projektu wdrożeniowego, który wyceniamy indywidualnie, zależnie od liczby i złożoności przepływów. Druga to koszty API modelu, które są publiczne, naliczane od tokenów i rosną liniowo z użyciem, a nie skokowo z licencją.

Ta druga warstwa jest projektowalna i to jest dobra wiadomość. Dobór modelu do zadania ma większy wpływ na rachunek niż negocjacje z kimkolwiek: klasyfikację i tagowanie obsłuży model lekki, a mocniejszy i droższy warto rezerwować do zadań, gdzie jakość tekstu jest widoczna dla czytelnika. Do tego dochodzą mechanizmy takie jak cache’owanie powtarzalnych fragmentów promptu i przetwarzanie wsadowe poza godzinami szczytu, które realnie obniżają koszt na dokument. W pilocie mierzymy zużycie na produkcyjnych danych i dopiero z tym pomiarem rozmawiamy o skali, bo prognozy kosztów API bez pomiaru są zgadywaniem z powagą arkusza kalkulacyjnego.

#Trzy warszawskie historie z praktyki

Wydawca z wieloletnim archiwum: zespół redakcyjny dużego serwisu contentowego utrzymywał taksonomię, która przez lata rozrosła się w chaos równoległych tagów i pustych kategorii. Ręczne porządkowanie umierało dwukrotnie na etapie planowania, bo nikt nie mógł poświęcić na to miesięcy. Wdrożyliśmy przepływ, w którym model proponuje klasyfikację według uzgodnionego słownika, a redaktorzy zatwierdzają propozycje seryjnie w panelu. Kluczową decyzją projektową okazało się nie AI, tylko interfejs zatwierdzania: praca, która wcześniej wymagała otwierania każdego wpisu, stała się przeglądem listy.

Sklep z ofertą wielojęzyczną: warszawska firma handlowa sprzedająca do kilku krajów potrzebowała opisów produktów w kilku językach, a dział e-commerce spędzał na nich znaczną część tygodnia. Zbudowaliśmy pipeline od danych produktowych do szkiców opisów we wszystkich językach naraz, z kolejką review dla każdego rynku osobno. Po pilocie klient zdecydował się na model tańszy niż pierwotnie testowany, bo różnica jakości na opisach technicznych okazała się kosmetyczna, a różnica kosztów nie. To jest dokładnie ten typ decyzji, dla którego pilot z pomiarem istnieje.

Korporacja z wymogami compliance: dział prawny klienta z sektora regulowanego zablokował pierwotny pomysł chatbota odpowiadającego swobodnie na pytania klientów. Słusznie. Wdrożona wersja odpowiada wyłącznie na podstawie zatwierdzonej bazy wiedzy, cytuje źródło przy każdej odpowiedzi, odmawia przy pytaniach spoza korpusu i loguje interakcje zgodnie z ustaloną retencją. Interfejs od pierwszego ekranu informuje, że rozmowa toczy się z systemem AI. Projekt trwał dłużej niż standardowy, ale przeszedł audyt wewnętrzny za pierwszym podejściem, a to w tym środowisku jest właściwa miara sukcesu.

#Kiedy AI w WordPressie nie ma sensu

Ta sekcja istnieje, bo częściej odradzamy wdrożenia, niż wypada przyznać stronie usługowej. Mała strona firmowa z kilkunastoma podstronami nie potrzebuje integracji AI: nie ma tam ani powtarzalnej pracy do zautomatyzowania, ani korpusu treści, na którym chatbot mógłby odpowiadać. Firma bez procesu contentowego również nie skorzysta, bo model przyspiesza istniejący proces, a nie tworzy go z niczego: jeśli nikt nie pisze, nie taguje i nie tłumaczy, nie ma czego usprawniać.

Trzeci przypadek jest najczęstszy i najtrudniejszy w rozmowie: moda zamiast potrzeby. Presja, żeby mieć coś z AI, bo konkurencja ogłosiła coś z AI, prowadzi do wdrożeń, które po trzech miesiącach nikt nie potrafi uzasadnić rachunkiem. Test, który proponujemy na pierwszym spotkaniu, jest prosty: jaka praca, wykonywana dziś przez ludzi, ma zniknąć z ich kalendarzy, i po czym poznamy, że zniknęła. Jeśli nie ma odpowiedzi, nie ma projektu, i mówimy to wprost, zanim powstanie jakikolwiek kod.

#Jak pracujemy: pilot, pomiar, decyzja

Wdrożenia prowadzimy etapami, bo entuzjazm z pierwszego demo to najgorszy doradca budżetowy w projektach AI: to, co zachwyca na dziesięciu przykładach, na dziesięciu tysiącach dokumentów pokazuje zupełnie inny rachunek i inną listę błędów. Zaczynamy od audytu: mapujemy proces contentowy lub obsługowy, klasyfikujemy dane pod RODO, oceniamy jakość treści źródłowych i wybieramy jeden przepływ na pilota. Pilot działa produkcyjnie w kilka tygodni, z pomiarem zużycia tokenów i jakości wyników, oraz z kolejką human review od pierwszego dnia.

Po pilocie następuje ewaluacja: porównanie modeli na własnych danych klienta, koszt na dokument, opinia zespołu, który z narzędziem pracował. Dopiero wtedy zapada decyzja o rozbudowie, a rollout obejmuje limity budżetowe, monitoring, dokumentację i oznaczenia wymagane przez AI Act. Kompetencje strategiczne, od doboru procesów po politykę AI dla całej organizacji, opisujemy szerzej na stronie wdrożeń AI.

#Kryteria odbioru dla zespołu, bezpieczeństwa i działu prawnego

Warszawskie wdrożenie często ma kilku odbiorców, którzy inaczej rozumieją słowo „działa”. Redakcja chce krótszej kolejki i przewidywalnego interfejsu zatwierdzania. Zespół techniczny sprawdza powtarzalność odpowiedzi, obsługę błędów API, limity i możliwość zmiany dostawcy modelu. Bezpieczeństwo pyta o zakres uprawnień, logowanie operacji oraz zachowanie systemu po przekroczeniu budżetu. Dział prawny potrzebuje opisu przepływu danych, podstaw retencji i czytelnej informacji dla użytkownika. Kryteria dla każdej z tych grup zapisujemy przed uruchomieniem pilota.

Przy chatbocie tworzymy testowy zestaw pytań na podstawie zatwierdzonych treści, pytań spoza bazy i prób wyłudzenia instrukcji systemowych. Odbiór nie polega na obejrzeniu kilku udanych rozmów. Sprawdzamy, czy odpowiedź wskazuje właściwe źródło, czy model odmawia tam, gdzie powinien, i czy przekazanie do człowieka zachowuje potrzebny kontekst bez niekontrolowanego kopiowania danych osobowych. Przy automatyzacji redakcyjnej próbka obejmuje materiały proste, niepełne i sprzeczne, bo właśnie na wyjątkach ujawnia się realny koszt korekty.

Do rozpoczęcia takiej oceny wystarczy wiadomość z adresem serwisu, opisem jednego procesu, rolą osoby zatwierdzającej i przykładami wejścia po usunięciu danych poufnych. Nie prosimy o pełny eksport klientów ani dostęp do produkcji. Po wstępnej analizie wskazujemy, czy sens ma pilot, porządkowanie źródeł, czy rezygnacja z warstwy AI na rzecz prostszej automatyzacji WordPressa.

#Dlaczego agencja WordPress do integracji AI

Rynek AI w Warszawie pełen jest firm, które znają modele, ale nie znają WordPressa, i agencji WordPress, które dokleiły AI do oferty w zeszłym kwartale. Wartość leży w przecięciu: integracja AI z systemem redakcyjnym wymaga zrozumienia, jak pracuje redakcja, jak działa Gutenberg, gdzie w WooCommerce kończy się katalog, a zaczyna checkout, i czego nie wolno dotykać bez testów regresyjnych.

Pracujemy z WordPressem od 2007 roku, a techniki z tej strony sprawdzamy najpierw u siebie: nasz własny serwis serwuje treści z metadanymi przygotowanymi pod crawlery AI. Dla warszawskich firm oznacza to partnera, który rozumie zarówno pytanie działu prawnego o retencję logów, jak i pytanie redaktora o to, czy nowy przycisk nie zepsuje mu kolejki publikacji. Pierwsze spotkanie kończy się jednym z dwóch wyników: planem pilota z mierzalnym celem albo listą powodów, dla których temat warto na razie odłożyć. Oba traktujemy jako dobrze wykorzystany czas, wasz i nasz.

Ostatnia aktualizacja: 10 lipca 2026