Passa al contenuto

L'AI di Odoo 20: potente, chiusa e solo Enterprise. Perché molte aziende ci penseranno due volte

Cosa fa davvero l'AI agentica di Odoo 20, dove vanno i dati e perché un sistema chiuso e solo Enterprise rischia di scontentare molte aziende

Odoo 20 è la release dell'AI. Nel repository Enterprise i moduli ai_* passano da quindici a cinquantuno; nel repository Community sono zero, come prima. Nella nostra overview tecnica di Odoo 20 l'abbiamo raccontata come la novità che cambia di più l'architettura. Qui la guardiamo dall'altro lato: quello del cliente che deve decidere se accenderla.

Il giudizio, anticipato: le funzionalità sono serie, la sicurezza è pensata, ma le scelte di fondo — solo Enterprise, a consumo, un unico canale verso un unico fornitore, nessuna scelta del modello — vanno contro quello che molte aziende hanno già costruito, e contro il motivo per cui alcune hanno scelto Odoo.

Cosa fa davvero

Il cuore è ai_agentic. Introduce le skill (ai.skill): istruzioni più un insieme di strumenti, dove gli strumenti sono azioni server (ir.actions.server) marcate per l'uso con l'AI. Un agente non si limita a suggerire una bozza: legge record, li crea, cambia stati, lancia automazioni, perché il modulo si appoggia a base_automation.

Attorno ci sono:

  • ai_mcp: Odoo espone un server MCP all'indirizzo /mcp dell'istanza, con autenticazione OAuth e chiavi API dedicate. Un assistente esterno può operare sul gestionale.
  • I bridge per applicazione: vendite, acquisti, magazzino, progetti, timesheet, report contabili, helpdesk, marketing automation, sito, e-commerce, livechat.
  • La ricerca sui documenti (RAG): pagine web, articoli di Knowledge e documenti vengono spezzati in blocchi e trasformati in embedding, vettori salvati in PostgreSQL con l'estensione pgvector, così l'agente può rispondere citando i tuoi contenuti.

È un lavoro esteso e ben integrato. Il punto non è se funzioni. È a che condizioni.

Perché rischia di scontentare molte aziende

1. Solo Enterprise, e a consumo sopra la licenza

Tutti i moduli AI hanno licenza OEEL-1 (Enterprise) e i principali — ai, ai_agentic — sono dichiarati iap_paid_service: si pagano a consumo con i crediti IAP, in aggiunta all'abbonamento per utente.

E non basta un abbonamento Enterprise qualsiasi: sul listino ufficiale l'IA agentica compare tra le funzioni del solo piano Personalizzato, insieme a Studio, API esterna e on-premise. Oggi quel piano costa 27,90 € per utente al mese con fatturazione annuale (33,90 € con fatturazione mensile), prima del consumo dei crediti. È anche il piano che dal 24 settembre costa il 20% in più: e tra le ragioni dell'aumento la stessa Odoo cita "the skyrocketing costs associated with AI" (blog ufficiale Odoo).

E non tutti gli utenti Enterprise li vedono: in Odoo 20 il menu AI è riservato al gruppo base.group_user_regular, cioè agli utenti pieni. I nuovi Light User, la licenza ridotta introdotta con la stessa release, ne sono esclusi per costruzione (come funzionano i Light User di Odoo 20).

Per chi è su Community la risposta è più semplice: l'AI di Odoo non c'è, e non è prevista.

2. Un sistema chiuso: un canale, un fornitore, nessuna scelta del modello

Tutte le chiamate partono verso un unico endpoint, https://ai.api.odoo.com (ai/utils/ai_utils.py), autenticate con il token IAP e l'UUID del database. Non si inserisce una propria chiave OpenAI, Anthropic o Google, e non si collega un modello in casa.

Nella 19 il modello ai.agent aveva almeno un campo llm_model per scegliere quale LLM usare. Nella 20 quel campo non c'è più: la scelta del modello è passata lato server, dentro il servizio di Odoo.

Per completezza: esiste un parametro di sistema ai.endpoint che sostituisce l'indirizzo. Ma il client parla il protocollo IAP di Odoo (/api/odoo_ai/<route> con token e UUID del database), non un'API standard: non è una porta aperta verso altri fornitori, è un'impostazione pensata per l'infrastruttura di Odoo.

Le conseguenze pratiche sono tre. Non si può scegliere un modello per costo, qualità o giurisdizione. Non si può usare un modello locale, che per molte aziende è l'unica forma di AI accettabile sui dati gestionali. E il prezzo, il fornitore e la qualità del modello possono cambiare senza che il cliente lo decida.

3. Molti l'hanno già fatto — da anni

Da quando i modelli linguistici sono diventati utilizzabili, partner e clienti Odoo hanno costruito le loro integrazioni: assistenti nel chatter, classificazione dei ticket, estrazione di dati dai documenti, server MCP, ricerca sui documenti interni. Spesso con il modello scelto da loro, a volte in casa.

Per queste aziende Odoo 20 non porta l'AI: porta un'alternativa a quello che già hanno, testato, pagato e adattato ai loro processi. La domanda non è "accendiamo l'AI?", ma "buttiamo quello che funziona per passare a una soluzione su cui abbiamo meno controllo?". In molti casi la risposta sarà no.

4. Le alternative aperte esistono

La comunità Odoo ha un repository dedicato, OCA/ai, con licenza AGPL. Il contenuto varia molto per versione (verificato il 18 ottobre 2026):

Versione Moduli principali
16.0 ai_oca_bridge e bridge per chatter, CRM, helpdesk, field service, produzione; ai_automation; ai_oca_mcp (server MCP)
18.0 ai_connection, ai_connection_openai, ai_oca_native_generate_ollama (generazione con modelli locali via Ollama), bridge
19.0 solo ai_tool
20.0 branch non ancora presente

Va detto onestamente: non è l'equivalente dei cinquantuno moduli Enterprise, e sulla 20 non è ancora disponibile. Ma l'impostazione è opposta: il modello lo sceglie chi installa, può essere un servizio esterno o un modello che gira sui propri server, e il codice è leggibile e modificabile. Fuori da OCA esistono anche progetti indipendenti, come apexive/odoo-llm.

5. La sicurezza dei dati: protezioni a monte, nulla a valle

Odoo ha messo delle protezioni, e vanno riconosciute:

  • una blocklist di modelli che l'AI non può leggere (configurazione della sicurezza, automazioni, dispositivi, impostazioni utente, i modelli ai.*);
  • l'agente eredita i permessi di chi lo usa: gli strumenti verificano i diritti prima di leggere, e le azioni server girano con i diritti dell'utente reale;
  • conferma umana prima di ogni scrittura, con l'approvazione automatica spenta per impostazione predefinita e un tetto alle chiamate consecutive.

Tutte agiscono su cosa l'AI può leggere o fare. Su cosa esce dall'istanza non c'è niente:

  • I dati escono in chiaro. Alla richiesta di completion partono conversazione, istruzioni, schemi degli strumenti e i risultati degli strumenti, cioè i record letti dal database. Nessuna anonimizzazione, nessun mascheramento.
  • I documenti escono prima ancora della domanda. Per creare gli embedding, il contenuto di documenti, articoli e pagine indicizzate — titolo e testo, a blocchi — viene inviato al servizio di Odoo (ai/models/ai_embedding.py). Succede all'indicizzazione, non quando qualcuno chiede qualcosa.
  • Su MCP la conferma umana salta. Quando la richiesta arriva da un client esterno, la conferma viene data per acquisita: chi ha il token agisce con i pieni diritti di quell'utente, senza nessuno nel mezzo.
  • La superficie è il set di permessi. Se l'agente lo usa chi vede tutte le fatture, tutte le fatture possono finire in un prompt. Il controllo vero sono i gruppi e le record rule, che in molte installazioni non sono mai stati disegnati con questa domanda in testa.
  • L'AI si installa da sola, se può. Il modulo ai_auto_install installa ai automaticamente quando sul server PostgreSQL è disponibile pgvector (era così già nella 19), e quasi tutti i bridge AI si installano da soli insieme alle app a cui si agganciano. Chi aggiorna l'infrastruttura per altri motivi può ritrovarsi l'AI installata senza averlo deciso.

Conservazione dei dati, uso per l'addestramento, residenza e sub-responsabili non sono nel codice: stanno nell'accordo sul trattamento dei dati di Odoo, ed è la prima cosa da leggere per chi tratta dati sanitari, giudiziari o coperti da riservatezza.

Il paradosso è evidente per chi ha scelto Odoo on-premise proprio per tenere i dati in casa: con l'AI nativa, i dati più interessanti escono comunque, verso un servizio che il cliente non sceglie e non può sostituire.

Quando ha senso, e cosa fare prima

L'AI di Odoo 20 ha senso per chi è già su Enterprise, non ha integrazioni proprie, non ha vincoli forti sui dati e vuole qualcosa che funzioni senza sviluppo. Per tutti gli altri, prima di accenderla:

  1. Inventario di quello che c'è già: integrazioni AI fatte in casa o dal partner, cosa fanno, quanto sono costate, se reggono la migrazione alla 20.
  2. Decidere quali dati possono uscire e verificare che i gruppi e le record rule degli utenti che useranno l'AI lo riflettano davvero.
  3. Leggere l'accordo sul trattamento dei dati di Odoo con chi in azienda si occupa di privacy, prima dell'installazione.
  4. Controllare pgvector sul server: se c'è, ai può installarsi da solo.
  5. Trattare i token MCP come password, e limitare gli strumenti esposti via MCP.
  6. Valutare le alternative aperte, anche sapendo che oggi richiedono più lavoro.

Se stai decidendo se adottare l'AI di Odoo 20, mantenere le integrazioni che hai o costruirne una con un modello scelto da te, parliamone: partiamo da quello che hai già e da quali dati possono uscire, non dalla lista delle funzionalità.

news 24 ottobre 2026
Etichette
Archivio
Accedi per lasciare un commento
Odoo 20, Light User: cosa sono, come si contano e perché la fattura può crescere senza che nessuno se ne accorga
Cosa sono i Light User di Odoo 20, come vengono contati i dipendenti e perché la nuova regola pesa su chi usa Odoo da anni