IA sul telefono: come capire cosa viene eseguito sul dispositivo

Dire che un telefono integra l’IA sul dispositivo può riferirsi a una capacità del processore, a una funzione specifica o a una parte del flusso di lavoro. Da solo, non dimostra che tutti gli strumenti intelligenti del telefono funzionino localmente. Un’app può usare un modello installato per un’attività e ricorrere ai server per un’altra, oppure combinare entrambi i metodi nella stessa interazione. Per questo è più utile chiedersi quale attività viene elaborata dove, invece di domandarsi soltanto se il telefono «ha l’IA locale». Un’etichetta generale può descrivere una tecnologia disponibile senza chiarire come funziona davvero una determinata funzione rivolta all’utente.

La distinzione è importante per ragioni pratiche. Se un’operazione avviene sul telefono stesso, potrebbe essere disponibile anche senza connessione, ma dipende dall’app e dagli altri suoi requisiti. Se interviene un server, possono essere necessari la connessione e la disponibilità del servizio. Il luogo di elaborazione è rilevante anche per capire il trattamento dei dati, ma l’esecuzione locale non equivale automaticamente a una privacy garantita. Occorre comunque verificare quali dati raccoglie l’app, che cosa sincronizza e quali controlli offre. Sapere dove avviene il calcolo risponde a una domanda specifica; da solo non descrive l’intero flusso dei dati né tutte le condizioni d’uso della funzione.

Parti dal nome esatto della funzione, non dalle espressioni generiche usate in una campagna. Cerca la documentazione del produttore o dello sviluppatore relativa proprio a quella funzione e controlla se indica un’elaborazione sul dispositivo, nel cloud o una combinazione delle due. La documentazione per sviluppatori Android, per esempio, descrive come integrare l’inferenza dei modelli linguistici su Android tramite Google AI Edge. Consente di verificare che esiste una via tecnica per l’esecuzione locale, ma non dimostra che una funzione specifica di un telefono commerciale la utilizzi. Una guida della piattaforma e l’implementazione di un prodotto sono prove di tipo diverso: non considerare la prima una conferma della seconda.

Annota anche le condizioni che possono cambiare il risultato: modello del dispositivo, versione del sistema, lingua, regione, eventuale download preliminare del modello, autorizzazioni e connessione. La disponibilità annunciata può dipendere da questi requisiti e variare da un utente all’altro. Per organizzare la verifica, confronta i punti seguenti. Cerca indicazioni riferite alla funzione esatta e alla sua configurazione attuale, invece di presumere che un requisito indicato per un modello o una regione valga ovunque. Se la documentazione non chiarisce uno di questi aspetti, registra l’incertezza invece di colmare il vuoto con una supposizione.

• Attività: l’azione esatta descritta dalla fonte, come riassumere un testo o riconoscere un’immagine.
• Elaborazione: se afferma esplicitamente che il calcolo avviene in locale, sui server o con un approccio ibrido.
• Requisiti: connessione, modello, versione, regione, lingua e impostazioni.
• Dati: quali informazioni vengono inviate, conservate o associate a un account, secondo l’informativa applicabile.

Una guida per sviluppatori può dimostrare che una piattaforma consente di eseguire modelli sul dispositivo. Google AI Edge documenta l’inferenza di modelli linguistici su Android tramite MediaPipe. Questo chiarisce una possibilità di implementazione, ma non identifica automaticamente quali app la adottano, quale modello usano o se inviano richieste aggiuntive al cloud. La capacità della piattaforma e il comportamento di una funzione non sono la stessa affermazione. Una guida tecnica aiuta a capire cosa possono realizzare gli sviluppatori; per stabilire come funziona una specifica funzione per i consumatori servono informazioni che riguardino quella funzione. Quando si arriva a una conclusione, è importante tenere distinti questi livelli di prova.

È inoltre importante distinguere l’esecuzione locale dal funzionamento del tutto indipendente dalla rete. Un’app può calcolare una risposta sul telefono e aver comunque bisogno di una connessione per accedere, scaricare risorse, aggiornare dati o sincronizzare risultati. Al contrario, il fatto che una funzione funzioni offline in una prova specifica non rivela da solo cosa accade in altri contesti d’uso. La guida Android sull’architettura offline-first considera la disponibilità offline una scelta di progettazione dell’app e del suo livello dati; non consente di dedurre dove un prodotto specifico esegue l’IA. Una prova senza connessione informa quindi sulla disponibilità in quella prova, ma non risolve le questioni più ampie relative al luogo di elaborazione o al trattamento dei dati.

Per valutare la privacy, cerca informazioni separate su elaborazione, conservazione e controlli. La documentazione Apple su Apple Intelligence distingue l’elaborazione sul dispositivo dalle richieste che, per alcune attività, possono ricorrere a Private Cloud Compute. Apple descrive il proprio sistema cloud come progettato per proteggere i dati durante tale elaborazione. Si tratta della spiegazione del fornitore sulla propria architettura e sulle garanzie dichiarate; non va trasformata in un’affermazione universale su tutti gli assistenti, produttori o servizi. Nel leggere queste informazioni, individua l’ecosistema e le richieste specifiche a cui si riferiscono, senza presumere che la stessa configurazione valga per prodotti diversi.

Una descrizione utile dovrebbe permettere di capire quali dati vengono elaborati, quando escono dal telefono, per quale finalità e cosa accade dopo. Se il testo si limita a promettere che i dati sono «protetti» o che l’IA è «privata», senza specificare il flusso, resta una domanda senza risposta. Controlla anche le impostazioni di cronologia, attività, sincronizzazione e uso dei dati, e verifica se appartengono al sistema operativo o a un’app di terze parti. Non confondere una misura di sicurezza annunciata con l’assenza di trasferimento dei dati, né l’assenza di una spiegazione pubblica con la prova che i dati vengano inviati. Una conclusione prudente dovrebbe precisare cosa conferma la documentazione disponibile, cosa non dimostra e quali dettagli restano indeterminati.

Quando esamini una funzione, la conclusione dovrebbe rispecchiare la portata delle prove. Se la documentazione specifica afferma che un’attività viene elaborata localmente, puoi descriverla così, includendo requisiti e limiti indicati. Se un documento illustra soltanto uno strumento per sviluppatori o la capacità generale di una piattaforma, la conclusione deve rimanere a quel livello. Se non esiste una spiegazione verificabile della funzione, è corretto dire che il metodo di elaborazione non è confermato dalle fonti consultate. Questo approccio evita di trasformare una possibilità tecnica in un’affermazione su un prodotto finito e di definire locale o cloud un processo che non è stato chiarito.

Prima di scegliere un telefono o attivare uno strumento, è ragionevole fare quattro verifiche: trovare la documentazione della funzione esatta, identificarne i requisiti, leggere l’informativa sui dati pertinente e provare il comportamento offline soltanto come verifica pratica della disponibilità. Quest’ultima prova non sostituisce la documentazione sulla privacy e non dimostra da sola cosa accade a ogni dato. Le informazioni disponibili qui non attestano uno specifico annuncio recente e non consentono di assegnare un metodo di elaborazione a tutte le funzioni di un marchio. Questa guida è quindi un metodo di verifica, non una notizia su un lancio. La conclusione deve restare circoscritta all’attività, alle prove e alle condizioni che sono state effettivamente controllate.