Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.
La settimana in cui un conteggio di tool ha smesso di valere come disclosure
La release note più importante che ho letto questa settimana era costituita da una frase.
L’undici di agosto il feed What’s New di Klaviyo ha aggiunto una voce intitolata “Klaviyo MCP Server, New Tools”. Il testo dice, per intero, che potete dare ad agenti AI e sviluppatori il controllo programmatico completo del vostro account Klaviyo, usando 260 o più nuovi tool MCP per leggere dati, costruire segmenti, far girare campagne, scrivere flow e gestire cataloghi, da Claude, da OpenAI o dal vostro agente.
È la superficie agentica più ampia che una customer engagement platform sulla mia watchlist abbia mai messo per iscritto.
TL;DR
- Klaviyo ha pubblicato la superficie agentica più ampia della mia watchlist e nessuno dei numeri che servirebbero a governarla. 260 e più tool MCP con quattro verbi di scrittura dichiarati, in una frase, senza durata di sessione, senza modello di ereditarietà dei permessi e senza percorso di revoca. Il vendor che ha pubblicato gli unici numeri di governance, MoEngage, ha una superficie molto più piccola.
- Cinque fatti rendono governabile un inventario di tool: il conteggio diviso fra lettura e scrittura, l’elenco delle scritture, la durata di sessione assoluta e per inattività, il modello di ereditarietà dei permessi e quanto tempo impiega una revoca completa a propagarsi. Abbiamo accettato per MCP uno standard più basso di quello che abbiamo mai accettato per una API key.
- In quattro giorni il percorso di opt-out è diventato programmabile, tracciabile e sanzionabile. Twilio ha permesso a un record di consenso di rimuovere un blocco imposto dal carrier, CalPrivacy ha multato un data broker per 116.490 dollari perché aveva messo le cifre del codice fiscale a guardia di quello stesso percorso, e IAB Tech Lab ha finalizzato DDRF 2.0, che mette una asserzione di identità firmata dentro una richiesta di cancellazione.
- L’identità per la personalizzazione e l’identità per le richieste di diritti sono due problemi diversi con strutture di costo opposte. Nella personalizzazione un falso positivo costa poco, quindi le soglie vengono tarate in modo generoso. In una richiesta di diritti un falso positivo cancella i dati della persona sbagliata, e l’istinto di compensare chiedendo più identificatori è esattamente ciò che la California ha già sanzionato due volte.
Il numero che Klaviyo ha pubblicato, e i due che non ha pubblicato
Partiamo da ciò che la frase dice davvero, perché è più specifica del linguaggio vendor abituale e questo va riconosciuto. Duecentosessanta tool è un numero vero. Klaviyo non ha scritto “capacità MCP ampliate” o “integrazione agentica più profonda”. Ha detto quanti, e ha nominato quattro verbi che sono inequivocabilmente scritture: costruire segmenti, far girare campagne, scrivere flow, gestire cataloghi. Nessuno che legga quella frase può fingere che si tratti di una superficie di sola lettura con sopra un wrapper di protocollo alla moda. Un agente collegato a tutto questo può creare la cosa che manda email ai vostri clienti.
Adesso guardate cosa manca, e notate che le assenze non sono esotiche. Non c’è una durata di sessione pubblicata, quindi nessuno fuori da Klaviyo sa per quanto tempo una connessione agentica autorizzata resta autorizzata. Non c’è un modello di permessi nella nota, quindi nessuno sa se questi 260 tool ereditino i permessi della persona che li ha autorizzati, girino con una service identity più ampia, o possano essere delimitati in qualche modo. Non c’è una dichiarazione su cosa un agente che scrive una campagna possa fare che un operatore non potrebbe, che è l’unica domanda che vi dice se il vostro workflow di approvazione attuale significhi ancora qualcosa.
La settimana scorsa MoEngage ha pubblicato le durate di sessione del suo MCP: trenta giorni, o sette giorni di inattività, gestite indipendentemente dalle sessioni di dashboard e mobile. Ho scritto sul fronte AI in quel momento che sembravano i primi numeri di sessione concreti che qualcuno avesse messo per iscritto per una superficie MCP di un vendor, e che erano la domanda di riferimento da portare a ogni altro vendor. Da allora nulla li ha sostituiti. Abbiamo quindi un mercato in cui il vendor con il conteggio di tool più alto non ha pubblicato numeri di governance, e il vendor con gli unici numeri di governance pubblicati ha una superficie molto più piccola. Lo intendo come la descrizione di una prassi di disclosure che non si è ancora assestata e significa che la domanda d’acquisto ha cambiato forma. Sei mesi fa la domanda utile era se un vendor avesse un server MCP. Ogni CEP importante ha risposto di sì entro maggio. La domanda utile adesso è quanti tool, quali di questi scrivono, e cosa impedisce a un agente di far partire una campagna alle tre di notte perché un prompt era ambiguo.
Cosa dovrebbe dire davvero un inventario di tool con capacità di scrittura
Ho iniziato a tenere una lista breve di ciò che voglio che un vendor pubblichi prima di lasciare che un agente si avvicini a una piattaforma di engagement in produzione, e nasce dallo stesso istinto con cui si giudicano le dichiarazioni di agentic marketing, cioè da ciò che un vendor è disposto a mettere per iscritto. Questa settimana le ha dato un contorno più netto. Sono cinque voci e nessuna è irragionevole.
Il conteggio dei tool, diviso fra lettura e scrittura. Klaviyo ha dato il conteggio e ha lasciato intuire la divisione; nessuno ha dato entrambe le cose in modo esplicito. L’elenco delle scritture, enumerato, perché “gestire cataloghi” copre sia l’aggiornamento di un prezzo sia la cancellazione di un catalogo. La durata di sessione, assoluta e per inattività, che MoEngage ha pubblicato e quasi nessun altro. Il modello di ereditarietà dei permessi: l’agente agisce come l’utente che lo autorizza, come un service principal, o come qualcosa di nuovo che il vostro identity provider non ha mai visto. E il percorso di revoca, cioè cosa fa un team di sicurezza alle due di notte quando deve eliminare ogni connessione agentica, e quanto tempo impiega a propagarsi.
Nulla di tutto questo è una richiesta di rallentare. È la richiesta della stessa documentazione che qualsiasi altra integrazione porta con sé da vent’anni. Quello che colpisce del momento attuale è che abbiamo accettato per MCP uno standard più basso di quello che abbiamo mai accettato per una API key, in larga parte perché il protocollo è arrivato vestito da comodità per sviluppatori più che da integrazione.
Un conteggio di tool vi dice cosa un agente può raggiungere. Una durata di sessione, un elenco di scritture e un percorso di revoca vi dicono cosa lo ferma.
Twilio rende il consenso autorevole sopra il carrier
Il secondo filone della settimana non ha nulla a che fare con gli agenti, ed è quello su cui mi aspetto di dover riscrivere documenti di architettura per i clienti.
Il dodici di agosto Twilio ha rilasciato nella sua Consent Management API il supporto agli override di opt-out a livello di rete per i numeri toll-free. Fino a ora, se un destinatario negli Stati Uniti o in Canada faceva opt-out su un numero toll-free, quel blocco veniva applicato a livello di rete e c’era esattamente un modo per rimuoverlo: il destinatario doveva rispondere con una keyword di opt-in. Non contava cosa dicesse il vostro CRM, cosa registrasse il vostro preference centre, o cosa il cliente avesse detto a un operatore del servizio. La soppressione viveva fuori dal vostro modello dati e il vostro modello dati non poteva raggiungerla.
Adesso non è più così. Quando un destinatario dà un consenso valido di re-opt-in attraverso un altro canale, un form web, un’email, un preference centre in-app, potete registrare quel consenso attraverso la Consent Management API e Twilio passa il segnale a valle per rimuovere il blocco. Twilio inquadra il beneficio in termini di deliverability, come l’eliminazione dei codici di errore 21610 e 30004, che è l’inquadramento commerciale onesto e sottovaluta ciò che è cambiato davvero.
Quello che è cambiato è la collocazione dell’autorità. Una soppressione imposta dal carrier era uno stato terminale che il vostro profilo poteva osservare ma mai modificare. Adesso è uno stato che il vostro record di consenso può cambiare, attraverso una API, con l’evidenza conservata dalla vostra parte del confine. Significa che l’oggetto consenso nella vostra piattaforma ha appena acquisito un potere reale a valle su una rete che la piattaforma non controlla, che è la stessa promozione ottenuta dal pixel di tracciamento delle aperture la settimana scorsa, quando è diventato un attributo di profilo, e significa che la qualità di quell’oggetto conta adesso in un modo in cui non contava il mese scorso. Se il vostro record di consenso non sa dire quale finalità, quale giurisdizione, quale canale, quando e su quale evidenza, vi è appena stata consegnata una API che non siete attrezzati a chiamare in modo responsabile.
La California rende sanzionabile l’attrito nel percorso di opt-out
L’undici di agosto, lo stesso giorno della nota di Klaviyo, il board della California Privacy Protection Agency ha ordinato a un data broker chiamato LocateSmarter di pagare 116.490 dollari e di modificare le proprie prassi. Due contestazioni. Non si era registrato come data broker nei tempi previsti, che è amministrativo. E richiedeva ai cittadini californiani di fornire le ultime quattro cifre del proprio numero di Social Security prima di poter fare opt-out dalla vendita dei propri dati personali.
La seconda contestazione va letta due volte. CalPrivacy sostiene che pretendere parte di un numero di Social Security possa intimidire i consumatori al punto da non esercitare un diritto che hanno, e separatamente che ciò violi il requisito di minimizzazione dei dati del CCPA, in linea con l’enforcement advisory che l’agenzia stessa ha pubblicato a gennaio su come la minimizzazione si applichi alle richieste dei consumatori. È la prima azione di CalPrivacy contro un data broker sotto il CCPA e la prima nata sotto CCPA e Delete Act insieme, e segue una decisione contro Ford a marzo, una sanzione da 375.703 dollari comminata esplicitamente per aver aggiunto attrito non necessario al processo di opt-out.
C’è un ultimo dettaglio che elimina la difesa più ovvia. Il direttore esecutivo dell’agenzia ha osservato che la sanzione è stata consistente anche se solo una manciata di consumatori aveva effettivamente inviato richieste di opt-out. Il volume basso non è un’attenuante. La contestazione si attacca al disegno del percorso, non a quante persone lo abbiano percorso.
Le richieste di cancellazione si dotano di una asserzione di identità
Lo stesso giorno, IAB Tech Lab ha pubblicato aggiornamenti al suo Privacy Standards Portfolio. La parte ripresa dalla stampa di settore è stata il lavoro sulla Global Privacy Platform, e la parte che conta dal punto di vista architetturale è stata appena menzionata.
Due correzioni prima della sostanza, perché stavo per ripeterle entrambe. La notizia è datata undici di agosto, non dodici, che è la data in cui l’aggregatore che l’ha rilanciata ha pubblicato il proprio riassunto. E quel riassunto descriveva il rilascio come se richiedesse il supporto ai segnali Global Privacy Control, cosa che nel documento primario non compare affatto. Le modifiche a GPP sono una bozza in consultazione pubblica, aperta fino all’undici di settembre, e riguardano l’allineamento al Quinto Multi-State Privacy Agreement emendato: rimozione della copertura MSPA per il vecchio approccio stato per stato, eliminazione delle modalità Service Provider e Opt-Out Option, rimozione dei consensi per uso secondario, e semplificazione dei campi di informativa e scelta.
La parte finalizzata è il Data Deletion Request Framework, versione 2.0, che chiude una consultazione aperta a fine 2025. Fra le sue revisioni: definizioni chiarite dei JSON Web Token di identità e di richiesta di cancellazione, feedback sui risultati e troubleshooting migliorati, integrità del framework rafforzata, e supporto a estensioni specifiche per implementazione.
Detta semplicemente, una richiesta di cancellazione adesso arriva portando con sé una asserzione firmata e strutturata su chi sia il soggetto. Non è un artefatto legale. È uno schema, e il vostro identity graph o sa risolverlo o non sa risolverlo. Gran parte del tooling di cancellazione che ho visto prende un indirizzo email, applica la stessa logica di match che alimenta la personalizzazione, e cancella ciò che trova. DDRF 2.0 descrive una richiesta che dice qualcosa di più preciso di un indirizzo email, e i sistemi che sapranno agire su di essa con accuratezza saranno quelli il cui modello di identità è stato costruito per rispondere a domande più che per massimizzare i match.
Un regolatore, un provider di messaggistica e un ente di standard, in quattro giorni, tutti al lavoro sullo stesso percorso di uscita.
I due problemi di identità che quasi tutti gli stack risolvono una volta sola
Leggete insieme la decisione californiana e la revisione DDRF e viene a fuoco un difetto di progettazione preciso, che io stesso ho costruito nei sistemi senza accorgermene.
Quasi ogni stack su cui ho lavorato ha una sola capacità di identity resolution, collocata dove la CDP fa la risoluzione. È stata costruita per la personalizzazione, e la personalizzazione ha un bias particolare: un falso positivo costa poco e un falso negativo costa molto. Se unite due record che appartengono a persone diverse, qualcuno riceve una raccomandazione di prodotto leggermente sbagliata. Se non riuscite a unire due record che appartengono alla stessa persona, mandate posta duplicata, frammentate il profilo e perdete i ricavi con cui l’intero investimento era stato giustificato. Così la soglia viene tarata in modo generoso, il grafo viene costruito per trovare connessioni, e tutti sono contenti.
Poi arriva una richiesta di esercizio dei diritti, e gli incentivi si invertono completamente. Adesso un falso positivo significa cancellare o sopprimere i dati della persona sbagliata, e un falso negativo significa non onorare un diritto previsto dalla legge. La struttura di costo che giustificava una soglia generosa non vale più, e l’istinto ingegneristico ovvio è compensare chiedendo a chi presenta la richiesta più informazioni identificative fino a essere sicuri. Quell’istinto è esattamente ciò che la California ha appena sanzionato, due volte, nello stesso anno.
Il percorso delle richieste di diritti ha quindi bisogno di una soglia di verifica più severa della personalizzazione sull’accuratezza e insieme più frugale sulla raccolta di dati. Questi due requisiti tirano in direzioni opposte e non potete soddisfarli entrambi riusando una sola funzione di match con una manopola girata. Vi trovate davanti a un secondo problema di identità con una funzione obiettivo diversa, e merita un progetto suo. Non credo che molte organizzazioni lo abbiano costruito così, e il registro degli enforcement ha reso quella mancanza costosa anziché teorica.
La personalizzazione rende i falsi positivi economici. Una richiesta di diritti li rende tutto il rischio. Stesso grafo, funzioni obiettivo opposte.
La settimana più tranquilla di Adobe, e lo schema che c’è sotto
Il resto della settimana è stato Adobe, ed è stato migliore di quanto il titolo suggerisca.
Adobe Journey Optimizer ha aggiunto il dodici di agosto gli allegati PDF personalizzati nelle email attivate via API. Fino a cinque per messaggio, statici o specifici per destinatario, con i file specifici per destinatario recuperati dalla Data Landing Zone al momento dell’invio e la posizione di ciascun file passata nel payload della API. La restrizione è reale, solo campagne transazionali attivate via API, ma la parte interessante è lo schema: Adobe non genera la fattura, raccoglie quella che il vostro sistema esistente ha già prodotto, nel momento dell’invio, da una posizione che controllate voi. Per chiunque abbia provato a spostare la consegna di estratti conto o documenti di polizza su una customer engagement platform e si sia arenato sulla questione della generazione documentale, quella è la forma di integrazione che lo rende possibile. Significa anche che il percorso di invio ha adesso una dipendenza a runtime da uno strato di storage, che va nella vostra analisi dei guasti e probabilmente non c’è.
Lo stesso giorno AJO ha aggiunto LINE come canale in Limited Availability, ed è arrivato attraverso il Custom outbound channel rilasciato il trentuno di luglio anziché come integrazione su misura. Treasure AI aveva reso LINE un canale di prima classe per le Always-on Campaign nove giorni prima e il dieci aveva rilasciato il flag di test-send nei log di consegna LINE. Due vendor, una finestra, un canale che le roadmap occidentali hanno storicamente trattato come un progetto di integrazione più che come un canale.
Journey Optimizer B2B ha iniziato oggi il deploy di 2026.8, portando le person journey dalla beta alla disponibilità generale insieme a person list, variant split path, rientro in journey e nodi di azione esterna sul lato persona. Il disegno a due modelli che rendeva quel prodotto difficile da spiegare sta convergendo. E Adobe Marketo Engage ha pubblicato il dieci le release note di agosto dopo un silenzio che durava dal diciotto di giugno, con una nuova interfaccia, uno Script Builder AI per gli script di personalizzazione, e un piccolo elemento che risparmierà a qualcuno un incidente in produzione: archiviare una cartella adesso disabilita e rimuove dalla schedulazione ogni campagna al suo interno.
Cosa chiedere ai vostri vendor lunedì
Tre domande, e sono tutte versioni della stessa.
Chiedete a ogni piattaforma con un server MCP il conteggio dei tool diviso fra lettura e scrittura, la durata di sessione e il percorso di revoca. Se la risposta è un elenco di capacità anziché tre numeri, avete imparato qualcosa. Chiedete alla vostra architettura di consenso se sappia esprimere finalità, giurisdizione, canale, timestamp ed evidenza come campi separati, perché Twilio ha appena reso quel record autorevole su una rete che non controllate e il prossimo provider a fare lo stesso non vi aspetterà. E chiedete a chi possiede l’identity resolution di mostrarvi il percorso delle richieste di diritti, in modo specifico, come cosa distinta dal percorso della personalizzazione. Se è lo stesso codice con una soglia diversa, avete il progetto su cui la California ha già sanzionato due aziende.
Un conteggio di tool è una dichiarazione di capacità. Una durata di sessione, un elenco di scritture e un percorso di revoca sono una dichiarazione di governance. Questa settimana un vendor ha pubblicato la prima e nessuno ha pubblicato la seconda, e la distanza fra le due è tutto il rischio.
Fonti
Server MCP e Composer di Klaviyo
Consent management di Twilio
Enforcement californiano
Standard privacy di IAB Tech Lab
Rilasci Adobe di questa settimana
- Journey Optimizer release notes
- Journey Optimizer B2B Edition release notes
- Marketo Engage release notes
Altri rilasci vendor di questa settimana
Il digest alla base di ogni articolo settimanale è prodotto attraverso una scansione strutturata, assistita dall’AI, di release note ufficiali e fonti di product update. Io rivedo l’output, verifico i segnali rilevanti e scrivo l’interpretazione architetturale.
Questo articolo si basa sulle scansioni del Martech Weekly Digest eseguite il 14 agosto 2026, che coprivano release note e aggiornamenti di prodotto su diverse piattaforme CEP e vendor. Il record datato che ne sta alla base è in MarTech Watch, Settimana 33.
Se trovate errori o lacune nella copertura, voglio saperlo. Il processo migliora quando l’output viene messo in discussione.
