Odoo 20 i agentowe AI: wdrożenia, koszty, prywatność

Według informacji o wydaniu Odoo 20 wprowadza agentów AI z własnymi umiejętnościami i narzędziami oraz możliwość podłączenia zewnętrznych modeli językowych. Sztuczna inteligencja przestaje więc być dodatkiem w interfejsie i trafia do miejsc, w których system podejmuje działania. Dla zespołu wdrożeniowego to większa zmiana, niż sugeruje pozycja na liście nowości. Poniżej opisujemy, co z niej wynika dla projektu, budżetu i danych klienta.

Co właściwie zmienia architektura agentowa

Agent, umiejętności i narzędzia

Agent w Odoo 20 to wydzielony komponent, któremu przypisuje się zestaw umiejętności i narzędzi. Wywołuje się go z poziomu modułu albo procesu. Brzmi to abstrakcyjnie, więc posłużmy się przykładem, który ilustruje różnicę, a nie opisuje konkretnej funkcji. Klasyczna automatyzacja działa według reguły „jeśli pole ma wartość X, wyślij szablon Y”. Agent może sam przeczytać wiadomość od klienta i zdecydować, co z nią zrobić.

Zewnętrzne modele i Model Context Protocol

Nowa architektura pozwala podłączyć zewnętrzny LLM przez Model Context Protocol. Odoo przekazuje wtedy modelowi kontekst biznesowy i zleca mu generowanie tekstu, klasyfikację lub inne zadania. Jednej rzeczy z dostępnych materiałów nie da się ustalić: jak dokładnie można sterować tym, które pola i rekordy trafiają do modelu. Od odpowiedzi na to pytanie zależy połowa decyzji opisanych niżej. Trzeba je zadać, zanim powstanie harmonogram projektu.

AI wewnątrz procesów

Agenci mogą działać w przepływach pracy, wyzwalaczach i akcjach zautomatyzowanych. I tu leży najważniejsza zmiana. Do tej pory błąd modelu kończył się niezgrabnym zdaniem w szkicu maila, które ktoś poprawiał przed wysłaniem. Teraz ten sam błąd może zmienić rekord w bazie. Audyt, uprawnienia i testy muszą to uwzględniać od pierwszego dnia projektu.

Co to oznacza dla projektu wdrożeniowego

Integracja i odporność na awarie

Jeśli wdrożenie korzysta z zewnętrznego modelu, trzeba zaplanować kolejkowanie zadań, ponawianie wywołań, limity czasu i monitoring. Model bywa niedostępny albo odpowiada z dużym opóźnieniem. System musi wiedzieć, co wtedy zrobić z zamówieniem czy zgłoszeniem, które czeka na decyzję agenta. Bez tego jedna awaria po stronie dostawcy modelu zatrzymuje proces w Odoo.

Agent działa sam czy tylko proponuje?

Tę decyzję podejmuje się osobno dla każdego punktu procesu. Naszym zdaniem rozsądnym punktem wyjścia jest tryb propozycji, a samodzielne działanie agenta warto dopuszczać tylko tam, gdzie skutek łatwo odwrócić. Podpowiedź kategorii dla zgłoszenia w module Helpdesk niesie niewielkie ryzyko. Wysłanie wiadomości do klienta albo zmiana warunków w zamówieniu sprzedaży powinny przechodzić przez zatwierdzenie człowieka. Automatyzacja staje się w ten sposób sprytniejsza, ale też trudniejsza do sprawdzenia, i ten koszt trzeba uczciwie wpisać w plan.

Community czy Enterprise

W wątkach społeczności o Odoo 20 pojawiają się obawy, że część funkcji AI nie trafi do edycji Community. Na razie są to głosy z forum, a nie oficjalny podział funkcji. Budżetu nie należy budować na samym wątku z Reddita.

Jeśli obawy się potwierdzą, wybór wygląda tak: zostać na CE i zbudować własną integrację, na przykład z modelem hostowanym lokalnie, albo przejść na Enterprise i dostać gotowe rozwiązanie ze wsparciem. Własna integracja w CE nie jest darmowa. To kod, który trzeba utrzymać przy każdej aktualizacji wersji, i często właśnie on przesądza o rachunku.

Koszty: tokeny, serwery i ludzie

Rachunek za API

Zewnętrzny model rozlicza się za liczbę zapytań i objętość przesyłanych tokenów. W testach te kwoty wyglądają niewinnie. Problem pojawia się wtedy, gdy agent podpięty pod wyzwalacz uruchamia się przy każdej zmianie rekordu, a w produkcji takich zmian są tysiące. Dlatego limity wydatków, buforowanie odpowiedzi i łączenie zapytań w paczki trzeba zaprojektować razem z samą automatyzacją, a nie dopisywać po pierwszej fakturze.

Model na własnym serwerze

Model hostowany lokalnie ma sens w kilku sytuacjach:

• firma wymaga pełnej kontroli nad danymi,
• liczba zapytań jest na tyle duża, że przewidywalny koszt własnej infrastruktury wygrywa z rozliczeniem za tokeny,
• liczy się niskie opóźnienie,
• przepisy lub umowy zabraniają przesyłania danych poza infrastrukturę klienta.

Koszt nie znika, tylko przenosi się z faktury dostawcy na zespół. Ktoś musi utrzymywać serwer, aktualizować model i zrozumieć, dlaczego po aktualizacji odpowiedzi nagle są gorsze.

Kiedy chmura wystarczy

Chmura wygrywa, gdy liczy się szybki start, dostęp do najnowszych modeli i brak własnego zespołu od uczenia maszynowego. Często spotyka się zalecenie podziału: zadania na wrażliwych danych obsługiwać lokalnie, resztę w chmurze. Tu mamy wątpliwość. W małej firmie taki model mieszany oznacza dwie infrastruktury, dwa zestawy kosztów i dwa źródła awarii. Czasem prościej i bezpieczniej jest w ogóle nie wysyłać wrażliwych procesów do agenta.

Prywatność, bezpieczeństwo i testy

Które dane trafiają do modelu

Dane osobowe i szczegóły transakcji najlepiej trzymać w infrastrukturze, którą firma kontroluje. Jeśli wdrożenie korzysta z zewnętrznego modelu, kontekst trzeba przed wysyłką filtrować. Warstwa pośrednia powinna maskować identyfikatory klientów, usuwać zbędne pola i skracać historię rozmowy do tego, czego model naprawdę potrzebuje do wykonania zadania. Agent klasyfikujący zgłoszenie nie musi znać numeru konta bankowego klienta.

Uprawnienia i audyt

Agent dostaje tylko te uprawnienia, których wymaga jego zadanie. To samo dotyczy integracji z modelem. Do tego dochodzą szyfrowanie danych w transmisji i w spoczynku, osobne klucze API dla każdej integracji oraz dziennik wywołań. Dzięki niemu po incydencie wiadomo, który agent, kiedy i na czyje polecenie wysłał zapytanie. Bez dziennika każda reklamacja klienta zamienia się w zgadywanie.

Testy przed produkcją

Decyzje agentów wymagają testów regresyjnych i scenariuszy akceptacyjnych, tak samo jak każda inna logika biznesowa. Szczególnie ważne są przypadki brzegowe: model odpowiada bez sensu, w złym formacie albo wcale. Dla każdego takiego przypadku potrzebna jest ścieżka awaryjna, a przed każdym trwałym skutkiem ręczne zatwierdzenie. Z dostępnych materiałów nie wynika, ile z tych zabezpieczeń Odoo 20 daje od razu, a ile trzeba będzie dobudować samemu. To kolejna niewiadoma, która może zmienić wycenę projektu.

Lista kontrolna przed uruchomieniem

• Ustalić, które procesy mogą działać automatycznie, a które wymagają zatwierdzenia.
• Wybrać model hostingu (lokalnie lub w chmurze) na podstawie wrażliwości danych i przewidywanej liczby zapytań.
• Zaprojektować warstwę, która maskuje i ogranicza dane przed wysyłką do modelu.
• Nadać agentom role i uprawnienia oraz włączyć dziennik wywołań API.
• Ustawić limity kosztów i buforowanie odpowiedzi.
• Przetestować integrację i reguły walidacji w środowisku testowym, zanim agent trafi na produkcję.
• Sprawdzić w oficjalnych materiałach Odoo, które funkcje AI obejmuje wybrana edycja.

Źródła

• Odoo 20 Release Notes
• With Odoo 20 CE missing out on AI features is it?