Most AI + ERP demos start with the same pattern:
- Connect an LLM to a database.
- Show it the schema.
- Ask it to generate SQL.
- Execute the SQL.
- Summarize the rows.
For a toy database, this is fine.
For an ERP system, it is a weak default.
ERP data is not just tables and columns. It is protected by business semantics, user permissions, record rules, company boundaries, field visibility, implementation-specific conventions, and audit requirements.
The question should not be:
Can the model generate SQL?
The better question is:
Can the system answer business questions while preserving the governance rules that already protect the ERP?
That difference matters.
The demo path is not the production path
The fastest demo is often the most dangerous production design.
If the model sees a database schema, it can produce impressive results quickly:
SELECT ...
FROM sale_order
JOIN res_partner ...
But an ERP database schema is not the real product boundary.
The real boundary lives higher up:
- which user is asking;
- which business object the user is allowed to access;
- which record rules apply;
- which companies the user can see;
- which fields are sensitive;
- which workflow states have business meaning;
- which metric definition is correct;
- which query should be rejected instead of guessed.
A generated SQL string does not naturally carry that context.
This is why "LLM writes SQL against the ERP database" is a useful demo technique, but a poor default architecture.
Raw SQL skips too many boundaries
When an AI client generates raw SQL against an ERP database, several boundaries become fragile.
First, user permissions are usually not encoded in the schema. A table name does not tell the model which user can see which records, which company boundary applies, or which fields are hidden by business policy.
Second, business semantics are not obvious from column names. A field called state might mean a sales lifecycle state, an invoice state, a delivery state, an approval state, or a local customization.
Third, audit becomes weak. If the main artifact is a generated SQL query, the system still has to explain why that query was allowed, what business model it mapped to, which permission rules were applied, and whether the returned result was within the user's access boundary.
Fourth, the interface tends to expand in the wrong direction. Once arbitrary SQL is accepted, users will ask for joins, subqueries, CTEs, window functions, unsupported tables, and "just one more column." The capability looks stronger on paper, while the safety boundary becomes less clear.
For ERP AI, "supports arbitrary SQL" is not the strongest promise.
A better promise is:
The system can answer useful business questions through governed query paths, and it can clarify or reject requests when the boundary is not safe.
ERP AI needs semantic models
A governed semantic layer changes the shape of the problem.
Instead of exposing physical tables, the system exposes query models:
- business fields with human-readable meaning;
- dimensions and measures;
- supported filters and aggregations;
- known relationships;
- metric definitions;
- permission and field boundaries;
- safe execution routes.
The model no longer needs to discover the ERP from raw schema. It receives a controlled business interface.
For example, in an Odoo context, a user should ask:
Show me the top 5 customers by total sales revenue in the last 30 days.
The system should route that through a governed sales query model, apply the effective Odoo user's permissions, execute within the supported query capability, and return structured results with evidence.
The model should not be invited to use raw tables as its primary interface.
MCP is useful, but protocol is not enough
MCP gives AI clients a standard way to call tools. That is valuable.
But MCP alone does not make a tool safe.
An MCP tool can expose raw SQL. It can ignore permissions. It can leak internal errors. It can return data the user should never see.
For enterprise data, governance has to live inside the tool boundary:
- authentication and tenant context;
- user or service-principal binding;
- permission projection from the host system;
- semantic model selection;
- query validation;
- result sanitization;
- audit evidence;
- fail-closed behavior when scope is unclear.
In other words, the tool should not simply be a protocol wrapper around database access.
It should be a governed execution boundary.
Odoo is a good case study
Odoo makes the problem concrete.
An Odoo user is not just a PostgreSQL user. Odoo controls access through model permissions, record rules, company access, and field boundaries.
If an AI tool bypasses Odoo and directly queries PostgreSQL, it risks bypassing the system that administrators actually use to govern data access.
The safer route is:
- MCP clients connect through Odoo-issued access.
- Query model visibility follows Odoo-side access boundaries.
- Odoo rules are applied before query execution.
- Multi-company boundaries are preserved.
- Field boundaries are handled before results reach the AI client.
- Raw database access is kept out of the model's hands.
The important point is not that Odoo is the only target.
The important point is that the host system should remain the authority for permissions and business context.
That same principle applies to other business systems as well.
Capability should be layered, not unlimited
Another mistake is to measure progress by asking:
How much SQL can the AI generate?
For governed business data, a more useful question is:
Which classes of business questions can the system answer safely, and where does it clarify or reject?
In Foggy, the query capability is intentionally layered:
- standard DSL-style queries for detail rows, filters, aggregations, TopN, and trends;
- controlled expression-style queries for comparisons, validations, and audit checks;
- staged query patterns for ratios, cumulative contribution, SLA-style checks, and funnel-like calculations;
- governed small-result secondary analysis;
- clarification when time range, metric definition, grain, or business rule is missing;
- rejection when the request asks for prediction, causal claims, physical table access, permission bypass, or write-back actions.
This is a more honest contract than "the model can write any SQL."
It allows useful business analysis while keeping unsupported requests visible.
What this means for Odoo
I am applying this design through Foggy Odoo Bridge.
The current Odoo direction is:
- Odoo 17 Community and Enterprise;
- Odoo.sh or On Premise as the practical deployment targets;
- Community edition for lightweight MCP / semantic-query evaluation;
- Pro edition for the in-Odoo AI Chat experience, curated query models, audit/export workflows, and supported production adoption;
- standalone MCP access without requiring OpenAI or Anthropic SDKs in the Odoo environment;
- optional built-in AI Chat when an administrator chooses to configure an LLM provider.
The intended message is not:
AI directly queries the Odoo database.
The intended message is:
AI clients query Odoo business data through governed semantic tools while Odoo permissions remain in control.
That distinction is the product.
The safe default
For ERP AI, I think the safe default should be:
- Do not expose unrestricted database schema to the model.
- Do not make model-generated SQL the primary interface.
- Expose governed semantic tools instead.
- Preserve host-system permissions before query execution.
- Return structured results with evidence.
- Clarify or reject when the governance boundary is not clear.
The goal is not to make AI look powerful in a demo.
The goal is to make AI data access usable inside real enterprise boundaries.
Links
Foggy Odoo Bridge Community:
https://apps.odoo.com/apps/modules/17.0/foggy_mcp
Foggy Odoo Bridge Pro:
https://apps.odoo.com/apps/modules/17.0/foggy_mcp_pro
Community repo:
https://github.com/foggy-projects/foggy-odoo-bridge
Product page:
Docs:
https://foggy-projects.github.io/foggy-data-mcp-docs/
I am especially interested in feedback from Odoo implementers, ERP engineers, and developers building MCP tools for business data.
