1 
2Per anni il browser è stato la faccia gentile dell'applicazione e il cloud il posto dove succedevano le cose difficili. L'utente scrive, clicca, carica un file; il frontend manda tutto al server; il server chiama un modello; la risposta torna indietro.
3 
4Questo schema resta utilissimo, ma non è gratis. Ogni chiamata porta latenza, costo, dipendenza dalla rete e domande di privacy. Se l'utente sta scrivendo una frase e vuole un suggerimento, mezzo secondo pesa. Se stai classificando migliaia di piccoli input, i centesimi diventano soldi veri. Se il testo è sensibile, mandarlo fuori dal dispositivo non è una scelta neutra.
5 
6Ecco perché WebGPU e AI on-device sono in hype. Non perché domani faremo girare ogni modello nel browser. Perché una parte delle feature intelligenti può avvicinarsi all'utente.
7 
8## Non tutto deve diventare locale
9 
10La versione infantile del discorso è: "cloud contro device". La versione utile è ibrida.
11 
12Alcuni task stanno benissimo sul dispositivo: riassunti brevi, rilevamento lingua, riscritture leggere, classificazioni semplici, filtri immagine, piccoli modelli vision, esperienze creative con feedback immediato.
13 
14Altri task restano migliori nel cloud: ragionamento complesso, modelli frontier, dati server-side, audit centralizzato, qualità uniforme, workflow dove devi controllare bene ogni passaggio.
15 
16L'architettura sana decide a runtime:
17 
18```mermaid
19flowchart TD
20    User[Utente] --> Browser[Browser]
21    Browser --> Detect[Feature detection]
22    Detect -->|Supportato| Local[Inferenza locale]
23    Detect -->|Non supportato| Cloud[Fallback cloud]
24    Local --> UX[Risposta veloce]
25    Cloud --> UX
26    UX --> Metrics[Metriche e qualità]
27```
28 
29Il browser non deve vincere contro il cloud. Deve evitare al cloud il lavoro che non serve fare lì.
30 
31## Perché WebGPU conta
32 
33WebGPU è una API moderna per usare la GPU dal browser. Non serve solo per grafica 3D più bella. È importante anche perché espone primitive adatte al compute: workload paralleli, shader, pipeline più vicine a quello che le GPU sanno fare bene.
34 
35Per AI, visualizzazione scientifica, editor 3D, filtri video e strumenti creativi, questa differenza si sente. WebGL ha fatto tantissimo per il web, ma WebGPU nasce con un modello più adatto al presente.
36 
37La prima cosa da scrivere, però, non è uno shader. È una feature detection sobria:
38 
39```typescript
40export async function requestWebGpuDevice() {
41  if (!('gpu' in navigator)) {
42    return null;
43  }
44 
45  const adapter = await navigator.gpu.requestAdapter({
46    powerPreference: 'high-performance',
47  });
48 
49  if (!adapter) {
50    return null;
51  }
52 
53  return adapter.requestDevice();
54}
55```
56 
57Questa funzione dice una cosa importante: WebGPU non è un diritto acquisito su ogni dispositivo. È una capacità da verificare. Alcuni browser non lo supportano pienamente, alcune GPU hanno limiti, alcuni ambienti aziendali disabilitano feature, alcuni utenti sono su hardware modesto.
58 
59## Built-in AI: quando il browser porta il modello
60 
61Chrome sta spingendo API built-in per task come prompt locali, riassunto, scrittura, riscrittura, traduzione, rilevamento lingua e proofreading. L'idea è molto interessante: il browser gestisce modello, disponibilità e aggiornamenti; l'app usa una API più vicina alla piattaforma.
62 
63Se funziona bene, cambia parecchio:
64 
65- meno chiamate server per task semplici;
66- dati che possono restare sul dispositivo;
67- latenza più bassa;
68- esperienze offline o semi-offline;
69- UX più naturale per scrittura e traduzione.
70 
71Ma va trattata come progressive enhancement. Alcune API sono stabili, altre in origin trial o preview, altre ancora dipendono da versione, lingua e dispositivo.
72 
73```typescript
74type LocalCapability = 'available' | 'downloadable' | 'unsupported';
75 
76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
77  const SummarizerApi = (globalThis as any).Summarizer;
78 
79  if (!SummarizerApi?.availability) {
80    return 'unsupported';
81  }
82 
83  const availability = await SummarizerApi.availability();
84 
85  if (availability === 'available') return 'available';
86  if (availability === 'downloadable') return 'downloadable';
87 
88  return 'unsupported';
89}
90```
91 
92Il codice specifico cambierà, ma il pattern resta: controlli disponibilità, spieghi eventuali download, offri fallback e misuri la qualità.
93 
94## Il fallback non è un piano B triste
95 
96Il fallback cloud non è una sconfitta. È parte del prodotto.
97 
98```typescript
99interface AiRequest {
100  task: 'summarize' | 'rewrite' | 'classify';
101  input: string;
102}
103 
104interface AiResult {
105  output: string;
106  runtime: 'local' | 'cloud';
107}
108 
109export async function runAiTask(request: AiRequest): Promise<AiResult> {
110  const local = await tryLocalAi(request);
111 
112  if (local) {
113    return { output: local, runtime: 'local' };
114  }
115 
116  const cloud = await fetch('/api/ai', {
117    method: 'POST',
118    headers: { 'Content-Type': 'application/json' },
119    body: JSON.stringify(request),
120  }).then((res) => res.json());
121 
122  return { output: cloud.output, runtime: 'cloud' };
123}
124```
125 
126Questa architettura ti permette di migliorare progressivamente. Chi ha supporto locale ottiene latenza e privacy migliori. Chi non ce l'ha usa comunque la feature. Tu puoi misurare percentuale di richieste locali, tempi, errori, memoria, qualità percepita e costo.
127 
128Senza metriche, l'on-device AI diventa una scelta estetica. Con le metriche, diventa una leva di prodotto.
129 
130## La UX del modello conta
131 
132Se il browser deve scaricare un modello, l'utente lo percepisce. Non nasconderlo dietro uno spinner vago. Meglio essere chiari: "Prepariamo il modello per usare questa funzione più velocemente e anche offline".
133 
134Una buona esperienza:
135 
136- mostra lo stato di preparazione;
137- non blocca tutta la pagina;
138- permette di continuare con il fallback cloud;
139- evita sorprese su batteria e memoria;
140- ricorda il modello quando possibile;
141- spiega il beneficio in una frase concreta.
142 
143La cosa peggiore è una feature "intelligente" che sembra rotta perché sta scaricando qualcosa in silenzio.
144 
145## Privacy: meglio, non automaticamente sicuro
146 
147Elaborare dati sul dispositivo può essere un grande vantaggio. Una bozza email, un documento interno o una nota personale non devono per forza lasciare il browser per ricevere un suggerimento.
148 
149Però locale non significa automaticamente sicuro. Devi comunque pensare a:
150 
151- XSS;
152- log accidentali;
153- dati salvati in storage;
154- prompt injection da contenuti non fidati;
155- permessi concessi al modello;
156- output usati in azioni automatiche.
157 
158Se un modello locale può leggere una pagina web e poi compilare un form, quella pagina può provare a manipolarlo. Se può chiamare tool, servono conferme. Se produce output strutturato, va validato. Il fatto che giri sul device riduce alcuni rischi di privacy, ma non cancella il security model.
159 
160## Dove diventa davvero interessante
161 
162Il testo è solo l'inizio. WebGPU rende credibili esperienze web che fino a poco tempo fa sembravano da app nativa:
163 
164- editor 3D complessi;
165- Gaussian splatting nel browser;
166- filtri video in tempo reale;
167- CAD leggero;
168- visualizzazioni scientifiche;
169- strumenti creativi con anteprima immediata;
170- inferenza vision vicino alla UI;
171- giochi browser più ambiziosi.
172 
173Qui frontend, grafica e machine learning iniziano a mescolarsi. È una zona un po' scomoda, ma anche fertile: il browser torna a essere una piattaforma applicativa seria, non solo il posto in cui mettiamo form e dashboard.
174 
175## Checklist prima della produzione
176 
177Prima di mettere una feature on-device davanti agli utenti, controllerei:
178 
1791. Browser e dispositivi target.
1802. Fallback cloud o degradazione elegante.
1813. Tempo di download e cache del modello.
1824. Memoria e batteria su hardware medio.
1835. Qualità rispetto alla versione cloud.
1846. Privacy policy e messaggi utente.
1857. Test con input ostili.
1868. Metriche separate per runtime locale e cloud.
1879. Piano per aggiornare o disabilitare il modello.
188 
189È una lista concreta perché il problema è concreto. Una feature AI lenta, fragile o opaca non diventa migliore solo perché gira nel browser.
190 
191## Il compromesso giusto
192 
193Io non credo che il futuro sia "tutto sul device". E non credo nemmeno che il cloud resterà l'unico posto ragionevole per l'inferenza. Il futuro più probabile è una miscela: locale quando migliora latenza, privacy o costo; cloud quando servono qualità, dati aggiornati e controllo centralizzato.
194 
195WebGPU, WebNN e le API AI integrate non rendono il browser onnipotente. Lo rendono più adulto. E per chi costruisce prodotti web, questa è una notizia enorme.
196 
197## Fonti utili
198 
199- [WebGPU API - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [WebGPU specification - W3C](https://www.w3.org/TR/webgpu/)
201- [Built-in AI - Chrome for Developers](https://developer.chrome.com/docs/ai/built-in)
202- [Built-in AI APIs - Chrome for Developers](https://developer.chrome.com/docs/ai/built-in-apis)
203- [WebNN API](https://webnn.io/)
204