Apple ha smesso di farsi l'AI in casa e l'ha presa da Google. La lezione build vs buy che a molti CTO non va giù
Per anni Apple ha costruito il suo racconto intorno a un'idea molto semplice: controlliamo tutto noi. Il chip, il sistema operativo, lo schermo, il negozio, perfino il modo in cui il prodotto arriva nelle mani del cliente. Poi, al WWDC di ieri, l'azienda più integrata del settore ha confermato una scelta che fino a poco tempo fa sarebbe sembrata quasi fuori personaggio: per una parte centrale della sua intelligenza artificiale userà modelli sviluppati da qualcun altro.
Non è una voce di corridoio e non è una lettura tra le righe. La nuova generazione di Apple Foundation Models, quella che alimenta il nuovo Apple Intelligence e il nuovo assistente, si basa sui modelli Gemini di Google. Apple ha valutato anche OpenAI e Anthropic, poi ha deciso di integrare tecnologia esterna invece di costruire tutto internamente. E lo ha fatto pur avendo risorse economiche, talento e infrastruttura come poche altre aziende al mondo.
Se sei un CTO o un founder e hai sul tavolo una decisione del tipo "ci facciamo il nostro modello o ne integriamo uno già pronto", questa notizia non è semplice cronaca tech. È un caso di studio enorme, visibile a tutti, e soprattutto molto utile da portare nella prossima riunione di budget.
Cosa è successo davvero, senza speculazioni
Partiamo dai fatti, perché online c'è ancora chi ne parla come se fosse solo un'ipotesi. La partnership tra Apple e Google era stata annunciata a inizio anno; ieri è diventata prodotto. I nuovi Apple Foundation Models si basano su Gemini, girano in parte sul dispositivo e in parte sui server Apple attraverso Private Cloud Compute, e sono stati adattati da Apple al punto che il nome Gemini non compare nell'interfaccia. Al centro c'è anche un sistema di orchestrazione che capisce quale app stai usando e decide quale strumento coinvolgere.
La parte interessante non è solo tecnica. È soprattutto strategica. L'azienda che può permettersi quasi qualunque investimento ha concluso, dopo una valutazione definita "attenta", che la scelta più sensata fosse usare la tecnologia di un concorrente diretto. La spiegazione ufficiale è sobria: Google offriva la base più adatta per i loro modelli. Detto in modo meno diplomatico, costruire da soli un modello di frontiera, in tempi accettabili, era una battaglia che perfino Apple ha scelto di non combattere.
Il paradosso che dovrebbe interessarti
Qui nasce il punto interessante. Per quindici anni il messaggio di Apple è stato: il controllo totale è un vantaggio competitivo. Ieri lo stesso brand ha mostrato, alla massima scala possibile, che puoi controllare l'esperienza senza possedere per forza il modello che la alimenta.
È una distinzione che proviamo spesso a far passare ai clienti, e che non sempre fa piacere sentire. Un founder ci ha chiesto di costruirgli "la sua AI proprietaria". La nostra prima domanda è stata: proprietaria di cosa, del modello o del problema che vuoi risolvere? Sono due cose molto diverse, e confonderle ti fa spendere una fortuna sul pezzo sbagliato.
Quando qualcuno ci dice "voglio controllare tutto", la prima domanda non dovrebbe essere "quale modello usiamo?". Dovrebbe essere: quale pezzo ti mette davvero in difficoltà se domani lo perdi? Quasi mai la risposta è il modello. Molto più spesso sono i dati, i flussi, le regole di business e il punto in cui decidi cosa entra nel sistema e cosa ne esce. Apple, di fatto, ha risposto alla stessa domanda e ha concluso che il modello non era il pezzo da possedere a ogni costo.
Dove vive davvero il controllo
Una volta abbiamo passato un pomeriggio intero a convincere un CTO a non addestrare un modello da zero. Cercava indipendenza, e per lui indipendenza significava possedere i pesi della rete. Il punto è che l'indipendenza, in molti progetti, non sta lì. Sta nello strato di orchestrazione che decide cosa entra e cosa esce, gestisce le alternative quando un servizio non risponde, ripulisce gli input e tiene insieme il sistema. Quello sì che lo governi davvero. Quello nessuno può cambiartelo sotto i piedi.
Non crediamo che "fatto in casa" significhi automaticamente "sotto controllo", e preferiamo dirlo prima di iniziare un progetto. Il codice che conta è spesso quello che collega il tuo dominio al modello: regole, dati, controlli, permessi, formati, eccezioni. Confondere questo strato con il modello sottostante è il modo più caro che conosciamo per sentirsi al sicuro. Spendi mesi ad addestrare qualcosa che invecchia in un trimestre, e intanto lasci fragile l'integrazione che lo circonda. È un pessimo affare.
Apple ha messo un orchestratore al centro della sua architettura proprio per questo. Il valore difendibile non è il modello in sé, visto che la base arriva da Google. Il valore è lo strato che instrada le richieste, decide cosa usare, protegge la privacy e tiene insieme l'esperienza su tutti i dispositivi.
È lo stesso motivo per cui, quando costruiamo agenti AI per un'azienda, li progettiamo in modo agnostico rispetto al modello. Un agente non dovrebbe dipendere per sempre da un solo fornitore, né usare lo stesso modello per ogni compito solo perché è quello già integrato. In un workflow reale può avere senso usare modelli diversi: uno più adatto a ragionare su documenti lunghi, uno più veloce per classificare richieste semplici, uno più preciso quando serve generare codice o analizzare dati strutturati. Il valore non sta nello scegliere un nome e restargli fedeli. Sta nel costruire un sistema capace di usare lo strumento giusto nel punto giusto.
L'integrazione è il punto che si rompe
Abbiamo visto fallire un progetto perché il cliente era concentrato quasi solo sul possesso del modello e aveva trascurato il punto più fragile: l'ingresso dei dati. I dati arrivavano sporchi, incoerenti, pieni di eccezioni non gestite. Il modello era buono, ma l'architettura intorno non reggeva. Il progetto è fallito comunque, non perché il modello fosse debole, ma perché il lavoro più importante era stato fatto nel posto sbagliato.
È il rischio che corre chi mette l'orgoglio del "lo facciamo noi" davanti all'ingegneria del sistema. Un modello, per quanto buono, da solo non basta. Vale quanto lo strato che decide quali informazioni riceve e cosa succede dopo la risposta. Apple lo ha capito e ha investito il suo lavoro proprio lì: sull'orchestrazione e su Private Cloud Compute, non sull'addestramento di un concorrente diretto di Gemini.
La domanda che cambia la decisione
La domanda che facciamo prima di ogni integrazione AI non è "on-device o cloud?". È: cosa succede il giorno in cui il fornitore cambia prezzi, licenza o condizioni? Se non hai una risposta progettata prima, non hai davvero un'architettura. Hai una dipendenza con una bella interfaccia sopra.
Apple si è mossa con molta attenzione proprio su questo punto. Ha strutturato l'accordo come non esclusivo. In pratica, si è tenuta aperta la possibilità di cambiare o aggiungere fornitori, e mantiene anche l'integrazione con OpenAI per alcune richieste. Non è solo un dettaglio legale. È un modo per progettare la dipendenza invece di subirla. La domanda "e se domani Google alza il prezzo o cambia i termini?" se l'è posta prima di firmare, non dopo.
Questa è la differenza tra comprare tecnologia sapendo cosa si sta facendo e comprarla sperando che vada tutto bene. Ai clienti diciamo spesso una cosa scomoda: integrare un modello può essere una scelta reversibile, ma solo se la progetti così fin dall'inizio. La differenza la fa uno strato di astrazione che nessuno vuole pagare quando tutto funziona, e che diventa di colpo indispensabile la notte in cui il fornitore cambia l'API su cui hai costruito mezzo prodotto. Di solito succede alle tre di notte.
Cosa significa per te, in pratica
Se stai valutando una decisione build vs buy su un componente AI, la storia di Apple ti lascia tre domande molto concrete da portare in riunione.
La prima: il modello è davvero il tuo vantaggio competitivo, o lo è il problema che risolvi grazie al modello? Se la risposta non è "il modello è il prodotto", quasi sempre ha più senso integrare tecnologia esterna e mettere i tuoi soldi altrove.
La seconda: se integri un fornitore esterno, puoi sostituirlo senza riscrivere tutto? Qui entrano in gioco uno strato di astrazione, una strategia multi-modello e accordi che non ti chiudano in una sola direzione. Se la risposta è no, non stai comprando un componente: ti stai sposando, e senza accordo prematrimoniale.
La terza: dov'è la parte davvero difendibile della tua architettura? Se la risposta è "nei pesi del modello", stai guardando nel posto sbagliato. Quasi sempre il valore sta nell'orchestrazione, nei dati, nelle regole di business e nei flussi che nessun fornitore può darti già pronti.
Apple ha risposto a queste domande in pubblico, accettando di sembrare un po' meno "Apple" pur di essere più efficace. Per chi costruisce software enterprise il segnale è chiaro: smettere di confondere il possesso con il controllo non è una scorciatoia, è la scelta più adulta.
Conclusione
L'azienda più ossessionata dal controllo ha appena mostrato che si può governare l'esperienza senza possedere ogni pezzo della tecnologia sottostante. Non è una resa. È ingegneria fatta da gente cresciuta. Il controllo che conta non vive nei pesi di una rete neurale che rischia di invecchiare in pochi mesi. Vive nello strato che governi tu: quello che decide cosa entra, cosa esce e cosa succede quando il fornitore cambia idea.
Se la tua prossima grande decisione tecnica è "ce lo costruiamo o lo compriamo?", parti da lì. Il modello è un componente. L'architettura intorno è il tuo prodotto.
Servizi correlati
Se stai valutando una scelta build vs buy su componenti AI, approfondisci il nostro approccio allo sviluppo AI a Torino. Quando l'AI deve diventare parte di un prodotto scalabile, il lavoro entra nel campo del SaaS product engineering e richiede una software house a Torino capace di progettare architettura, integrazioni e governance.