Connecting an AI assistant to your CRM is the difference between an assistant that writes about your business and one that works in it. “Which contacts opened the last newsletter but never bought anything?” stops being a question you answer by exporting a CSV.
It is also the moment personal data leaves your platform and reaches a third party. That deserves more thought than a toggle. Here is how to do it properly.
What MCP is, briefly
MCP stands for Model Context Protocol. It is an open standard that lets an AI assistant use a real system: not by scraping a screen or guessing at an API, but by calling defined actions that the system itself exposes. Your CRM says “here are the things you may do”, and the assistant does them.
The practical consequence is that the assistant is limited by what your system offers and by what your account is allowed to do. That is the lever you pull.
Step one: give it its own account
Do not connect the assistant as yourself. Create a separate user, give it the narrowest role that still does the job, and generate credentials for that user.
Start read-only. Genuinely. Spend a week asking questions and reading answers before you allow anything that writes. Most of the value people get from this turns out to be reading: finding segments, spotting patterns, pulling numbers that would otherwise take an afternoon.
Step two: make it revocable
Use credentials you can withdraw in one click without changing your own password. Application passwords do exactly this. If something feels wrong, you revoke it, the connection dies, and you have lost nothing.
Write down where that button is before you need it.
Step three: keep a human on anything irreversible
Let the assistant draft and propose. You approve anything that sends an email, charges a card, deletes a record or changes a price.
This is not because the assistant is careless. It is because instructions are ambiguous and consequences are asymmetric. “Clean up the duplicate contacts” is a sentence with several reasonable interpretations, and one of them deletes something you wanted.
Step four: the GDPR part
If personal data reaches your AI supplier, that supplier is a processor for you. That means:
- Use a business plan. Free and consumer plans do not come with a data processing agreement, and some train on your input.
- Check that training on your data is off, and that it is off contractually and not just as a setting.
- Add the supplier to your processing register, and mention it in your privacy statement.
- Apply data minimisation to the connection itself. An assistant that can read every contact is doing more than an assistant that can read one segment.
The risk most people miss
It is not that the model goes rogue. It is prompt injection.
Your assistant reads text that other people wrote: support tickets, form submissions, product reviews, community posts. If someone puts instructions in that text, and your assistant has write access, those instructions are now sitting in the same context as your own.
This is a real vector, not a theoretical one, and it is the strongest argument for the previous three steps. Read-only access removes most of the sting. Human approval on anything that sends or deletes removes most of the rest. A narrow role removes what is left.
What good looks like after a month
A dedicated user with a limited role. Read access to your CRM, your project boards and your help desk. Write access to exactly the things you have seen it get right repeatedly, and nothing else. A habit of reading what it proposes before you approve it. And a note in your processing register that says which supplier, on which plan, since when.
That setup is useful every day and defensible if anyone ever asks.
See how the connection works on Autorespond Hub, where it is included in every package.