Databricks più GPT-5.5: dove metti i tuoi agent è una questione di data gravity

Databricks ha integrato GPT-5.5 direttamente nei workflow degli agent enterprise, e GPT-5.5 detiene ora lo stato dell'arte sul benchmark OfficeQA Pro. Per molti CTO, la notizia suona come un semplice aggiornamento di modello. Non lo è — è un forcing function su dove vivono i tuoi agent rispetto ai tuoi dati, e la finestra per fare quella scelta a basso costo si sta chiudendo.

Cosa è cambiato

OpenAI e Databricks hanno annunciato che GPT-5.5 è ora disponibile nativamente all'interno dei workflow degli agent enterprise di Databricks. L'integrazione significa che i team già sulla lakehouse di Databricks possono puntare GPT-5.5 ai propri catalog esistenti, alle regole di governance e al compute, senza esportare dati verso una piattaforma agent separata. GPT-5.5 ha raggiunto la prima posizione sul benchmark OfficeQA Pro, un test progettato per simulare il lavoro di ragionamento multi-step su documenti — esattamente quello che caratterizza gli agent di back-office enterprise: revisione contratti, analisi finanziaria, lookup cross-sistema.

Il risultato pratico è che un cliente Databricks può ora eseguire un modello di ragionamento avanzato all'interno dello stesso perimetro di sicurezza delle proprie Delta table e delle policy Unity Catalog. In precedenza, collegare un frontier model capace ai dati enterprise significava o accettare l'egress dei dati verso un'API esterna, o costruire middleware sostanziale per applicare la governance al confine. Quel costo di middleware — in tempo di engineering, latency e superficie di audit — era spesso l'argomento nascosto contro l'adozione degli agent enterprise.

Non è una research preview. Databricks ha una base installata ampia tra aziende nella fascia 200–2.000 dipendenti, e quelle aziende hanno tipicamente già dati strutturati e semi-strutturati nella piattaforma. Le performance di GPT-5.5 sul benchmark indicano che il modello è sufficientemente capace da gestire la complessità di ragionamento che quei casi d'uso richiedono davvero — non solo semplice retrieval.

Perché questo ridefinisce la decisione build-vs-buy per il tuo stack

Il dibattito classico sull'architettura degli agent enterprise ha tre posizioni: costruire uno stack agent custom sulle API raw, comprare uno strumento SaaS verticale, o usare un framework di orchestrazione generale come LangChain o CrewAI davanti alla propria infrastruttura. Tutte e tre assumono che il layer degli agent sia separato dal layer dei dati, collegato da pipeline di retrieval che possiedi e mantieni.

L'integrazione Databricks/GPT-5.5 rompe quell'assunzione. Se i tuoi dati vivono già in Databricks, eseguire gli agent nativamente in quell'ambiente elimina una pipeline di retrieval, un layer di enforcement della governance e una bolletta compute separata. Il vantaggio architetturale non è solo la qualità del modello — è che il modello gira dove stanno i dati, il che rimuove il sovraccarico di latency e compliance che affossa i progetti di agent enterprise in produzione. La data gravity — il principio per cui il compute si muove verso i dati, non il contrario — si applica ora direttamente all'orchestrazione degli agent.

Il rischio è simmetrico. Se hai costruito, o stai costruendo, uno stack agent fuori da Databricks mentre il tuo data warehouse sta dentro, ora devi affrontare un confronto più difficile. Lo stack standalone deve essere significativamente migliore sul tuo caso d'uso specifico, o più economico in scala, o più flessibile in modi che riesci effettivamente a nominare. "Possediamo l'architettura" non è una giustificazione sufficiente se il costo di possederla include overhead ETL continuo e un gap di governance. I CTO che hanno fatto quella scelta 18 mesi fa, prima che un modello di questa capacità di ragionamento fosse disponibile nativamente nella piattaforma, dovrebbero rifare i conti.

Ci sono ragioni legittime per restare off-platform: requisiti di neutralità multi-cloud, casi d'uso che coprono più data store non consolidati in Databricks, o complessità degli agent che richiedono primitive di orchestrazione che Databricks non espone ancora. Ma quelle ragioni devono essere esplicite nei tuoi documenti di architettura, non implicite.

Cosa fare lunedì mattina

L'albero decisionale ha cinque input. Lavoraci prima della prossima infrastructure review.

• Posizione dei dati: Quale percentuale dei dati di cui hanno bisogno i tuoi agent è già in Databricks? Se è sopra il 70%, il percorso nativo merita una valutazione formale, non un'esclusione a priori.
• Spesa Databricks esistente: Stai già pagando per un tier Databricks che include agent tooling? Se sì, il costo marginale del percorso nativo potrebbe essere inferiore ai costi API e infrastrutturali combinati del tuo stack standalone attuale.
• Postura di governance: Il tuo team di security o compliance richiede che l'inference del modello rimanga all'interno di un perimetro dati specifico? La soluzione nativa nella piattaforma è spesso il percorso più breve per soddisfare quel requisito.
• Complessità degli agent: I tuoi agent fanno ragionamento multi-step su dati enterprise strutturati, o semplice retrieval-augmented generation su documenti? Le performance di GPT-5.5 su OfficeQA Pro sono più rilevanti per il primo scenario.
• Ownership del team: Chi possiede attualmente il tuo stack agent? Se è un piccolo team di data engineering che già usa Databricks, il consolidamento riduce la loro superficie operativa. Se è un product team che costruisce logica differenziata, potrebbe aver bisogno della flessibilità di un layer di orchestrazione standalone.

Se le tue risposte puntano verso il consolidamento, avvia una proof of concept di 2 settimane su un caso d'uso agent già in produzione — scegli qualcosa con baseline misurabili di latency e costi. Hai bisogno di numeri reali, non di estrapolazioni da benchmark, prima di impegnarti in una migrazione.

Cosa costa e cosa si risparmia

Il costo del percorso nativo è la dipendenza dalla piattaforma. Databricks non è un layer infrastrutturale neutro; ha potere di pricing, e consolidare il tuo agent compute lì aumenta la tua esposizione a futuri cambiamenti di prezzo. Stai anche accettando le primitive di orchestrazione della piattaforma, che potrebbero essere in ritardo rispetto ai framework open-source su feature come la coordinazione multi-agent complessa. Per i team che hanno costruito tooling interno significativo su LangGraph o simili, il costo di migrazione è tempo di engineering reale — probabilmente 4-8 settimane per una superficie agent non banale.

Il caso del risparmio è meno astratto. Rimuovere una pipeline di retrieval tra il tuo layer agent e il tuo layer dati taglia tipicamente la latency p95 in modo misurabile sulle query data-heavy. L'enforcement della governance al layer dati piuttosto che al confine API riduce la superficie di audit che il tuo team di security deve mantenere. E se stai attualmente eseguendo un vector store separato e una pipeline di embedding per il retrieval enterprise, l'approccio nativo alla lakehouse può collassare completamente quell'infrastruttura. Per un'azienda con 3 o 4 workflow agent attivi e un footprint Databricks modesto, i risparmi infrastrutturali annuali possono giustificare il costo di migrazione in un singolo trimestre — ma quel calcolo dipende interamente dal costo reale del tuo stack attuale, che la maggior parte dei team non ha ancora quantificato completamente.