Strona może być świetnym źródłem informacji dla AI, a jednocześnie fatalnym miejscem do wykonania zadania. Agent może poprawnie odczytać ofertę, lecz zatrzymać się na formularzu, nie rozpoznać przycisku, pomylić cenę, stracić dane po błędzie albo nie wiedzieć, czy rezerwacja została faktycznie utworzona.
Gotowość na agentów AI zaczyna się tam, gdzie kończy się samo odczytywanie treści. Serwis musi pozwolić przejść od informacji do kontrolowanego działania: rozpoznać opcje, uzupełnić dane, zrozumieć warunki, obsłużyć błędy, potwierdzić rezultat i zatrzymać proces przed operacją wymagającą decyzji człowieka.
Strona gotowa dla agentów AI powinna łączyć semantyczny HTML, czytelne drzewo dostępności, jednoznaczne kontrolki, dostępne formularze, stabilną nawigację, aktualne dane transakcyjne, jasne komunikaty błędów oraz bezpieczne potwierdzanie działań. Nie trzeba tworzyć osobnej „wersji dla AI”. Najpierw trzeba sprawić, aby główny interfejs był zrozumiały, przewidywalny i możliwy do obsłużenia zarówno przez człowieka, technologie asystujące, jak i system automatyzujący przeglądarkę.
Agent AI nie tylko odpowiada — ma doprowadzić do rezultatu
To podstawowa różnica między klasycznym systemem generującym odpowiedź a agentem wykonującym zadanie.
| System odpowiedzi | Agent wykonawczy |
|---|---|
| odnajduje informacje | odnajduje informacje i wykonuje akcje |
| porównuje opcje | wybiera właściwą opcję |
| opisuje ofertę | przechodzi przez proces |
| generuje odpowiedź | osiąga albo przygotowuje rezultat |
Agent może więc próbować:
Gotowość agentowa to kolejny poziom AI Ready
Strona AI Ready musi być najpierw możliwa do odnalezienia i zrozumienia. Agentic readiness dodaje do tego możliwość działania.
system dociera do zasobu
rozpoznaje treść i ofertę
identyfikuje możliwe działania
przechodzi przez interfejs
sprawdza rezultat
finalizuje zgodnie z intencją użytkownika
Szerszy model przygotowania treści i strony opisuje hub Treści AI Ready.
Najważniejszym interfejsem może być drzewo dostępności
Agent działający w przeglądarce nie musi interpretować strony dokładnie tak jak człowiek.
W zależności od technologii może korzystać z:
DOM
Elementy dokumentu, ich atrybuty, tekst i relacje.
Drzewo dostępności
Role, nazwy, wartości, stany i relacje kontrolek.
Obraz strony
Wizualna analiza interfejsu i lokalizacji elementów.
Dane i interfejsy
Uporządkowane informacje lub mechanizmy integracyjne.
Nie każdy agent korzysta z drzewa dostępności, DOM, obrazu lub API w ten sam sposób. Projekt powinien być spójny w kilku reprezentacjach jednocześnie.
Semantyczny HTML jest tańszy niż naprawianie niejednoznaczności
Najprostsza zasada brzmi: używaj elementu odpowiadającego rzeczywistej funkcji.
| Funkcja | Właściwy element |
|---|---|
| przejście do zasobu | a |
| wykonanie działania | button |
| główna nawigacja | nav |
| formularz | form |
| etykieta pola | label |
| grupa opcji | fieldset + legend |
| dane tabelaryczne | table |
Przycisk zbudowany jako neutralny div może wyglądać poprawnie, lecz wymaga ręcznego odtworzenia semantyki, obsługi klawiatury, fokusu i stanów.
ARIA powinna uzupełniać interfejs, a nie go udawać
Najpierw natywny HTML. ARIA dopiero wtedy, gdy rzeczywiście trzeba uzupełnić brakującą semantykę komponentu.
Ręczne nadawanie ról źle zbudowanym komponentom może stworzyć interfejs, który deklaruje jedną funkcję, a zachowuje się inaczej.
Agent powinien wiedzieć cztery rzeczy o każdej kontrolce
Rola → nazwa → stan → możliwe działanie.
Przykładowo lista wyboru powinna ujawniać:
Widoczny interfejs i drzewo dostępności muszą mówić to samo
Jednym z trudniejszych błędów jest sytuacja, w której użytkownik widzi jeden element, a warstwa programowa udostępnia dwa lub trzy.
Na ekranie istnieje jeden „Kup teraz”, ale ukryta poprzednia wersja komponentu nadal pozostaje dostępna w drzewie.
Agent może wtedy wykonać akcję na niewłaściwym elemencie.
Nazwa przycisku powinna opisywać skutek
Im ważniejsza operacja, tym mniej miejsca na kreatywne etykiety.
| Niejednoznacznie | Lepiej |
|---|---|
| Dalej | Przejdź do płatności |
| Wyślij | Wyślij zapytanie ofertowe |
| OK | Potwierdź rezerwację |
| Kliknij | Pobierz fakturę PDF |
Przycisk „Sprawdź cenę” nie może potajemnie składać zamówienia. Nazwa działania powinna odpowiadać jego rzeczywistemu skutkowi.
Formularz jest testem dojrzałości strony agentowej
Agent musi jednocześnie zrozumieć:
Jeżeli człowiek musi się domyślać, co autor formularza miał na myśli, agent prawdopodobnie również będzie miał problem.
Placeholder nie zastępuje etykiety
Trwała etykieta → typ pola → wymaganie → format → wartość → błąd.
Pole „Adres e-mail” powinno posiadać prawdziwą, programowo powiązaną etykietę. Placeholder może podać przykład, ale nie powinien być jedyną informacją opisującą pole.
Właściwy typ danych usuwa część niejednoznaczności
email dla adresu e-mailtel dla telefonudate dla datynumber dla wartości liczbowejWarto również prawidłowo wykorzystywać name i autocomplete, gdy odpowiadają rzeczywistemu przeznaczeniu pola.
Walidacja powinna kontrolować znaczenie, a nie karać za format
Typowe bariery to:
Tolerancyjny format → rygorystyczne znaczenie.
Błąd powinien mówić, co się stało i co zrobić dalej
| Słabo | Dobrze |
|---|---|
| Nieprawidłowe dane | Numer telefonu jest za krótki. Wprowadź co najmniej 9 cyfr. |
| Coś poszło nie tak | Wybrany termin nie jest już dostępny. Wybierz inny termin. |
| Błąd formularza | Adres e-mail nie ma prawidłowego formatu. |
Dobry komunikat odpowiada na trzy pytania:
Po błędzie nie każ agentowi zaczynać od początku
Prawidłowo wprowadzone dane powinny zostać zachowane.
Po nieudanej próbie agent powinien:
rozpoznaj błąd
znajdź problematyczne pole
zmień tylko błędną wartość
wyślij ponownie
Dynamiczna zmiana musi pozostawić czytelny ślad
Agent powinien jednoznacznie dowiedzieć się, że:
Krótkotrwała zielona ikonka bez tekstu jest słabym mechanizmem potwierdzenia.
Nawigacja powinna być przewidywalna
Tekst linku powinien pozwalać przewidzieć cel przejścia.
| Niejednoznacznie | Opisowo |
|---|---|
| Więcej | Sprawdź warunki dostawy |
| Czytaj | Zobacz zasady anulowania rezerwacji |
| Szczegóły | Sprawdź warunki gwarancji |
Duże sklepy i systemy rezerwacyjne powinny dodatkowo jasno komunikować bieżące położenie, etap procesu i możliwość powrotu.
Interfejs nie powinien uciekać spod kursora
Niestabilność wizualna jest nie tylko problemem UX. Może prowadzić do wykonania niewłaściwej akcji.
Obsługa klawiaturą jest bardzo dobrym testem jakości
Jeżeli pełną ścieżkę można przejść za pomocą klawiatury, interfejs zazwyczaj posiada bardziej przewidywalny model interakcji.
Dane transakcyjne muszą pozwalać podjąć decyzję przed kliknięciem
Agent nie powinien dochodzić do warunków zakupu dopiero po rozpoczęciu transakcji.
Co? → który wariant? → za ile? → czy dostępne? → kiedy? → na jakich warunkach?
W sklepie cena bez kontekstu jest niepełną informacją
Agent powinien móc ustalić:
Rezerwacja wymaga także kontekstu czasu
„Wolne o 15:00” bez daty, lokalizacji lub strefy czasowej może być informacją niewystarczającą do bezpiecznego działania.
Dostępność oferty powinna oznaczać możliwość jej wykorzystania teraz
Jeżeli produkt jest dostępny tylko:
informacja „Dostępny” powinna ujawniać ten kontekst.
Dane strukturalne pomagają opisać ofertę, ale nie wykonują procesu
Schema.org może uporządkować informacje o produkcie, cenie, organizacji, wydarzeniu czy dostępności.
Dane strukturalne nie naprawią formularza bez etykiet, przycisku bez nazwy, błędu bez komunikatu ani procesu bez potwierdzenia.
Najważniejsza zasada agentic commerce: przed zobowiązaniem pokaż pełny stan
Produkt / usługa → wariant → odbiorca → termin → pełny koszt → metoda płatności → warunki → skutek zatwierdzenia.
Agent może przygotować operację. Użytkownik powinien dokładnie wiedzieć, co zostanie wykonane.
Operacja wysokiego ryzyka potrzebuje granicy decyzyjnej
Można automatyzować
Wyszukanie oferty, filtrowanie, porównanie lub przygotowanie formularza.
Wymaga jasnego potwierdzenia
Wysłanie zapytania, utworzenie rezerwacji lub zmiana danych.
Przekaż kontrolę człowiekowi
Płatność, zobowiązanie prawne, operacja nieodwracalna lub dostęp do danych wrażliwych.
Końcowy przycisk nie może pozostawiać wątpliwości
Przy działaniach powodujących realne zobowiązanie lepsze są etykiety:
niż neutralne „Dalej”, „OK” czy „Potwierdź”.
Agent nie powinien obchodzić zabezpieczeń
CAPTCHA, MFA czy ponowna autoryzacja mogą być celowymi granicami bezpieczeństwa.
Agent przygotowuje → zatrzymuje proces → użytkownik przejmuje → użytkownik autoryzuje.
Gotowość agentowa nie oznacza usunięcia kontroli bezpieczeństwa tylko po to, aby automatyzacja mogła przejść dalej.
Treść strony nie jest upoważnieniem użytkownika
Agent może napotkać na stronie tekst próbujący skłonić go do wykonania nieuzgodnionego działania.
Polecenie użytkownika i treść odczytana ze strony to dwa różne źródła instrukcji.
Serwis nie powinien projektować komunikatów podszywających się pod instrukcje systemowe ani próbować wymuszać działania niezwiązanego z intencją użytkownika.
JavaScript nie jest problemem. Nieprzewidywalny stan jest problemem
Aplikacje SPA mogą być bardzo dobrze obsługiwalne, jeżeli zachowują spójną semantykę i stan.
Nie twórz osobnej strony „dla AI”
Strona dla ludzi → osobna uproszczona kopia dla agentów → dwa różne źródła prawdy.
Oddzielna wersja szybko może zacząć pokazywać inną cenę, ofertę, dostępność lub warunki.
Lepszy model:
Jedna rzeczywistość → widoczny interfejs → semantyka → dane strukturalne → ewentualne API.
Kiedy API ma sens?
Nie każdy formularz potrzebuje specjalnego interfejsu programistycznego.
API staje się szczególnie interesujące, gdy proces jest:
Najpierw jednak należy uporządkować podstawowy produkt, dane i proces. API nie powinno maskować chaosu istniejącego w systemie źródłowym.
Gotowość agentową trzeba testować jako pełne zadanie
Test „agent kliknął przycisk” jest za słaby.
Cel użytkownika → odnalezienie → wybór → formularz → wyjątek → potwierdzenie → rezultat.
Przykładowe scenariusze:
Testuj również sytuacje, w których coś idzie nie tak
Dobry agentic interface nie tylko pozwala wykonać ścieżkę idealną. Pozwala także bezpiecznie wyjść z błędu.
Test klawiaturą i drzewem dostępności powinien wejść do audytu
przejdź cały proces bez myszy
sprawdź kontrolki
zweryfikuj etykiety
sprawdź zmiany dynamiczne
wymuś wyjątki
potwierdź zakończenie
Gotowość agentowa i dostępność mocno się pokrywają, ale nie są tym samym
| Dostępność | Gotowość agentowa |
|---|---|
| równy dostęp ludzi do treści i funkcji | możliwość bezpiecznego delegowania części działań |
| semantyka kontrolek | semantyka + konsekwencje działania |
| obsługa formularza | formularz + rezultat + wyjątki |
| obsługa klawiaturą | przewidywalna automatyzacja interfejsu |
WCAG jest bardzo dobrą bazą, ale nie opisuje całego problemu delegowania transakcji agentowi.
Najczęstsze błędy przy projektowaniu pod agentów AI
Interfejs z samych divów
Wygląd jest poprawny, ale funkcja elementów pozostaje niejednoznaczna.
Placeholder jako label
Po wpisaniu wartości znika informacja o znaczeniu pola.
„Coś poszło nie tak”
Komunikat nie mówi, co poprawić.
Niejednoznaczne CTA
Nazwa przycisku nie opisuje konsekwencji działania.
Niespójne ceny
Lista, produkt i koszyk pokazują różne wartości bez wyjaśnienia.
Brak końca procesu
Agent nie wie, czy operacja się powiodła i może ją powtórzyć.
Najważniejsze mity
| Mit | Rzeczywistość |
|---|---|
| Wystarczy Schema.org | uporządkowane dane nie obsłużą niedostępnego interfejsu |
| Agent widzi stronę jak człowiek | może używać DOM, drzewa dostępności, obrazu lub API |
| WCAG = agent ready | dostępność jest fundamentem, ale potrzebne są także dane i bezpieczeństwo transakcji |
| Vision rozwiązuje każdy interfejs | analiza obrazu nie usuwa niejednoznaczności |
| Agent powinien wszystko finalizować sam | część działań wymaga świadomej autoryzacji człowieka |
| Potrzebna jest osobna strona dla AI | lepsza jest jedna spójna wersja serwisu |
Checklista minimalnej gotowości agentowej
Model końcowy: agent musi widzieć drogę od intencji do rezultatu
Intencja użytkownika → informacja → dostępne działanie → wymagane dane → warunki → walidacja → podsumowanie → zgoda → wykonanie → potwierdzenie.
To znacznie szerszy problem niż „czy bot może wejść na stronę?”.
Crawler potrzebuje dostępu do treści.
System odpowiedzi potrzebuje treści, którą może zrozumieć i wykorzystać.
Agent potrzebuje dodatkowo interfejsu, w którym każde działanie posiada jednoznaczne znaczenie, aktualne dane wejściowe, przewidywalny rezultat i bezpieczną granicę odpowiedzialności.
Dlatego najlepsza strona dla agentów AI bardzo często okazuje się po prostu lepszą stroną dla ludzi: ma mniej domysłów, bardziej przejrzyste formularze, stabilniejszą nawigację, czytelniejsze warunki oferty i mniej błędów w procesie konwersji.
