How AI Tools Access Your Odoo Data
Every AI feature in Odoo gets its raw material from somewhere, and that somewhere is your database. The question is which door it uses to leave.
There are three doors, and they behave very differently.
The first is Odoo's own In-App Purchase (IAP) mechanism. Features like the OCR-based bill digitization in Accounting, or the AI content generation buttons in the Website builder, run through IAP: your database sends a specific payload — a scanned invoice, a text prompt, an image request — to a service endpoint, gets a result back, and a credit is deducted from your IAP wallet. Odoo's documentation on [In-App Purchase services](https://www.odoo.com/documentation/18.0/applications/essentials/in_app_purchase.html) describes this as a metered, per-call model rather than a bulk data feed. That distinction matters: IAP calls are narrow. A bill-scanning request sends one PDF, not your general ledger.
The second door is the Odoo Apps store, where third-party developers publish modules that call OpenAI, Anthropic, or Google's APIs directly from server-side Python. These bypass Odoo's IAP gateway entirely. The module's code decides what gets serialized and sent, and unless you've read that code, you don't actually know.
The third door is the one implementation partners build for you: a custom Odoo module that calls an LLM API to draft quote emails, summarize support tickets, or flag at-risk customers. This is where the real exposure tends to live, because scope creep is easy. A developer writing "summarize this customer's history" will often pull the whole `res.partner` record plus every linked invoice and message rather than the three fields actually needed, because filtering fields takes extra code and nobody budgeted for it.
What Information Actually Gets Sent to LLM Providers
Concretely, here's what crosses the wire in common scenarios:
- Invoice/bill digitization: the full scanned image or PDF, which typically contains vendor bank details, VAT numbers, line-item pricing, and sometimes purchase order references. Odoo's documentation on [invoice digitization](https://www.odoo.com/documentation/18.0/applications/finance/accounting/vendor_bills/invoice_digitization.html) confirms this runs as an IAP-metered OCR call — the document itself is the payload, not a summary of it.
- Website AI content generation: whatever text prompt you type, plus contextual fields the module includes automatically — company name, industry, sometimes product descriptions already in your catalog.
- Custom email-drafting or "smart reply" integrations: often the entire email thread, the customer's name and address, and — this is the one people miss — negotiated pricing sitting in the sale order lines referenced by the thread.
- Support ticket summarization: message history from `mail.message`, which can include internal notes marked "not sent to customer" if the query pulling context doesn't filter on visibility.
Do the arithmetic on a realistic case. A distributor with 60 sales reps using a ChatGPT-based follow-up email assistant, each rep sending 15–20 AI-drafted emails a day, is pushing 900-plus requests daily that include customer contact data and line-level pricing to a US-based API. Nobody signed off on that as a data flow; it accreted one convenient feature at a time.
Data Privacy Risks with Popular AI Integrations
The risks split into categories, and they don't get equal attention.
**Retention and training.** API-tier access from major LLM providers generally doesn't train on submitted data by default, unlike consumer chat products where opt-outs are separate settings. But "generally" is doing work in that sentence — the actual terms vary by provider, by product tier, and change over time. If your integration was built against a provider's consumer API by mistake (it happens, especially with community modules using personal API keys), you may be in a different, worse retention regime than you think.
**Shared credentials in free modules.** This is the one that surprises people. Some free Apps store connectors ship with the developer's own API key hardcoded, meaning every company that installs the module for free sends its prompts to the developer's account, not a company-owned one. You have no contract with that developer's LLM subprocessor, no DPA, and no visibility into their retention settings. Check the module's code before installing anything that touches AI, or ask your partner to.
**Logging that duplicates the exposure.** Odoo can log both the prompt and the response — into `mail.message` or a custom audit model — every time an AI feature fires. Good practice for accountability, bad news for exposure: the sensitive data you sent externally now sits twice inside your own database. That's a second thing to secure, and a second thing to produce if a data subject access request comes in.
**Prompt injection.** If an AI feature reads customer-supplied text — an email body, a support ticket, a website contact form — and acts on it (drafting a reply, updating a field, triggering a workflow), a customer can embed instructions in that text aimed at the model rather than at you. This is a known class of attack against LLM-integrated systems generally, not an Odoo-specific flaw, but it's underappreciated by teams who think of AI features as "just autocomplete."
How to Minimize Data Exposure When Using AI in Odoo
Odoo makes it easy to bolt on one more button, one more automated action, one more field on a form view — that's true of the platform generally, and it's exactly why AI features spread through a database without anyone reviewing the data path behind them. The fix isn't avoiding AI. It's treating each integration with the same scrutiny you'd give a new field on `res.partner` that syncs to a third party.
- Scope the payload to fields, not records. Insist that custom integrations pass named fields (`partner_id.name`, `invoice_total`) rather than serializing whole records. This is a code review question, not a settings toggle.
- Use your own API key, per company. Never rely on a module's bundled credentials. On a multi-company database, use separate keys per company so a breach or billing dispute in one entity doesn't expose data from another.
- Turn off features you're not actively using. Every enabled AI feature is a live data path. Disable IAP services and third-party AI modules for companies or teams that don't need them.
- Mask before you send. Strip bank account numbers, tax IDs, and national ID numbers with a pre-processing step before anything reaches an external API — a pattern-match filter for IBAN and tax ID formats takes an afternoon to build; an incident report takes a lot longer to close out.
- Set retention to zero where the provider allows it. Most enterprise API agreements let you configure zero data retention. Ask for it explicitly; it's rarely the default.
- Audit what's actually being sent. Log the outbound payload during testing — not just the feature's output — and read it. Assumptions about "just the summary" are wrong more often than teams expect.
- Get a signed Data Processing Agreement with the AI vendor before go-live. File it next to your Odoo hosting agreement, not in someone's inbox.
On-Premise vs Cloud LLM Solutions for Sensitive Data
If the data category is genuinely sensitive — health records adjacent, financial account numbers, anything under a client confidentiality clause — cloud LLM APIs are a harder sell regardless of provider terms, because the data leaves your infrastructure by design.
The alternative is running the model yourself: Ollama or vLLM serving an open-weight model like Llama 3.1 or Mistral on hardware you control, with your custom Odoo module calling a local endpoint instead of an internet API. Nothing leaves the network. The honest cost of this: open-weight models running on hardware a mid-size company can afford are noticeably behind GPT-4-class or Claude 3.5-class models on reasoning-heavy tasks. Running something closer to that quality bar (a 70B-parameter model at usable speed) needs real GPU investment — A100 or H100-class cards — that most 50- to 200-employee Odoo shops haven't budgeted for and shouldn't, unless the sensitivity of the data justifies it.
A middle path exists: managed enterprise offerings like Azure OpenAI Service or AWS Bedrock, where the model runs in the cloud but under a contract that specifies no training on your data, defined retention, and — this is the part that matters for the next section — a chosen data residency region. This gets you closer to frontier model quality without the GPU bill, at the cost of trusting the provider's contractual commitments rather than your own network perimeter.
The honest framing for a client: if the data is genuinely sensitive and the volume is low, self-hosting is worth the friction. If the volume is high and the data is moderately sensitive, a residency-committed enterprise API is the pragmatic middle. If you're drafting marketing copy or summarizing public product descriptions, none of this matters — use whatever's convenient.
Compliance Considerations (GDPR, Data Residency) with AI Adoption
Under GDPR, any external service that processes personal data on your behalf — including an LLM API that receives a customer's name, email, or purchase history — is a sub-processor under Article 28. That triggers obligations regardless of how small the integration feels: a signed DPA, an entry in your Records of Processing Activities under Article 30, and a check on the legal basis for the transfer if the provider sits outside the EU. Most frontier LLM providers are US-based, which means you're relying on Standard Contractual Clauses or the EU-US Data Privacy Framework, not on the provider being "GDPR compliant" as a general claim — that phrase alone doesn't satisfy the transfer requirement.
Odoo publishes its own position on this for the platform itself on its [GDPR page](https://www.odoo.com/gdpr) and [privacy policy](https://www.odoo.com/privacy), including its subprocessor list — worth reading before you assume Odoo's compliance posture extends automatically to whatever AI vendor you've bolted on. It doesn't. Odoo SA's commitments cover Odoo's own infrastructure and the IAP services it operates; they say nothing about a third-party OpenAI-calling module your partner installed last quarter.
Data residency compounds this. Odoo Online lets you select a hosting region at database creation, and Odoo.sh gives you control over where your instance runs. That choice does not automatically extend to AI API calls layered on top — a request from an EU-hosted Odoo database can still route to a US datacenter if the underlying AI service doesn't offer regional endpoints. If data residency is a contractual requirement for your business (public sector, healthcare-adjacent, certain financial services clients), confirm the AI vendor's endpoint region explicitly. Some providers, including Azure OpenAI and Mistral, offer EU-region deployments precisely for this reason — but only if you configure them, not by default.
Before rolling out any AI feature, three concrete steps: identify which personal data categories the feature touches, update your Records of Processing Activities to reflect the new sub-processor, and revise the privacy notice you show customers if their data now reaches a third party it didn't reach before. Skip any one of these and it's the first thing a data protection authority asks about when an AI feature makes headlines for the wrong reason.
