Rozważmy proponowanego asystenta Odoo Helpdesk, który odczytuje zgłoszenie i przygotowuje odpowiedź. Weryfikacja takiego szkicu to inna decyzja dotycząca uprawnień niż zezwolenie asystentowi na wysłanie go do klienta. Treść może być identyczna, ale wysłanie oznacza przekazanie jej odbiorcy zewnętrznemu i podjęcie komunikacji biznesowej, czego wewnętrzny szkic jeszcze nie powoduje.
Nadawaj uprawnienia do działania, nie do interfejsu. Oddziel pobieranie informacji, tworzenie szkiców treści, proponowanie zmian w rekordach i faktyczne wprowadzanie zmian. Ogranicz dany przypadek użycia do przygotowywania szkiców, dopóki nie zostaną zademonstrowane uprawnienia wykonawcze, reguły zatwierdzania i obsługa wyjątków. Dopuść wykonywanie działań w określonych granicach tylko wtedy, gdy właściciel procesu akceptuje ich konsekwencje, a wymagane mechanizmy kontroli przejdą testy.
Zacznij od konsekwencji biznesowych
Ask AI i tworzenie projektu na podstawie pliku PDF to przydatne scenariusze do takiej oceny. René Passmann w komentarzu do planu rozwoju Odoo opisuje wyszukiwanie informacji biznesowych za pomocą języka naturalnego oraz tworzenie etapów i zadań projektu na podstawie technicznego dokumentu PDF jako proponowane kierunki rozwoju. Zastrzega też, że plan rozwoju nie gwarantuje dostarczenia każdej funkcji, a większość omawianych możliwości AI wiąże z edycją Enterprise.
Traktuj omawiane tutaj Ask AI, przygotowywanie odpowiedzi Helpdesk, tworzenie projektu z PDF i zmianę przypisania leadów CRM jako proponowane scenariusze oceny, a nie potwierdzone funkcje produkcyjne. Przed zleceniem pilotażu uzyskaj potwierdzenie wymaganej wersji, edycji, modelu hostingu i subskrypcji. Dostępność w Enterprise nie dowodzi istnienia konkretnego mechanizmu kontroli uprawnień lub zatwierdzania.
Dla pobierania informacji określ, jakie rekordy i spółki może przeszukiwać osoba zgłaszająca żądanie. Dla tworzenia szkiców dodaj zasady określające miejsce zapisu wygenerowanej treści i osoby, które mogą ją zobaczyć. Dla proponowanych zmian wymagaj możliwego do zweryfikowania porównania wartości obecnych i sugerowanych. Dla wykonania określ dozwoloną operację zapisu lub wysyłki oraz warunki, które na nią zezwalają. Uprawnienie do wcześniejszego kroku nie powinno automatycznie oznaczać uprawnienia do następnego.
Propozycja zmiany przypisania leada powinna pokazywać obecnego opiekuna, sugerowanego opiekuna, wskazany lead i uzasadnienie, bez zmiany przypisania. Wprowadzenie tej propozycji wymaga osobnej decyzji: których leadów może dotyczyć, komu wolno je przypisać i kto zatwierdza wyjątki. Podobnie uprawnienie do przygotowania odpowiedzi Helpdesk nie powinno oznaczać prawa do jej wysłania, zmiany odbiorców ani dołączania dokumentów.
Spisz specyfikację kontroli działań
Przygotuj specyfikację dla każdego działania, zamiast jednej zgody opisanej jako „włączenie AI”. Wcześniejsza analiza oceny procesów AI w ERP zaleca sporządzenie mapy rekordów, działań i tożsamości wykonawczej, a następnie demonstrację na reprezentatywnych uprawnieniach zamiast na nieograniczonym koncie administratora. Zastosuj tę samą dyscyplinę do węższej decyzji o nadaniu uprawnień.
Poniższa macierz to proponowana specyfikacja odbioru. Jej pozycje są wymaganiami do ustalenia i przetestowania, a nie twierdzeniami o mechanizmach kontroli dostarczanych przez Odoo.
| Obszar kontroli | Co należy zapisać w specyfikacji | Jakich dowodów wymagać |
|---|---|---|
| Dostępne dane | Dozwolone rekordy, spółki, załączniki i tożsamość wykonawcza | Reprezentatywne testy dostępu, w tym rekordy z zabronionym dostępem oraz dostęp przez konta techniczne |
| Dozwolone zmiany | Dozwolone typy rekordów, pola, operacje i dopuszczalne wartości | Stan rekordów przed operacją i po niej, pokazujący wyłącznie uprawnione zmiany |
| Ujawnianie danych na zewnątrz | Dane przekazywane dostawcom modeli, odbiorcy wiadomości i dozwolone załączniki | Przepływ danych dla konkretnej konfiguracji i obowiązujące warunki dostawcy |
| Odpowiedzialność za zatwierdzanie | Rola zatwierdzająca, warunki akceptacji i zmiany unieważniające zgodę | Blokada wykonania bez ważnej akceptacji dokładnie tego działania, które zaproponowano |
| Dowody audytowe | Wnioskodawca, osoba zatwierdzająca, tożsamość wykonawcza, obiekt działania, zatwierdzone wartości i wynik | Możliwa do zweryfikowania ścieżka łącząca żądanie z jego rzeczywistym wynikiem |
| Obsługa wyjątków | Warunki zatrzymania, weryfikacji i ponowienia oraz osoba odpowiedzialna za przywrócenie poprawnego stanu | Demonstracja obsługi odrzucenia, błędu i niepewnego zakończenia |
| Zatrzymanie dalszego wykonywania | Kto może wyłączyć działanie i co dzieje się z oczekującymi zadaniami | Test wykazujący, że dalsze nieuprawnione wykonanie zostaje uniemożliwione |
W Helpdesk określ granicę jednoznacznie: działanie tworzące szkic może przygotować treść z dozwolonych informacji o zgłoszeniu; wysłanie wymaga zatwierdzenia odbiorcy, tekstu i załączników. Jeśli te elementy zmienią się po akceptacji, wymagaj ponownej weryfikacji. Stwierdzenie „człowiek może sprawdzić odpowiedź” nie wystarcza, jeśli nadal można ją wysłać bez takiej kontroli.
Przy tworzeniu projektu z PDF oddziel proponowaną strukturę projektu od utworzenia rekordów operacyjnych. Poproś właściciela projektu o zatwierdzenie zadań, spółki, powiązania z klientem i proponowanych przypisań przed utworzeniem rekordów. W przypadku zmiany przypisania leadów reguła ograniczonego wykonania mogłaby obejmować jednoznacznie określoną grupę leadów i dopuszczalnych opiekunów, kierując pozostałe przypadki do weryfikacji. To proponowane zasady działania, a nie twierdzenia o funkcjach natywnych.
Kwestię ujawniania danych rozstrzygnij niezależnie od uprawnień do zapisu. Ustal dostawcę modelu i konfigurację konta, a następnie uzyskaj obowiązujące warunki przechowywania danych, wykorzystywania ich do trenowania modeli, udziału dalszych podmiotów przetwarzających i lokalizacji danych. Nawet proces ograniczony do szkiców powinien pozostać wyłączony, jeśli wymagane przez niego ujawnianie danych jest nieakceptowalne.
Niech agenci wywołują procesy podlegające kontroli
Preferuj architekturę, w której agent interpretuje żądanie i wywołuje ustalony proces biznesowy, zamiast improwizować każdy krok wykonania. Dyskusja o AI w przedsiębiorstwach ilustruje to rozróżnienie przykładem faktury: agent pyta, czy ją przetworzyć, a następnie wywołuje już zbudowany proces, zamiast próbować samodzielnie przeprowadzić przetwarzanie. Wniosek: kontrolę uprawnień i walidację biznesową należy umieścić w możliwej do zweryfikowania ścieżce wykonania, nie tylko w instrukcjach konwersacyjnych.
Dla zmiany przypisania leada poproś zespół o demonstrację operacji, która przed zapisem sprawdza kwalifikowalność, akceptację i dozwolone zmiany pól. Dla wiadomości Helpdesk zapytaj, gdzie sprawdzane są odbiorca i zatwierdzenie. Płynnie sformułowana odmowa na czacie nie wystarcza: trzeba wykazać, że sama operacja również odrzuca nieuprawnione żądanie.
Konkretny wzorzec rozwiązania zewnętrznego przedstawia dokumentacja zatwierdzania w MCP Server firmy TeqStars. Opisuje ona konfigurowany mechanizm, w którym wywołanie narzędzia wykonującego wrażliwą operację musi zostać przekształcone we wniosek do zatwierdzenia lub odrzucenia przez człowieka w Odoo. To ilustracja wzorca implementacji, a nie gwarancja natywnej funkcji Odoo ani dowód, że inna integracja działa identycznie. Wymagaj demonstracji mechanizmu zatwierdzania w proponowanej konfiguracji.
Przetestuj odmowy, zanim dopuścisz wykonanie
Zacznij od ograniczonego obszaru, w którym dane i reguły procesu są jasne. W dyskusji o AI w przedsiębiorstwach zaleca się rozpoczynanie od obszarów bardziej precyzyjnych i mniej chaotycznych, a następnie rozwijanie rozwiązania iteracyjnie. Podczas odbioru testuj zachowania zabronione równie świadomie jak poprawne wykonanie:
- Nieuprawnione pobieranie: zażądaj zgłoszenia z ograniczonym dostępem, załącznika lub rekordu innej spółki. Wymagaj odmowy bez ujawniania chronionej treści.
- Niezamierzone zapisy: poproś o podsumowanie, ale sprawdź, czy opiekun, status i niezwiązane pola pozostały bez zmian.
- Brak akceptacji lub nieaktualna akceptacja: spróbuj wysłać wiadomość albo zmienić przypisanie bez zatwierdzenia, a następnie zmień zatwierdzonego odbiorcę lub wartość docelową. Wymagaj zatrzymania wykonania.
- Niepewne zakończenie: przerwij działanie i ponów próbę. Wymagaj wyniku możliwego do zweryfikowania oraz decyzji o sposobie przywrócenia poprawnego stanu przed ponownym zleceniem operacji.
- Cofnięte uprawnienia: odbierz dostęp lub wyłącz działanie, gdy zadanie oczekuje na wykonanie. Zademonstruj, co nadal może zostać wykonane i dlaczego.
Dla każdego testu zapisz użytkownika zgłaszającego żądanie, tożsamość wykonawczą, oczekiwaną odmowę, rzeczywisty wynik i stan rekordów po teście. Zbadaj wszelkie szersze uprawnienia konta technicznego, zamiast zakładać, że ograniczenia wnioskodawcy obowiązują również podczas wykonania. Pozostaw działanie w trybie przygotowywania szkiców, jeśli kontrola wykonania zawiedzie; wyłącz je, jeśli nawet pobieranie danych lub tworzenie szkiców nie spełnia wymaganych ograniczeń.
Przed uruchomieniem danego przypadku użycia uzyskaj akceptację właściciela procesu i osoby odpowiedzialnej za bezpieczeństwo dla specyfikacji kontroli działań oraz wyników testów negatywnych. Jeśli potrzebujesz pomocy w zdefiniowaniu procesów Odoo lub prac technicznych potrzebnych do egzekwowania tych granic, omów wymagania z konsultantami funkcjonalnymi i programistami Odoo w Digiventi.
