By Peter Pandiraj.M, Tech Head, 25 years of experience. Published 4 November 2026.
Start with one process
Good first use cases are frequent, time consuming and easy to check. Examples include summarising records, classifying requests, extracting details from documents, drafting replies and flagging unusual entries.
Avoid starting with decisions that are costly to reverse, such as payments or automatic approvals.
Check your data and access
AI can only work with data it can reach and understand. Before building, find out where the data lives, whether it is reasonably consistent, and how it can be accessed through an API or database layer.
If key information is on paper or spread across spreadsheets, digitising that process may be the better first step. Our AI readiness calculator can help you with a quick check.
Keep permissions and privacy in place
An AI assistant should never see more than the user asking the question is allowed to see. Apply your existing ERP roles to every AI request.
Decide what data may be sent to an external AI service, review the provider's data terms, and limit sensitive fields where possible. Some situations may call for a more private deployment.
Keep a human in the loop
Treat AI output as a draft or suggestion, especially at first. Show the source records behind an answer, let staff edit or reject results, and keep a log of what was suggested and who approved it.
Autonomy can be increased later for low-risk steps once the results have proven reliable.
Run a small pilot and measure it
Pick one team and one workflow. Record the current time per task and error rate, then compare them after the pilot, along with how often staff accept or correct the AI output.
Those numbers will tell you whether to expand, adjust or stop, and they make the next business case much easier.
A simple rollout path
1. Choose one process and define success. 2. Confirm data access and permissions. 3. Build a review-first pilot. 4. Measure with real users. 5. Expand to related workflows only when the first one works.
Good first use cases by department
Purchasing: extract details from supplier quotes and invoices, then match them to orders for someone to review.
Sales and service: summarise customer history before a call, draft replies and sort incoming requests by topic and urgency.
Finance: flag unusual entries and prepare plain-language explanations of exceptions for review. A person should still make the final decision.
Management: ask questions about reports in plain language, with answers linked to the underlying data so that they can be checked.
How AI connects to an ERP
The usual pattern is a small service between the ERP and the AI model. It checks who the user is, fetches only the records they may see, sends the relevant text to the model and returns the answer with its sources.
Keeping this layer separate means the ERP itself needs few changes, and the AI model can be replaced later without rebuilding everything. If your ERP has no API, a read-only database connection or scheduled export may be an option, subject to its terms and technical limits.
Risks to plan for
AI models can produce confident answers that are wrong. Reduce the risk by using source data, showing references and requiring review for anything important.
Prompt injection is another risk: text inside a document or email may try to instruct the AI to do something else. Treat that content as data, limit what the AI can do and require approval for actions that change records.
Costs also need attention. Usage-based pricing can grow with volume, so measure it during the pilot and set limits.
Build, buy or wait?
Many ERP vendors now offer AI features, so check what your current product includes first. These can be enough for common tasks.
A custom layer makes more sense when you need to combine several systems, follow your own process or apply specific data controls. If your process is still undocumented or your data unreliable, it can be better to fix that first. The cleanup will pay off with or without AI.
Questions to answer before you start
Which single process are we improving, and how long does it take today? Who checks the output? What is the cost of a mistake? What data is needed, and are we allowed to use it in this way? How will we know the pilot worked, and what would make us stop?