Da qualche settimana ho sul tavolo un esperimento che mi diverte più di quanto dovrei ammettere: parlare ad Adobe Experience Manager in italiano. Non attraverso l’interfaccia, non con una query GraphQL scritta a mano, ma dicendo a Claude “trovami le pagine della sezione prodotti che non hanno una meta description” e vedendolo tornare con l’elenco. Sotto c’è il Model Context Protocol, lo standard che da un anno permette a un assistente come Claude di connettersi a sistemi esterni, e uno dei primi server MCP per AEM as a Cloud Service apparsi in queste settimane.
Voglio raccontarlo da builder, perché è il tipo di lavoro che mi distingue e perché — lo dico subito — questo incrocio tra chi conosce l’ecosistema Adobe e chi sa costruire con gli agenti è, secondo me, il vero vantaggio competitivo dei prossimi mesi. Non l’AI in astratto. L’AI innestata su una piattaforma che padroneggi davvero.
Cosa vuol dire “collegare Claude ad AEM”
Facciamo un passo indietro sul meccanismo, senza retorica. MCP è un protocollo aperto: definisce come un client (nel mio caso Claude) scopre e invoca gli tool esposti da un server. Da settembre esiste anche un Registry pubblico dei server, il che rende la scoperta meno artigianale di com’era all’inizio. I server MCP per AEM as a Cloud Service sono comparsi da poco e li tratto per quello che sono: early. Funzionano, ma li tengo su ambienti di author non di produzione e li guardo a vista.
Concretamente, il server espone verso Claude un set di operazioni sull’istanza di author: interrogare il repository dei contenuti, leggere le proprietà di una pagina, elencare gli asset di una cartella del DAM, verificare i metadati. Alcuni tool sono di sola lettura, altri consentono modifiche. La distinzione tra questi due mondi, per me, non è un dettaglio: è l’intera architettura di sicurezza del lavoro.
Cosa automatizzo davvero
Sfrondo l’entusiasmo e vado sul concreto. Le cose che oggi faccio girare in modo affidabile sono quasi tutte di lettura e di preparazione, non di scrittura cieca.
- Trovare pagine per criterio. “Elenca le pagine sotto
/content/sito/itmodificate dopo il primo settembre e non ancora pubblicate.” In AEM è una query che conosco benissimo, ma scriverla ogni volta è attrito. In linguaggio naturale è istantaneo, e Claude mi restituisce path, data di modifica e stato di replica. - Controllare asset e metadati. Su un progetto reale — un merchant fashion, GMV nell’ordine dei 15 milioni — mi serviva sapere quali immagini nel DAM erano prive di alt text o pesavano troppo prima di una migrazione. Un giro di conversazione al posto di mezza giornata di export e filtri.
- Preparare modifiche, non eseguirle. Questo è il punto che mi sta più a cuore. Chiedo a Claude di preparare l’aggiornamento dei metadati di venti pagine, di mostrarmi il diff proposto pagina per pagina, e di fermarsi lì. La scrittura vera è un secondo passo, deliberato.
- Audit di coerenza. Far confrontare la struttura di due sezioni, individuare template usati in modo incoerente, trovare i content fragment orfani. Lavoro noioso che un agente fa senza lamentarsi e senza sbagliare per stanchezza.
Quello che non automatizzo: pubblicazioni verso l’ambiente live, cancellazioni, modifiche di massa lanciate e dimenticate. Non perché la tecnologia non lo permetta, ma perché non voglio che lo faccia senza di me.
I gate di sicurezza che tengo
Qui viene la parte che, da consulente prima ancora che da builder, considero non negoziabile. Un agente che sa operare su un CMS è potente esattamente quanto è pericoloso se lo lasci correre. I miei tre gate sono semplici e non li salto mai.
Primo: backup e reversibilità. Prima di qualsiasi operazione di scrittura, mi assicuro che esista un punto di ripristino. AEM aiuta — le version delle pagine sono native — ma non mi fido dell’implicito: verifico che la versione precedente sia lì prima di toccare qualcosa. Se un’operazione non è reversibile con un gesto, non la delego.
Secondo: anteprima obbligatoria. Nessuna modifica va in scrittura senza che io abbia visto prima il diff proposto. Claude mi presenta “ecco le venti pagine, ecco il campo che cambierebbe, ecco il valore vecchio e quello nuovo”. Leggo, e solo allora dico di procedere. È il passaggio che trasforma l’agente da esecutore autonomo a collaboratore controllato.
Terzo: approvazione esplicita e ambiti separati. I tool di sola lettura girano liberi. I tool di scrittura richiedono un mio “sì” per ogni batch, e lavorano solo su author, mai in diretta su publish. La separazione tra ciò che l’agente può leggere e ciò che può scrivere è la prima cosa che configuro, prima ancora di iniziare a lavorare.
Sembrano precauzioni ovvie. Non lo sono: la tentazione, quando vedi funzionare la magia, è di alzare progressivamente l’autonomia finché un giorno l’agente scrive su produzione senza che tu abbia guardato. Il mio lavoro è resistere a quella tentazione, e costruire il processo perché resistere sia la strada più comoda, non quella più faticosa.
Perché questo incrocio è il vantaggio competitivo
Arrivo alla tesi. In queste settimane vedo due popolazioni distinte. Ci sono gli esperti Adobe che guardano gli agenti con diffidenza, come all’ennesima moda. E ci sono i costruttori di AI che parlano di CMS senza aver mai gestito un rollout multilingua o un launch con dieci stakeholder che litigano sulla home.
Il valore, secondo me, sta esattamente in mezzo, ed è un posto scomodo e poco affollato. Per far fare a Claude qualcosa di utile su AEM devi sapere cosa chiedergli — e per saperlo devi conoscere il modello dei contenuti di AEM, le insidie della replica, il modo in cui i content fragment si legano alle pagine. L’agente amplifica la competenza di dominio, non la sostituisce. Chi non conosce AEM chiederà a Claude le cose sbagliate, e le otterrà, il che è peggio.
Per questo continuo a investire su entrambi i fronti: le certificazioni Adobe da un lato, la pratica quotidiana con Claude e MCP dall’altro. Non perché faccia scena, ma perché è l’unico modo che conosco per stare dove il valore si sta spostando davvero. L’AI agentica su piattaforme enterprise non premia chi arriva prima con lo strumento. Premia chi sa cosa farci.
Dove sono i limiti, oggi
Per onestà da builder: i server MCP per AEM as a Cloud Service sono giovani. La copertura dei tool è parziale, la gestione degli errori a volte grezza, e su repository grandi le query vanno pensate per non chiedere troppo tutto insieme. Non ci costruirei sopra un processo di produzione mission-critical, non ancora. Ma per ridurre l’attrito quotidiano, per gli audit, per la preparazione del lavoro — funziona già oggi, e la traiettoria è chiara. Tra sei mesi ne riparliamo, e scommetto che questa conversazione sembrerà preistoria.
Mini-FAQ
Serve saper programmare per usare Claude su AEM via MCP? No per interrogare i contenuti: si parla in linguaggio naturale. Serve però conoscere il modello dei contenuti di AEM per porre le domande giuste e per validare le risposte.
Claude può pubblicare pagine da solo su AEM? Tecnicamente alcuni tool lo permetterebbero, ma nella mia configurazione no. Tengo la scrittura su ambiente di author, con anteprima del diff e approvazione manuale per ogni batch.
È sicuro collegare un agente AI al CMS aziendale? Lo è se separi i tool di lettura da quelli di scrittura, garantisci reversibilità con backup e version, e imponi un’approvazione esplicita prima di ogni modifica. Senza questi gate, non lo è.
Perché usare MCP invece delle API dirette di AEM? Le API restano lo strumento per l’automazione strutturata. MCP serve a un altro scopo: dare a un assistente conversazionale un modo standard per scoprire e usare quelle capacità, abbassando l’attrito delle attività esplorative e di preparazione.
Chi sono. Sono un consulente Adobe presso il gruppo Lutech, certificato su Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Da tempo unisco la competenza sull’ecosistema Adobe alla pratica dell’AI agentica — Claude, il Model Context Protocol e i primi server che collegano gli assistenti alle piattaforme enterprise. Scrivo di quello che costruisco davvero, con i suoi limiti.