Why AI Should Not Write SQL Against ERP Databases

The article argues that allowing AI to generate raw SQL queries against ERP databases is a poor architectural choice, despite being a common demo technique. It explains that ERP data is governed by complex business rules, user permissions, and audit requirements that are not reflected in the database schema, making direct SQL access unsafe. The recommended approach is to use a governed semantic layer that routes queries through the ERP system's own permission and business logic controls.

Most AI + ERP demos start with the same pattern: 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 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: 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. 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. A governed semantic layer changes the shape of the problem. Instead of exposing physical tables, the system exposes query models: 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 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: In other words, the tool should not simply be a protocol wrapper around database access. It should be a governed execution boundary. 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: 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. 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: This is a more honest contract than "the model can write any SQL." It allows useful business analysis while keeping unsupported requests visible. I am applying this design through Foggy Odoo Bridge. The current Odoo direction is: 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. For ERP AI, I think the safe default should be: 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. 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.