MCP su WordPress: quattro domande di governance prima di collegare l’AI al sito

Il difficile comincia il giorno dopo, perché in azienda è entrato un nuovo «ruolo»: un agente AI che può leggere il sito e, se glielo permetti, modificarlo. Va gestito come ogni altro accesso importante, anche se le guide tecniche non ne parlano e i piani IT tradizionali non sanno dove metterlo.

Ecco le quattro domande di governance che marketing e IT dovrebbero farsi prima di attivare il primo collegamento, per non scoprirle il giorno in cui l’AI pubblica per errore una bozza in home page.

Domanda 1: quale identità autorizza l’agente, e con quali permessi?

Ogni collegamento MCP entra con un’identità precisa: un utente WordPress, un’app installata o un’utenza tecnica dedicata (service account). L’agente può fare esattamente ciò che quell’identità può fare.

La scelta più comoda, usare un amministratore esistente, è la peggiore: l’agente eredita il potere su tutto, da contenuti e utenti a plugin, tema e struttura. Oltre al rischio per la sicurezza, togliergli un singolo permesso diventa difficile.

Meglio un’identità di servizio dedicata, con un ruolo WordPress su misura che dia all’agente solo i permessi necessari, come si fa con ogni utenza tecnica. Per la SEO bastano lettura completa, scrittura in bozza e modifica dei contenuti pubblicati, con traccia di ogni intervento.

Domanda 2: che cosa può fare l’agente in autonomia, e chi lo decide?

Fissati i permessi massimi, va deciso cosa l’agente fa senza chiedere e cosa richiede ogni volta il via libera di una persona.

Conviene scriverlo in una piccola griglia interna a tre livelli:

• Autonomia piena: operazioni poco rischiose e reversibili, come aggiungere il testo alternativo alle immagini o correggere uno slug (l’indirizzo della pagina) palesemente sbagliato. L’agente esegue, registra e avvisa.
• Approvazione in blocco: lavori ripetitivi come riscrivere 100 meta description, che l’agente prepara tutti insieme e applica dopo un solo ok di una persona.
• Approvazione caso per caso: operazioni strutturali o irreversibili, come pubblicare un articolo, modificare una pagina importante o cancellare qualcosa, ciascuna con la sua conferma.

Per costruirla bisogna sedersi una volta e classificare ogni tipo di operazione possibile. Ne vale la pena, perché senza griglia ogni intervento diventa una piccola decisione, e il team resta fermo o lascia fare troppo.

Domanda 3: come si passa da un sito a molti senza accumulare debito di governance?

Sul primo sito si fa tutto a mano: una persona crea l’identità, imposta i permessi e salva le credenziali in un file sul proprio computer, e fino al terzo sito funziona.

Dal quarto in poi, senza un metodo, si accumula debito di governance, cioè disordine su chi accede a cosa:

• I token finiscono sui computer di persone diverse.
• Per revocare un accesso bisogna intervenire su ogni sito.
• Nessuno cambia periodicamente i token.
• Quando qualcuno se ne va, nessun elenco centrale dice a cosa aveva accesso.

Le domande diventano: chi custodisce le credenziali MCP di tutti i siti, dove le tiene e ogni quanto le cambia?

Con tre-cinque siti basta un password manager condiviso che registri gli accessi. Da dieci in su conviene un sistema che cambi le chiavi in automatico, con un archivio protetto come Vault, AWS Secrets Manager o equivalenti. In ogni caso serve una persona responsabile delle credenziali, altrimenti il disordine cresce in silenzio.

Il costo tecnico è basso, e decidere subito evita di arrivare all’ottavo sito con un caos ormai impossibile da sistemare.

Domanda 4: ogni quanto rivediamo permessi e attività dell’agente?

I permessi dati all’inizio potrebbero restare fissi a due condizioni: che l’uso dell’agente non cambi e che la fiducia iniziale sia stata dosata bene.

Nella pratica nessuna delle due tiene. Dopo qualche settimana arrivano nuove richieste («possiamo fargli gestire anche le immagini?»), dopo qualche mese il registro delle attività mostra operazioni non previste: magari vanno benissimo, ma è meglio saperlo.

Serve quindi una revisione trimestrale con tre domande:

1. I permessi attivi sono ancora quelli giusti? Vanno ridotti o estesi?
2. Il registro delle attività riserva sorprese? Ci sono operazioni che non ricordavamo di aver autorizzato, o errori ripetuti su cui indagare?
3. I token sono stati cambiati di recente? Su quanti computer, e di chi, stanno i file di configurazione?

Basta un’ora ogni tre mesi, eppure è l’attività di governance che si salta più spesso.

Come marketing, IT e compliance si dividono il lavoro

Messe in fila, le quattro domande descrivono un progetto condiviso fra reparti, in cui l’IT è coinvolto dall’inizio e il marketing ha voce in capitolo:

• Il marketing decide per cosa usare l’agente, cosa può fare da solo e quale risultato ci si aspetta.
• L’IT decide come gestire l’identità di servizio, dove custodire le credenziali e ogni quanto cambiarle.
• La compliance verifica che i permessi rispettino le regole interne su dati personali, accessi privilegiati e registri delle attività.
• Il responsabile del processo, di solito chi ha proposto il progetto, coordina la revisione trimestrale.

Con questa organizzazione MCP entra in azienda in fretta e senza incidenti. Se invece «se ne occupa il marketing manager», dopo sei mesi il sistema non lo sa mantenere nessuno e un cambio di persona blocca tutto per giorni.

Poche ore oggi per evitare mesi di confusione domani

Se ti sembra tutto più complicato del previsto, guarda i tempi. Affrontate prima, le quattro domande chiedono tre-quattro ore di lavoro divise fra marketing, IT e compliance; lasciate aperte, tornano a sistema avviato come problemi veri e costano mesi di confusione.

Per la parte tecnica bastano nozioni base di amministrazione di sistema; la governance chiede una conversazione fra due o tre reparti, da fare una volta sola.

Un’AI che agisce sui sistemi aziendali è un ruolo nuovo: conviene decidere dal primo giorno chi è, che cosa può fare e chi la controlla.