Zanim powierzysz rozwój aplikacji zespołowi korzystającemu z agentów AI, sprawdź, co agent może zrobić bez pytania człowieka. W Awakast mamy to zapisane: oddzielamy samodzielną pracę od decyzji wymagających zgody i określamy, jak sprawdzić rzeczywisty wynik.
Dla właściciela firmy to ważniejsze niż długa lista narzędzi. Przygotowanie zmiany, zgoda na jej wdrożenie i sprawdzenie działającej aplikacji to odrębne zadania. Można zlecić agentowi pierwsze, nie oddając mu pozostałych.
Pracujemy z własnymi agentami. Dajemy im swobodę w zbieraniu informacji i przygotowywaniu pracy, ale część decyzji zostaje po stronie ludzi. Na własnej stronie zobaczyliśmy też, dlaczego sam zapis nie wystarcza. Zaakceptowana nowa wersja nie przeszła pierwszego wdrożenia. Z kolei działająca strona demonstracyjna próbowała uruchomić analitykę przed decyzją odwiedzającego.
W naszych zasadach dzielimy tę odpowiedzialność na cztery kategorie.
1. Agent działa samodzielnie
Może zbierać informacje, czytać dane analityczne i przygotowywać robocze teksty. Nie potrzebuje osobnej zgody na każde otwarcie źródła czy porównanie rozwiązań. Ma zamienić pytanie w materiał, na którym da się oprzeć dalszą pracę.
Granica przebiega między przygotowaniem a działaniem w imieniu firmy. Gotowy szkic wiadomości nie jest zgodą na jej wysłanie. Propozycja zmiany nie oznacza, że można ją od razu wdrożyć. Zlecenie przygotowania pracy nie daje agentowi prawa do wydawania pieniędzy.
Dzięki temu nie trzeba angażować właściciela firmy w każdy krok. Powinien dostać coś, co może ocenić: odpowiedź opartą na źródłach, tekst do sprawdzenia albo zmianę gotową do testów. Sam komunikat „zrobione” niczego takiego nie zastępuje.
Osobna zasada dotyczy czytanych materiałów. Strona internetowa, otrzymany e-mail czy załącznik mogą dostarczyć informacji. Nie mogą zmienić uprawnień agenta ani wydać mu polecenia w imieniu osoby decydującej. Tekst z zewnątrz jest materiałem do pracy, nie źródłem zgody na działanie.
2. Agent kończy pracę i informuje o wyniku
Nasze zasady pozwalają publikować sprawdzone artykuły i niewielkie poprawki na istniejących stronach bez każdorazowego pytania o zgodę. Wymagane sprawdzenia i ocena podglądu nadal obowiązują, a o wyniku informujemy tego samego dnia.
„Niewielka poprawka” nie oznacza dowolnej zmiany w małym pliku. Poprawienie podpisu albo doprecyzowanie akapitu to co innego niż przebudowa sekcji, zmiana formularza czy sposobu działania analityki. Agent nie może wybrać prostszej ścieżki tylko dlatego, że wygodniej byłoby pominąć zgodę.
Przygotowanie zmiany oddzielamy też od jej publikacji. Proces wdrożenia buduje wskazaną wersję, wykonuje kopię zapasową i sprawdza wynik na działającej stronie. Agent odpowiedzialny za rozwój treści nie przesyła samodzielnie plików na hosting. Po publikacji trzeba jeszcze otworzyć stronę i obejrzeć rzeczywisty rezultat.
Przy wyborze zespołu warto zejść właśnie do tego poziomu. Zdanie „sprawdzamy pracę AI” niewiele mówi. Liczy się to, jaka zmiana może przejść bez Twojej decyzji, co zostanie sprawdzone i gdzie zobaczysz wynik.
3. Najpierw potrzebna jest decyzja człowieka
Nowa strona, większa przebudowa, zmiana infrastruktury czy poniesienie kosztu wymagają zgody. Agent nie może też sam zdecydować o wysłaniu wiadomości do osoby spoza firmy. Może przygotować pracę, ale nie zyskuje przez to prawa do wykonania kolejnego kroku.
Zgoda dotyczy konkretnego działania. Akceptacja jednej strony nie upoważnia do wdrożenia innej zmiany. Polecenie przygotowania propozycji nie oznacza zgody na zakup usługi. Jeśli odpowiedź nie rozstrzyga całej sprawy, nasza zasada nakazuje zapytać o brakujący punkt, zamiast dopowiadać sobie resztę.
Gdy potrzebna jest decyzja o widocznej zmianie na stronie, przekazujemy działający podgląd oraz zrzuty z komputera i telefonu. Osoba decydująca ma zobaczyć, na co się zgadza. Sama nazwa gałęzi z kodem albo obietnica przyszłego efektu nie daje jej tej możliwości.
Zgoda rozstrzyga, czy wolno działać. Nie potwierdza, że działanie się udało. Przekonaliśmy się o tym przy wdrożeniu nowej wersji naszej strony.
4. Tych działań agentowi nie wolno podejmować
Nie wolno wymyślać wyników klientów, ujawniać poufnych danych ani zmieniać własnych uprawnień. Nie wolno też przypisywać człowiekowi zgody, której nie udzielił. Zatrzymanie działania przez zabezpieczenie nie jest zachętą do szukania innej drogi, żeby je ominąć.
Gdy coś idzie nie tak, instrukcja nakazuje zatrzymać dane działanie, opisać stan i zaproponować następny krok. Nie ponawiać destrukcyjnych prób tak długo, aż pojawi się komunikat o sukcesie.
Zaakceptowane wdrożenie, które trzeba było powtórzyć
26 października pierwsza próba opublikowania zaakceptowanej nowej wersji naszej strony zakończyła się błędem. Mechanizm ograniczający usuwanie plików zatrzymał przesyłanie. W wyniku wdrożenia zapisano niepowodzenie oraz przywrócenie poprzedniej strony z kopii zapasowej.
Projekt miał już zgodę na publikację. Nie zmieniło to wyniku nieudanej próby ani nie dawało agentowi prawa do samodzielnej zmiany zabezpieczeń wdrożenia. Operator poprawił konfigurację publikacji i ponownie wdrożył tę samą wersję.
Drugi wynik potwierdził udane wdrożenie oraz sprawdzenie 32 stron, w tym trzech przekierowań obsługiwanych przez hosting, a także mapy witryny i instrukcji dla robotów wyszukiwarek. Był to konkretny zestaw sprawdzeń opublikowanej strony, nie pełny test każdej jej funkcji.
Dla osoby powierzającej komuś aplikację istotny jest przebieg: pierwsza próba miała zapisany błąd, poprzednie pliki zostały przywrócone, a kolejna próba dostała osobne potwierdzenie wyniku. Akceptacja projektu nie posłużyła za dowód, że strona już działa w nowej wersji.
Droga powrotna powinna być częścią planu wdrożenia, zanim okaże się potrzebna. Tutaj zapis potwierdza jej użycie. Ponowne wdrożenie dotyczyło tej samej zaakceptowanej wersji; interwencja operatora dotyczyła sposobu jej opublikowania.
Strona się otwierała, ale robiła coś, czego nie powinna
Drugi przypadek dotyczył naszej strony demonstracyjnej. Sprawdzenie w przeglądarce 1 listopada wykazało, że starszy sposób ładowania analityki wysyłał żądania śledzące, zanim odwiedzający zdecydował, czy dopuszcza analitykę.
Strona otwierała się poprawnie. Samo potwierdzenie dostępności nie odpowiadało jednak na pytanie, czy respektuje wybór użytkownika.
Zastąpiliśmy starszy sposób ładowania analityki mechanizmem zgody używanym na głównej stronie. Poprawka została opublikowana 1 listopada. Zapisane sprawdzenia na komputerze i telefonie obejmowały wejście bez podjętej decyzji, odmowę, akceptację oraz wycofanie zgody i ponowne załadowanie strony. Sprawdzaliśmy nie tylko działanie analityki po akceptacji, lecz także to, czy pozostaje wyłączona bez zgody i po jej wycofaniu.
Stara wersja próbowała załadować narzędzie śledzące przed decyzją użytkownika. Poprawiona wersja nie robiła tego przy pierwszym wejściu ani po odmowie i odświeżeniu strony. Po wycofaniu zgody i ponownym załadowaniu strony zapisany stan zgody wyłączał śledzenie.
Przy tej poprawce potwierdzenie wdrożenia było więc tylko częścią odbioru. Trzeba było sprawdzić zachowanie strony po odmowie równie konkretnie jak po akceptacji. Komunikat o udanej publikacji nie odpowiadał na to pytanie.
Co ustalić, zanim oddasz zespołowi dostęp do aplikacji
Wybierz jedno rzeczywiste zadanie, które chcesz powierzyć zespołowi. Przed rozpoczęciem pracy poproś o zapisanie:
- Co agent może przygotować, a co również samodzielnie zakończyć.
- Które działanie wymaga Twojej decyzji albo zgody wskazanej osoby z zespołu.
- Jaki wynik dostaniesz do oceny i jak zostanie sprawdzony w miejscu, w którym ma działać.
- Co nastąpi po nieudanym sprawdzeniu, kto zatrzyma pracę i kto zdecyduje o następnym kroku.
Ten zapis powinien towarzyszyć zadaniu. Przy wdrożeniu poproś o potwierdzenie, która wersja trafiła na stronę i co sprawdzono po publikacji. Jeśli wdrożenie się nie udało, potrzebujesz również opisu błędu, potwierdzenia przywrócenia poprzedniej wersji oraz wyniku kolejnej próby. Przy poprawce dotyczącej zgody potrzebne będą wyniki sprawdzeń wyborów odwiedzającego. Dowód ma odpowiadać na pytanie o efekt pracy, nie tylko potwierdzać uruchomienie narzędzia.
Jeśli masz już aplikację napisaną z pomocą AI, nasz przegląd przed uruchomieniem sprawdza w niej m.in. logowanie i uprawnienia, kopie zapasowe oraz to, czy nieudane wdrożenie da się wycofać.
Korzystamy z własnych agentów, ale nie przenosimy na nich odpowiedzialności. Po stronie programistów zostają decyzje i sprawdzenie tego, co trafia do Twojej firmy. Tak rozumiemy zdanie „Agenci AI dają szybkość. Programiści dają pewność”: agent ma określone zadanie, a za rezultat odpowiadają ludzie.