Il setup tecnico è la parte facile
La parte tecnica di un collegamento MCP su WordPress, una volta capito il pattern, è una procedura ripetibile di trenta minuti. È documentata nella guida operativa parallela: installa il plugin giusto, genera un token, configura il client, fai un test. Fine.
La parte difficile inizia il giorno dopo. Quando il connettore è attivo, un nuovo “ruolo” è entrato nella tua organizzazione digitale: un agente AI con accesso a leggere e (potenzialmente) modificare il CMS aziendale. Quel ruolo va governato come si governa qualunque altro accesso strutturale. La differenza è che le guide tecniche non se ne occupano, e i piani IT classici non hanno categorie per descriverlo.
Questo articolo è la lista delle quattro domande di governance che ogni CMO, direttore marketing o IT manager dovrebbe porsi prima di mettere il primo connettore in produzione — non dopo aver scoperto che il modello ha pubblicato per errore una bozza di test sulla home.
Domanda 1 — Chi è l’identità che autorizza l’agente, e con quali permessi?
Ogni connettore MCP autentica come un’identità precisa: un utente WordPress, un’app installata, un service account. Le permessi che quell’identità ha sul CMS sono esattamente quelli che l’agente può esercitare. Non di più, non di meno.
La scelta più comoda — autorizzare con un utente admin esistente — è anche la peggiore. Significa che l’agente eredita potere su tutto: contenuti, utenti, plugin, tema, struttura del sito. Non è solo un rischio di sicurezza: è anche difficile da revocare in modo selettivo se serve.
La scelta corretta è creare un’identità di servizio dedicata all’agente, con un ruolo WordPress custom che espone solo i permessi che servono per il caso d’uso effettivo. Per la SEO: lettura completa, scrittura in stato bozza, modifica contenuti pubblicati con audit. Niente di più.
Sembra una distinzione tecnica, è invece una distinzione di governance: l’agente non è una persona, e non deve avere il profilo di una persona. Va trattato come un service account, con il principio del minimo privilegio applicato esplicitamente.
Domanda 2 — Quale processo decide che cosa l’agente può fare in autonomia?
Una volta definiti i permessi massimi dell’agente, resta la domanda operativa: quali operazioni effettivamente lasciamo che esegua senza approvazione umana, e quali richiedono un’autorizzazione esplicita ogni volta?
Distinzione che vale la pena formalizzare in una piccola griglia interna, con tre livelli:
- Autonomia piena: operazioni a basso rischio reversibili (es. aggiunta di alt text mancanti, correzione di slug palesemente errati). L’agente esegue, traccia, notifica.
- Approvazione per batch: operazioni ripetitive su molti oggetti (es. riscrittura di 100 meta description). L’agente propone l’intero batch, un umano approva con un solo ok, l’agente applica.
- Approvazione per istanza: operazioni strutturali o irreversibili (es. pubblicazione di un articolo, modifica di pagine importanti, cancellazioni). Una conferma per ogni singola operazione.
La griglia non è ovvia: richiede di sedersi e classificare esplicitamente, una volta, ogni tipo di operazione che l’agente potrebbe eseguire. Ma è la differenza tra “abbiamo MCP” e “MCP fa parte del nostro modo di lavorare”. Senza questa griglia, ogni operazione richiede una micro-decisione e il team finisce per non muoversi o per muoversi troppo.
Domanda 3 — Come si scala da un sito a N siti senza moltiplicare il debito di governance?
Il setup del primo sito è gestibile artigianalmente: una persona crea l’identità, configura i permessi, mette le credenziali nel file di config locale del client. Tutto va bene fino al sito numero tre.
Dal sito numero quattro in poi, senza una struttura, il setup inizia a creare debito di governance:
- I token sono sparsi su macchine diverse di persone diverse.
- Le revoche richiedono passaggi manuali su ogni sito.
- Le rotazioni periodiche dei token non si fanno mai.
- Quando un membro del team lascia l’azienda, non c’è un registro centrale di cosa avesse accesso.
La domanda diventa allora: chi è il custode delle credenziali MCP del network? Dove sono memorizzate? Con che frequenza vengono ruotate?
Per un’azienda con tre-cinque siti la risposta minima è un password manager condiviso, con accessi tracciati. Per dieci siti o più, vale la pena valutare un piccolo sistema di rotazione automatica con secret manager (Vault, AWS Secrets Manager, equivalenti). In tutti i casi, va definito chi è la persona responsabile del registro: senza un proprietario chiaro, il debito di governance si accumula in silenzio.
Non è un costo tecnico significativo. È una decisione che, presa fin dall’inizio, evita di trovarsi a sito numero otto con un caos non più sanabile.
Domanda 4 — Con che frequenza rivediamo permessi e attività dell’agente?
I permessi concessi all’agente a setup time non sono permanenti. Lo dovrebbero essere, almeno, sotto due condizioni: che il caso d’uso non cambi, e che il livello di fiducia nell’agente non sia stato calibrato male all’inizio.
Entrambe le condizioni, nella pratica, si violano. Dopo qualche settimana di operatività emergono nuovi casi d’uso (“possiamo far gestire all’agente anche le immagini?”). Dopo qualche mese, dall’audit log, può emergere che l’agente sta facendo cose che inizialmente non erano previste — magari va benissimo, ma vale la pena saperlo.
La pratica sana è una revisione trimestrale, con tre domande:
- I permessi attivi sono ancora quelli giusti? Vanno ridotti? Vanno estesi?
- L’audit log mostra qualcosa di inaspettato? Operazioni che non ricordavamo di aver autorizzato? Errori ripetuti su cui vale la pena indagare?
- I token sono stati ruotati di recente? Chi ha accesso ai file di config locali su quante macchine?
Una revisione di un’ora ogni tre mesi. Tipicamente la più trascurata delle attività di governance — e tipicamente la più importante.
Cosa cambia nel piano IT e marketing
Mettendo insieme le quattro domande, il profilo della “funzione MCP” in azienda diventa chiaro. Non è un esperimento del marketing che IT non sa nemmeno esista. Non è nemmeno una pura iniziativa IT che il marketing subisce. È una funzione cross-funzionale, con responsabilità divise:
- Marketing decide quali casi d’uso attivare, quali operazioni vanno in autonomia, quali no, qual è il valore atteso.
- IT decide come è gestita l’identità di servizio, dove sono custodite le credenziali, con che frequenza ruotano.
- Compliance valida che i permessi concessi siano coerenti con le policy interne (dati personali, accessi privilegiati, log di audit).
- Il proprietario del processo — di solito chi ha proposto l’iniziativa — coordina la revisione trimestrale.
Le aziende che impostano fin dall’inizio questa struttura adottano MCP velocemente e senza incidenti. Quelle che lasciano che “se ne occupi il marketing manager” trovano dopo sei mesi un setup non manutenibile, in cui un cambio di persona blocca l’intera infrastruttura per giorni.
Non è burocrazia, è quello che evita la burocrazia
Una possibile reazione a queste quattro domande è: “ma allora è più complicato del previsto”. In realtà è esattamente il contrario. Le quattro domande messe a fuoco prima del setup richiedono tre-quattro ore totali di lavoro distribuite tra le funzioni interessate. Le stesse domande lasciate aperte costano mesi di confusione organizzativa quando emergono come problemi reali a sistema già in produzione.
La parte tecnica di MCP su WordPress è alla portata di qualunque team con competenze minime di amministrazione di sistema. La parte di governance richiede una conversazione tra due o tre funzioni aziendali — ma è una conversazione che si fa una volta e dura.
L’AI agentica entra nelle organizzazioni come un nuovo ruolo silenzioso. Definirne identità, permessi, processo di revisione fin dal primo giorno è il modo più economico di evitarsi due anni di toppa.
Per il framework di maturità MCP nei workflow di marketing — i tre livelli di adozione e i prerequisiti di ciascuno: la guida operativa.