The compliance conversation, should not begin when something goes wrong. It should determine what you build in the first place.
This is written to be forwarded to whoever handles data protection, security or legal at your business before anything gets switched on rather than after.
Introduction
The best time to decide what an automated CRM system should be allowed to do is before it can do anything at all. Once customer data is connected, workflows are running and teams are relying on the output, decisions about access, retention and accountability become much harder to revisit.
So before switching anything on, get the people responsible for CRM, data, privacy, security and legal around the same questions. What customer data should the system actually need, what should always remain out of reach, how will you explain what it does, and what happens to that data when a customer asks you to delete it?
These are much easier questions to answer while the architecture still exists on a whiteboard. The aim is not to slow down automation, but to agree the boundaries early enough that you can build quickly inside them.
Step One: Map What Data Exists, Before Deciding What Gets Used
Before asking what an automated system should be allowed to see, get a clear picture of everything you actually hold. Not just what sits neatly in your CRM. Look across your CRM, customer data platform, support platform, billing system, product analytics, data warehouse, marketing tools, call transcripts, survey responses, spreadsheets and anything else that contains meaningful customer information.
For every source, record at least four things: What data does it contain?Why do you hold it? How sensitive is it? Which other systems can access it?
Pay particular attention to unstructured data. A structured CRM field called plan_type is relatively easy to classify. A support ticket is different. A customer may have mentioned a health condition, financial difficulty, family situation or other sensitive information halfway through a conversation without anybody ever deciding that this information should become available to a marketing workflow. The fact that two systems can be connected does not mean everything inside them should become part of the same customer context.
This matters because unmanaged data is already a measurable security problem. IBM reported that 35% of breaches in its research involved data stored in unmanaged data sources, or “shadow data”. Those environments create problems precisely because organisations cannot reliably classify, protect or manage the lifecycle of information they do not properly understand. So build the map first.
You cannot make a meaningful decision about what an automated CRM system should access until you know what access would actually expose.
Step Two: Decide What Any Future System Is Allowed To Touch
Once you can see what exists, decide explicitly what an automated system would be permitted to access.Do not default to everything that happens to be technically connected. A useful starting point is to classify data into simple access tiers.
Generally available: Information required for routine CRM activity, such as plan, account status or purchase history.
Purpose-specific: Information that can be accessed for particular workflows but should not automatically be available everywhere.
Targeting only: Information that can inform segmentation or scoring but should not normally appear directly in customer-facing copy.
Restricted: Information that should not be exposed to ordinary marketing automation or AI workflows without a specific justification and appropriate controls.
Then give the decision a named owner. Someone should be able to answer: who decided that this system could access this field, for this purpose?
Access control should be designed before deployment, not added once the system has already demonstrated why it was necessary.
Expert help is only a call away. We are always happy to give advice, offer an impartial opinion and put you on the right track. Book a call with a member of our friendly team today.
Step Three: Work Out How You Would Explain A Single Decision
Before anything automated exists, give yourselves a simple test. Pick a hypothetical customer and message. Then ask: Why did this person receive this message?
Could somebody answer clearly? Not “because the model selected them”. Not “because they met the criteria”. What criteria? Which data contributed? What business rule or prediction was involved? Was the outcome determined automatically or suggested to somebody who made the final decision? If the honest answer today is that an analyst built a segment six months ago and roughly remembers the logic, strengthen that process before adding another layer of automation on top.
Start documenting how important segments and decisions are created. You do not necessarily need to explain every mathematical operation inside a model. What matters is being able to reconstruct the logic that mattered to the outcome.
Step Four: Decide Whether You Need A DPIA Before You Build
This deserves its own step because it is much easier to assess risk while something is still a proposal.A Data Protection Impact Assessment, or DPIA, is not required for every AI experiment. But ICO guidance says one is required where processing is likely to result in a high risk to people’s rights and freedoms.
That can include systematic and extensive evaluation or profiling that produces legal or similarly significant effects, large-scale processing of special-category information, and some forms of systematic monitoring.
The ICO also flags characteristics common to sophisticated CRM and AI projects as potentially relevant to high-risk processing, including data matching, invisible processing, scoring, behavioural tracking and the use of new technologies.Even where a DPIA is not strictly required, the ICO describes it as good practice for major projects involving personal data.
So ask the question early. What personal information will this system process? What new inferences could it create? Who could be affected if it gets something wrong? What happens if a prediction is inaccurate? Could the customer reasonably expect this use of their data? Doing that assessment while the architecture can still change is considerably more useful than documenting the risks after deployment.
Step Five: Confirm Deletion Requests Actually Reach Everywhere
Trace, what actually happens when a customer asks for their data to be erased. Do not look at the process diagram. Test it.
Follow a request through your CRM, warehouse, support system, marketing platform, analytics environment and any downstream tools that have received that customer’s information. Then ask what happens once AI enters that architecture.
Could customer data have been copied into a vector database? A context store? A campaign-generation tool? A vendor’s logs? An agent’s memory? An evaluation dataset?
Can you identify those copies? Can you delete them where required? Can you demonstrate that you did?
The ICO is clear that individual data rights continue to apply wherever personal information is used across the AI lifecycle. Those rights can include erasure, restriction and objection depending on the circumstances. An AI integration does not make those obligations disappear. It can simply make the map of where the data travelled considerably more complicated.
So test the process while the architecture is still relatively simple.
Step Six: Decide What Gets Logged
There is another piece worth designing before launch: the audit trail. For meaningful automated CRM actions, decide what you need to retain to reconstruct what happened later.
That might include: Which system or agent took the action. Which customer data was available to it. Which segment, model or rule influenced the decision. Which version of the workflow or model was running. Whether a human reviewed or overrode it. What ultimately reached the customer.
You do not necessarily need to log everything forever. In fact, doing so could create its own data minimisation problem.
The objective is to retain enough information, for an appropriate period, to investigate a decision without creating an unnecessary second archive of customer data.
Ask legal, privacy and security to help define that balance before launch.
Step Seven: Evaluate Any Vendor That Will Touch Customer Data
By “vendor”, we do not just mean whichever company provides the AI model. In a modern CRM stack, customer data can pass through a long chain of third parties: your CRM and marketing automation platform, CDP, data warehouse, personalisation tools, customer support software, AI or model provider, agent platform, analytics tools and any service enriching your existing customer records.
The simplest way to decide who belongs in this conversation is to follow the data. If a third party will receive, store, enrich, analyse or act on customer information, you need to understand what happens to that information once it reaches them.
This is why vendor evaluation comes relatively late in this process. By this point, you already know what customer data you hold, which information an automated system should be allowed to access, what needs to remain restricted, how deletion should work and what audit trail you need. You can therefore evaluate a vendor against your requirements rather than allowing the capabilities of their product to define your boundaries for you.
Ask precise questions. What happens to data passed through their system? Where is it processed and stored? How long is it retained? Is any of it used to train or improve models beyond your account? Which subprocessors can receive it? Can access be restricted by field, role or workflow? What happens when one of your customers asks for their data to be deleted? Can you retrieve an audit trail showing what happened in a particular automated interaction?
The answers also need to cover what happens later. If you stop using the vendor, what happens to the customer data they hold? If they change their underlying model provider, add a new subprocessor or materially change how data is handled, how will you know?
A statement such as “we are GDPR compliant” should not end the conversation. What matters is whether the vendor can explain, specifically, how their product fits the data-handling rules your business has already agreed.
The Data Worth Watching At Every Stage
Compliance does not finish when the system goes live. Keep a small set of operational measures that tell you whether the controls you designed are actually working.
Track deletion completion time: how long a request really takes to propagate across every relevant system.
Track deletion failures: systems where the request failed, stalled or needed manual intervention.
Track explainability coverage: sample customer-facing automated decisions and ask whether somebody can reconstruct why each one happened.
Track restricted-data access: how often sensitive or restricted data is accessed by automated workflows and whether that access matches the purpose originally approved.
Track new data destinations: every new system, vendor, model or context store receiving customer information.
Track human overrides and escalations where automated decision-making is involved.
And track governance drift: changes to prompts, models, data sources, integrations or workflows that mean the original assessment no longer accurately describes the system that is actually running.
That last one matters. Compliance documentation has a habit of describing the system that existed on launch day while the production system quietly evolves around it. Your data map, DPIA, vendor assessment and access decisions should change when the system materially changes.
Knowing what data can be used means teams can move without renegotiating the boundary every time. Knowing what must be logged makes investigations faster. Having deletion processes that actually work makes adding another system less frightening. Knowing your vendor requirements makes procurement more precise. The objective is not to create enough compliance paperwork that nothing can ever go wrong. It is to make deliberate decisions about customer data while those decisions are still cheap and easy to change.
Get In Touch
Our friendly team are always on hand to answer questions, troubleshoot problems and point you in the right direction.
