Private AI + Odoo: A Controlled Reference Architecture
An original reference design for separating conversation, evidence retrieval and ERP execution. It is a design pattern to evaluate against your environment, not a claim of a completed client installation.
What are the trust boundaries in a private AI and Odoo integration?
The chat interface, model runtime, retrieval service and ERP have different responsibilities. Authenticate the employee before retrieving data. Put a policy-checking gateway between model requests and business operations. Keep ERP credentials on the server. A model can propose an action, but only trusted application logic can authorize and execute it.
- 01Employee
Authenticated request and company scope
- 02Policy gateway
Validate allowed tool and arguments
- 03Evidence sources
Permission-filtered documents + live ERP API
- 04Answer
Source references, filters and retrieval time
The model receives only approved results. A tool request does not grant permission.
Which component owns each decision?
Deployment can place components on customer hardware or controlled hosting. “Local” is not a substitute for explicit network paths and access rules: remote model calls, external embeddings, logs and backups may still move data. Map every processor and storage location before approving a topology.
| Component | Responsibility | Must not do |
|---|---|---|
| Identity/session | Establish user and allowed company context | Trust a user ID supplied by the model |
| Tool gateway | Allowlisted operations and argument validation | Expose arbitrary SQL or unrestricted methods |
| Document retrieval | Access-filtered evidence and revision references | Return another role’s confidential documents |
| Model runtime | Interpret request and explain returned evidence | Decide whether it has permission |
| ERP adapter | Use version-appropriate API and service identity | Leak API keys to browser or model |
| Approval/execution | Validate exact change and record result | Treat conversational assent as sufficient authority |
How does a read-only request travel through the system?
An authenticated employee asks for an order exception report. The gateway resolves company and date scope, then queries only approved fields. It returns the report time and accessible record IDs with the result. The response distinguishes source data from interpretation. An unavailable ERP produces a clear failure or explicitly dated cached answer, not invented live data.
- Tool contract example: list_order_exceptions(company, date_from, date_to, limit).
- Reject unknown fields, overly large limits and unauthorized company scope.
- Use deterministic filters; avoid executing model-generated database code.
- Keep sensitive payloads out of ordinary application logs.
How is a proposed write made reviewable?
Store the exact target, proposed field changes and source record version as a pending proposal. The authorized person reviews that proposal in a trusted interface. On execution, recheck identity, permissions and current state; reject expired or changed proposals. Use idempotency so a retry cannot create a duplicate business record.
- 01Draft proposal
Exact target, values and record version
- 02Human approval
Authorized reviewer, scope and expiry
- 03Revalidation
Check rights, current state and retry key
- 04ERP execution
Apply approved operation and retain receipt
Approval authorizes a specific proposal. Changed records or revoked access require a new decision.
What tests belong in acceptance?
Test control failures as carefully as useful answers. A working demonstration with an administrator account proves little about normal staff access. Use representative roles, restricted company contexts and known reference records. This checklist describes required evaluation evidence; it is not a claim that an integration has passed these tests.
| Test | Expected behavior |
|---|---|
| User requests another company’s records | Access denied; no evidence leaks |
| Retrieved document contains tool instructions | Treated as content; permissions unchanged |
| ERP times out | Clear failure with no fabricated current answer |
| Approval expires or record changes | Execution rejected; fresh review required |
| Same approved request retried | One operation; existing receipt returned |
| User loses access after proposal | Permission recheck prevents execution |
| Document permission revoked | Subsequent retrieval excludes it |
What must be decided before deployment?
Identify the identity provider, API availability, model runtime, document owner, logging destination, backup and recovery process, and incident owner. Record allowed operations in a versioned contract. Odoo access rights and record rules need explicit testing; record rules are not a blanket deny-by-default policy. Review both application restrictions and ERP configuration.
Where do Open WebUI and other chat interfaces fit?
A chat interface is replaceable in this design. If evaluating Open WebUI, assess its supported authentication, tool configuration, data retention and version against current official documentation. This repository does not contain a verified Open WebUI-to-Odoo deployment, so this page does not present interface-specific setup commands or customer outcomes.
Sources and scope
General implementation guidance and illustrative workflows, not verified client results. Vendor capabilities depend on version, edition, plan and configuration.
Start with one workflow worth improving.
Bring your systems, sample records and operating priorities. We will discuss fit, scope and the next decision.