In this piece
Odoo AI data residency: does EU hosting cover inference?
The procurement form asks where customer data is processed. Your Odoo database is in the requested region, so the hosting box looks complete. Then someone enables an AI feature that uses record context. That feature needs its own evidence before the form can be signed.
An EU database region alone cannot establish where an Odoo AI workflow processes its data. Approve the specific feature only after mapping its configured route, content, inference, logs, retention and support access against the actual location requirement, with an evidence link and responsible owner for each unresolved step.
Research checked: 5 November 2026. We inspected the current IAP policy and official hosting documentation source. The proposed checklist and synthetic record support the illustrative approval scenarios below. We did not inspect a customer tenant, capture Odoo traffic or establish legal compliance.
What does the current Odoo evidence establish?
The evidence supports two separate questions: where the database is hosted and where a configured AI operation may run. Preserve the source and scope of each answer. A hosting-region confirmation should not silently become a promise about another service, a retrieved document, an external tool or a diagnostic log.
Odoo’s IAP policy lists global inference for Ask AI/AI Agents and automatic provider selection from v20. Prompts, context and retrieved material may be sent to providers.
Odoo’s hosting instructions separately ask for the database’s desired region. Our architectural conclusion is that these are distinct boundaries. An EU-only requirement cannot be approved using the database-region evidence alone.
Obtain the current hosting and backup commitments that apply to your database. Record which storage and copies are covered. Assess access arrangements separately from AI processing. Public policy describes a service; it does not establish how every path in your tenant is configured.
Which location requirement are you trying to satisfy?
Write the requirement in terms someone can test and sign. Identify which operations use each data class and where they are permitted. A requirement limited to primary database storage differs from one covering every AI request, attachment, log, backup and support path. The approving owner must decide which boundary applies.
| Statement | Question to resolve | Evidence needed |
|---|---|---|
| “Our database must be hosted in the EU.” | Does this also cover backup copies and AI processing? | Hosting scope and explicit decisions for other paths |
| “These customer records may only be processed in the EU.” | Which fields and derivative content inherit the restriction? | A route-specific processing commitment and context inventory |
| “No provider may use this content for training.” | What are the separate location and retention requirements? | Each commitment recorded independently |
| “Only public material may enter this pilot.” | Can the configured feature add private context or tools? | Configuration review and a synthetic context inspection |
These are fictional examples, not legal rules. If the requirement comes from a customer contract, record the relevant clause and its responsible interpreter. If it is an internal risk decision, name the data owner. Avoid asking an implementation team to satisfy a phrase whose meaning changes at sign-off.
For general provider and endpoint distinctions, use the EU data residency guide for AI APIs. This article applies the evidence question specifically to an Odoo feature; it does not reproduce that provider directory.
What belongs in the workflow evidence map?
Start from the actual feature and list every step that handles the restricted data. Record possible steps as unverified until you establish whether they exist. For each confirmed step, separate storage, processing, retention and access evidence. Keep the date and configuration beside the evidence so later changes can be assessed.
| Step, if present | What to identify | Useful evidence |
|---|---|---|
| Odoo source record | Selected fields and attachments within the approved user scope | Feature configuration and a synthetic input record |
| Prompt assembly | Instruction and history, including any added record fields | Authorized payload inspection or documented assembly behavior |
| Orchestration service | Who operates the request route and retains intermediate state | Applicable service terms and configuration reference |
| Model inference | The service and location commitment for this route | Current provider or contractual evidence |
| Retrieval or external tool | What the tool sends, where it sends it and what it returns | Tool allowlist and observed test invocation |
| Logs, exports and backups | Content copied beyond the immediate operation | Logging/retention settings and hosting evidence |
| Support access | Who can inspect content and through which route | Access procedure and applicable commitments |
Download the location evidence checklist. It deliberately starts with unverified rows and unassigned owners. Mark confirmed absent steps as not applicable with evidence, add missing ones, and attach the relevant records. A filled row should explain a decision; it should not merely contain a reassuring country name.
Distinguish what you observed from what the supplier commits to. A request destination or IP address can help identify a service, but it does not by itself establish where every inference operation executes. Conversely, a contractual location promise needs to apply to the configuration your team enabled.
How can you inspect the context without real customer data?
Use a synthetic record with distinguishable values in the fields you intend to include and in fields that should remain outside the request. Run an authorized inspection in a suitable test environment. Compare the available evidence with the expected context, and document visibility limits instead of treating missing traces as proof of absence.
The downloadable synthetic context canary describes a fictional quotation. It has a product, quantity, an email address under example.invalid and distinct markers in an internal note and attachment field. Its requested output needs only the product and quantity. The file is a proposed test input, not an Odoo import module.
- Record the exact feature, version, configured sources, tools and user permissions.
- Define which synthetic fields the task should need before running it.
- Use the authorized observability available for that route to inspect context and tool requests.
- Record unexpected fields, missing visibility and the evidence reference.
- Review the route’s location commitment separately from the context result.
A canary appearing in an output can reveal an unexpected path. Its absence from an output does not prove that the field was never sent. That is why the proposed check combines configuration evidence, available traces and the applicable commitments. No single screenshot certifies the whole data path.
When can the feature proceed, narrow its scope or wait?
Make the decision at feature and data-class level. A mandatory location requirement needs matching evidence before restricted material enters the route. When the business can use a narrower dataset, assess that reduced scope explicitly. When a decisive fact remains unknown, assign its resolution instead of approving the entire application by association.
| Scenario | Evidence position | Proposed decision |
|---|---|---|
| Public product-copy pilot | Public inputs are permitted; added context and tools still need inspection | Consider a bounded pilot after confirming the scope |
| Restricted customer-document summary | EU-only processing is mandatory; route commitment is missing or inconsistent | Keep that data class out until a supported route is evidenced |
| Approved route gains a retrieval tool | The original assessment did not cover the new source and destination | Review the changed path before extending the approval |
A narrower decision is easier to maintain. “Product-description drafting with these fields and tools” identifies something an owner can revisit. “Odoo is compliant” leaves the reader guessing which version, feature, data and requirement were assessed.
Does an alternative route solve the location question?
An alternative can help only when its entire configured path meets the requirement. Evaluate the model service, orchestration, tools, logs, backups and access arrangements together. Changing the database host, choosing an EU-labelled endpoint or removing a provider logo does not independently establish the behavior of all the remaining steps.
This is an architectural evaluation, not a claim that any particular Odoo edition supports an arbitrary replacement. Establish the supported connection and operating responsibility first. The Odoo API integration limits guide covers that platform boundary. The reviewed-quotation AI budget covers the separate purchasing consequences.
Apply the same evidence questions to a self-hosted proposal. An internally operated database is one component; an external inference, retrieval or support path still needs its own decision. If the requirement cannot be met within the supported design and budget, keep the affected operation manual while evaluating alternatives.
What would we verify first?
Select one feature and one data class, write the actual location requirement, and complete the evidence map with named owners. Resolve the fact that could change the approval first. Keep other data classes outside the pilot until their paths are covered, and reopen the assessment when the approved configuration materially changes.
Carry the resulting record into Odoo AI upgrade readiness. Use the standard feature versus custom software decision guide if the requirement demands another route. The Twinsoft AI case study is separate delivery context, not a residency certification.
Wavect’s AI security service can help organize that review. Discuss an Odoo AI data-flow review with the requirement and the feature that will process the affected data.