What connecting AI to these systems means
A language model knows nothing about your customers, orders or stock. To be useful with them, it has to be given the relevant records at the moment of the request, and sometimes the ability to act. The connection is the software that does this: it takes a question or an event, fetches the right data from the CRM or ERP, passes it to the model with instructions, and handles what comes back.
Many CRM and ERP vendors now sell assistants of their own inside their products. Those are worth evaluating first for tasks that stay within one system. A custom connection earns its place when the task spans several systems, needs your own rules or must appear somewhere the vendor's assistant does not, such as your own portal or a messaging channel. Our comparison of a custom AI assistant and Copilot configuration looks at that choice.
Tasks worth connecting, from safest to riskiest
| Pattern | Example | Access needed | Risk |
|---|---|---|---|
| Answer questions about records | What did this customer order last quarter, and is anything overdue? | Read | Low, if permissions are respected |
| Summarize | A briefing on an account before a meeting, from notes, emails and orders | Read | Low |
| Draft for a person to send | A reply to a customer, a follow-up, a quote covering letter | Read | Low to moderate. A person reviews |
| Classify and route | Assign an incoming enquiry to the right team and priority | Read, plus a narrow write | Moderate |
| Extract and enter | Read a purchase order from an email and create a draft sales order | Write, as a draft | Moderate. Needs validation and review |
| Act across steps | Check stock, reserve it, create the order and notify the customer | Write | High. Needs limits, approval and an audit trail |
Start in the first three rows. They deliver value quickly, they cannot damage your data and they teach you how the model behaves with your records. Our AI use case assessment helps to rank candidates.
How the AI reaches your data
- 01
Use the documented interface
Connect through the API the vendor supports, on a plan that includes it. Reading the database directly bypasses the system's own permissions and rules.
- 02
Fetch at the moment of asking
For live facts such as balances and stock, the connection should query the system when the question is asked, so that answers are current.
- 03
Index where search is needed
For notes, emails and documents, a searchable index lets the model find relevant passages. The index must carry each item's access rules with it.
- 04
Give the model defined tools
Each thing the AI may do is a named function with fixed inputs, such as look up a customer or create a draft order. The model chooses among them. It is never handed open access.
- 05
Keep the answer tied to its source
Every figure in an answer should be traceable to the record it came from, with a link, so that a person can check it.
Models are poor at arithmetic over many rows and can misread large tables. For totals and comparisons, have the system or a query calculate the number, and let the model explain it.
Permissions: the AI inherits the user's rights
The most common design mistake is to connect the AI through one powerful account that can see everything. Any user can then ask for anything, and the careful permissions built into the CRM or ERP over years are bypassed in a sentence.
The safer rule is simple. When a person asks, the connection acts with that person's own rights and can retrieve only what they could open themselves. A sales representative asking about margins receives the same refusal from the assistant as from the system. Where a service account is unavoidable, the connection must apply the user's permissions itself before any record reaches the model. Have this tested deliberately, by people asking for things they should not see.
Know what leaves your systems
When a hosted model is used, the records included in a request are sent to the model provider for processing. That is manageable, and it needs to be a decision, not an accident.
- 01
Which provider and which service?
What to establishBusiness and consumer versions of the same product often have different data terms.
- 02
Is submitted data used to train models, and how long is it retained?
What to establishRead the provider's current terms for the specific service, and keep a copy.
- 03
Where is the data processed?
What to establishSome organizations and sectors have rules on location. Providers offer regional options to varying degrees.
- 04
What must never be sent?
What to establishDecide which fields are excluded or masked before the request is built, for example identity numbers, health details or payment data.
- 05
Who has reviewed this?
What to establishYour data protection adviser should see the design before personal data is involved, and customer contracts may contain their own restrictions.
A worked example
An account briefing for a distributor's sales team
This example is invented to show a first connection that only reads. A distributor's representatives prepare for customer visits by opening six screens in two systems.
- TaskOne request produces a briefing: recent orders, open quotes, overdue invoices, last three visit notes and any open complaints.
- DataOrders, invoices and stock come from the ERP through its interface, fetched live. Visit notes and complaints come from the CRM.
- PermissionsThe connection uses the representative's own sign-in for the CRM. The ERP is reached through a service account, with a rule that a representative receives only accounts assigned to them.
- LeavingCustomer names and order lines are sent to the model provider under its business terms. Bank details and credit limits are excluded before the request is built.
- CheckTotals are calculated by the ERP, not the model. Each line in the briefing links to its record. In a trial with 40 real accounts, managers find 3 briefings that omit a complaint, traced to complaints logged against a contact instead of the company.
Representatives get in two minutes what took twenty. The omissions found in the trial were a data habit, not a model fault, and fixing the habit improved the CRM for everyone.
Letting the AI change records
Writing is where value and risk both rise. Introduce it gradually, and design each write so that a mistake is small, visible and reversible.
Controlled writing
- Changes are created as drafts for a person to confirm
- Each tool does one narrow thing with validated inputs
- Limits exist on value, quantity and frequency
- Every action is logged with who asked and what was sent
- Irreversible steps, such as sending or paying, always need approval
Uncontrolled writing
- The AI can update any field on any record
- Actions are taken directly from text in incoming emails
- No record of what the AI did or why
- One account with administrator rights
- No way to switch the capability off quickly
Text arriving from outside, such as an email or a document, may contain instructions written to mislead a model. Treat it as data to be read, never as commands, and keep approval in front of any action it could trigger.
Connection checklist
AI to CRM and ERP connection checklist
0 of 11 checkedWhat to do next
Ask your sales or operations team which question they answer most often by opening several screens. That is your first candidate. Then ask whoever administers the CRM and ERP how another application may read from them.
Our AI integration services page explains how we build these connections, and the integration pages for Salesforce, HubSpot and Microsoft Dynamics 365 cover the system side. Tell us the task you have in mind.
Common questions
Is it safe to connect AI to our ERP?
It can be, when access is read-only at first, the user's own permissions are enforced, sensitive fields are excluded, the provider's data terms have been reviewed and every request is logged. The risks come from broad service accounts, uncontrolled writing and nobody checking what is sent where. Each of those is a design choice you can refuse.
Should we use the assistant built into our CRM instead?
Evaluate it first. A vendor's assistant already understands the product's data and permissions, and it may be included in your plan or available at extra cost. It is strongest for tasks inside that one product. A custom connection is worth considering when you need to combine several systems, apply your own rules or serve users outside the product.
Will the AI give wrong answers about our data?
It can, most often when the retrieved records are incomplete or when it is asked to calculate. Reduce the risk by fetching data live, having the system compute totals, showing the source of every figure and testing with real questions whose answers you know. People should treat answers as a fast first view that they can verify with one click.
Do we need to move our data into a new platform first?
Usually not. For most tasks the connection reads from your existing systems through their interfaces when a question is asked. A separate searchable index is useful for unstructured content such as notes and documents. Large data platform projects are rarely a precondition, and starting with one task shows what, if anything, is missing.
Can the AI update records automatically?
Technically yes, and it should be earned in stages. Begin with drafts that a person confirms, then allow narrow automatic changes where an error is cheap and visible, such as tagging or routing. Keep human approval for anything that commits money, stock or a message to a customer, and log every action so that it can be reviewed and reversed.