Gdy zaczęliśmy prezentować naszego bota AI klientom korporacyjnym, pierwsze pytanie zawsze brzmiało tak samo: co się stanie, jeśli bot zmodyfikuje nasze dane? To uzasadnione obawy. Masz produkcyjną instancję Odoo obsługującą całą Twoją firmę - sprzedaż, magazyn, księgowość, HR. Udostępnienie narzędziu AI dostępu do takiego systemu brzmi ryzykownie. Dlatego zaprojektowaliśmy architekturę tak, aby fizycznie uniemożliwić botowi zapis, aktualizację lub usunięcie czegokolwiek.
Podstawa jest prosta: bot łączy się z Odoo przez XML-RPC, używając dedykowanego konta serwisowego, które ma wyłącznie uprawnienia do odczytu. To nie jest programowy przełącznik, który można przypadkowo zmienić. Użytkownik Odoo przypisany do bota ma niestandardowe prawa dostępu na poziomie modelu - dostęp do odczytu modeli zatwierdzonych przez klienta, zero uprawnień zapisu/tworzenia/usuwania czegokolwiek. Nawet gdyby nasz kod miał błąd próbujący zapisu, własna warstwa kontroli dostępu Odoo odrzuciłaby go z komunikatem AccessError.
Poszliśmy dalej niż same uprawnienia Odoo. Warstwa integracji bota w ogóle nie ma zaimplementowanych metod zapisu. Klient XML-RPC, który zbudowaliśmy, udostępnia tylko operacje search_read, fields_get i read. W całej bazie kodu nie istnieje żadne wywołanie execute_kw dla create, write ani unlink. To obrona w głąb - nawet gdyby ktoś przełamał warstwę aplikacji, narzędzia do modyfikacji danych po prostu nie istnieją w wdrożonym kodzie.
Kolejną krytyczną decyzją było przechowywanie danych uwierzytelniających. Dane połączeniowe do Odoo każdego klienta - URL, nazwa bazy danych, klucz API - są szyfrowane w spoczynku algorytmem AES-256-GCM. Klucze szyfrujące przechowywane są oddzielnie od zaszyfrowanych danych, zgodnie ze wzorcem envelope encryption. Używamy unikalnego wektora inicjalizacyjnego dla każdej operacji szyfrowania, co oznacza, że nawet identyczne dane uwierzytelniające dwóch klientów dają zupełnie różne szyfrogramy.
Same klucze API zasługują na uwagę. Używamy wbudowanego systemu kluczy API Odoo zamiast przechowywać hasła. Klucze API mogą zostać natychmiast unieważnione przez klienta z panelu administracyjnego Odoo bez angażowania nas. Jeśli klient chce odciąć botowi dostęp, usuwa klucz API i bot natychmiast przestaje działać. Bez zgłoszenia, bez czekania, bez zależności od nas.
Dane w tranzycie są chronione przez TLS 1.3 we wszystkich połączeniach pomiędzy naszym serwerem bota a instancjami Odoo klienta. Wymuszamy walidację certyfikatów - bez pomijania kontroli SSL nawet w środowisku deweloperskim. Sam serwer bota działa na odizolowanej instancji VPS Hetzner z minimalną powierzchnią ataku: brak zbędnych otwartych portów, uwierzytelnianie wyłącznie kluczem SSH, automatyczne aktualizacje bezpieczeństwa.
Jedno pytanie, które otrzymujemy od zespołów IT, brzmi: czy dane klienta są używane do trenowania modeli AI? Odpowiedź brzmi: nie, a architektura to wymusza. Gdy użytkownik zadaje botowi pytanie, wysyłamy zapytanie do Odoo klienta o odpowiednie dane, formatujemy je w prompt, wysyłamy do API Claude i zwracamy odpowiedź. Nie przechowujemy wyników zapytań poza sesją rozmowy. Nie gromadzimy danych do trenowania. Warunki API Claude wyraźnie stanowią, że dane wejściowe i wyjściowe API nie są używane do trenowania modeli.
Sama historia konwersacji przechowywana jest w naszej bazie danych z tym samym szyfrowaniem AES-256-GCM, którego używamy dla danych uwierzytelniających. Konwersacje są powiązane z indywidualnymi użytkownikami Telegrama i automatycznie usuwane po 30 dniach. Klient może zażądać natychmiastowego usunięcia wszystkich swoich danych konwersacji, a my możemy to wykonać w ciągu kilku minut.
Reguły rekordów w Odoo dodają kolejną warstwę ochrony, którą większość ludzi pomija. Nawet przy dostępie do odczytu reguły rekordów mogą ograniczać, które rekordy widzi użytkownik bota. Klient może skonfigurować Odoo tak, aby bot widział tylko rekordy z określonych firm w konfiguracji wielofirmowej, tylko zatwierdzone/opublikowane produkty lub tylko wybrane kategorie pracowników. Bot dziedziczy wszystkie te ograniczenia automatycznie, ponieważ działa jako zwykły użytkownik Odoo.
Zaimplementowaliśmy również ograniczenia przepustowości na wielu poziomach. Bot ogranicza liczbę zapytań na użytkownika na minutę, aby zapobiec nadużyciom. Ogranicza całkowitą liczbę zapytań na organizację klienta na godzinę, aby zapobiec niekontrolowanym kosztom. Ma również globalny limit przepustowości chroniący naszą infrastrukturę. Jeśli któryś limit zostanie osiągnięty, bot odpowiada uprzejmym komunikatem, a użytkownik może spróbować ponownie za chwilę.
Klientom z branż regulowanych dostarczamy szczegółową odpowiedź na kwestionariusz bezpieczeństwa i możemy zorganizować audyt naszego kodu przez ich zespół bezpieczeństwa. Zrobiliśmy to już trzykrotnie, a każdy audyt potwierdził, że architektura tylko do odczytu jest prawdziwa, a nie tylko marketingowa. Jeden audytor zwrócił szczególną uwagę, że brak metod zapisu w bazie kodu był nietypowy - większość systemów implementuje metody zapisu, a następnie próbuje je blokować na poziomie uprawnień, co jest z natury mniej bezpieczne.
Praktycznym rezultatem tego wszystkiego jest fakt, że nasz bot przetworzył ponad 10 000 zapytań w instancjach Odoo klientów bez ani jednego incydentu dotyczącego danych. Żadnych przypadkowych zapisów, żadnych wycieków danych, żadnego nieautoryzowanego dostępu. Architektura tylko do odczytu to nie tylko funkcja bezpieczeństwa - to fundamentalna zasada projektowa produktu, która umożliwia adopcję w przedsiębiorstwach.