AI can create noticeable advantages in customer relationship management. Conversation notes can be summarized faster, service requests classified better, and sales activities prepared in a more targeted way. At the same time, a CRM processes a particularly large amount of information about customers, contacts, prospects, partners, and employees.
Especially in grown organizations with numerous users, roles, integrations, and data sources, it is therefore not sufficient to technically activate individual AI functions. Companies must be able to explain in a traceable way which data is processed, where it is transferred, who bears responsibility, and how faulty results are detected.
These questions come not only from data protection authorities. Customers, purchasing departments, corporate groups, insurers, auditors, works councils, and internal audit also increasingly demand robust answers.
Professional AI governance must not block innovation. But it must prevent a quick test from becoming an uncontrolled permanent solution.
The pragmatic path therefore does not consist of circumventing data protection and governance. It consists of creating a limited, controlled, and measurable entry from which a sustainable governance structure can be developed step by step.
Why AI governance is becoming an operational topic
AI has long ceased to be a purely innovation topic in companies. According to Eurostat, in 2025 20 percent of companies in the European Union with at least ten employees already used AI technologies. In 2024, it was still 13.5 percent. Among large companies, the share was already around 55 percent in 2025. Applications for the analysis and generation of language spread particularly strongly – precisely those functions that are also used in CRM, sales, and service processes. (European Commission)
Statistics: AI use in European companies
| Metric | Value | Significance for CRM managers |
|---|---|---|
| Companies using AI 2023 | 8,1 % | AI was often still limited to individual tests or business units. |
| Companies using AI 2024 | 13,5 % | Use spread significantly beyond IT and innovation teams. |
| Companies using AI 2025 | 20,0 % | AI is increasingly becoming part of regular business processes. |
| Large companies using AI 2025 | 55,03 % | In larger organizations, AI becomes a governance and scaling topic. |
| Companies using AI to analyze written language 2025 | 11,8 % | Text analysis directly affects emails, conversation notes, and service requests. |
| Companies using AI to generate written or spoken language 2025 | 8,8 % | Generative AI is increasingly used for communication and documentation. |
Source: Eurostat. The statistical company sizes refer to the number of employees and not to the number of CRM users. (European Commission)
As adoption increases, expectations change. An informal test with synthetic sample data is assessed differently than an assistant permanently integrated into the CRM. As soon as real customer data is processed, results are stored, or recommendations are used for operational decisions, a regular business process arises.
This process must not only work. It must also be explainable, controllable, and documentable.
The GDPR and the EU AI Act must be considered together
The General Data Protection Regulation and the EU AI Act pursue different but interconnected goals. The GDPR governs the processing of personal data regardless of which technology is used for it. The AI Act pursues a risk-based approach to the development and use of certain AI systems.
The AI Act entered into force on 1 August 2024. Prohibitions of certain AI practices and the requirements for AI literacy have applied since 2 February 2025. Governance rules and requirements for general-purpose AI models have applied since 2 August 2025. Further requirements take effect in a staggered manner; following the political agreement to simplify the AI Act, certain high-risk requirements are to apply from December 2027 and August 2028 respectively. (Europe’s Digital Strategy)
For companies, this staggering does not mean that they can defer their governance until the last regulatory deadline. Customer questionnaires, data protection reviews, information security assessments, and contract negotiations are already taking place today.
The company must also, independently of the AI Act, meet the requirements of the GDPR. These include, among others, purpose limitation, data minimization, transparency, lawfulness, storage limitation, security, and accountability. Personal data must not be transferred to an AI service simply because the corresponding function is technically available. (EUR-Lex)
Not every AI function in the CRM carries the same risk
The risk of an AI use case does not depend solely on the technology used. What is decisive is the purpose, the processed data, the degree of automation, and the effects of the result.
An assistant that summarizes an internal conversation note is to be assessed differently than a system that automatically decides which customers do not receive an offer. A suggestion for the next sales activity is to be classified differently than an automatic creditworthiness or risk assessment. A service classification by product group is to be treated differently than a prioritization based on presumed personal characteristics.
Special attention is required when AI significantly influences a decision that can have legal or similarly significant effects on a person. Article 22 GDPR contains special provisions for this on solely automated decisions. The European Court of Justice has also clarified that an automatically generated probability value can be relevant if a subsequent decision is significantly based on this value. (EUR-Lex)
For governance, a risk-based assessment is therefore sensible. A text draft with subsequent human review needs different controls than an automated prioritization that triggers immediate operational consequences.
The first problem: companies do not know their entire AI usage
AI rarely enters the organization exclusively through a central rollout project. New functions become available through CRM extensions, office applications, marketing platforms, meeting assistants, service tools, or individual user accounts.
This creates parallel usage scenarios. Alongside approved applications, personal test accounts exist. Software providers activate new AI functions within existing contracts. Employees transfer conversation notes or emails to generative AI tools because it allows them to work faster.
A policy alone does not solve this problem. A prohibition without a practicable alternative often leads to usage simply continuing invisibly.
The first governance step is therefore transparency. A company must know which AI systems are used, what purpose they serve, which data they process, and who is responsible for them.
Data minimization must come before pseudonymization
A fundamental mistake is to first transfer a complete CRM record to an AI service and then think about protective measures afterward. The better path begins with the question of which information is actually necessary for the respective use case.
An assistant for drafting a follow-up email may need the conversation topic, the agreed next steps, and some approved product information. But it does not automatically need the contact’s private mobile number, historical invoice data, internal creditworthiness attributes, or all previous service escalations.
Data minimization therefore does not mean only hiding individual fields. The entire amount of information must be tailored to the specific purpose.
In technical implementation, allowlists have proven effective. They explicitly define which CRM fields may be passed to a specific AI function. All other data remains blocked by default.
The guiding question is not:
Which data should we better remove?
But rather:
Which data does the AI demonstrably need for this specific purpose?
Distinguishing anonymization, pseudonymization, and masking
The terms anonymization, pseudonymization, and masking are often equated in everyday business. Legally and technically, however, there are considerable differences.
The GDPR defines pseudonymization as processing in which personal data can no longer be attributed to a specific person without additional, separately kept information. Pseudonymized data, however, remains personal data. It continues to be subject to the GDPR. (EUR-Lex)
Only truly anonymized data falls outside the scope of European data protection law. For this, identification must be sufficiently ruled out, taking the specific context into account. (European Data Protection Board)
| Method | Meaning | Does the GDPR still apply? | Example from the CRM |
|---|---|---|---|
| Data minimization | Only the information necessary for the purpose is processed. | Ja | The AI receives only the conversation reason and next steps, not the complete customer file. |
| Masking | Individual values are removed or made unrecognizable. | As a rule, yes | An email address is replaced with [EMAIL]. |
| Pseudonymization | Direct identifiers are replaced; a separate mapping remains possible. | Ja | “Max Mustermann” becomes “Contact-84721.” |
| Anonymization | Identification is no longer possible with reasonably usable means. | No, if it is actually effective | Aggregated analysis of processing times without identifiable individuals. |
| Synthetic data | Artificially generated data sets replicate structures without depicting real people. | Only if there is no connection to real people | Test data set for developing an AI workflow. |
Why true anonymization is difficult in an operational CRM
Removing names, phone numbers, and email addresses does not automatically result in anonymous data. People can also remain indirectly identifiable based on other characteristics.
In CRM systems, these include, for example, the company, the role, the location, a specific project, contract details, personal complaints, or particular conversation content. The smaller the relevant customer group, the more easily a combination of such information can point to a specific person.
Free-text fields are particularly critical. A conversation note can uniquely describe a person even though their name has already been removed. The combination of several seemingly harmless details can also enable re-identification.
With pseudonymization, it is therefore not sufficient to replace only a name with a number. According to the guidelines of the European Data Protection Board, all components of the data set must be considered. The additional mapping information must be stored separately and protected by technical and organizational measures. Pseudonymization must also always be supplemented by further protective measures.
The European Data Protection Board emphasizes, also for AI models, that a claimed anonymity must be examined in the specific individual case. A model should only be regarded as anonymous if a direct or indirect identification of the data subjects and the extraction of their personal data are sufficiently unlikely. (European Data Protection Board)
For operational CRM processes, pseudonymization is therefore usually the more realistic approach. Full anonymization is more suitable for aggregated analyses, statistics, or the study of general process patterns.
What a pseudonymized CRM AI architecture can look like
For many operational use cases, an architecture with a controlling intermediate layer is suitable:
CRM → data protection and AI gateway → AI service → gateway → CRM
The gateway can be part of the CRM integration, a middleware, or a company-wide AI platform. It decides which information may leave the controlled company area.
Before transfer, fields that are not needed are removed. Direct identifiers are replaced with randomly generated pseudonyms. Free-text fields are checked for names, contact data, and sensitive content. After processing, the result is reassigned within the company to the correct CRM process.
| Original information in the CRM | Transfer to the AI |
|---|---|
| Max Mustermann | Contact-84721 |
| max.mustermann@beispiel.de | Not transferred |
| +49 170 1234567 | Not transferred |
| Beispiel GmbH | Customer-315 or approved industry context |
| CRM record ID | Randomly generated external pseudonym |
| Conversation note | Reduced to the purpose and cleaned |
| Internal creditworthiness assessment | Not transferred |
| Product interest | Transferred if required for the use case |
| Agreed next step | Transferred |
| Mapping table | Remains in the controlled company area |
The mapping between “Contact-84721” and the actual contact must not be accessible to the AI service. It should be stored separately, technically protected, and reachable only for authorized processes.
The pseudonym itself must also be chosen sensibly. A simple sequential customer number, an unchanged CRM ID, or a predictable identifier can enable unwanted linkages. For external processing, randomly generated identifiers limited to the respective use case are usually more suitable.
Pseudonymization reduces the risk. But it replaces neither the legal basis nor the provider review, the data processing agreement, or the required technical and organizational measures.
Not only the prompt may contain personal data
When assessing an AI use case, one must not consider only the text a user writes into an input field. Personal data can arise or be stored in several places.
This includes the inputs transmitted to the model, supplementary CRM data, automatically generated metadata, log files, the AI output, and possible intermediate storage. Embeddings, vector databases, and retrieval systems must also be included in the consideration if information about people can be derived from them or linked with CRM records.
The output of an AI system can also contain personal data. An automatically created conversation summary or customer assessment remains personal if it relates to a specific person.
Companies must therefore document the complete data flow. It is not sufficient merely to state which information was originally exported from the CRM.
Treat special categories of personal data separately
CRM systems can unintentionally contain specially protected information. This includes, for example, details about health, religion, political conviction, or trade union membership.
This information is often not in fields intended for it. It is found in conversation notes, emails, complaints, or service descriptions.
Pseudonymization does not remove the special protection of this data. In addition to a legal basis under Article 6 GDPR, for special categories the requirements of Article 9 GDPR must in principle also be taken into account. (EUR-Lex)
For normal CRM AI processes, such content should therefore be excluded as far as possible. Technical filters can detect certain terms and patterns. For ambiguous or particularly sensitive cases, a manual review or a fully separate process may be required.
An AI provider must deliver more than good functions
When selecting an AI solution, the focus is often first on feature scope, usability, and cost. For robust governance, these criteria are not sufficient.
Companies need to know, among other things, whether the provider stores inputs and outputs, for which purposes it uses them, and whether customer data is used to train or improve general models. Storage locations, subprocessors, deletion periods, access options, and third-country transfers are equally relevant.
The technical configuration must also match the contractual statement. A contractually promised short storage period helps little if logs or conversation histories remain permanently activated within the application.
The provider should also inform about changes in a traceable way. Models, subprocessors, data flows, and product functions can change. A one-time review before rollout is therefore not sufficient for indefinite operation.
What actually has to be demonstrated in an audit
The company should be able to answer which systems are used, who approved them, which data they process, and which risks were assessed. Equally important are the technical controls, the human review, and the handling of errors or changes.
| Review area | Typical evidence |
|---|---|
| AI systems and functions | Central AI and use case register |
| Business purpose | Documented use case description |
| Responsibility | Named business owner and technical responsibility |
| Processed data | Data categories, allowlists, and data flow |
| Legal basis | Data protection assessment |
| Risk | Classification under GDPR, AI Act, and internal methodology |
| Pseudonymization | Concept, pseudonymization scope, and protection of the mapping |
| Provider | Contract, DPA, storage locations, and subprocessors |
| Access rights | CRM roles, technical accounts, and permissions |
| Human control | Approval, correction, and override process |
| Quality | Test cases, samples, and defined quality criteria |
| Traceability | Logs, versions, and documented approvals |
| Incidents | Reporting path, escalation, and measures |
| Training | Evidence of AI literacy and usage rules |
| Regular review | Review dates, metrics, and responsible parties |
The documentation does not need to be as extensive as possible. What is decisive is its consistency.
The provider questionnaire must not describe a different data processing than the internal register. The technical CRM configuration must correspond to the documented permissions. The actual usage must not permanently deviate from the approved usage.
Ten building blocks for audit-ready AI governance
A functioning governance connects organization, technology, data protection, and business process. A pure AI policy is not sufficient for this. Nor is a technical interface enough if responsibilities and approvals remain unclear.
Existing data protection, information security, and CRM processes should be extended where possible. A completely new parallel organization often creates additional effort and unclear responsibilities.
The following building blocks can be built up step by step. Not every building block has to be fully automated at the start. The basic structure, however, should already be in place at the first productive pilot.
| No. | Suggestion | Description | Pragmatic entry | Sustainable expansion |
|---|---|---|---|---|
| 1 | AI use case register | Central overview of all planned, tested, and productive AI applications | Table with purpose, system, owner, and data types | Integration into architecture, data protection, and risk management |
| 2 | Risk classification | Assessment by data, impact, and degree of automation | Three classes: low, elevated, and critical | Detailed methodology with approval thresholds |
| 3 | Data allowlists | Definition of the CRM fields permitted for a use case | Manually maintained field list | Technically enforced policies per AI function |
| 4 | Pseudonymization concept | Separation of identifying details from functional content | Random pseudonyms and separate mapping | Central gateway and key management |
| 5 | Provider review | Assessment of contracts, storage, training, and subprocessors | Standardized provider questionnaire | Ongoing third-party risk management |
| 6 | Role and approval model | Definition of who requests, assesses, and approves | Business owner, IT, and data protection | Fixed governance board with escalation paths |
| 7 | Human control | Definition of which results must be reviewed | Drafts instead of automatic communication | Risk-based control levels |
| 8 | Testing and monitoring | Review of quality, errors, and undesired results | Defined test cases and samples | Continuous monitoring and drift detection |
| 9 | AI literacy | Qualifying users on possibilities and limits | Short mandatory basic training | Role-based training and refreshers |
| 10 | Audit pack | Consolidation of the relevant evidence | Structured project folder | Integrated control and evidence system |
The pragmatic path: minimum viable governance
Before the first controlled pilot project, companies do not have to immediately establish a fully built-out AI management system. But they do need a robust minimum framework.
This framework can be understood as minimum viable governance. It initially reduces complexity and scope but leaves no central questions of responsibility open.
A pilot needs at least a clear purpose, a functional owner, a defined user group, and a limited data basis. In addition, the permitted data fields, the provider, the human control, and an abort mechanism must be defined.
Minimum viable governance is not a permanent final solution. It is a controlled entry whose results and structures are subsequently expanded.
Phase 1: Create immediate guardrails
The fastest entry is a preliminary usage rule for AI in customer management. It defines which tools may be used and which information must not be entered into public or unapproved AI services.
In parallel, a practicable approved alternative should be provided. Pure prohibitions often do not prevent usage, but shift it into invisible areas.
For a first pilot, the data is deliberately limited. Instead of complete customer files, selected conversation notes, approved product information, or standardized service content can be used.
Particularly sensitive fields, internal assessments, and unstructured historical communication histories remain excluded at first.
Phase 2: Inventory and classify AI use cases
In the second step, all known AI applications are recorded in a shared register. This also includes functions that have been activated within existing CRM, office, marketing, or service platforms.
Each use case receives a business owner. In addition, purpose, user group, data categories, provider, expected benefit, and potential effects are documented.
For the initial classification, a simple model with three risk classes can suffice. Internal drafting aids with human review can, for example, be assessed as low risk. Customer communication, prioritization, and personal recommendations usually require a more intensive review. Decisions with significant effects or specially protected data belong in a critical class.
Phase 3: Implement a pseudonymized quick win
A suitable first use case is a CRM assistant that creates a structured summary and a suggestion for the next steps from an approved conversation note.
Before transfer, a technical intermediate layer removes direct identifiers and CRM fields that are not needed. The AI service receives a random pseudonym as well as the functionally necessary conversation context. The mapping to the real contact remains in the CRM or in a controlled middleware.
The result is not automatically sent to the customer. The user reviews and corrects the draft before it is saved or reused.
For the pilot, quality, processing time, and correction effort are measured. At the same time, unsuitable data fields, problematic inputs, and typical errors are documented.
This path creates momentum without circumventing governance. It delivers a visible benefit and at the same time creates reusable structures for further AI projects.
Phase 4: Turn the pilot into a controlled operating process
After the pilot, a deliberate decision must be made. The use case is discontinued, adjusted, or scaled in a controlled way.
For this, benefit, quality, risks, and actual usage are assessed together. The effectiveness of the pseudonymization and data filtering must also be reviewed.
The approval is then embedded into the regular CRM and IT processes. New functions, data fields, or provider changes trigger a renewed review.
This turns an innovation project into a permanently manageable business process.
Technical controls should be as close to the CRM as possible
The CRM already knows users, roles, customer data, and processes. Therefore, many controls should be implemented as close to this platform as possible.
An AI service should not automatically be allowed to access all information that a user can theoretically see in the CRM interface. For AI functions, narrower permissions are often sensible.
A service assistant may need product, contract, and ticket information. But it does not need internal sales assessments. A sales assistant does not automatically need all complaints and escalations from service.
Different levels of automation must also be provided for the results. A suggestion, a saved draft, and an automatically executed action are not the same thing.
The higher the impact of a result, the more strongly review, logging, and approval must be designed.
The pragmatic audit folder
In many companies, relevant information is spread across ticketing systems, emails, contract folders, and data protection documentation. When a customer inquiry arrives, a time-consuming search therefore begins.
A central audit folder quickly provides relief. For each approved use case, it contains the current description, the data flow, the risk classification, the approvals, contracts, test evidence, and contacts.
The pseudonymization concept also belongs in this folder. This includes the procedures used, the defined pseudonymization scope, the protection of the mapping information, and the examination of possible re-identification risks.
The audit folder does not have to consist exclusively of copied documents. Stable references to data protection management, the ticketing system, contract management, and the CRM are sufficient.
The goal is a fast and consistent ability to respond. A company should be able to explain within a short time what the system does, which data it processes, how it is controlled, and what happens in the event of an error.
Practical example: Step-by-step rollout with measurable benefit
The following example is condensed from several typical project situations. The company, industry, and figures have been anonymized and rounded for illustration.
An industrial company with around 140 active CRM users wanted to use AI for conversation summaries, email drafts, service classification, and opportunity scoring. Originally, the plan was to activate several functions almost simultaneously for large user groups.
In a preliminary phase, an AI register was first built. In doing so, it turned out that five business units were already testing different AI tools. In some cases, customer emails and conversation transcripts were processed via personal user accounts.
The company therefore decided on a controlled pilot with 20 sales users. The assistant received only approved conversation content, product information, and next steps. Names, email addresses, phone numbers, and internal CRM IDs were removed before transfer or replaced with random pseudonyms.
The mapping remained within the company’s own integration layer. The external AI service could not assign the processed content to a specific CRM contact without additional information.
After eight weeks, the average documentation effort in the pilot group dropped by around 35 percent. The share of fully documented follow-up steps rose from 62 to 87 percent.
At the same time, the project team identified several unsuitable fields and prompt templates before they were used company-wide. Internal assessments and extensive free texts in particular were removed from the data flow.
In a second phase, service classification was added. Through iterative tests, the correct initial assignment of tickets in the example rose from around 79 to 91 percent.
Only afterward was opportunity scoring examined. This was deliberately not implemented as an automatic decision. The assessment appeared as an explainable hint and had to be confirmed by the sales manager.
After six months, the pilot group showed a conversion rate around four percentage points better than a comparable baseline group. The effect could not be attributed solely to the AI. What was measurable, however, was that follow-up steps were carried out faster, information was maintained more completely, and opportunities were discussed in a more structured way.
The sustainable benefit therefore lay not only in the time savings. The company subsequently had a reusable approval procedure, an AI register, standardized provider questions, a pseudonymization concept, and robust audit evidence.
Checklist for getting started with AI governance in the CRM
A checklist does not replace an individual legal or data protection assessment. But it makes central gaps visible early. Every answer should match the actual technical implementation in the CRM and in the connected systems. In the case of increased risk, data protection, information security, legal counsel, and, if applicable, the works council must be involved early. It is also important not to treat the review as a one-time project task, but to repeat it regularly.
- All productive, planned, and tested AI applications are recorded in a central register.
- For every AI use case, there is a functionally responsible business owner.
- Purpose, user group, and expected benefit are clearly described.
- The processed CRM data and complete data flows are documented.
- For every use case, there is an allowlist of permitted CRM fields.
- Data that is not needed is removed before transfer.
- Direct identifiers are, as far as possible, not transferred to the AI service.
- For operational use cases, it has been checked whether pseudonymization is possible.
- The mapping information is stored separately and specially protected.
- The pseudonyms used are not easily predictable or reusable across systems.
- Free-text fields are checked for identifying and sensitive content.
- The processing of special categories of personal data is prevented or separately approved.
- The legal basis and data protection assessment are documented.
- The need for a data protection impact assessment has been examined.
- The classification under the EU AI Act has been documented.
- Providers, storage locations, subprocessors, and third-country transfers are known.
- A data processing agreement is in place where required.
- The use of inputs and outputs for the provider’s training has been clarified.
- Storage and deletion periods are defined contractually and technically.
- The roles and permissions of the AI application are limited in the CRM.
- Supporting suggestions and automated decisions are clearly distinguished.
- For relevant results, a human review is provided.
- Test cases, quality criteria, and acceptable error thresholds are defined.
- Wrong decisions and problematic outputs can be reported.
- Changes to the model, provider, data flow, or use case trigger a renewed review.
- Employees have been trained on permitted use, data protection, and the limits of AI.
- Contracts, assessments, approvals, and tests are consolidated in an audit pack.
- Benefit, quality, risks, and actual usage are reviewed regularly.
Conclusion: Start fast, but scale in a controlled way
Companies do not have to wait until every regulatory detail is conclusively clarified. But they should also not allow uncontrolled individual attempts to create permanent facts.
A pragmatic entry begins with a clearly limited use case, a reduced data basis, a responsible owner, and traceable documentation. Where a later assignment to the CRM process remains necessary, effective pseudonymization is usually more realistic than the claim of full anonymization.
The functionally robust statement is therefore:
We transfer only the data required for the respective AI use case. Where an assignment to the CRM process remains necessary, personal information is pseudonymized as far as possible and direct identifiers are removed. Anonymization is assumed only where re-identification based on the data and the specific processing context can be sufficiently ruled out.
The quick win must not become a substitute for sustainable governance. Rather, it should be the first controlled step on this path.
Good AI governance is not a brake block. It ensures that successful CRM use cases can be approved faster, scaled safely, and explained robustly to customers, auditors, or supervisory bodies.
Note: This article reflects the state of information as of 13 July 2026 and does not replace individual legal or data protection advice.
