Governance dell’IA nel marketing: come costruirla in pratica

La governance dell’IA nel marketing riunisce l’essenziale: inventario, regole, ruoli, evidenze e autorità per fermare il sistema. Per ogni caso d’uso risponde a cinque domande: per che cosa viene utilizzato il sistema? Quali dati può trattare? Quale output o azione può generare? Quale persona decide? Che cosa succede in caso di errori o modifiche? Una direttiva senza queste risposte operative resta carta; uno strumento senza regole resta fuori controllo.

Per i team svizzeri la governance inizia da responsabilità chiare e obblighi concreti sui dati. L’Incaricato federale della protezione dei dati e della trasparenza (IFPDT) rileva che la legge sulla protezione dei dati, tecnologicamente neutra, si applica al trattamento di dati personali assistito dall’IA. A seconda del trattamento entrano in gioco la trasparenza e, per le decisioni individuali automatizzate, la loro verifica; in caso di rischio elevato si aggiunge una valutazione d’impatto sulla protezione dei dati. Quale obbligo si applichi nel concreto caso di marketing va verificato sul piano specialistico e giuridico.

1. Un inventario che rende possibili le decisioni

Registri ogni sistema di IA utilizzato o in fase pilota, comprese le funzioni presenti nelle piattaforme esistenti. Per ogni voce servono almeno: scopo, persona responsabile, gruppi di utenti, persone interessate, fornitore e versione, fonti dei dati, integrazioni, tipo di output, azione consentita, approvazione umana, conservazione, livello di rischio, ultimo test e prossima revisione.

Un nome di prodotto da solo non basta. La stessa applicazione può essere usata per generare idee da informazioni pubbliche, per briefing riservati o per un contatto personalizzato con i clienti. Questi utilizzi comportano dati e conseguenze diversi. Tenga quindi una voce d’inventario per ogni caso d’uso, non solo per ogni licenza.

L’inventario è al tempo stesso una porta d’accesso. Un nuovo scopo, una nuova fonte di dati o una nuova azione automatizzata genera una modifica che viene riesaminata. Così il team evita che un progetto pilota innocuo diventi gradualmente un processo di produzione non autorizzato.

2. Utilizzo consentito, limitato e vietato

Una direttiva comprensibile descrive attività concrete. «Usare l’IA in modo responsabile» non è attuabile. Meglio tre categorie con esempi:

Consentito: per esempio raccogliere idee da informazioni pubbliche e approvate, purché gli output siano trattati come bozze e verificati.

Solo dopo approvazione: riassumere documenti interni, classificare il feedback dei clienti, creare previsioni, personalizzare contenuti o integrare sistemi. Qui devono essere chiariti scopo, dati, contratto, test e controllo umano.

Vietato: inserire in uno strumento pubblico e non controllato password, chiavi segrete o dati non approvati, riservati, personali o degni di particolare protezione; pubblicare affermazioni non verificate; interpretare una possibilità di accesso tecnico come un’approvazione.

L’Ufficio federale della cibersicurezza (UFCS) raccomanda di non inserire dati personali, sensibili o riservati di clienti e aziende in applicazioni di IA, di leggere le condizioni e di mettere in discussione criticamente le risposte. Questa regola generale di sicurezza è una buona base prudente, ma non sostituisce una classificazione dei dati specifica dell’azienda.

3. Regole sui dati lungo tutto il flusso

Per ogni caso il flusso dei dati deve essere visibile dalla fonte alla cancellazione. Chiarisca:

• Da dove provengono i dati e per quale scopo sono stati raccolti?
• Vengono trattati dati personali, contenuti riservati o opere protette?
• Quali campi sono davvero necessari e quali possono essere rimossi o anonimizzati?
• Dove vengono trasmessi input, metadati e output?
• Un fornitore utilizza gli input per il miglioramento o per l’addestramento?
• Chi ottiene l’accesso, per quanto tempo vengono conservati i dati e come vengono cancellati?
• Quali subappaltatori e Paesi sono coinvolti?
• Come ricevono le persone interessate le informazioni necessarie o una verifica?

Le risposte non appartengono a una presentazione una tantum, ma a una scheda dati versionata. Contratti, configurazione tecnica e comportamento effettivo devono coincidere. Se una domanda resta aperta, l’accesso reale ai dati rimane bloccato oppure il progetto pilota utilizza dati sintetici adeguati.

La protezione dei dati non è l’unico livello di diritti in gioco. L’Istituto federale della proprietà intellettuale (IPI) segnala che materiale riconoscibilmente protetto negli output dell’IA può sollevare questioni di diritti e che l’apporto creativo umano può essere rilevante per una possibile protezione dell’output. Un workflow di marketing richiede quindi una verifica di fonti, licenze e originalità, soprattutto per testo, immagini, audio e video.

4. Ruoli umani con autorità reale

«Human in the loop» è un controllo solo quando sono definiti quattro punti: chi verifica, che cosa vede questa persona, quando decide e quale potere ha. Una persona che riceve un risultato soltanto dopo che è già stato pubblicato o dopo che è stato modificato un budget non costituisce un’approvazione a monte.

Una ripartizione snella dei ruoli può presentarsi così:

• Il responsabile di business porta scopo, beneficio e rischio residuo.
• Il responsabile del caso d’uso risponde del processo, della qualità e delle verifiche.
• Il responsabile dei dati approva fonti, accessi e conservazione.
• Protezione dei dati, diritto e sicurezza hanno punti di verifica definiti e l’autorità di fermare il sistema.
• Chi utilizza i sistemi rispetta gli obblighi di input, verifica e segnalazione.
• Il responsabile degli incidenti coordina contenimento, analisi e comunicazione.

Una persona può ricoprire più ruoli, ma le responsabilità devono restare assegnate. In caso di impatto maggiore, non dovrebbe essere la stessa persona a costruire il sistema, a valutarlo da sola e ad accettare il rischio residuo.

5. Livelli di rischio interni come strumento operativo

I team di marketing possono usare un semplice triage interno. Non è una classificazione prevista dalla legge.

Livello A – assistenza con output interno facilmente correggibile: dati pubblici o approvati, nessuna azione automatica, verifica qualificata prima dell’uso.

Livello B – impatto su contenuti pubblicati, analisi o raccomandazioni operative: verifica aggiuntiva sotto il profilo specialistico, dei diritti e delle fonti; test documentati e monitoraggio.

Livello C – dati personali, trattamento individuale, azioni su budget o clienti, conseguenze difficilmente reversibili: verifica formale di protezione dei dati, giuridica, di sicurezza e da parte della direzione; perimetro ristretto; approvazioni chiaramente definite; piano per gli incidenti e di ripristino.

Il livello dipende dall’utilizzo e dall’impatto, non dal nome di marketing dello strumento. Se l’azione passa da «proposta» a «esecuzione automatica», occorre una nuova classificazione.

6. Testare prima di attribuire autorità

Un test conforme alla governance dispone di dati approvati, casi definiti in anticipo e un riferimento. Non valuta soltanto la qualità media, ma anche errori critici, omissioni, distorsioni, diritti, correzioni necessarie e comportamenti al di fuori del contesto previsto.

Documenti versione del modello o del prodotto, configurazione, dati di test, valutatori, risultato e scostamenti. Il principio di responsabilità dell’OCSE sottolinea la tracciabilità di set di dati, processi e decisioni. Nel marketing ne deriva una regola pratica: l’approvazione è documentata con le relative evidenze, così la persona responsabile può spiegarne in seguito la decisione.

L’autorità viene attribuita per gradi. Un sistema può dapprima fornire bozze, poi eventualmente raccomandazioni in un ambito più ristretto. Un’azione in un sistema in produzione riceve un’autorizzazione tecnica e un’approvazione di business separate. L’autorizzazione a installare e usare un sistema non vale da sola per ogni modifica che esso può apportare. Un mandato di business documentato a parte può coprire azioni definite entro i suoi limiti; le azioni già coperte non richiedono una doppia approvazione.

7. Trasparenza e contenuti generati dall’IA

La trasparenza ha diversi destinatari. I collaboratori devono sapere quando utilizzano l’IA e quali limiti valgono. I revisori hanno bisogno di fonti, configurazione e incertezza. Le persone interessate possono aver bisogno, a seconda del trattamento, di informazioni su scopo, funzionamento o decisioni automatizzate. Il pubblico e i clienti necessitano in determinate situazioni di un’indicazione riconoscibile che inquadri contenuti generati o manipolati dall’IA.

Per i riferimenti all’UE non è ammessa un’affermazione generalizzata. La Commissione europea rileva che l’AI Act è in linea di principio applicabile dal 2 agosto 2026, con eccezioni e termini transitori modificati. Se un’impresa svizzera, un sistema o un output di marketing concreto rientri nell’ambito di applicazione va verificato sul piano giuridico.

Una dichiarazione volontaria può inoltre sostenere la fiducia, ma non deve sostituire una verifica giuridica. Allo stesso modo, una piccola etichetta non basta se il trattamento stesso fosse illecito o fuorviante.

8. Controllare i fornitori e le piattaforme integrate

Chi si occupa degli acquisti non verifica soltanto il fornitore alla data del contratto. Definisce quali modifiche devono essere comunicate: cambio di modello, nuovo uso dei dati, subappaltatori, ubicazione di archiviazione, logica di prezzo, funzione di sicurezza o limite essenziale di prestazione.

Per il caso concreto richieda flusso dei dati, ruoli, cancellazione, canale di segnalazione in caso di guasti, possibilità di test, note di versione, esportazione dei dati e modalità di cessazione del servizio. Una scheda di sicurezza generale è utile, ma non risponde automaticamente a come funziona un’integrazione di marketing con le sue autorizzazioni.

Per le funzioni presenti in piattaforme pubblicitarie, CRM o di contenuti vale la stessa logica. Una funzione di IA attivata per impostazione predefinita deve entrare nell’inventario se tratta dati rilevanti o influenza decisioni. La comodità della piattaforma non è un’eccezione alla governance.

9. Monitoraggio, incidenti e diritti di arresto

Monitori metriche adeguate alle conseguenze degli errori: errori critici di fatto, affermazioni non comprovate, violazioni di diritti, accessi non consentiti ai dati, approcci errati ai clienti, azioni sbagliate, correzioni necessarie, costi o deriva dopo un aggiornamento. Un semplice contatore di utilizzo non dimostra alcun controllo.

La procedura per gli incidenti deve essere nota prima di doverla usare. Chi utilizza i sistemi sa come segnalare un incidente e come contenerlo. La persona responsabile degli incidenti può bloccare gli accessi, fermare le integrazioni o passare al processo manuale. Prove e log vengono messi al sicuro in modo adeguato. I ruoli di protezione dei dati, sicurezza, diritto e comunicazione vengono coinvolti secondo criteri definiti.

Dopo un incidente si analizzano le cause, poi si correggono, si testa di nuovo e si decide esplicitamente il riavvio. Non ogni errore è un incidente soggetto a notifica, ma ogni schema critico merita una reazione documentata.

10. Modifiche e disattivazione

I sistemi di IA cambiano. Definisca quali modifiche richiedono test di regressione o una nuova approvazione: versione del modello, prompt, fonte dei dati, pubblico di riferimento, canale, autorizzazione, valore di soglia o fornitore. Confronti i nuovi risultati con un set di test stabile e con le metriche di protezione.

La governance comprende anche la fine. Il piano di uscita indica esportazione dei dati, blocco dell’account, conferma della cancellazione, archiviazione dei giustificativi necessari, processo sostitutivo e comunicazione. Un sistema senza persona responsabile, senza beneficio o senza fornitore controllabile non viene semplicemente pagato ancora; viene disattivato in modo ordinato.

Il pacchetto minimo di governance

Per un piccolo progetto pilota di marketing non servono cento pagine, ma dovrebbero esistere sei documenti: voce del caso d’uso, scheda dati, matrice di ruoli e approvazioni, registro dei test e delle evidenze, scheda operativa e per gli incidenti, piano di modifica e di uscita. Ogni documento ha una persona responsabile, una versione e una data di revisione.

Questo pacchetto rende visibile la responsabilità senza bloccare in anticipo ogni idea. Più aumentano il volume di dati, il grado di automazione e le conseguenze degli errori, più approfondita diventa la verifica specialistica. Una buona governance non è quindi l’opposto della sperimentazione. Consente sperimentazioni limitate i cui risultati sono valutati con trasparenza e impedisce che da un test nasca inosservato un processo decisionale permanente.

Come aiuta maitiq: regole con cui il team può lavorare

Classifichi le attività in base al loro impatto: una bozza di testo interna, una pubblicazione e una modifica di budget richiedono verifiche diverse. Per ogni attività indichi i dati consentiti, la persona responsabile e la procedura in caso di incertezza. Un esempio breve e comprensibile per ogni attività aiuta più di una direttiva astratta senza legame con il lavoro.

In un progetto concordato, maitiq traduce queste regole in modelli, formazione e controlli di processo. Le approvazioni specialistiche o giuridiche restano alle persone responsabili. Misuri se i collaboratori sanno che cosa possono fare e a chi va segnalato un caso problematico.

Come inizia un primo progetto pilota con maitiq

In un progetto concordato, una fase di analisi iniziale limitata mostra quale governance è già abbastanza concreta e come maitiq traduce le regole ancora aperte in un flusso operativo praticabile. Riceve un caso d’uso chiaramente delimitato, le questioni aperte su dati e controlli, un piano di progetto pilota e i criteri per la successiva gestione operativa.

Fonti e inquadramento

Le fonti delle autorità chiariscono il contesto: l’IFPDT per la protezione dei dati, l’UFCS per la sicurezza e l’IPI per il diritto d’autore. La Commissione europea documenta l’applicazione dell’AI Act e i periodi transitori. Il principio di responsabilità dell’OCSE sostiene la tracciabilità di set di dati, processi e decisioni. Informazioni sul modo di lavorare di maitiq sono disponibili su maitiq.com.

Faccia esaminare il suo caso concreto da maitiq.