Un team vendite si riprende 10.000 ore al mese
Nel maggio 2026, Cloudflare ha lasciato silenziosamente che persone estranee alla propria organizzazione di ingegneria iniziassero a costruire software. Non a testarlo, non a richiederlo con un ticket: a costruirlo loro stessi. Addetti alle vendite, personale di supporto e altri dipendenti non tecnici hanno ricevuto accesso a Cloudflare OS, una piattaforma interna che consente loro di assemblare agenti e app IA ancorati ai dati propri dell'azienda e collegati ai suoi sistemi interni.
Il primo numero emerso è stato netto. Il team vendite di Cloudflare ha dichiarato di risparmiare oltre 10.000 ore al mese da quando il proprio personale costruisce strumenti sulla piattaforma invece di aspettare l'ingegneria. Sono ore recuperate, non una previsione sulla produttività futura.
4.000 app, costruite da chi non scrive codice
Cloudflare ha reso noti i numeri più ampi il 5 agosto 2026, pubblicando due articoli sul proprio blog, "Cloudflare OS" e un pezzo di accompagnamento intitolato "How We Use AI with Cloudflare OS", rendendo al contempo la piattaforma open source per l'uso al di fuori dell'azienda. Nei primi 30 giorni dopo che i non ingegneri hanno ottenuto l'accesso, i dipendenti hanno costruito oltre 4.000 app proprie.
Per procedere a questo ritmo, Cloudflare ha reclutato 1.111 stagisti specificamente per aiutare a radicare la piattaforma in tutta l'azienda, mostrando ai team cosa potesse fare per il proprio flusso di lavoro un agente ancorato al contesto aziendale, invece di aspettare che la domanda emergesse da sola.
La stessa piattaforma rivede il proprio codice
Cloudflare OS non è stata usata solo per costruire app; è stata messa al lavoro anche per verificarle. In quattro mesi, la revisione del codice basata su IA della piattaforma ha segnalato circa 250.000 problemi e bloccato 16.000 richieste di merge prima che raggiungessero la produzione.
Per il rollout esterno, Cloudflare lancia la piattaforma con due partner di lancio, Presidio e Happy Cog, accompagnata da un articolo complementare, "The Agent Access Model", che espone la progettazione di sicurezza dietro tutto questo.
Il vero prodotto è il modello di accesso, non le app
Le 4.000 app non sono davvero la notizia. Ciò che ha permesso ai non ingegneri di costruirle in sicurezza è stato il modello di accesso sottostante: Cloudflare lo ha strutturato attorno all'identity brokering, così che un agente IA riceve un permesso limitato e basato sull'identità per toccare un solo sistema interno specifico. Non è un'altra funzione IA aggiunta sopra gli accessi esistenti: è un'impostazione predefinita diversa, in cui un agente si autentica come se stesso, limitato a un compito, invece di ereditare l'accesso già detenuto dal proprio operatore umano.
I numeri della revisione del codice illustrano lo stesso punto da un'altra angolazione. 250.000 problemi segnalati e 16.000 richieste di merge bloccate non sono un team di sicurezza che intercetta errori dopo che il codice è stato pubblicato; sono il modello di accesso applicato alle modifiche del codice stesse, che decide proprio al momento della richiesta di merge cosa un agente, o una persona che opera attraverso di esso, può far avanzare. La governance risiede nello strato di accesso, non in una coda di revisione aggiunta successivamente.
Cosa dovrebbe portarsi a casa un operatore UE o UK dal 5 agosto
Qualsiasi azienda dell'UE o del Regno Unito che valuti un'adozione interna di IA dopo il 5 agosto 2026 sarà spinta verso la domanda a cui Cloudflare ha risposto per prima: un agente IA riceve un ampio accesso di rete perché è più comodo da configurare, oppure riceve un accesso limitato e basato sull'identità esattamente ai sistemi richiesti dal suo compito? La seconda opzione richiede più lavoro preliminare, ed è quella che Cloudflare sta ora rendendo open source e raccomandando.
In pratica, un operatore UE o UK che sperimenta un rollout simile dovrebbe trattare l'identity brokering, non un'ennesima interfaccia di chat, come la voce di budget e la decisione di governance. I numeri di Cloudflare stessa, 4.000 app in 30 giorni e 16.000 richieste di merge bloccate in quattro mesi, mostrano come appare l'accesso limitato quando funziona su larga scala, e costituiscono un parametro ragionevole per chiedere a un fornitore o a un team interno di spiegare perché il proprio rollout non si avvicini nemmeno lontanamente.
Da leggere ora: Microsoft riduce di dieci volte i costi degli agenti | Il modello è cambiato, il nome API no



