ERP Chatbot Architecture: Grounding, Permissions, and Audit
An ERP chatbot architecture has to solve three problems at once, or it is not ready for production regardless of how well the demo goes: grounding, so answers come from live, verified ERP data rather than the model's general knowledge or a stale cache; permissions, so the chatbot never shows a user data they could not already see in SyteLine or Infor LN directly; and audit, so every answer can be traced back to the query, the source records, and the user who asked. Most first-generation ERP chatbots get grounding right and skip the other two, which is why they clear a proof of concept and then stall in security review. This guide lays out the architecture that clears all three.
Grounding: Retrieval Plus Live Query, Not a Fine-Tuned Model
Do not attempt to fine-tune a model on your ERP data expecting it to memorize current facts; ERP data changes constantly and a fine-tuned model's knowledge is frozen at training time. Instead, ground the chatbot with two complementary mechanisms: a retrieval layer over relatively static reference content, like policy documents, item descriptions, and process documentation, and live query execution through the ERP's integration layer for anything transactional, like order status, inventory, or open balances. Route each user question to the correct mechanism, and when the chatbot is uncertain which applies, have it ask rather than guess. Never let the chatbot answer a transactional question from memory of a prior conversation turn, since the underlying record may have changed since.
- Retrieval layer for static reference content: policies, item descriptions, documented processes
- Live IDO, ION, or M3 API calls at query time for anything transactional: orders, inventory, balances
- Explicit routing logic deciding which mechanism a question needs, defaulting to a clarifying question
- Never answer a transactional question from earlier conversation memory without a fresh live query
Permissions: Inheriting the ERP's Security Model, Not Reinventing It
The chatbot must never become a way to see data a user's ERP role would not otherwise expose. The correct pattern executes every live query under the requesting user's own ERP-scoped credentials, or at minimum replicates their exact security group and site restrictions in the service account used, rather than running everything through a single broad chatbot service account and hoping the prompt filters correctly. A prompt-level instruction to only show authorized data is not a security control, since it can be bypassed by rephrasing the question, and any security reviewer worth the title will find that gap in the first session. Test this explicitly: have a user with restricted access try to extract data outside their scope through creative phrasing, and confirm the system blocks it at the query layer, not the prompt layer.
- Execute live queries under the user's own ERP-scoped permissions or an equivalent restricted service account
- Never rely on prompt instructions alone to enforce data access restrictions
- Test explicitly with restricted-access users attempting creative rephrasing to bypass scope
- Apply the same site, plant, and business unit filtering the ERP client itself would apply
Audit: Making Every Answer Reconstructable
Log the user, the question as asked, the routing decision, every tool or query call made with its parameters and response, and the final answer given, tied together by a correlation ID and retained to the same standard as other ERP audit logs. This is not optional for regulated manufacturers under AS9100 or CMMC, but it is good practice for any ERP chatbot, because the first time a chatbot gives a wrong answer that affects a business decision, someone will ask exactly what it was told and why it said what it said. Build a simple internal tool that lets your IT or quality team pull the full trace for any conversation by correlation ID, rather than needing to query raw logs under time pressure.
Handling Multi-Turn Conversations Without Losing Grounding
Multi-turn conversations are where chatbots quietly drift from grounded to hallucinated, because each turn's context window includes prior answers the model may treat as established fact even if they were wrong or have since changed. Re-verify any transactional fact referenced in a follow-up question rather than trusting it from earlier in the conversation, and cap how far back conversational context extends before requiring a fresh grounding check. This costs a small amount of latency and API calls, and it is the difference between a chatbot that stays accurate through a ten-turn conversation and one that compounds an early error across the rest of the session.
How Netray Architects ERP Chatbots
Netray builds ERP chatbots with permissions and audit designed in from the architecture diagram, not retrofitted after a security review flags them, because we have seen how expensive that retrofit gets once a chatbot is already in daily use. Our ERPray product runs on this exact architecture, live IDO and ION grounding for SyteLine and Infor LN, user-scoped permission enforcement at the query layer, and full conversation audit trails, so you can deploy a chatbot your security and quality teams sign off on rather than one that needs justifying after the fact. We also run the explicit permission-bypass testing as a standard part of every chatbot delivery.
Frequently Asked Questions
Should an ERP chatbot be built on a fine-tuned language model?
Generally no, for factual grounding. Fine-tuning bakes in knowledge frozen at training time, and ERP data changes constantly, so a fine-tuned chatbot will confidently give stale answers. Ground the chatbot instead with retrieval over static reference content and live query execution through the ERP's integration layer for transactional data like orders, inventory, and balances, verified fresh on every relevant question.
How do you prevent an ERP chatbot from leaking unauthorized data?
Execute every live query under the requesting user's own ERP-scoped permissions, or an equivalent restricted service account matching their security group and site access, rather than a single broad service account with prompt-level filtering. Prompt instructions are not a security control and can be bypassed by rephrasing. Test explicitly with restricted-access users attempting to extract out-of-scope data through creative questions.
What should an ERP chatbot log for audit purposes?
Log the requesting user, the question as asked, the routing decision made, every tool or query call with its parameters and response, and the final answer, all tied together by a correlation ID and retained to the same standard as other ERP audit logs. This lets your team reconstruct exactly why the chatbot gave a specific answer if it is ever questioned, which regulated manufacturers under AS9100 or CMMC should treat as a requirement, not an enhancement.
Key Takeaways
- 1Grounding: Retrieval Plus Live Query, Not a Fine-Tuned Model: Do not attempt to fine-tune a model on your ERP data expecting it to memorize current facts; ERP data changes constantly and a fine-tuned model's knowledge is frozen at training time. Instead, ground the chatbot with two complementary mechanisms: a retrieval layer over relatively static reference content, like policy documents, item descriptions, and process documentation, and live query execution through the ERP's integration layer for anything transactional, like order status, inventory, or open balances.
- 2Permissions: Inheriting the ERP's Security Model, Not Reinventing It: The chatbot must never become a way to see data a user's ERP role would not otherwise expose. The correct pattern executes every live query under the requesting user's own ERP-scoped credentials, or at minimum replicates their exact security group and site restrictions in the service account used, rather than running everything through a single broad chatbot service account and hoping the prompt filters correctly.
- 3Audit: Making Every Answer Reconstructable: Log the user, the question as asked, the routing decision, every tool or query call made with its parameters and response, and the final answer given, tied together by a correlation ID and retained to the same standard as other ERP audit logs. This is not optional for regulated manufacturers under AS9100 or CMMC, but it is good practice for any ERP chatbot, because the first time a chatbot gives a wrong answer that affects a business decision, someone will ask exactly what it was told and why it said what it said.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
AI Agent Security Review Checklist
A 30-point security review for AI agents that can call tools and write to business systems, covering identity, permissions, prompt injection, data handling, and audit.
Free ToolAI Pilot-to-Production Readiness Assessment
Score your AI pilot against the ten gates that decide whether it reaches production, and get a prioritized list of the gaps blocking deployment.
Free ToolERP AI Copilot ROI Calculator
Turn user count, query volume, and time saved per question into a monthly savings, license cost offset, and payback period for an ERP AI copilot.
Terms used in this article
Building an ERP chatbot that needs to clear security review, not just a demo? Netray designs the grounding, permissions, and audit layers before the first prompt gets written.
Related Resources
Human-in-the-Loop Design for ERP AI
Human-in-the-loop design for ERP AI: where to place approvals, confidence thresholds, and audit trails so agents act safely inside SyteLine, LN, and M3.
Infor SyteLineIntegrating an AI Copilot with SyteLine: A Technical Guide
Integrate an AI copilot with SyteLine safely: IDO access patterns, ION API touchpoints, Mongoose hooks, and read-only vs write guardrails that hold up.
AI & AutomationNatural Language Reporting Over Your ERP: A Guide
Build natural language reporting over your ERP the safe way: text-to-SQL guardrails, semantic layers, and why raw text-to-SQL fails on real ERP schemas.