Per 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.

Questo 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.

Ecco 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.

Non tutto deve diventare locale

La versione infantile del discorso è: "cloud contro device". La versione utile è ibrida.

Alcuni task stanno benissimo sul dispositivo: riassunti brevi, rilevamento lingua, riscritture leggere, classificazioni semplici, filtri immagine, piccoli modelli vision, esperienze creative con feedback immediato.

Altri task restano migliori nel cloud: ragionamento complesso, modelli frontier, dati server-side, audit centralizzato, qualità uniforme, workflow dove devi controllare bene ogni passaggio.

L'architettura sana decide a runtime:

Il browser non deve vincere contro il cloud. Deve evitare al cloud il lavoro che non serve fare lì.

Perché WebGPU conta

WebGPU è 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.

Per 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.

La prima cosa da scrivere, però, non è uno shader. È una feature detection sobria:

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

Questa 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.

Built-in AI: quando il browser porta il modello

Chrome 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.

Se funziona bene, cambia parecchio:

• meno chiamate server per task semplici;
• dati che possono restare sul dispositivo;
• latenza più bassa;
• esperienze offline o semi-offline;
• UX più naturale per scrittura e traduzione.

Ma va trattata come progressive enhancement. Alcune API sono stabili, altre in origin trial o preview, altre ancora dipendono da versione, lingua e dispositivo.

type LocalCapability = 'available' | 'downloadable' | 'unsupported';

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

  if (availability === 'available') return 'available';
  if (availability === 'downloadable') return 'downloadable';

  return 'unsupported';
}

Il codice specifico cambierà, ma il pattern resta: controlli disponibilità, spieghi eventuali download, offri fallback e misuri la qualità.

Il fallback non è un piano B triste

Il fallback cloud non è una sconfitta. È parte del prodotto.

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

  return { output: cloud.output, runtime: 'cloud' };
}

Questa 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.

Senza metriche, l'on-device AI diventa una scelta estetica. Con le metriche, diventa una leva di prodotto.

La UX del modello conta

Se 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".

Una buona esperienza:

• mostra lo stato di preparazione;
• non blocca tutta la pagina;
• permette di continuare con il fallback cloud;
• evita sorprese su batteria e memoria;
• ricorda il modello quando possibile;
• spiega il beneficio in una frase concreta.

La cosa peggiore è una feature "intelligente" che sembra rotta perché sta scaricando qualcosa in silenzio.

Privacy: meglio, non automaticamente sicuro

Elaborare 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.

Però locale non significa automaticamente sicuro. Devi comunque pensare a:

• XSS;
• log accidentali;
• dati salvati in storage;
• prompt injection da contenuti non fidati;
• permessi concessi al modello;
• output usati in azioni automatiche.

Se 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.

Dove diventa davvero interessante

Il testo è solo l'inizio. WebGPU rende credibili esperienze web che fino a poco tempo fa sembravano da app nativa:

• editor 3D complessi;
• Gaussian splatting nel browser;
• filtri video in tempo reale;
• CAD leggero;
• visualizzazioni scientifiche;
• strumenti creativi con anteprima immediata;
• inferenza vision vicino alla UI;
• giochi browser più ambiziosi.

Qui 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.

Checklist prima della produzione

Prima di mettere una feature on-device davanti agli utenti, controllerei:

1. Browser e dispositivi target.
2. Fallback cloud o degradazione elegante.
3. Tempo di download e cache del modello.
4. Memoria e batteria su hardware medio.
5. Qualità rispetto alla versione cloud.
6. Privacy policy e messaggi utente.
7. Test con input ostili.
8. Metriche separate per runtime locale e cloud.
9. Piano per aggiornare o disabilitare il modello.

È una lista concreta perché il problema è concreto. Una feature AI lenta, fragile o opaca non diventa migliore solo perché gira nel browser.

Il compromesso giusto

Io 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.

WebGPU, 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.

Fonti utili

• WebGPU API - MDN
• WebGPU specification - W3C
• Built-in AI - Chrome for Developers
• Built-in AI APIs - Chrome for Developers
• WebNN API