{"slug": "why-ai-should-not-write-sql-against-erp-databases", "title": "Why AI Should Not Write SQL Against ERP Databases", "summary": "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.", "body_md": "Most AI + ERP demos start with the same pattern:\nFor a toy database, this is fine.\nFor an ERP system, it is a weak default.\nERP 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.\nThe question should not be:\nCan the model generate SQL?\nThe better question is:\nCan the system answer business questions while preserving the governance rules that already protect the ERP?\nThat difference matters.\nThe fastest demo is often the most dangerous production design.\nIf the model sees a database schema, it can produce impressive results quickly:\nSELECT ...\nFROM sale_order\nJOIN res_partner ...\nBut an ERP database schema is not the real product boundary.\nThe real boundary lives higher up:\nA generated SQL string does not naturally carry that context.\nThis is why \"LLM writes SQL against the ERP database\" is a useful demo technique, but a poor default architecture.\nWhen an AI client generates raw SQL against an ERP database, several boundaries become fragile.\nFirst, 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.\nSecond, business semantics are not obvious from column names. A field called state\nmight mean a sales lifecycle state, an invoice state, a delivery state, an approval state, or a local customization.\nThird, 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.\nFourth, 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.\nFor ERP AI, \"supports arbitrary SQL\" is not the strongest promise.\nA better promise is:\nThe system can answer useful business questions through governed query paths, and it can clarify or reject requests when the boundary is not safe.\nA governed semantic layer changes the shape of the problem.\nInstead of exposing physical tables, the system exposes query models:\nThe model no longer needs to discover the ERP from raw schema. It receives a controlled business interface.\nFor example, in an Odoo context, a user should ask:\nShow me the top 5 customers by total sales revenue in the last 30 days.\nThe 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.\nThe model should not be invited to use raw tables as its primary interface.\nMCP gives AI clients a standard way to call tools. That is valuable.\nBut MCP alone does not make a tool safe.\nAn MCP tool can expose raw SQL. It can ignore permissions. It can leak internal errors. It can return data the user should never see.\nFor enterprise data, governance has to live inside the tool boundary:\nIn other words, the tool should not simply be a protocol wrapper around database access.\nIt should be a governed execution boundary.\nOdoo makes the problem concrete.\nAn Odoo user is not just a PostgreSQL user. Odoo controls access through model permissions, record rules, company access, and field boundaries.\nIf an AI tool bypasses Odoo and directly queries PostgreSQL, it risks bypassing the system that administrators actually use to govern data access.\nThe safer route is:\nThe important point is not that Odoo is the only target.\nThe important point is that the host system should remain the authority for permissions and business context.\nThat same principle applies to other business systems as well.\nAnother mistake is to measure progress by asking:\nHow much SQL can the AI generate?\nFor governed business data, a more useful question is:\nWhich classes of business questions can the system answer safely, and where does it clarify or reject?\nIn Foggy, the query capability is intentionally layered:\nThis is a more honest contract than \"the model can write any SQL.\"\nIt allows useful business analysis while keeping unsupported requests visible.\nI am applying this design through Foggy Odoo Bridge.\nThe current Odoo direction is:\nThe intended message is not:\nAI directly queries the Odoo database.\nThe intended message is:\nAI clients query Odoo business data through governed semantic tools while Odoo permissions remain in control.\nThat distinction is the product.\nFor ERP AI, I think the safe default should be:\nThe goal is not to make AI look powerful in a demo.\nThe goal is to make AI data access usable inside real enterprise boundaries.\nFoggy Odoo Bridge Community:\nhttps://apps.odoo.com/apps/modules/17.0/foggy_mcp\nFoggy Odoo Bridge Pro:\nhttps://apps.odoo.com/apps/modules/17.0/foggy_mcp_pro\nCommunity repo:\nhttps://github.com/foggy-projects/foggy-odoo-bridge\nProduct page:\nDocs:\nhttps://foggy-projects.github.io/foggy-data-mcp-docs/\nI am especially interested in feedback from Odoo implementers, ERP engineers, and developers building MCP tools for business data.", "url": "https://wpnews.pro/news/why-ai-should-not-write-sql-against-erp-databases", "canonical_source": "https://dev.to/foggy-projects/why-ai-should-not-write-sql-against-erp-databases-1ef8", "published_at": "2026-05-22 13:16:03+00:00", "updated_at": "2026-05-22 13:36:32.606454+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "enterprise-software", "data"], "entities": ["ERP", "LLM", "SQL"], "alternates": {"html": "https://wpnews.pro/news/why-ai-should-not-write-sql-against-erp-databases", "markdown": "https://wpnews.pro/news/why-ai-should-not-write-sql-against-erp-databases.md", "text": "https://wpnews.pro/news/why-ai-should-not-write-sql-against-erp-databases.txt", "jsonld": "https://wpnews.pro/news/why-ai-should-not-write-sql-against-erp-databases.jsonld"}}