Le imprese europee che affrontano una migrazione del CRM si muovono oggi in un contesto normativo particolarmente denso e articolato. Sei strumenti regolatori dell’Unione Europea – Data Act, AI Act, eIDAS 2.0, NIS2, DORA e i requisiti di sovranità del cloud – stanno entrando in vigore nello stesso arco di tempo, tra il 2025 e il 2027. Ciascuno ha implicazioni dirette sul modo in cui i sistemi CRM e di gestione delle comunicazioni si integrano tra loro.

Per le organizzazioni che operano nei mercati DACH, in Italia e in Francia l’indicazione è una sola: la conformità non è un’attività da svolgere dopo l’entrata in produzione, ma un requisito da incorporare nell’architettura fin dall’inizio, fin dalle fasi di progettazione e di sviluppo. È il principio che si riassume nella formula compliance by design.

La conformità può succedere al go-live?

I sei regolamenti che abbiamo nominato sono adempimenti che si sovrappongono e convergono verso uno stesso punto: la creazione di una cornice normativa che inquadri il modo in cui i dati del cliente possono essere estratti dal CRM, trasformati in comunicazioni e consegnati.

Affrontare a posteriori gli obblighi che derivano da questi regolamenti, quando l’integrazione tra i sistemi è già stata progettata e messa in produzione, significa intervenire su un’architettura già in esercizio, con costi e rischi molto più alti. Il principio della compliance by design ribalta questa logica. Ogni obbligo viene tradotto in un requisito architetturale già nella fase di progettazione dell’integrazione, prima che i sistemi vengano connessi.

Compliance by design in concreto: Data Act e AI Act

Il Data Act richiede che tutti i dati trattati dalla CCM platform siano esportabili in formati interoperabili: è una caratteristica che dipende da come vengono strutturati i dati e le interfacce all’origine, molto più onerosa da introdurre una volta che i formati sono già attivi nel sistema reale.

L’AI Act interviene quando le comunicazioni vengono personalizzate tramite intelligenza artificiale. In questi casi, per ogni messaggio generato, il sistema deve conservare traccia di tre elementi: i dati utilizzati in ingresso, la versione del modello che ha prodotto il contenuto e il criterio con cui è stata presa la decisione. Una piattaforma è in grado di registrare queste informazioni solo se è stata progettata fin dall’inizio per farlo: non sono dati che si possono ricostruire a posteriori.

Sei regolamenti, un punto di convergenza

It is worth mapping out what each instrument requires in concrete terms — not exhaustively, but specifically Vale la pena esaminare come ciascuno strumento si traduce in un requisito concreto, senza pretendere qui di descriverlo nella sua interezza.

• I requisiti di sovranità del cloud impongono che l’intera catena di trattamento del dato resti entro la giurisdizione europea, al riparo da normative extraterritoriali (per esempio il CLOUD Act statunitense).
• Il Data Act mira a prevenire il lock-in del fornitore e impone di fatto la portabilità dei dati.
• L’AI Act introduce la classificazione del rischio per i sistemi di intelligenza artificiale che intervengono nelle decisioni riguardanti le persone.
• eIDAS 2.0 ridefinisce l’identità elettronica e i servizi fiduciari, e impone il supporto delle firme qualificate e del portafoglio europeo di identità digitale.
• NIS2 estende gli obblighi di resilienza informatica agli operatori dei servizi essenziali – energia, acqua, telecomunicazioni, sanità, infrastrutture digitali e altri settori giudicati critici per il funzionamento del Paese – e ai fornitori di cui questi operatori si servono.
• DORA, infine, impone alle entità finanziarie una gestione documentata del rischio informatico, estesa anche ai fornitori terzi.

Il punto è che questi sei regolamenti, e gli obblighi che ne derivano, non operano in compartimenti separati. Una comunicazione regolatoria inviata da una banca può essere contemporaneamente soggetta a DORA per la resilienza, all’AI Act se il contenuto è personalizzato da un modello, a eIDAS 2.0 per la firma e ai requisiti di sovranità per la residenza del dato.

È per questo che la valutazione di una CCM platform non può limitarsi alle funzionalità, ma deve estendersi all’architettura: è dall’architettura che dipende la possibilità di rispettare tutti questi obblighi simultaneamente, su una stessa comunicazione, all’interno del normale funzionamento della piattaforma anziché attraverso interventi correttivi costruiti caso per caso.

L’integrazione come infrastruttura regolatoria

Dalla sovrapposizione di questi obblighi deriva un’indicazione precisa: l’integrazione tra CRM e sistema di comunicazione va progettata come una componente soggetta agli stessi requisiti normativi che valgono per ciascuno dei due sistemi, e non come il processo che abilita il semplice transito dei dati. In concreto, questo si traduce in alcuni requisiti puntuali.

La portabilità dei dati deve essere garantita dal design stesso dell’architettura: le piattaforme costruite su interfacce aperte e modelli di dati documentati soddisfano questo requisito, quelle basate su formati proprietari e chiusi no.

La registrazione delle decisioni prese dall’intelligenza artificiale – i dati in ingresso, la versione del modello e il criterio decisionale di ogni comunicazione generata – deve essere conservata e resa consultabile dai team di conformità.

La consegna di documenti con firma qualificata deve essere instradata attraverso servizi fiduciari conformi a eIDAS.

La resilienza operativa richiede che si definisca in anticipo cosa accade se uno dei due sistemi – il CRM o la piattaforma di comunicazione – diventa indisponibile.

E l’intera catena – estrazione dal CRM, transito, elaborazione, archiviazione – deve restare entro la giurisdizione europea. Per gli istituti finanziari della regione DACH e per la pubblica amministrazione francese, in particolare, quest’ultimo requisito non è negoziabile.

Il quadro normativo europeo, declinato per Paese e per settore

The European framework is shared, but every country layer national regulation on top of it. This is where CCM platform selection has to account for local specifics.

Germania

In Germania il Bundesdatenschutzgesetz (BDSG), la Legge federale tedesca sulla protezione dei dati, integra il GDPR con disposizioni più stringenti sui rapporti con i fornitori. La vigilanza di BaFin, l’autorità di regolamentazione che vigila sulla sicurezza e sulla protezione del settore finanziario in Germania, richiede una gestione documentata del rischio informatico che includa esplicitamente le dipendenze dai fornitori di comunicazioni.

Italia

In Italia le indicazioni dell’Agenzia per la Cybersicurezza Nazionale sull’attuazione di NIS2 si estendono ai fornitori di servizi informatici, mentre il Codice dell’Amministrazione Digitale impone, per la pubblica amministrazione, accessibilità e integrazione con l’identità digitale nazionale.

Francia

In Francia l’orientamento verso la sovranità tecnologica, rafforzata da SecNumCloud – la certificazione sviluppata dall’agenzia francese per la cybersicurezza (ANSSI) – porta le organizzazioni dei settori regolati a privilegiare in modo sistematico infrastrutture che mantengono i dati e il loro trattamento all’interno dell’Unione Europea.

Obblighi diversi per settore, un’unica scelta architetturale

A queste differenze nazionali si sommano gli obblighi propri di ciascun settore. Una utility deve garantire comunicazioni di emergenza autenticate e tracciabili sotto NIS2; una compagnia assicurativa è soggetta a DORA e agli obblighi dell’AI Act sulle comunicazioni che derivano da valutazioni automatizzate; un’amministrazione pubblica deve rispettare gli standard di accessibilità e integrarsi con i sistemi di identità nazionali. Sono obblighi diversi che ricadono però sulla stessa scelta architetturale.

Le verifiche da affrontare al momento della migrazione

La convergenza di questi sei regolamenti porta a una conclusione operativa: il momento della migrazione del CRM è anche il momento in cui verificare se la piattaforma di comunicazione scelta è in grado di reggere il quadro normativo nel suo insieme. Rimandare questa verifica a dopo l’entrata in produzione espone l’organizzazione a una fase in cui le comunicazioni vengono gestite senza piena conformità, proprio mentre le scadenze europee diventano vincolanti.

Il whitepaper Moving to Cloud CRM: Where Customer Engagement Meets Intelligent Communications analizza nel dettaglio ciascuno dei sei regolamenti, le loro implicazioni a livello di integrazione e le specificità dei mercati DACH, italiano e francese, e offre un framework di riferimento pensato per chi deve tradurre questi obblighi in criteri di valutazione concreti