Quando abbiamo iniziato a proporre il nostro Bot IA ai clienti enterprise, la prima domanda era sempre la stessa: cosa succede se modifica i nostri dati? E una preoccupazione ragionevole. Si ha un'istanza Odoo in produzione che gestisce l'intera azienda - vendite, magazzino, contabilita, HR. Dare a uno strumento IA accesso a quel sistema suona rischioso. Per questo abbiamo progettato l'architettura in modo da rendere fisicamente impossibile al bot scrivere, aggiornare o cancellare qualsiasi cosa.
Le fondamenta sono semplici: il bot si collega a Odoo via XML-RPC utilizzando un account di servizio dedicato con permessi rigorosamente di sola lettura. Non si tratta di un'opzione software che possiamo attivare accidentalmente. L'utente Odoo assegnato al bot ha diritti di accesso personalizzati a livello di modello - accesso in lettura sui modelli approvati dal cliente, zero permessi di scrittura/creazione/eliminazione su qualsiasi cosa. Anche se il nostro codice avesse un bug che tentasse un'operazione di scrittura, il livello di controllo degli accessi di Odoo la rifiuterebbe con un AccessError.
Siamo andati oltre i soli permessi Odoo. Il livello di integrazione del bot non implementa alcun metodo di scrittura. Il client XML-RPC che abbiamo costruito espone solo operazioni search_read, fields_get e read. Non esiste alcuna chiamata execute_kw per create, write o unlink in tutto il codice. Questa e difesa in profondita - anche se qualcuno compromettesse il nostro livello applicativo, gli strumenti per modificare i dati semplicemente non esistono nel codice distribuito.
L'archiviazione delle credenziali e stata un'altra decisione critica. I dettagli di connessione Odoo di ogni cliente - URL, nome database, API key - sono cifrati a riposo utilizzando AES-256-GCM. Le chiavi di cifratura sono memorizzate separatamente dai dati cifrati, seguendo il pattern di envelope encryption. Usiamo un vettore di inizializzazione unico per ogni operazione di cifratura, il che significa che anche credenziali identiche per due clienti producono testi cifrati completamente diversi.
Le API key stesse meritano attenzione. Utilizziamo il sistema di API key integrato di Odoo invece di memorizzare password. Le API key possono essere revocate istantaneamente dal cliente dal proprio pannello admin Odoo senza coinvolgerci. Se un cliente vuole interrompere l'accesso del bot, cancella l'API key e smette di funzionare immediatamente. Nessun ticket, nessuna attesa, nessuna dipendenza da noi.
I dati in transito sono protetti da TLS 1.3 per tutte le connessioni tra il nostro server bot e le istanze Odoo dei clienti. Applichiamo la convalida dei certificati - nessun bypass dei controlli SSL nemmeno in sviluppo. Il server bot stesso gira su un VPS Hetzner isolato con una superficie di attacco minima: nessuna porta non necessaria aperta, autenticazione SSH solo tramite chiave, aggiornamenti di sicurezza automatici.
Una domanda che riceviamo dai team IT e se i dati dei clienti vengono utilizzati per addestrare i modelli IA. La risposta e no, e l'architettura lo garantisce. Quando un utente fa una domanda al bot, interroghiamo l'Odoo del cliente per i dati rilevanti, li formattiamo in un prompt, li inviamo all'API di Claude e restituiamo la risposta. Non memorizziamo i risultati delle query oltre la sessione di conversazione. Non aggreghiamo dati per il training. I termini dell'API di Claude stabiliscono esplicitamente che input e output dell'API non vengono utilizzati per l'addestramento dei modelli.
La cronologia delle conversazioni stessa e memorizzata nel nostro database con la stessa cifratura AES-256-GCM utilizzata per le credenziali. Le conversazioni sono legate ai singoli utenti Telegram e vengono automaticamente eliminate dopo 30 giorni. Un cliente puo richiedere la cancellazione immediata di tutti i dati delle proprie conversazioni, e noi possiamo eseguirla in pochi minuti.
Le regole di record di Odoo aggiungono un ulteriore livello di protezione che la maggior parte delle persone trascura. Anche con l'accesso in lettura, le regole di record possono limitare quali record l'utente bot puo vedere. Un cliente puo configurare il proprio Odoo in modo che il bot veda solo i record di aziende specifiche in un setup multi-azienda, o solo prodotti approvati/pubblicati, o solo determinate categorie di dipendenti. Il bot eredita automaticamente tutte queste restrizioni perche opera come un normale utente Odoo.
Abbiamo anche implementato il rate limiting a piu livelli. Il bot limita le query per utente al minuto per prevenire abusi. Limita le query totali per organizzazione cliente all'ora per prevenire costi incontrollati. E ha un rate limit globale per proteggere la nostra infrastruttura. Se qualsiasi limite viene raggiunto, il bot risponde con un messaggio cortese e l'utente puo riprovare a breve.
Per i clienti in settori regolamentati, forniamo una risposta dettagliata a questionari di sicurezza e possiamo organizzare un audit del nostro codice da parte del loro team di sicurezza. L'abbiamo fatto tre volte finora, e ogni audit ha confermato che l'architettura in sola lettura e autentica, non solo marketing. Un auditor ha specificamente notato che l'assenza di metodi di scrittura nel codice era insolita - la maggior parte dei sistemi implementa metodi di scrittura e poi cerca di bloccarli a livello di permessi, il che e intrinsecamente meno sicuro.
Il risultato pratico di tutto questo e che il nostro bot ha elaborato oltre 10.000 query su istanze Odoo di clienti con zero incidenti sui dati. Nessuna scrittura accidentale, nessuna fuga di dati, nessun accesso non autorizzato. L'architettura in sola lettura non e solo una funzionalita di sicurezza - e il principio di design fondamentale del prodotto che rende possibile l'adozione enterprise.