Integracja AI w Krakowie

#Dwie krakowskie gospodarki, jeden zaległy serwis

Kraków ma dwie gospodarki, które rzadko ze sobą rozmawiają. Pierwsza siedzi w biurowcach Zabłocia i wzdłuż Opolskiej: firmy SaaS, studia gier, software house’y i uczelniane spin-offy wyrastające z AGH i UJ, które wbudowują modele językowe we własne produkty i nie potrzebują nikogo, kto wytłumaczy im, czym jest token. Druga obsługuje miliony gości rocznie: hotele, aparthotele, restauracje i organizatorzy zwiedzania wokół Rynku i Kazimierza, dla których AI jest wciąż hasłem z konferencyjnego slajdu, a nie narzędziem w grafiku recepcji.

Obie mają jednak zaskakująco podobny problem: serwis WWW, najczęściej na WordPressie, który został z tyłu za resztą biznesu. W firmie produktowej zespół inżynierski wpiął model w produkt, ale strona marketingowa, dokumentacja i blog działają jak przed pięcioma laty, a changelogi przekleja ręcznie ktoś z marketingu. W hotelu recepcja odpowiada mailowo na te same pytania o parking, dojazd z Balic i godziny śniadań w pięciu językach, choć wszystkie odpowiedzi od dawna stoją na stronie.

Integracja AI z WordPressem, którą prowadzimy, adresuje dokładnie tę lukę. Nie trenujemy modeli i nie obiecujemy autonomicznej firmy: podpinamy istniejące modele językowe, Claude i OpenAI, przez API do serwisu, który już macie, i to wyłącznie tam, gdzie efekt daje się zmierzyć. Ramowy opis usługi znajduje się na stronie integracji AI z WordPressem, tutaj piszemy o tym, jak wygląda ona w krakowskich realiach.

#AI w produkcie to nie to samo co AI w serwisie firmowym

Rozmowy z krakowskimi firmami technologicznymi mają inną dynamikę niż gdziekolwiek indziej, bo po drugiej stronie stołu często siedzi ktoś, kto sam woła API modeli w codziennej pracy. Nie musimy nikogo przekonywać, że LLM działa. Musimy za to odpowiedzieć na trudniejsze pytanie: skoro nasi inżynierowie potrafią to zbudować, po co nam wykonawca?

Odpowiedź brzmi: bo nie zbudują, a przynajmniej nie utrzymają. Serwis marketingowy na WordPressie jest w firmie produktowej niczyj. Zespół inżynierski traktuje go jak zło konieczne, marketing nie ma kompetencji technicznych, a każdy pomysł w rodzaju wyszukiwarki dokumentacji na modelu językowym umiera w backlogu, bo zawsze przegrywa priorytetyzację z funkcją produktu. Nasza rola polega na tym, że bierzemy tę warstwę na siebie w całości: znamy Gutenberga, taksonomie, REST API WordPressa i pułapki wtyczek, a architekturę integracji wasi inżynierowie mogą odebrać podczas przeglądu kodu zamiast pisać ją po godzinach.

Typowe przepływy w tym segmencie to wyszukiwarka dokumentacji odpowiadająca na pytania naturalnym językiem z cytowaniem źródła, szkice release notes generowane z changelogów przed redakcją człowieka oraz strona bazy wiedzy, która odciąża support z pytań zadawanych setny raz. Dla studiów gier dochodzi jeszcze obsługa społeczności: baza wiedzy o grze, patch notes w kilku językach i FAQ, które przestaje być martwym dokumentem, bo model potrafi po nim nawigować.

Studia gier zasługują tu na osobny akapit, bo ich potrzeby wokół WordPressa jako zaplecza społeczności są specyficzne. Typowe wdrożenia to wielojęzyczne patch notes generowane ze zmian w buildzie jako szkice do redakcji, baza wiedzy o grze, po której model potrafi nawigować, oraz FAQ odciążające support z pytań powtarzanych przy każdej premierze i wyprzedaży. Pilnujemy przy tym jednej granicy: model przygotowuje szkic, ale komunikat do graczy zatwierdza człowiek, bo w społecznościach gier ton i pojedyncze słowo potrafią wywołać reakcję nieproporcjonalną do samej treści. Danych graczy nie wysyłamy do API modelu, a treści przygotowane z jego pomocą oznaczamy zgodnie z naszą polityką AI.

#Chatbot wielojęzyczny dla hotelu: gość pyta po norwesku, odpowiedź jest z waszego cennika

Krakowska turystyka ma cechę, która czyni ją wyjątkowo dobrym przypadkiem dla modeli językowych: goście zadają w kółko te same pytania, tylko w różnych językach. Czy jest parking i ile kosztuje strefa. O której zameldowanie i czy można zostawić bagaż wcześniej. Czy śniadanie jest w cenie. Jak dojechać z lotniska. Czy pokój ma klimatyzację, bo lipiec. Recepcja odpowiada na to mailem i telefonem, w sezonie po kilkadziesiąt razy dziennie, a każda z tych odpowiedzi od dawna jest na stronie obiektu.

Chatbot, który budujemy dla obiektów noclegowych, działa na jednej zasadzie: odpowiada wyłącznie na podstawie treści serwisu i zatwierdzonej bazy wiedzy, a nie z ogólnej wiedzy modelu. Treść prowadzicie po polsku, model odpowiada w języku gościa, bo wielojęzyczność jest naturalną własnością dużych modeli językowych, a nie osobnym modułem do dokupienia. Przy pytaniu, na które baza nie zna odpowiedzi, bot odmawia i podaje kontakt do recepcji, a przy pytaniach o konkretną rezerwację przekazuje rozmowę człowiekowi razem z podsumowaniem wątku.

Ważne rozgraniczenie, które stawiamy uczciwie na początku współpracy: chatbot informacyjny nie dotyka silnika rezerwacyjnego. Prowadzi gościa do niego linkiem, ale nie zakłada, nie zmienia i nie odwołuje rezerwacji. Operacje na rezerwacjach przez agenta AI są technicznie możliwe, ale wymagają warstwy uprawnień, potwierdzeń i audytu, i są osobnym projektem o innym profilu ryzyka. Obiekt, który najpierw sprawdzi chatbota informacyjnego na realnym ruchu sezonu, podejmuje decyzję o tym drugim kroku na podstawie danych, a nie entuzjazmu.

#Zaplecze redakcyjne: od notatek projektowych do opublikowanego tekstu

Druga grupa wdrożeń w ogóle nie jest widoczna dla odwiedzających, a daje najpewniejszy zwrot: automatyzacja powtarzalnej pracy redakcyjnej z obowiązkowym zatwierdzeniem przez człowieka. W Krakowie pytają o nią dwa różne światy.

Software house’y i firmy usługowe mają chroniczny problem z opisami realizacji. Projekty się kończą, wiedza zostaje w notatkach z retrospektyw i wątkach na Slacku, a inżynierowie tekstów marketingowych nie napiszą, bo nie po to zostali inżynierami. Proces, który wdrażamy, zamienia materiał źródłowy, notatki z projektu, opis architektury i wynik wdrożenia w szkic opisu realizacji w ustalonym stylu. Szkic trafia do kolejki w panelu WordPressa, gdzie PM lub opiekun klienta poprawia fakty i zatwierdza publikację. Model nie wie, co było w projekcie poufne, dlatego weryfikacja przez człowieka jest tu mechanizmem bezpieczeństwa, a nie biurokracją.

Drugi świat to e-commerce i treści produktowe. Dla sklepów na WooCommerce, które prowadzimy w mieście w ramach rozwoju WooCommerce w Krakowie, model przygotowuje szkice opisów z danych produktowych, propozycje kategorii i robocze wersje tłumaczeń. Serwisy turystyczne używają tego samego wzorca w drugą stronę: treść źródłowa po polsku, szkice wersji angielskiej, niemieckiej czy hiszpańskiej z weryfikacją przed publikacją, bo wiemy z własnej sześciojęzycznej platformy, jak systematycznie modele gubią niuanse i idiomy.

Do tego dochodzi wyszukiwarka na treściach serwisu, wspólna dla obu światów. Klasyczne wyszukiwanie WordPressa zawodzi przy pytaniach zadawanych pełnym zdaniem, a tak właśnie pytają użytkownicy przyzwyczajeni do rozmów z modelami. Warstwa LLM rozumie intencję, znajduje właściwe strony i streszcza je z linkami do źródła. Personalizację treści i rekomendacje traktujemy jako etap ostatni, nie pierwszy: wymaga danych i zgód, które trzeba najpierw uczciwie zebrać i zmierzyć.

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

W krakowskich zespołach produktowych Model Context Protocol nie wymaga wprowadzenia, bo część z nich buduje własne serwery MCP do swoich produktów. Standard zapoczątkowany przez Anthropic pozwala wystawić treści i operacje systemu jako narzędzia, z których agent AI korzysta w kontrolowany sposób. My robimy to samo dla warstwy WordPressa: agent może przeszukać ofertę, pobrać treść strony, przygotować szkic wpisu, zawsze w granicach nadanych uprawnień i z logiem operacji.

Zastosowania są dwa. Wewnętrzne: zespół marketingu pracujący na co dzień z Claude może przez serwer MCP operować na serwisie bezpośrednio z rozmowy, zamiast przeklejać treści między oknami. Zewnętrzne: ruch agentowy w sieci rośnie i serwis, którego ofertę agent potrafi czytelnie odpytać, będzie w tym ruchu obecny, co dla obiektu noclegowego oznacza po prostu bycie znalezionym, gdy czyjś asystent planuje pobyt w Krakowie. Serwery budujemy w ramach usługi MCP server development, zawsze z warstwą uprawnień zaprojektowaną przed pierwszą linią kodu, bo agent z prawem zapisu do produkcyjnego serwisu bez ograniczeń to ryzyko, którego żaden audyt później nie wybroni.

#Art. 50 AI Act i RODO: obowiązki, które w turystyce widać gołym okiem

Zgodność z prawem traktujemy jako element architektury, nie załącznik do odbioru, a branża hotelarska pokazuje dlaczego lepiej niż jakakolwiek inna. Gość rozmawiający z chatbotem obiektu z własnej woli wpisuje imię, daty pobytu, czasem numer rezerwacji i szczegóły podróży. To są dane osobowe płynące do API zewnętrznego dostawcy i żadna klauzula w stopce tego nie załatwi.

Nasze podejście ma trzy warstwy. Po pierwsze, projektowanie rozmowy: chatbot informacyjny nie potrzebuje danych osobowych do odpowiedzi o parking, więc o nie nie prosi, a interfejs nie sugeruje, że ich podanie przyspieszy sprawę. Po drugie, higiena danych: maskowanie danych osobowych przed zapisem logów, umowa powierzenia z dostawcą modelu, wybór regionu przetwarzania, wyłączenie wykorzystania danych z API do treningu i ustalona retencja. Po trzecie, dokumentacja: opis przepływu danych w formie, którą inspektor ochrony danych klienta może przejąć do własnego rejestru.

Obowiązki przejrzystości z art. 50 AI Act, stosowane od 2 sierpnia 2026 roku, w hotelu sprawdzają się z perspektywy gościa, nie audytora. Gość piszący po norwesku o parking musi od pierwszej wiadomości wiedzieć, że rozmawia z asystentem AI, więc komunikat ujawniający tłumaczymy razem z resztą rozmowy, zamiast zostawiać go po polsku w stopce widgetu. Przejęcie wątku przez recepcję oznaczamy wprost jako zmianę rozmówcy, a robocze wersje językowe opisów pokoi przygotowane z pomocą modelu dostają oznaczenie w metadanych każdej wersji z osobna, bo obowiązek nie znika w tłumaczeniu.

#Kiedy integracja AI nie ma sensu

Częściej odradzamy projekty, niż wypada przyznać stronie usługowej, więc oto krakowska lista przypadków, w których mówimy nie.

Restauracja z menu na jednej podstronie nie potrzebuje chatbota, bo nie ma korpusu treści, z którego mógłby odpowiadać, a pytanie o wolny stolik załatwia telefon lub widget rezerwacji. Startup przed dowiezieniem produktu, który chce mieć coś z AI na stronie dla inwestorów, dostaje od nas radę, żeby ten budżet włożyć w produkt, bo atrapa na stronie marketingowej nie przetrwa pierwszego pytania na demo. Hotel, którego prawdziwym problemem jest przestarzały silnik rezerwacyjny gubiący gości przy płatności, powinien najpierw naprawić silnik, bo chatbot doprowadzający ruch do zepsutego formularza tylko powiększa stratę.

Jest też przypadek czwarty, najdelikatniejszy: firma, która chce modelem zastąpić redakcję, a nie ją odciążyć. Odmawiamy, bo widzieliśmy, jak kończy się publikowanie niezweryfikowanych treści na skalę: krótkoterminowo tanio, długoterminowo utrata zaufania i widoczności, której nie odbudowuje żaden kolejny model. Test kwalifikacyjny, który proponujemy zamiast dyskusji o trendach, jest przyziemny: policzcie przez dwa tygodnie powtarzalne maile, zapytania i godziny pracy redakcyjnej. Jeśli licznik jest pusty, projekt nie ma paliwa i uczciwie to powiemy.

#Od warsztatu do produkcji: jak wygląda współpraca

Wdrożenie zaczyna się od warsztatu kwalifikacyjnego, na którym wybieramy jeden przepływ o mierzalnym efekcie i klasyfikujemy dane pod kątem RODO. Sprawdzamy też rzecz, którą pomija większość ofert: czy treści serwisu w ogóle nadają się na bazę wiedzy, bo chatbot na nieaktualnym cenniku będzie z pełnym przekonaniem wprowadzał gości w błąd.

Potem powstaje prototyp na waszych treściach, w kilka tygodni, z human review od pierwszej wersji. Z prototypem pracuje zespół, który będzie go używał naprawdę: recepcja na pytaniach z ostatniego sezonu, PM na notatkach z zamkniętego projektu. Mierzymy jakość odpowiedzi, koszty tokenów i przypadki odmowy, bo odmowa przy pytaniu spoza bazy jest funkcją systemu, nie jego wadą. Dopiero po tej ewaluacji zapada decyzja o produkcji, która obejmuje limity budżetowe, monitoring, oznaczenia wymagane przez AI Act i dokumentację przekazania.

Wycena projektu jest indywidualna i zależy od zakresu. Koszty API modelu są osobną, publiczną pozycją rozliczaną od tokenów: w pilocie mierzymy je na realnym ruchu, więc rozmowa o skalowaniu toczy się nad rachunkiem, a nie nad prognozą. A gdy po pilocie pytania przestają dotyczyć serwisu, a zaczynają dotyczyć całej firmy, które procesy nadają się do automatyzacji i kto ma za nią odpowiadać, ta rozmowa toczy się już w ramach wdrożeń AI.

#Co przygotować do pierwszej oceny projektu

Żeby pierwsza rozmowa nie kończyła się listą ogólnych możliwości, prosimy o konkretny materiał wejściowy. Hotel lub aparthotel może przesłać adres serwisu, aktualne FAQ, regulamin pobytu i kilka zanonimizowanych pytań, które regularnie trafiają do recepcji. Firma technologiczna może wskazać repozytorium dokumentacji dostępnej publicznie, przykładowy changelog oraz opisać, kto dziś zatwierdza publikację. Nie potrzebujemy na tym etapie eksportu rozmów zawierającego dane gości ani dostępu administracyjnego do produkcyjnego WordPressa.

Na tej podstawie oceniamy cztery rzeczy: czy źródła są wystarczające i aktualne, gdzie konieczna jest odmowa modelu, kto będzie właścicielem human review oraz jaki wynik da się sprawdzić po pilocie. Dla krakowskiego obiektu noclegowego może nim być udział poprawnych odpowiedzi na zamkniętym zestawie pytań po polsku, angielsku i niemiecku. Dla software house’u lepszą miarą będzie odsetek szkiców release notes, które redaktor akceptuje po korekcie faktów. Kryterium ustalamy przed prototypem, dzięki czemu efektowna demonstracja nie zastępuje odbioru jakościowego.

Jeżeli materiał źródłowy jest rozproszony albo sprzeczny, rekomendujemy najpierw uporządkowanie treści. To również jest wynik analizy: baza wiedzy dla modelu ujawnia stare cenniki, rozbieżne godziny zameldowania i strony bez właściciela szybciej niż klasyczny audyt. Dopiero po usunięciu tych różnic integracja ma stabilny punkt odniesienia.

#Dlaczego agencja WordPress, a nie kolejny wykonawca od AI

Kraków nie ma deficytu ludzi znających modele językowe, ma deficyt ludzi, którzy znają jednocześnie modele i WordPressa. Integracja AI z systemem redakcyjnym wymaga wiedzy o tym, jak pracuje redakcja i recepcja, gdzie w WooCommerce kończy się katalog, a zaczyna checkout, i które wtyczki wybuchną przy pierwszym konflikcie z nowym endpointem.

Pracujemy z WordPressem od 2007 roku, a warstwę AI stosujemy najpierw u siebie: nasza platforma liczy ponad siedem tysięcy statycznych podstron w sześciu językach, serwuje metadane dla crawlerów AI i oznacza treści wspierane modelami zgodnie z własną, opublikowaną polityką. Dla krakowskiej firmy produktowej oznacza to partnera, który zdejmie serwis marketingowy z barków zespołu inżynierskiego bez wstydu podczas przeglądu kodu. Dla hotelu przy Rynku oznacza to wykonawcę, który rozumie zarówno sezonowość ruchu, jak i pytanie o to, gdzie trafiają dane gościa. Wejście w obu przypadkach jest takie samo i niezobowiązujące: warsztat z rekomendacją, także wtedy, gdy rekomendacja brzmi, że AI nie jest wam teraz potrzebne.

Ostatnia aktualizacja: 10 lipca 2026