TL;DR: tra il 28 luglio e il 3 agosto 2026 l’AI aziendale ha iniziato a mostrare il suo vero pannello di amministrazione. Meta porta il supporto clienti sul consumo a token; GitHub misura l’attività per utente e consente di limitare modelli, client e controllo remoto. Per PMI e professionisti la priorità è collegare ogni euro e ogni permesso a un risultato.
Le notizie più utili degli ultimi giorni non presentano un modello più potente. Mostrano come le piattaforme vogliono vendere e amministrare l’AI quando entra nel lavoro quotidiano. Il filo è economico prima ancora che tecnico: chi usa quale modello, da quale dispositivo, con quanti token e per ottenere cosa. Se queste domande non hanno risposta, un progetto AI resta una spesa condivisa senza proprietario.
Meta passa dal messaggio al token
Dal 1° agosto Meta Business Agent su WhatsApp Business Platform usa un pricing basato sui token, secondo Economic Times. Meta aveva presentato l’agente come strumento per rispondere ai clienti, consigliare prodotti, qualificare lead e passare una conversazione a un operatore. Nel suo annuncio ufficiale dichiarava oltre un milione di aziende attive su WhatsApp e Messenger e anticipava offerte a pagamento.
Il cambio di unità modifica il controllo di gestione. Una conversazione lunga, un prompt ripetitivo o un catalogo caricato male non incidono soltanto sulla latenza: aumentano il costo del servizio. Il KPI utile non è il numero di messaggi gestiti. È il costo per richiesta risolta, insieme al tasso di passaggio a un umano e al valore commerciale prodotto.
GitHub attribuisce il consumo ai singoli utenti
Il 28 luglio GitHub ha esteso le metriche della Copilot app. I report enterprise e organizzazione possono ora attribuire l’attività ai singoli utenti e includere sessioni, richieste, prompt e consumo di token. I dati distinguono anche modello, linguaggio e superficie di utilizzo.
Questa è la differenza tra comprare licenze e amministrare un servizio. Sapere che venti persone hanno accesso non dice se lo strumento riduce tempi di sviluppo o genera solo richieste costose. La telemetria per utente permette di confrontare adozione, output e costo, ma va letta con una metrica di risultato: pull request accettate, tempo di revisione, errori riaperti o ticket risolti.
Il controllo remoto viene legato ai dispositivi gestiti
Il 30 luglio GitHub ha aggiunto controlli per le sessioni Copilot comandate da remoto. Gli amministratori possono richiedere autorizzazione SSO, bloccare la funzione oppure consentirla; la policy può essere distribuita dal server, tramite MDM o con un file sui dispositivi.
Il dettaglio importante è il perimetro. La stessa persona può lavorare da un portatile aziendale aggiornato o da una macchina personale senza gestione centrale. Trattare i due contesti come equivalenti significa ignorare dove finiscono file, credenziali e sessioni. Anche una piccola agenzia dovrebbe decidere quali automazioni possono partire fuori dai dispositivi controllati.
I modelli diventano un permesso assegnato per team
Il 31 luglio GitHub ha aperto una preview per assegnare l’accesso ai modelli in base ai team enterprise. L’amministratore imposta una base comune e può rendere altri modelli opzionali per gruppi specifici. Il rollout raggiunge la maggior parte dei clienti enterprise il 3 agosto.
È un segnale più interessante dell’ennesimo catalogo di modelli. L’accesso può seguire ruolo, formazione e funzione. Un team che tratta codice o dati sensibili non deve avere automaticamente le stesse opzioni di chi sperimenta su contenuti pubblici. La scelta del modello diventa parte della matrice dei permessi, non una preferenza lasciata nel menu di ogni utente.
Una sola console non basta
Questi aggiornamenti spostano il problema verso il control plane delle piattaforme. È comodo, ma crea un nuovo lock-in: metriche, policy e budget restano separati tra Meta, GitHub, cloud e strumenti interni. Una PMI non deve replicare una suite enterprise. Deve però mantenere un registro esterno minimo che colleghi fornitore, proprietario, utenti, dati accessibili, limite di spesa e risultato atteso.
Ho già analizzato i conti reali tra costi AI e lock-in. Qui aggiungo un punto: il costo per token serve solo se arriva fino al margine del workflow. Un agente da 20 euro al mese che fa perdere due ore di revisione è più caro di un servizio da 100 euro che chiude richieste verificabili.
Take operativa: misurare per workflow, non per piattaforma
La mia take è netta: non usare la dashboard del fornitore come contabilità dell’AI. Crea una scheda per ogni workflow con cinque campi: proprietario, utenti autorizzati, costo massimo mensile, azione misurabile e criterio di stop. Per un’automazione WordPress, per esempio, il risultato può essere una bozza approvata; pubblicazioni fallite e tempo di revisione devono rientrare nel costo.
Meta sta dicendo che conta il consumo. GitHub sta dicendo che contano identità, dispositivo e modello. L’azienda deve completare il quadro con l’esito. Solo così token e permessi smettono di essere dati amministrativi e diventano una decisione economica.

