Przy agentach AI — programach, które korzystają z AI i same wykonują zadania w firmowych systemach — najbardziej praktyczne pytanie nie dotyczy modelu, tylko CRM, czyli systemu do obsługi klientów: „a co on będzie mógł w nim zrobić?” W firmie z działem bezpieczeństwa odpowiedź powstaje w procedurze. W firmie, która ma dwadzieścia czy sto osób i jednego informatyka albo zewnętrzną obsługę IT, ktoś musi ją po prostu zapisać — i najlepiej, żeby był to jeden arkusz, który rozumie zarówno właściciel, jak i dostawca.
Ten tekst jest takim arkuszem. Jeden wiersz to jeden system, do którego agent ma dostęp: CRM, skrzynka pocztowa, ERP (system do zamówień, magazynu i finansów), kalendarz, dysk z dokumentami. Kolumny porządkują pytania, które trzeba rozstrzygnąć przed startem: na jakim koncie agent pracuje, gdzie leży jego klucz dostępu, kto go wyłączy i co się stanie z zadaniem przerwanym w trakcie. Poniżej znajdziesz trzy wypełnione wiersze, przykładowe błędy, przed którymi chronią kolumny konta, klucza i wyłącznika, pytania do dostawcy, którego produkt „potrzebuje pełnego dostępu”, oraz to, co z arkusza warto przenieść do załącznika technicznego umowy.
Pobierz arkusz (CSV) — otwiera się w Excelu, Arkuszach Google i LibreOffice, z trzema wypełnionymi przykładami i pustymi wierszami na Twoje systemy. Jeśli dane pojawią się w jednej kolumnie, zaimportuj plik w kodowaniu UTF-8, ze średnikiem (;) jako separatorem.
Arkusz w skrócie: jeden wiersz na system, dwanaście kolumn
| Kolumna | Pytanie, na które odpowiada |
|---|---|
| System | Do którego systemu agent dostaje dostęp? |
| Co agent czyta | Z których danych korzysta — i z których nie? |
| Co agent zmienia | Co wolno mu zapisać i w jakiej postaci (wersja robocza, notatka, szkic)? |
| Czego nigdy nie robi sam | Które czynności mają istotne skutki i zawsze czekają na człowieka? |
| Kto zatwierdza | Która rola zatwierdza i kto ją zastępuje? |
| Konto agenta | Na jakim koncie agent działa w tym systemie? |
| Klucz dostępu | Gdzie leży jego hasło albo klucz i kto ma do niego dostęp? |
| Wymiana klucza | Kiedy klucz się zmienia i kto to robi? |
| Wyłącznik | Kto zatrzymuje agenta, w jaki sposób i ile to trwało w teście? |
| Zadanie w toku | Co się dzieje z pracą przerwaną w trakcie? |
| Zapis działań | Gdzie widać, co agent zrobił? |
| Przegląd | Kiedy ostatnio ktoś sprawdził ten wiersz i przetestował wyłącznik? |
Kolumny o odczycie, zapisie i czynnościach wymagających człowieka oraz zapis działań to podstawy, które opisaliśmy już na stronie o wdrażaniu agentów AI: zakres odczytu tak wąski, jak pozwala zadanie, zakres zapisu jeszcze węższy, zgoda człowieka na czynności, których nie da się cofnąć, i rejestr działań pozwalający odtworzyć decyzję. Jak zaprojektować sam krok zatwierdzania przez człowieka (human in the loop), żeby nie zamienił się w klikanie, rozpisaliśmy w osobnym tekście. Tutaj tylko jedna zasada, bez wyjątków: w pierwszej wersji agentów, które budujemy, czynności o istotnych skutkach — wysyłka do klienta, płatność, zmiana ceny, rezerwacja, zobowiązanie, ale też zmiana statusu, która w firmie uruchamia coś dalej — zatwierdza człowiek, nawet jeśli technicznie da się je cofnąć. Kolumna „czego nigdy nie robi sam” musi więc być wypełniona dla każdego systemu.
Reszta tekstu dotyczy kolumn, o których najłatwiej zapomnieć: konta, klucza i wyłącznika.
Dlaczego „pełny dostęp, żeby wszystko działało” to kosztowne ustawienie
Najprostszy sposób, żeby agent od razu działał, to dać mu konto administratora albo login kogoś, kto ma dostęp do wszystkiego. Wtedy nic nie blokuje testów i wszystko wygląda dobrze — do pierwszego błędu. OWASP, międzynarodowa organizacja zajmująca się bezpieczeństwem aplikacji, opisuje to ryzyko pod nazwą excessive agency (nadmierna sprawczość) i wymienia trzy jego źródła: agent ma więcej funkcji, niż potrzebuje, więcej uprawnień, niż potrzebuje, i więcej samodzielności, niż powinien (OWASP, LLM06:2025).
OWASP ilustruje ten mechanizm przykładem. Asystent ma streszczać przychodzącą pocztę, ale narzędzie, przez które czyta skrzynkę, umie też wysyłać. Ktoś przysyła wiadomość z ukrytymi poleceniami dla modelu — takie wstrzyknięcie poleceń (prompt injection) to tekst, który agent czyta jak instrukcję, choć przyszedł z zewnątrz. Agent przeszukuje skrzynkę i przesyła poufne wiadomości nadawcy. OWASP wskazuje trzy zabezpieczenia: narzędzie tylko do czytania poczty, dostęp z uprawnieniem tylko do odczytu i ręczne zatwierdzanie każdej wysyłki. Każde z nich jest jedną komórką arkusza.
Pełny dostęp nie jest więc ustawieniem, tylko brakiem decyzji. Zwiększa możliwy zasięg każdego błędu, a koszt tej decyzji odkłada się do dnia, w którym agent pomyli się na danych, do których nie powinien był mieć dostępu.
Tożsamość: agent nigdy nie pracuje na loginie właściciela
Pierwsza z tych kolumn to konto. Zasada jest prosta: agent dostaje osobne konto w każdym systemie, z rolą obejmującą tylko jego zadanie. Nigdy hasło właściciela, prezesa ani kogokolwiek innego. Wspólny login niesie trzy ryzyka:
- Historia zmian. Gdy agent działa na Twoim loginie, w CRM i ERP każda jego zmiana wygląda jak Twoja. Po błędzie nie da się ustalić, co zrobił człowiek, a co automat.
- Odcięcie dostępu. Osobne konto agenta można zablokować bez blokowania człowieka. Na wspólnym loginie odcięcie agenta oznacza odcięcie Ciebie, a zmiana Twojego hasła — na przykład po urlopie — może bez ostrzeżenia zatrzymać agenta.
- Zasięg szkody. Agent na koncie właściciela ma uprawnienia właściciela, także te, których jego zadanie nie wymaga. Każdy błąd ma wtedy zasięg całego konta.
OWASP w swojej liście najpoważniejszych ryzyk dla agentów AI (Top 10 for Agentic Applications) wymienia nadużycie tożsamości i uprawnień agenta jako osobną pozycję — dlatego poświęcamy tej kolumnie osobną część tekstu.
Czasem czynność musi zostać wykonana w imieniu konkretnej osoby — na przykład szkic w jej skrzynce. Wtedy zamiast hasła stosuje się dostęp delegowany: osoba udziela agentowi wąskiego, opisanego uprawnienia (np. tylko do tworzenia szkiców), które można odebrać bez zmiany jej hasła. OWASP zaleca w takim przypadku działanie w kontekście użytkownika, ale z minimalnymi uprawnieniami — to nie to samo co przekazanie hasła ani pełnej sesji. Co taki dostęp obejmuje, jak widać go w historii zmian i jak go odebrać — to trzeba sprawdzić w konkretnym systemie, zanim wpiszesz go do arkusza.
Jeśli Twoja firma korzysta już z Microsoft 365, a więc z Microsoft Entra, warto wiedzieć, że Microsoft udostępnia osobne tożsamości dla agentów (Microsoft Entra Agent ID), a rozszerzenie na nie funkcji bezpieczeństwa Entra wymaga Microsoft Agent 365 (Microsoft Learn, stan na 12 października 2026 r.).
Typowy scenariusz (ilustracja, nie historia konkretnego klienta). Automatyzacja zakładająca zadania i przesuwająca etapy szans sprzedaży w CRM działa na loginie właściciela, bo „tak było najszybciej”. Właściciel zmienia hasło, automatyzacja przestaje działać, a nikt nie łączy tych dwóch faktów przez kilka dni. Gdy w końcu ktoś szuka, kto zmienił etap kilkunastu szans sprzedaży, historia zmian pokazuje jedną osobę — właściciela.
Klucze dostępu i ich wymiana — po ludzku
Agent łączy się z systemem przez API, czyli interfejs, przez który programy wymieniają dane bez klikania w ekran. Żeby system go wpuścił, agent przedstawia klucz dostępu — klucz API, token (cyfrowe potwierdzenie dostępu) albo hasło konta technicznego. Fachowo nazywa się to sekretem, ale najlepiej myśleć o nim jak o kluczu do drzwi: kto go ma, ten wchodzi, niezależnie od tego, kim jest.
Z tego porównania wynika pięć zasad, które da się wpisać do arkusza:
- Jeden klucz na jeden system i jednego agenta. Wtedy unieważnienie jednego klucza nie zatrzymuje wszystkiego.
- Zakres klucza sprawdza się osobno i ogranicza do zadania. Klucz nie musi mieć tych samych uprawnień co konto, do którego należy — bywa węższy, ale bywa też szerszy (np. token wygenerowany przez administratora dla całej firmy). Klucz z prawami administratora otwiera wszystkie drzwi naraz.
- Klucz leży w sejfie, czyli w menedżerze haseł albo w sejfie kluczy narzędzia do automatyzacji. Nie w mailu, nie w arkuszu, nie w komunikatorze, nie w treści poleceń dla modelu.
- Wiadomo, kto ma do niego dostęp. Co najmniej dwie wskazane osoby potrafią wymienić klucz i odciąć dostęp — jedna to za mało na urlop. Samą wartość klucza widzą tylko te osoby, które jej potrzebują, i to przez własne konta w sejfie, a nie przez przesłaną kopię.
- Klucz się wymienia: po odejściu każdej osoby, która go znała, po każdym podejrzeniu wycieku i w stałym terminie, który ustalacie przy wdrożeniu. Tam, gdzie system na to pozwala, klucz dostaje datę ważności.
Ostatnia zasada ma test praktyczny: wymień klucz w środowisku testowym (osobnej instalacji bez prawdziwych danych) i sprawdź, czy agent działa dalej po podmianie w jednym miejscu. Jeżeli wymiana oznacza dzień szukania, gdzie jeszcze ten klucz wklejono, regularne utrzymanie staje się trudne — i tę informację lepiej mieć przed startem niż po incydencie.
Typowy scenariusz (ilustracja, nie historia konkretnego klienta). Osoba, która rok temu konfigurowała integrację, wygenerowała klucz z uprawnieniami administratora, „żeby nie było problemów”, i wkleiła go w kilku miejscach. Potem odeszła z firmy. Nikt nie wie, gdzie klucz jest używany, więc nikt go nie wymienia — bo wymiana mogłaby coś zepsuć. Klucz administratora żyje dłużej niż zatrudnienie osoby, która go znała.
Wyłącznik i cofnięcie dostępu
Wyłącznik to kolumna, którą najłatwiej wpisać i najtrudniej przetestować. Dobrze zaprojektowany ma dwa poziomy:
- Zatrzymanie — wstrzymanie automatyzacji, w której działa agent. Szybkie, ale zależy od tego, czy narzędzie do automatyzacji działa i słucha.
- Odcięcie — zablokowanie konta agenta oraz unieważnienie jego kluczy i aktywnych sesji (trwających zalogowań) po stronie systemu docelowego: CRM, poczty, ERP. Działa nawet wtedy, gdy automatyzacja się zawiesiła. Zależy jednak od tego, jak dany system obsługuje już wydane tokeny i otwarte sesje, dlatego procedurę ustala się dla każdej integracji osobno. Jeżeli system nie pozwala odebrać istniejącego dostępu od razu, wpisuje się to ograniczenie i przetestowaną procedurę zamiast obietnicy natychmiastowego odcięcia.
Odcięcie działa niezależnie od modelu z tego samego powodu, dla którego OWASP zaleca, żeby to system docelowy przy każdej operacji sprawdzał, co agentowi wolno, zamiast polegać na decyzji modelu: o dostępie rozstrzyga system, a nie agent.
Do arkusza wpisuje się trzy rzeczy. Kto — co najmniej dwie osoby po Twojej stronie, nie tylko dostawca. Jak — konkretna czynność, a nie „kontakt z dostawcą”. Ile to trwało — czas zmierzony w teście do chwili, w której system rzeczywiście odrzuca kolejne operacje agenta, a nie czas zadeklarowany w ofercie.
Osobne pytanie to zadanie w toku. Agent wyłączony w trakcie pracy mógł zapisać notatkę tylko częściowo albo założyć trzy z pięciu pozycji zamówienia. Dlatego tam, gdzie system to umożliwia, zapis wykonujemy w całości albo wcale, a przy zadaniu wieloetapowym agent zapisuje, które kroki ukończył. Po przerwaniu człowiek sprawdza wynik i decyduje o wznowieniu tak, żeby wpisy się nie powieliły. Test wyłącznika robi się przed startem i po każdej większej zmianie, a jego datę wpisuje się w ostatniej kolumnie.
AI Act, czyli unijne rozporządzenie o sztucznej inteligencji, wymaga dla systemów wysokiego ryzyka, żeby osoba nadzorująca mogła przerwać działanie systemu — przyciskiem „stop” lub podobną procedurą — i zatrzymać go w bezpiecznym stanie (art. 14 ust. 4 lit. e). Przepis ten będzie stosowany od 2 grudnia 2027 r. dla systemów z załącznika III i 2 sierpnia 2028 r. dla systemów z załącznika I — to, co obowiązuje już dziś, zebraliśmy na stronie o AI Act. Wyłącznik warto mieć niezależnie od tego, czy przepis Cię obejmuje.
Typowy scenariusz (ilustracja, nie historia konkretnego klienta). Agent porządkujący zgłoszenia zaczyna masowo nadawać im zły status. Jedyna osoba z dostępem do konta automatyzacji jest na urlopie, a dostawca odpowiada następnego dnia roboczego. Nikt w firmie nie wie, że wystarczyłoby zablokować konto agenta w systemie zgłoszeń — bo nikt nie zapisał, że takie konto istnieje.
Trzy wypełnione wiersze: CRM, skrzynka pocztowa i ERP
Te same trzy przykłady są w pliku CSV. To ilustracje typowych zadań, nie gotowa konfiguracja — nazwy ról i zakresy dopasujesz do swoich systemów, a czasy i daty wpiszesz dopiero po własnym teście.
| Kolumna | CRM | Wspólna skrzynka pocztowa | ERP |
|---|---|---|---|
| Co agent czyta | Karty firm i kontaktów oraz historię kontaktów w lejku, którego dotyczy zadanie; bez eksportu całej bazy | Tylko skrzynkę wspólną (np. zamowienia@); żadnych skrzynek osobistych | Stany magazynowe, statusy zamówień, kartotekę kontrahenta bez danych bankowych |
| Co agent zmienia | Dodaje notatkę i zadanie dla handlowca | Tworzy szkice odpowiedzi i nadaje etykiety | Zakłada zamówienie sprzedaży jako wersję roboczą do zatwierdzenia |
| Czego nigdy nie robi sam | Nie usuwa i nie scala rekordów; nie zmienia opiekuna kontaktu ani etapu, który uruchamia ofertę lub umowę | Nie wysyła, nie usuwa, nie przekazuje na zewnątrz, nie zakłada reguł przekierowania | Nie zatwierdza dokumentów, nie wystawia faktur, nie zmienia cen, rabatów, limitów kupieckich ani numeru rachunku kontrahenta |
| Kto zatwierdza | Kierownik sprzedaży; zastępca: wskazany handlowiec | Osoba dyżurna obsługi; zastępca: kierownik obsługi | Osoba z działu obsługi zamówień; zastępca: kierownik działu |
| Konto agenta | Osobny użytkownik z rolą tylko do notatek i zadań | Osobna integracja (tożsamość aplikacji przypisana do skrzynki wspólnej, nie czyjeś hasło) z dostępem tylko do tej skrzynki, ze szkicami bez wysyłki | Osobny operator z rolą do zamówień roboczych |
| Klucz dostępu | Sejf na hasła albo sejf kluczy w narzędziu do automatyzacji; dostęp przez własne konta w sejfie mają dwie wskazane osoby | Jak w CRM | Jak w CRM |
| Wymiana klucza | Po odejściu osoby, po podejrzeniu wycieku i w ustalonym terminie | Jak w CRM | Jak w CRM |
| Wyłącznik | Zatrzymanie automatyzacji; administrator CRM blokuje użytkownika agenta, unieważnia jego klucze i aktywne sesje | Zatrzymanie automatyzacji; administrator poczty odbiera dostęp, unieważnia klucz i aktywne sesje | Zatrzymanie automatyzacji; administrator ERP blokuje operatora agenta, unieważnia jego klucze i aktywne sesje |
| Zadanie w toku | Przegląd notatek i zadań od ostatniego sprawdzenia | Przegląd szkiców i zmian etykiet od ostatniego sprawdzenia; nic nie wyszło bez człowieka | Wersje robocze trafiają do przeglądu przed zatwierdzeniem |
| Zapis działań | Dziennik automatyzacji i historia zmian CRM pod użytkownikiem agenta | Dziennik automatyzacji i dziennik dostępu do skrzynki | Dziennik automatyzacji i rejestr zmian ERP pod operatorem agenta |
| Przegląd | Do uzupełnienia po teście wyłącznika; bez niego nie uruchamiać | Jak w CRM | Jak w CRM |
Dwie uwagi. Przy poczcie odpowiednikiem osobnego konta jest zwykle osobna integracja, czyli tożsamość aplikacji przypisana do skrzynki wspólnej — wciąż nie hasło właściciela. Nie każdy system pozwala dać uprawnienie do szkiców bez prawa wysyłki, a uprawnienie do szkiców często pozwala też usuwać wiadomości. Jeżeli Twój system nie daje węższego uprawnienia, wysyłkę, usuwanie i zakładanie przekierowań musi blokować kod albo osobny program pośredniczący, działający niezależnie od modelu — samo polecenie dla modelu nie jest kontrolą — a przed startem testuje się, że próba wysłania, usunięcia, przekazania i założenia przekierowania jest odrzucana. Jeśli tego nie da się zapewnić, agent przygotowuje szkice poza skrzynką albo zostaje przy samym odczycie. Przy ERP nie każdy system ma rolę ograniczoną do wersji roboczych; wtedy agent zapisuje do tabeli pośredniej — miejsca na rekordy czekające na import — a import do ERP zatwierdza człowiek. W obu przypadkach wiersz arkusza pokazuje słabsze miejsce, zamiast je ukrywać.
Gdy produkt „potrzebuje pełnego dostępu”: pytania do dostawcy
Jeżeli gotowy produkt z agentem prosi przy podłączeniu o szerokie uprawnienia, decyzję o uprawnieniach podjął za Ciebie ktoś, kto nie zna Twoich danych. Zanim klikniesz „zezwól”, zadaj dostawcy te pytania:
- Jakie dokładnie czynności agent wykonuje w naszym systemie i jakie uprawnienie jest potrzebne do każdej z nich?
- Czy agent może działać na osobnym koncie z ograniczoną rolą, a nie na koncie administratora?
- Czy da się go podłączyć tylko do odczytu i tylko do wydzielonego zakresu danych pilotażowych?
- Które czynności agent może wykonać bez zatwierdzenia przez człowieka i czy da się to wyłączyć?
- Gdzie przechowywany jest klucz dostępu do naszego systemu, kto po Waszej stronie ma do niego dostęp i jak go wymieniamy?
- Jak odebrać agentowi dostęp po naszej stronie, bez Waszego udziału, i co dzieje się wtedy z zadaniami w toku?
- Jakie działania agenta są zapisywane, gdzie i jak długo — i czy mamy do tych zapisów dostęp?
Jeżeli na pierwsze pytanie nie ma odpowiedzi albo produkt działa wyłącznie na koncie administratora, sprawdź dwie drogi: uruchomienie go w odizolowanym środowisku testowym na danych przykładowych, bez połączenia z prawdziwymi systemami, albo podłączenie tylko do odczytu i tylko do wydzielonego zakresu danych pilotażowych (np. jednej skrzynki albo jednego lejka sprzedaży), jeśli produkt to obsługuje. Samo „tylko do odczytu” nie wystarczy: produkt nadal może odczytać wszystkie dane w przyznanym mu zakresie, więc ten zakres też trzeba ograniczyć. Jeżeli żadna z tych dróg nie jest możliwa, nie podłączaj go do systemu z prawdziwymi danymi. Jeśli agent ma korzystać z funkcji Twojego systemu przez standard MCP (Model Context Protocol, czyli wspólny sposób podłączania narzędzi do asystentów AI), te same pytania dotyczą każdego udostępnionego narzędzia — opisujemy to na stronie o połączeniu asystenta AI z Twoim systemem.
Co z arkusza trafia do załącznika technicznego umowy
Arkusz jest dokumentem roboczym, ale jego wiersze mają naturalne odpowiedniki w tym, co warto mieć na piśmie z dostawcą. Nie podajemy tu brzmienia zapisów umownych — to praca dla prawnika. Podajemy pytania, na które odpowiedzi warto uzgodnić z dostawcą albo z prawnikiem, i kolumnę arkusza, z której wynikają:
| Kolumna arkusza | Co uzgodnić na piśmie |
|---|---|
| Co czyta i co zmienia | Czy tabela zakresów dla każdego systemu jest częścią załącznika, czy jej rozszerzenie wymaga zgody na piśmie i co się dzieje z czynnością spoza uzgodnionego zakresu? |
| Czego nigdy nie robi sam, kto zatwierdza | Czy lista czynności wymagających zatwierdzenia jest zamknięta i kto po stronie klienta zatwierdza zmiany tej listy? |
| Konto agenta | Czy agent działa wyłącznie na kontach założonych i kontrolowanych przez klienta? |
| Klucz dostępu, wymiana klucza | Kto przechowuje klucze, kto ma do nich dostęp i w jakim terminie wymienia je po zakończeniu współpracy albo po incydencie? |
| Wyłącznik, zadanie w toku | Czy klient może samodzielnie odciąć dostęp, jak dostawca dokumentuje procedurę, jak często ją wspólnie testujecie i kto po przerwaniu sprawdza niedokończone zadania oraz zgadza się na wznowienie? |
| Zapis działań | Jakie działania są rejestrowane, jak długo zapisy są przechowywane i kto ma do nich dostęp? |
Część z tych tematów wiąże się z obowiązkami z RODO, czyli ogólnego rozporządzenia o ochronie danych — umową powierzenia przetwarzania danych (art. 28) i odpowiednimi środkami bezpieczeństwa (art. 32) w rozporządzeniu. To, czy i jak dany punkt zapisać w umowie, rozstrzyga Twój prawnik; my wdrażamy kontrole, które klient i jego prawnik nam przypiszą. Jak ustalić role przy danych osobowych, opisaliśmy w tekście o RODO przy wdrożeniu LLM i na stronie o bezpieczeństwie i RODO, a pozostałe pytania przed podpisaniem umowy — w tekście o tym, ile kosztuje wdrożenie AI.
Co dalej
Wybierz jeden system, do którego agent miałby dostęp, i wypełnij dla niego jeden wiersz. Jeżeli puste zostaną konto, klucz albo wyłącznik, to właśnie one są listą rzeczy do ustalenia przed pierwszą linijką kodu. W metodyce wdrożenia prosimy po stronie klienta o osobę z IT do spraw dostępów; proponujemy, żeby to ona wypełniła te kolumny razem z nami, a właściciel procesu wpisał, kto zatwierdza.
Źródła i stan na 12 października 2026 roku
- OWASP GenAI Security Project, LLM06:2025 Excessive Agency — trzy źródła nadmiernej sprawczości, zalecenia (m.in. minimalne uprawnienia, zatwierdzanie przez człowieka, sprawdzanie uprawnień w systemie docelowym) i przykład ze skrzynką pocztową.
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, opublikowany 9 grudnia 2025 r. — lista najpoważniejszych ryzyk dla agentów AI, wśród nich nadużycie tożsamości i uprawnień agenta (ASI03).
- Microsoft Learn, What is Microsoft Entra Agent ID? — strona czytana 12 października 2026 r.; zakres funkcji i licencje mogą się zmienić.
- Rozporządzenie (UE) 2016/679 (RODO), art. 28 i 32.
- AI Act, art. 14 (nadzór człowieka) i art. 113 (terminy stosowania) w serwisie Komisji Europejskiej; daty po zmianach wprowadzonych pakietem Digital Omnibus zebraliśmy na stronie o AI Act.