Europäische Unternehmen, die eine CRM-Migration durchführen, bewegen sich in einem der regulatorisch dichtesten Umfeld seit Jahren. Sechs EU-Instrumente — Data Act, AI Act, eIDAS 2.0, NIS2, DORA und die Anforderungen an die Datensouveränität in der Cloud — treten im selben Zeitfenster in Kraft, zwischen 2025 und 2027. Jedes davon hat direkte Auswirkungen darauf, wie CRM-Systeme und Kommunikationsmanagement-Plattformen zusammenarbeiten und sich integrieren.
Für Unternehmen, die in den DACH-Märkten, in Italien und in Frankreich tätig sind, ist die Richtung klar: Compliance lässt sich nicht nachträglich einbauen. Sie muss von Anfang an in die Architektur einfließen — in der Entwurfsphase, bevor die Systeme verbunden werden. Das ist der Kern von Compliance by Design.
Kann Compliance nach dem Go-live noch umgesetzt werden?
Die sechs Verordnungen sind keine isolierten Pflichten. Sie konvergieren auf einen gemeinsamen Punkt: die Schaffung eines regulatorischen Rahmens dafür, wie Kundendaten aus dem CRM extrahiert, in Kommunikation überführt und zugestellt werden können. Sie überschneiden sich — und sie summieren sich.
Wer diese Pflichten erst angeht, nachdem eine Integration bereits entworfen und in Betrieb genommen wurde, muss in eine laufende Architektur eingreifen — mit deutlich höherem Aufwand und Risiko. Compliance by Design kehrt diese Logik um. Jede Anforderung wird als architektonisches Kriterium festgelegt, bevor die Systeme verbunden werden, nicht danach.
Compliance by Design in der Praxis: Data Act und AI Act
Der Data Act verlangt, dass alle von der CCM-Plattform verarbeiteten Daten in interoperablen Formaten exportierbar sind. Das ist eine architektonische Eigenschaft — sie hängt davon ab, wie Datenstrukturen und Schnittstellen von Anfang an aufgebaut werden. Nachträglich einzuführen ist sie wesentlich aufwändiger, sobald die Formate im Produktivsystem aktiv sind.
Der AI Act greift, sobald Kommunikation durch Künstliche Intelligenz personalisiert wird. In diesen Fällen muss das System für jede generierte Nachricht drei Elemente festhalten: die verwendeten Eingabedaten, die Version des Modells, das den Inhalt erzeugt hat, und die Entscheidungslogik. Eine Plattform kann diese Informationen nur protokollieren, wenn sie von Beginn an dafür ausgelegt wurde. Diese Daten lassen sich im Nachhinein nicht rekonstruieren.
Sechs Verordnungen, ein Konvergenzpunkt
Es lohnt sich, die konkreten Anforderungen jedes Instruments zu benennen — nicht erschöpfend, aber präzise genug, um die architektonischen Konsequenzen zu verstehen.
- Die Anforderungen an die Cloud-Datensouveränität verpflichten dazu, die gesamte Datenverarbeitungskette innerhalb der europäischen Jurisdiktion zu halten — abgeschirmt von extraterritorialer Gesetzgebung wie dem US CLOUD Act.
- Der Data Act zielt darauf ab, Anbieterabhängigkeiten zu verhindern, und schreibt faktisch Datenportabilität vor.
- Der AI Act führt eine Risikoklassifizierung für KI-Systeme ein, die an Entscheidungen beteiligt sind, die Personen betreffen.
- eIDAS 2.0 definiert elektronische Identität und Vertrauensdienste neu und schreibt die Unterstützung qualifizierter Signaturen sowie der European Digital Identity Wallet (EUDI-Wallet) vor.
- NIS2 erweitert die Cybersicherheitspflichten auf Betreiber wesentlicher Dienste — Energie, Wasser, Telekommunikation, Gesundheit, digitale Infrastruktur und weitere kritische Sektoren — sowie auf deren Lieferanten.
- DORA verpflichtet Finanzunternehmen zu einem dokumentierten IT-Risikomanagement, das ausdrücklich auch Drittanbieter einschließt.
Der entscheidende Punkt: Diese sechs Verordnungen wirken nicht in getrennten Bereichen. Eine regulatorische Mitteilung einer Bank kann gleichzeitig DORA (Resilienz), dem AI Act (wenn der Inhalt durch ein Modell personalisiert wird), eIDAS 2.0 (Signatur) und den Souveränitätsanforderungen (Datenspeicherort) unterliegen.
Deshalb kann die Bewertung einer CCM-Plattform nicht beim Funktionsumfang enden. Sie muss sich auf die Architektur erstrecken. Denn die Architektur entscheidet darüber, ob alle diese Pflichten gleichzeitig erfüllt werden können — bei derselben Kommunikation, im normalen Betrieb der Plattform, ohne nachträgliche Korrekturen von Fall zu Fall.
Integration als regulatorische Infrastruktur
Aus der Überlagerung dieser Pflichten ergibt sich eine klare operative Schlussfolgerung: Die Integration zwischen CRM und Kommunikationssystem muss als Komponente geplant werden, die denselben regulatorischen Anforderungen unterliegt wie jedes der beiden Einzelsysteme — nicht lediglich als Prozess, der Daten zwischen ihnen transportiert.
In der Praxis führt das zu vier konkreten Anforderungen.
Datenportabilität muss durch die Architektur selbst sichergestellt sein. Plattformen, die auf offenen Schnittstellen und dokumentierten Datenmodellen basieren, erfüllen diese Anforderung. Plattformen, die auf proprietären, geschlossenen Formaten beruhen, nicht.
Die Protokollierung von KI-Entscheidungen — Eingabedaten, Modellversion und Entscheidungslogik hinter jeder generierten Kommunikation — muss gespeichert und Compliance-Teams zugänglich gemacht werden.
Die Zustellung von Dokumenten mit qualifizierter Signatur muss über eIDAS-konforme Vertrauensdienste erfolgen.
Operative Resilienz erfordert, dass im Voraus festgelegt wird, was passiert, wenn das CRM oder die Kommunikationsplattform nicht verfügbar ist. Und die gesamte Kette — Extraktion aus dem CRM, Transit, Verarbeitung, Archivierung — muss innerhalb der europäischen Jurisdiktion verbleiben. Für Finanzinstitute im DACH-Raum und für die französische öffentliche Verwaltung ist diese letzte Anforderung nicht verhandelbar.
Der EU-Regulierungsrahmen — nach Land und Sektor
Der europäische Rahmen ist gemeinsam, aber jedes Land ergänzt ihn um nationale Regelungen. Genau hier muss die Wahl einer CCM-Plattform den lokalen Besonderheiten Rechnung tragen.
Deutschland
In Deutschland ergänzt das Bundesdatenschutzgesetz (BDSG) die DSGVO durch strengere Bestimmungen zu Lieferantenbeziehungen. Die BaFin, die Finanzmarktaufsichtsbehörde, verlangt ein dokumentiertes IT-Risikomanagement, das ausdrücklich Abhängigkeiten von Kommunikationsdienstleistern einschließt.
Italien
In Italien erstrecken sich die Leitlinien der Nationalen Cybersicherheitsbehörde (ACN) zur Umsetzung von NIS2 auch auf IT-Dienstleister. Der Kodex für die digitale Verwaltung (CAD) schreibt für die öffentliche Verwaltung Barrierefreiheitsstandards und die Integration mit der nationalen digitalen Identitätsinfrastruktur vor.
Frankreich
In Frankreich veranlasst das Streben nach technologischer Souveränität — gestärkt durch SecNumCloud, das Zertifizierungsschema der französischen Cybersicherheitsbehörde ANSSI — Unternehmen aus regulierten Sektoren dazu, systematisch Infrastrukturen zu bevorzugen, die Daten und deren Verarbeitung innerhalb der EU halten.
Unterschiedliche Pflichten je Sektor, eine gemeinsame Architekturentscheidung
Zu den nationalen Unterschieden kommen sektorspezifische Pflichten. Ein Versorgungsunternehmen muss unter NIS2 authentifizierte, nachvollziehbare Notfallkommunikation gewährleisten. Ein Versicherungsunternehmen unterliegt DORA und den Anforderungen des AI Act für Kommunikation, die aus automatisierten Bewertungen resultiert. Eine Behörde muss Barrierefreiheitsstandards erfüllen und sich in nationale Identitätssysteme integrieren. Unterschiedliche Pflichten — aber alle konvergieren auf dieselbe Architekturentscheidung.
Die Prüfschritte zum Zeitpunkt der Migration
Die Konvergenz dieser sechs Verordnungen führt zu einer operativen Schlussfolgerung: Die CRM-Migration ist auch der Moment, um zu prüfen, ob die gewählte Kommunikationsplattform dem gesamten regulatorischen Rahmen standhält. Wer diese Prüfung auf die Zeit nach dem Go-live verschiebt, führt die Organisation durch eine Phase, in der Kommunikation ohne vollständige Compliance verwaltet wird — genau dann, wenn die europäischen Fristen verbindlich werden.
Das Whitepaper Moving to Cloud CRM: Where Customer Engagement Meets Intelligent Communications analysiert jede der sechs Verordnungen im Detail, ihre Auswirkungen auf Integrationsebene sowie die Besonderheiten der DACH-, italienischen und französischen Märkte. Es bietet einen Bezugsrahmen für alle, die diese Anforderungen in konkrete Bewertungskriterien übersetzen müssen.
FAQ
Welche sechs EU-Verordnungen betreffen die Kundenkommunikation?
Data Act, AI Act, eIDAS 2.0, NIS2, DORA und die Anforderungen an die Cloud-Datensouveränität. Alle sechs treten zwischen 2025 und 2027 in Kraft und haben direkte Auswirkungen darauf, wie CRM- und Kommunikationsmanagementsysteme integriert werden.
Was bedeutet Compliance by Design?
Es bedeutet, Compliance bereits in der Entwurfsphase in die IT-Architektur einzubauen — bevor die Systeme verbunden werden — statt sie nach dem Go-live nachzurüsten. Jede Anforderung wird vorab als architektonisches Kriterium definiert, weil Eingriffe in eine bereits laufende Architektur deutlich aufwändiger und riskanter sind.
Warum kann sich die Bewertung einer CCM-Plattform nicht auf den Funktionsumfang beschränken?
Weil die sechs Verordnungen nicht isoliert wirken: Eine einzige Kommunikation kann gleichzeitig mehreren Anforderungen unterliegen. Die Architektur entscheidet darüber, ob alle gemeinsam erfüllt werden können — im normalen Betrieb der Plattform, ohne nachträgliche Korrekturen.
Gilt der EU-Regulierungsrahmen in allen Ländern gleich?
Nicht vollständig. Die europäische Grundlage ist gemeinsam, aber jedes Land legt nationale Regelungen darüber: Deutschland hat BDSG und BaFin-Aufsicht, Italien hat ACN-Vorgaben und den CAD, Frankreich hat eine Souveränitätsorientierung, die durch SecNumCloud gestärkt wird. Sektorspezifische Pflichten kommen auf all das noch hinzu.
