# AI for Odoo Manufacturing That Reads Your Own Database, Not a Vendor's Cloud > Source: https://netray.co/erp-ai/odoo-ai-integration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer AI for Odoo connects a private LLM to the Odoo ORM and PostgreSQL database so planners, buyers, and shop-floor leads can ask plain-English questions about mrp.production, mrp.bom, and stock.quant and get answers grounded in live data, with the underlying domain filter shown. It runs on-prem or in a private cloud next to your existing Odoo Community or Enterprise instance, so customer BoMs, costs, and supplier terms never leave your infrastructure. ## Kind platform ## Erp Family other ## Erp Products - Odoo Manufacturing - Odoo Enterprise - Odoo Community ## Industries - Manufacturing - Distribution ## Region Global ## Persona Operations Manager ## Eyebrow Odoo Manufacturing + private AI ## Intro Odoo grew from a lightweight open-source accounting tool into a full manufacturing ERP largely through Studio, custom modules, and a very permissive ORM. That flexibility is the reason mid-market manufacturers picked it over heavier platforms, and it is also why every Odoo instance ends up looking slightly different from every other one after two or three years of go-lives, acquisitions, and app-store additions. The result is an ERP where the data model is genuinely powerful (any user with ORM access can, in principle, query any linked model) but where almost nobody outside the implementation partner actually knows the field names well enough to use that power. Planners ask the same questions in Slack every Monday morning that a well-built AI layer could answer in seconds directly from mrp.production and stock.quant. Odoo's own AI additions (IAP-based suggestions, the built-in Spreadsheet AI helper) are useful for surface-level tasks but route through Odoo's cloud services and are not designed for grounded, auditable question-answering over your specific customizations, your specific chart of accounts, or your specific work center naming conventions. Manufacturers running Odoo self-hosted, in a VPC, or under a customer NDA that restricts data flow need something that stays inside the boundary they already control. This page covers what AI on top of Odoo Manufacturing actually looks like in practice: which models and APIs it touches, where a private LLM fits next to a self-hosted or Odoo.sh instance, and what questions to ask before you let anyone plug an AI agent into your production database. ## Pain Points ### Reporting stops where dashboards stop **Detail:** Odoo's built-in dashboards and the Spreadsheet app cover the questions someone anticipated when they built the view. Anything ad hoc ("which work orders are behind because of the same component shortage") means exporting to Excel or filing a ticket with whoever wrote the last custom report. ### Studio and custom modules drift from the vendor baseline **Detail:** Every added field in Studio, every inherited model, every custom module from the App Store makes the next major version upgrade (17.0 to 18.0, for example) riskier and makes generic documentation less useful, because your instance is no longer quite the instance the manual describes. ### Multi-company and multi-warehouse hides true availability **Detail:** With intercompany rules, multiple stock.warehouse records, and routes that vary by company, a simple question like "do we have enough of this component" requires knowing which warehouses count and which don't, knowledge that usually lives with one planner. ### Odoo-specific talent is scarce and unevenly priced **Detail:** Functional-technical consultants who know both manufacturing operations and the Odoo ORM well enough to build reliable customizations are in short supply outside the largest partner firms, and turnover on that one internal expert is a real operational risk. ### The ORM's power is locked behind field names nobody remembers **Detail:** mrp.production, mrp.workorder, stock.move, stock.quant, purchase.order.line: the data to answer almost any operational question is there, but only someone who has spent real time in Odoo's technical documentation can write the domain filter to get it. ## Use Cases ### Natural-language BoM and work order queries **Description:** Planners ask questions like "which open manufacturing orders are waiting on a component from this supplier" in plain English and get an answer built from a live query, not a cached report. **Erp Objects:** mrp.production, mrp.bom, mrp.bom.line, stock.quant **Outcome:** Cuts the daily round of Slack messages to the planning team from a running list to a self-serve question, freeing planners for exceptions. ### Shop-floor work order assistant **Description:** Operators ask a tablet-based assistant for the current routing step, linked quality checks, or the reason a work order is on hold, without leaving the work center screen. **Erp Objects:** mrp.workorder, mrp.routing.workcenter, quality.check **Outcome:** Reduces the number of times a supervisor is pulled away from the floor to answer a routing or quality-check question. ### Purchase order follow-up agent **Description:** An agent reviews open purchase.order.line records against promised dates and drafts a follow-up email to the buyer for review, rather than a human scanning the purchase dashboard every morning. **Erp Objects:** purchase.order, purchase.order.line, stock.picking **Outcome:** Turns a manual morning review into a queue of drafted follow-ups a buyer approves in minutes. ### Work order exception triage **Description:** When a work order stalls, the agent checks linked stock moves, quality checks, and maintenance.request records to summarize the likely cause before an operations manager investigates. **Erp Objects:** mrp.workorder, maintenance.request, stock.move **Outcome:** Shortens the time between a stall being noticed and someone knowing why it happened. ### Quality alert and non-conformance drafting **Description:** When a quality.check fails, the assistant drafts a quality.alert with the relevant lot, work order, and prior similar failures pre-filled, for the quality lead to review and submit. **Erp Objects:** quality.check, quality.alert, stock.lot **Outcome:** Cuts the time to file a usable non-conformance record from a distracted-form-fill to a two-minute review. ### Multi-company, multi-warehouse inventory visibility **Description:** A single natural-language question resolves across every stock.warehouse and company the user has access to, instead of requiring a saved filter per site. **Erp Objects:** stock.quant, stock.warehouse, res.company **Outcome:** Gives group-level operations visibility without building and maintaining a cross-company reporting view by hand. ### Customization and Studio field documentation **Description:** The assistant reads ir.model.fields, Studio-added views, and custom module code to answer "what does this field actually do and who added it," turning tribal knowledge into a searchable answer. **Erp Objects:** ir.model.fields, ir.ui.view, custom module source **Outcome:** Reduces onboarding time for new administrators and lowers the risk when the one person who remembers a customization leaves. ## Architecture **Overview:** The AI layer sits beside your existing Odoo deployment (self-hosted, Docker, or a private VPS) and reads through Odoo's own ORM and API rather than bypassing it, so every answer respects the record rules and access groups already defined in Odoo. **Layers:** #### Odoo connector **Detail:** Connects via XML-RPC, JSON-RPC, or the Odoo external API using a dedicated read-focused API user, so queries run inside Odoo's own record rules and multi-company access controls. #### Semantic layer **Detail:** Maps mrp.*, stock.*, purchase.*, and quality.* models (including Studio-added fields) to business terms planners and buyers actually use, so "late orders" resolves correctly without a developer writing the domain filter each time. #### Model serving **Detail:** An open-weight model (Llama, Qwen, Mistral, or similar) served with vLLM or Ollama on customer-owned or customer-controlled GPUs, sized to Odoo's typical transaction volumes for mid-market manufacturers. #### Retrieval and agents **Detail:** Retrieval-augmented generation grounds answers in live ORM queries; agents that draft purchase follow-ups, quality alerts, or documentation require explicit human approval before any write-back. #### Governance and audit **Detail:** Every question and the generated domain filter are logged, mapped to the requesting Odoo user and their existing access groups, so the audit trail matches what Odoo itself would show. ## Deployment Options ### Air-gapped on-prem **Fit:** Manufacturers self-hosting Odoo behind their own firewall, especially those serving defense or export-controlled customers who cannot allow ERP data to reach any public API. **Detail:** The model, retrieval layer, and Odoo connector all run on customer-owned hardware with no outbound path; PostgreSQL access stays local to the network. ### Private or sovereign cloud **Fit:** Companies already running Odoo.sh or a managed VPS who want AI without operating GPUs themselves. **Detail:** Deployed in a dedicated tenant or VPC under the customer's own cloud agreement, isolated from Odoo's own SaaS infrastructure and from any shared multi-tenant AI service. ### Hybrid **Fit:** Groups with a mix of self-hosted plants and Odoo.sh-hosted subsidiaries after an acquisition. **Detail:** A central retrieval and governance layer connects to each Odoo instance through its own API user, with per-site data residency preserved rather than centralized into one database. ## Compliance ### Deployment inside the customer's own infrastructure means personal data in HR, CRM, or customer records never transits a third-party AI API, simplifying the lawful-basis and data-transfer analysis. **Framework:** GDPR / regional data protection ### Manufacturers who accepted "no cloud AI on our data" terms from an OEM customer can point to an architecture where the model runs on infrastructure they control, not a SaaS AI vendor's servers. **Framework:** Customer NDAs and flow-down clauses ### The AI layer is scoped to read-only access outside cardholder-data tables; payment records are excluded from retrieval by default. **Framework:** PCI DSS (where a payment module is active) ### Access logging, role mapping to existing Odoo security groups, and no external data egress give you concrete answers for a customer's vendor security questionnaire. **Framework:** SOC 2 expectations from downstream customers ## Integration Notes - Connects through Odoo's XML-RPC or JSON-RPC external API, or a dedicated REST module, using a scoped API user rather than a superuser account. - Domain filters are generated to match Odoo's own ORM search syntax, so results respect record rules, multi-company rules, and field-level access already configured. - Studio-added fields and custom modules are indexed from ir.model.fields so the assistant stays current after a functional consultant adds new fields. - Optional read-replica PostgreSQL connection for heavier analytical questions that would be slow through the ORM API alone. - Write-back actions (draft POs, quality alerts, follow-up emails) go through Odoo's own base_automation or a queued action a human approves, never a direct database write. - Version-aware: the connector is built and tested against your specific Odoo version (13 through 18) rather than assuming a generic schema. - Works with self-hosted, Docker-based, and Odoo.sh deployments; Odoo.sh's own infrastructure constraints (no root SSH) are handled through the standard API layer, not a workaround. ## Product Fit ### ERPray **Why:** Odoo's ORM-based data model, once mapped to a semantic layer, is a good fit for ERPray's grounded natural-language question answering and dashboards, especially for planners and buyers who don't want to learn Studio. ### Custom build **Why:** Manufacturers with heavy Studio customization or unusual custom modules often need a bespoke connector and agent set built around their specific fields rather than a generic template. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of Studio fields, custom modules, and relevant mrp.*/stock.*/purchase.* models - Access and security-group review - Priority use cases ranked by planner and buyer pain - Deployment option recommendation (on-prem, private cloud, hybrid) ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Working connector against a non-production Odoo instance - 3-5 use cases live for a pilot group - Accuracy review against known correct answers - Governance and logging validated against existing Odoo access groups ### Production **Duration:** 4-6 weeks **Deliverables:** - Cutover to the production Odoo instance with a read-only service account - Full audit logging in place - Runbook for adding new use cases without redeploying the whole system - Handoff documentation for your internal Odoo administrator ### Scale **Duration:** Ongoing **Deliverables:** - Expansion to additional companies or warehouses in a multi-entity instance - Additional agent use cases with write-back approval workflows - Model refresh as open-weight options improve - Quarterly review of usage and accuracy against real questions asked ## Buyer Questions - Does the AI layer read through Odoo's own ORM and record rules, or does it require a separate, wider database credential? - Where does the model actually run, and can you show us the network path to confirm no data leaves our environment? - How does the system handle Studio-added fields and custom modules without a developer re-mapping them by hand each time? - What happens when our next major-version upgrade changes field names or removes a model the AI relies on? - Is every generated query and answer logged against the requesting user's own Odoo access group? - What is the actual hardware requirement, and can it run on GPUs we already own or plan to buy anyway? - Can we start with question-answering only, with no write-back, before considering agents that draft or submit records? - What happens to the deployment if we ever cancel: do we keep the connector code, the prompts, and the logs? ## Faq ### Can AI work with a heavily customized Odoo instance? **Answer:** Yes, but the semantic layer has to be mapped to your actual fields, including anything added through Studio or a custom module, rather than assumed from a generic Odoo schema. That mapping is most of the discovery-phase work and is what determines whether answers are trustworthy. ### Does this replace Odoo's own AI features? **Answer:** No. Odoo's built-in AI (IAP suggestions, Spreadsheet AI) handles narrow, surface-level tasks and routes through Odoo's own cloud services. A private AI layer is for grounded, auditable question-answering and agents over your specific data, run on infrastructure you control. ### Is this only for large Odoo Enterprise deployments? **Answer:** No. It works with Odoo Community and Enterprise, self-hosted or on Odoo.sh, and scales down to a single-plant instance. The main requirement is a reasonably well-understood data model, which discovery work establishes regardless of company size. ### How do you handle multi-company and multi-warehouse access control? **Answer:** The connector uses a scoped API user and generates queries that respect Odoo's own record rules and company-level access, so a user only ever sees what their existing Odoo permissions already allow. Nothing bypasses Odoo's access model. ### What happens if an Odoo version upgrade changes the schema? **Answer:** Version upgrades are handled as a planned, tested step: the connector and semantic layer are validated against the new version before cutover, similar to how any other integration or customization is retested during an Odoo upgrade project. ### Can the AI write data back into Odoo, like creating a purchase order? **Answer:** It can draft records, such as a follow-up email or a quality alert, but any write-back requires explicit human approval through Odoo's own workflow or a reviewed queue. Nothing is written directly to the database without a person confirming it. ### What does this cost compared to a custom reporting project? **Answer:** Costs vary with the number of use cases, the deployment model, and how much Studio customization needs mapping, but the mechanism is comparable to a mid-sized custom reporting or BI project, with the AI layer covering a much wider range of ad hoc questions over time. ## Search terms Odoo AI, Odoo AI integration, AI for Odoo Manufacturing, on-prem AI for Odoo, Odoo copilot, Odoo generative AI, Odoo natural language query, private LLM Odoo, Odoo MRP AI, Odoo Studio AI, Odoo self-hosted AI, Odoo ORM AI agent --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json