Cand am inceput sa prezentam botul nostru IA clientilor enterprise, prima intrebare era intotdeauna aceeasi: ce se intampla daca modifica datele noastre? Este o preocupare rezonabila. Aveti o instanta Odoo in productie care ruleaza intreaga afacere - vanzari, stoc, contabilitate, HR. Oferirea accesului unui instrument IA la acel sistem pare riscanta. Asa ca am proiectat arhitectura astfel incat sa fie fizic imposibil pentru bot sa scrie, sa actualizeze sau sa stearga ceva.
Fundatia este simpla: botul se conecteaza la Odoo prin XML-RPC folosind un cont de serviciu dedicat care are permisiuni strict de citire. Aceasta nu este o setare software pe care o putem schimba din greseala. Utilizatorul Odoo atribuit botului are drepturi de acces personalizate la nivelul modelului - acces de citire la modelele aprobate de client, zero permisiuni de scriere/creare/stergere pe orice. Chiar daca codul nostru ar avea un bug care ar incerca o operatiune de scriere, propriul strat de control al accesului Odoo ar respinge-o cu o eroare AccessError.
Am mers mai departe decat simplele permisiuni Odoo. Stratul de integrare al botului nu are deloc metode de scriere implementate. Clientul XML-RPC pe care l-am construit expune doar operatiunile search_read, fields_get si read. Nu exista niciun apel execute_kw pentru create, write sau unlink nicaieri in codul sursa. Aceasta este aparare in adancime - chiar daca cineva ar compromite stratul nostru de aplicatie, instrumentele de modificare a datelor pur si simplu nu exista in codul implementat.
Stocarea credentialelor a fost o alta decizie critica. Detaliile conexiunii Odoo ale fiecarui client - URL, numele bazei de date, cheia API - sunt criptate in repaus folosind AES-256-GCM. Cheile de criptare sunt stocate separat de datele criptate, urmand modelul de criptare envelope. Folosim un vector de initializare unic pentru fiecare operatiune de criptare, ceea ce inseamna ca chiar si credentialele identice pentru doi clienti produc text cifrat complet diferit.
Cheile API in sine merita atentie. Folosim sistemul integrat de chei API al Odoo in loc sa stocam parole. Cheile API pot fi revocate instantaneu de client din panoul de administrare Odoo, fara implicarea noastra. Daca un client doreste sa intrerupa accesul botului, sterge cheia API si aceasta inceteaza sa functioneze imediat. Fara tichet, fara asteptare, fara dependenta de noi.
Datele in tranzit sunt protejate prin TLS 1.3 pentru toate conexiunile dintre serverul nostru de bot si instantele Odoo ale clientilor. Impunem validarea certificatelor - fara omiterea verificarilor SSL nici macar in dezvoltare. Serverul botului in sine ruleaza pe un VPS Hetzner izolat, cu o suprafata minima de atac: fara porturi inutile deschise, autentificare doar cu cheie SSH, actualizari de securitate automate.
O intrebare pe care o primim de la echipele IT este daca datele clientilor sunt folosite pentru antrenarea modelelor IA. Raspunsul este nu, iar arhitectura impune acest lucru. Cand un utilizator pune o intrebare botului, interogam sistemul Odoo al clientului pentru datele relevante, le formatam intr-un prompt, le trimitem la API-ul Claude si returnam raspunsul. Nu stocam rezultatele interogarilor dincolo de sesiunea conversatiei. Nu grupam datele pentru antrenare. Termenii API-ului Claude afirma explicit ca intrarile si iesirile API nu sunt folosite pentru antrenarea modelelor.
Istoricul conversatiilor in sine este stocat in baza noastra de date cu aceeasi criptare AES-256-GCM folosita pentru credentiale. Conversatiile sunt legate de utilizatorii Telegram individuali si sunt eliminate automat dupa 30 de zile. Un client poate solicita stergerea imediata a tuturor datelor sale de conversatie, iar noi putem executa acest lucru in cateva minute.
Regulile de inregistrare ale Odoo adauga un alt strat de protectie pe care majoritatea oamenilor il trec cu vederea. Chiar si cu acces de citire, regulile de inregistrare pot restrictiona ce inregistrari poate vedea utilizatorul bot. Un client isi poate configura Odoo astfel incat botul sa vada doar inregistrari de la anumite companii intr-o configuratie multi-companie, sau doar produse aprobate/publicate, sau doar anumite categorii de angajati. Botul mosteneste automat toate aceste restrictii, deoarece functioneaza ca un utilizator Odoo obisnuit.
De asemenea, am implementat limitarea ratei la mai multe niveluri. Botul limiteaza interogarile pe utilizator pe minut pentru a preveni abuzul. Limiteaza interogarile totale pe organizatia clientului pe ora pentru a preveni costurile scapate de sub control. Si are o limita globala de rata pentru a ne proteja infrastructura. Daca este atinsa vreo limita, botul raspunde cu un mesaj politicos, iar utilizatorul poate incerca din nou in scurt timp.
Pentru clientii din industrii reglementate, oferim un raspuns detaliat la chestionarul de securitate si putem aranja ca echipa lor de securitate sa auditeze codul nostru. Am facut acest lucru de trei ori pana acum, iar fiecare audit a confirmat ca arhitectura doar pentru citire este autentica, nu doar marketing. Un auditor a remarcat in mod specific ca absenta metodelor de scriere din codul sursa era neobisnuita - majoritatea sistemelor implementeaza metode de scriere si apoi incearca sa le blocheze la nivel de permisiune, ceea ce este inerent mai putin sigur.
Rezultatul practic al tuturor acestor lucruri este ca botul nostru a procesat peste 10.000 de interogari pe instantele Odoo ale clientilor, cu zero incidente de date. Fara scrieri accidentale, fara scurgeri de date, fara acces neautorizat. Arhitectura doar pentru citire nu este doar o caracteristica de securitate - este principiul de baza al produsului care face posibila adoptarea la nivel enterprise.