I team di sicurezza Databricks e Google affrontano un nuovo compromesso nella difesa basata sull'AI

Databricks ha pubblicato una nuova guida alla sicurezza incentrata su un conflitto: l'AI può accelerare la difesa, ma solo quando i team si fidano dei dati e dell'automazione sottostanti. Per le organizzazioni che valutano implementazioni databricks google, la proposta va oltre l'analisi dei dati. Databricks vuole che il lakehouse diventi un livello operativo per i dati di sicurezza, le indagini, l'ingegneria di rilevamento e la risposta assistita dall'AI.

La guida arriva mentre i team di sicurezza riconsiderano il sistema di gestione delle informazioni e degli eventi di sicurezza, o SIEM, che tradizionalmente centralizza log e avvisi. Databricks sostiene che telemetria frammentata, costi di conservazione elevati e workflow scollegati impediscano ai difensori di utilizzare efficacemente l'AI. La sua risposta proposta pone al centro dati aziendali governati, consentendo poi ad analisti e agenti AI di lavorare su questo contesto condiviso.

Questa posizione mette Databricks in competizione con più dei fornitori SIEM affermati. Mette in discussione l'idea che i dati di sicurezza debbano rimanere all'interno di una piattaforma di sicurezza specializzata. Google Security Operations, Microsoft Sentinel, Splunk, CrowdStrike e altri fornitori stanno anch'essi aggiungendo indagini e risposte guidate dall'AI. La competizione sta diventando una scelta tra una suite di sicurezza integrata e una piattaforma dati più ampia adattata alla difesa.

Cosa ha effettivamente messo Databricks sul tavolo

L'annuncio è un piano strategico per le operazioni di sicurezza, non un benchmark di prodotto convalidato in modo indipendente.

Databricks ha pubblicato il suo ebook sulla leadership nella sicurezza il 2 settembre 2026. La guida presenta un'architettura dati unificata come fondamento della moderna difesa informatica. Il suo argomento centrale è che le organizzazioni non possano implementare agenti di sicurezza affidabili finché log, identità, avvisi e contesto aziendale rimangono separati.

L'azienda descrive tre cambiamenti connessi. I team di sicurezza dovrebbero consolidare più telemetria, rendere l'analisi accessibile oltre i gruppi specialistici di ingegneria e introdurre agenti AI all'interno di workflow governati. Questo approccio trasforma il lakehouse in qualcosa di più di un archivio a lungo termine. Diventa un luogo per rilevamento, indagine, arricchimento e attività di risposta selezionate.

La guida alla leadership nella sicurezza evidenzia diversi dati relativi a clienti e settore. Databricks afferma che il 72% dei dirigenti della sicurezza intervistati fatica a gestire dati in silos. Indica inoltre Arctic Wolf, che elabora otto trilioni di eventi di sicurezza ogni settimana.

La guida afferma che Rivian ha ridotto del 60% i costi legati al SIEM dopo aver modernizzato la propria architettura dei dati di sicurezza. Un altro esempio sostiene che i team abbiano implementato regole di rilevamento da cinque a sei volte più velocemente. Queste cifre illustrano l'argomentazione dell'azienda, ma richiedono un'interpretazione attenta.

Databricks non presenta ogni dato come un confronto controllato tra ambienti di sicurezza equivalenti. Mix dei carichi di lavoro, policy di conservazione, organico, volume di dati e contratti esistenti possono influire sostanzialmente sul risultato. Un'implementazione di successo presso un cliente non stabilisce un tasso di risparmio universale.

Il segnale utile è il modello alla base degli esempi. I team di sicurezza desiderano una conservazione più lunga, telemetria più ampia e accesso più rapido a dati contestuali. L'economia dei SIEM tradizionali può indurli a filtrare le informazioni prima dell'acquisizione o a spostare i log meno recenti in archivi separati.

Questa separazione crea attrito operativo. Un analista che indaga su un accesso sospetto potrebbe aver bisogno di avvisi degli endpoint, cronologia delle identità, record di audit cloud, proprietà degli asset e attività applicativa. Se tali record risiedono in diversi sistemi, un'indagine automatizzata eredita le stesse lacune.

Un lakehouse modifica il confine tra archiviazione e analisi. Può conservare record strutturati insieme a informazioni meno standardizzate, supportando al contempo SQL, Python, machine learning e condivisione governata dei dati. Databricks definisce questa architettura una piattaforma unificata per dati, analisi e AI.

L'azienda promuove inoltre Agent Bricks, il proprio ambiente per creare agenti AI specifici per dominio. Nelle operazioni di sicurezza, un agente potrebbe riassumere avvisi correlati, recuperare attività storiche o aiutare a redigere logiche di rilevamento. L'agente dipende comunque da autorizzazioni, contesto affidabile e un percorso di approvazione definito.

Questa distinzione è importante. La guida non dimostra che gli agenti AI possano sostituire in sicurezza gli analisti della sicurezza. Mostra come Databricks desideri che le organizzazioni preparino dati e governance per una maggiore automazione.

Si tratta di un'affermazione più circoscritta, ma anche più rilevante. Se le imprese accettano questa premessa, le decisioni sull'architettura di sicurezza si avvicinano al team della piattaforma dati. L'acquisto di un SIEM diventa in parte una questione di formati di archiviazione, cataloghi, accesso ai modelli e contesto aziendale riutilizzabile.

Perché le implementazioni Databricks e Google contano ora

La storia databricks google conta perché la difesa basata sull'AI ora abbraccia la piattaforma dati, i controlli cloud, i sistemi di identità e i fornitori esterni di modelli.

Databricks opera su Google Cloud da quando le aziende hanno annunciato la loro partnership nel 2021. La partnership cloud iniziale ha enfatizzato analisi integrate, machine learning, fatturazione unificata, supporto per le identità Google e accesso ai dati più semplice.

Da allora le implicazioni per la sicurezza si sono ampliate. Un workspace Databricks può utilizzare servizi Google Cloud per storage, networking, identità, crittografia e audit. I team di sicurezza possono anche analizzare la telemetria all'interno di Databricks senza considerare la piattaforma stessa come l'unica fonte di protezione.

Le attuali indicazioni di Google Cloud descrivono la sicurezza come una responsabilità condivisa tra Databricks, il cliente e il fornitore cloud. Questo confine è essenziale quando un'organizzazione trasferisce più dati di sicurezza nel lakehouse.

Google Cloud protegge l'infrastruttura sottostante e fornisce controlli per identità, reti, storage e crittografia. Databricks protegge la propria piattaforma gestita e fornisce funzionalità a livello di workspace. I clienti rimangono responsabili di autorizzazioni, classificazione dei dati, isolamento dei carichi di lavoro, comportamento delle applicazioni e molte scelte di configurazione.

Un dataset di sicurezza unificato non elimina questi confini. Li rende più visibili. Le indagini possono correlare azioni tra sistemi, ma gli amministratori devono comunque comprendere quale controllo appartenga a quale operatore.

Ad esempio, Databricks su Google Cloud supporta federazione delle identità, single sign-on, connettività privata, chiavi gestite dal cliente e registrazione di audit cloud. Questi controlli possono ridurre l'esposizione se configurati correttamente. Possono anche creare punti ciechi quando i team presumono che un'altra parte abbia coperto il requisito.

L'espressione databricks google può quindi descrivere diverse decisioni di acquisto. Un'organizzazione potrebbe utilizzare Databricks per l'analisi mantenendo Google Security Operations come SIEM principale. Un'altra potrebbe trasferire la telemetria storica in Databricks. Una terza potrebbe creare rilevamenti direttamente sui dati del lakehouse.

Queste architetture comportano rischi diversi. Un archivio di analisi secondario non necessita di ogni workflow disponibile in una console di sicurezza primaria. Un sistema che gestisce triage in tempo reale, contenimento automatizzato e prove regolamentari richiede garanzie operative più rigorose.

Google sta inoltre facendo avanzare il proprio stack per la sicurezza e il controllo degli agenti. Il suo framework per l'identità degli agenti del 2026 include identità, gestione degli accessi, gateway, guardrail e difesa runtime per software autonomo. Ciò si sovrappone al problema di governance che Databricks affronta dal livello dati.

La sovrapposizione crea sia cooperazione sia concorrenza. Databricks beneficia dell'infrastruttura Google Cloud e può servire clienti già investiti nelle identità e nello storage di Google. Tuttavia, Google vende anche una piattaforma per le operazioni di sicurezza che compete per telemetria, attenzione degli analisti e carichi di lavoro di automazione.

Questa tensione non è insolita nel software cloud. Le piattaforme spesso si integrano a livello di infrastruttura mentre competono più in alto nello stack applicativo. Gli acquirenti dovrebbero valutare quale sistema diventi autorevole per rilevamenti, casi, approvazioni di risposta e conservazione delle evidenze.

L'architettura influenza anche la portabilità. Databricks enfatizza formati dati aperti e operatività multicloud. Google Cloud enfatizza servizi integrati e controlli cloud-native. Le imprese possono attribuire valore a entrambi, ma questi obiettivi non portano sempre allo stesso design.

Un formato di archiviazione aperto può rendere i record di sicurezza più facili da riutilizzare. Non rende automaticamente portabili regole di rilevamento, workflow di gestione degli incidenti o playbook di automazione. Queste risorse di livello superiore dipendono spesso da schemi e API proprietari.

Questo lascia ai leader della sicurezza una domanda più precisa. Non stanno scegliendo tra apertura e integrazione in astratto. Stanno decidendo dove accettare la specializzazione, dove richiedere portabilità e dove la governance debba rimanere coerente.

La vera competizione è tra il livello dati e la suite SIEM

Databricks scommette che il controllo dei dati di sicurezza conterà più della proprietà della tradizionale console per analisti.

Un SIEM convenzionale combina acquisizione, normalizzazione, ricerca, rilevamento, allerta, indagine e reportistica. Il suo valore deriva dall'integrazione di queste funzioni in un unico workflow orientato alla sicurezza. La sua debolezza emerge quando il volume dei dati cresce più rapidamente dei budget o della capacità operativa.

Databricks affronta il problema dalla direzione opposta. Parte da archiviazione dati scalabile, strumenti di elaborazione aperti, governance centralizzata e machine learning. Le funzioni di sicurezza vengono poi costruite su questa base.

Questo modello può aiutare i team a preservare la telemetria grezza per indagini successive. Supporta inoltre join tra record di sicurezza e contesto aziendale. Un accesso insolito diventa più utile quando gli analisti possono collegarlo al ruolo di un dipendente, a un dispositivo gestito, al proprietario di un'applicazione e a recenti modifiche degli accessi.

La difesa guidata dall'AI trae vantaggio da questo contesto. Un modello che riceve soltanto il titolo di un avviso e pochi campi evento dispone di prove limitate. Un agente governato in grado di recuperare cronologia autorizzata ha maggiori probabilità di produrre un riepilogo utile.

Più dati non garantiscono una risposta migliore. Una normalizzazione scadente può creare identità contraddittorie, eventi duplicati e cronologie fuorvianti. I team di sicurezza devono comunque mantenere schemi, controlli di qualità, tracciabilità e logiche di rilevamento.

È qui che i fornitori SIEM mantengono un vantaggio. Forniscono contenuti specifici per la sicurezza, interfacce di indagine consolidate, connettori, gestione dei casi e integrazioni per la risposta. Molti clienti preferiscono queste capacità preconfezionate rispetto all'assemblaggio su una piattaforma dati generica.

Google Security Operations offre analisi di sicurezza e threat intelligence su scala cloud in un ambiente operativo dedicato. Microsoft collega Sentinel con i propri prodotti per identità, endpoint, produttività e cloud. CrowdStrike sta estendendo i dati sugli endpoint e sulle minacce in una piattaforma di sicurezza agentica.

Splunk dispone di un'ampia base installata, integrazioni estese e anni di contenuti per il rilevamento. Anche Palo Alto Networks e altri fornitori di sicurezza stanno consolidando dati e automazione. Databricks entra in un mercato in cui gli acquirenti devono già confrontarsi con affermazioni di piattaforma sovrapposte.

La posizione più forte di Databricks non è la sostituzione immediata. È la leva architetturale. Le organizzazioni possono usare il lakehouse per ridurre la duplicazione della telemetria, conservare più storico, arricchire le indagini e sperimentare flussi di lavoro assistiti dall'AI senza spostare subito ogni processo operativo.

Un approccio graduale rende anche le prestazioni più facili da misurare. I team possono iniziare dall'ottimizzazione dei costi dei log o dalla threat hunting storica. Possono confrontare velocità delle query, copertura di rilevamento, impegno ingegneristico e spesa operativa totale con il sistema esistente.

La fase successiva potrebbe trasferire rilevamenti selezionati in Databricks. Gli ingegneri della sicurezza possono gestire la logica attraverso pratiche di sviluppo familiari, tra cui controllo di versione e test. Gli avvisi possono continuare a fluire in un sistema consolidato di gestione dei casi.

Una sostituzione completa richiede più prove. Un SIEM primario deve supportare acquisizione affidabile, rilevamento a bassa latenza, continuità delle indagini, requisiti di audit e coordinamento della risposta. Deve inoltre rimanere utilizzabile durante incidenti che colpiscono altri sistemi aziendali.

Databricks promuove Lakewatch come un SIEM aperto e agentico costruito sulla piattaforma dell'azienda. La direzione del prodotto rende più chiara l'intenzione competitiva. Databricks vuole passare dal supportare le analisi di sicurezza al possedere una quota maggiore del flusso di lavoro operativo.

Questo cambiamento mette sotto pressione i fornitori tradizionali sul piano dell'economia della conservazione e dell'accesso ai dati. Mette anche Databricks sotto pressione affinché soddisfi aspettative specifiche per la sicurezza. L'affidabilità della piattaforma dati è necessaria, ma un sistema di difesa operativa comporta responsabilità aggiuntive.

Il potere contrattuale dell'acquirente deriva dal separare le affermazioni in livelli verificabili. L'economia dello storage può essere valutata indipendentemente dalla qualità del rilevamento. La produttività degli agenti può essere valutata separatamente dalla sicurezza della risposta. La portabilità può essere testata a livello di dati, query, regole e flussi di lavoro.

I responsabili della sicurezza dovrebbero anche tenere traccia del lavoro nascosto. Una piattaforma può ridurre la pressione delle licenze aumentando al contempo il lavoro ingegneristico. Manutenzione degli schemi, sviluppo dei connettori, messa a punto dei rilevamenti, autorizzazioni e supporto reperibile rientrano tutti nel confronto.

Per questo la proposta di Databricks è più significativa di un altro annuncio sulle funzionalità AI. Riapre il confine tra l'infrastruttura dati aziendale e il centro operativo di sicurezza. Questo confine ha modellato per anni budget e flussi di lavoro della sicurezza.

La difesa guidata dall'AI eredita un problema di governance dell'AI

Gli stessi agenti che comprimono le indagini possono anche accelerare errori, accessi non autorizzati e risposte supervisionate in modo inadeguato.

Databricks presenta la governance come parte dell'architettura anziché come un passaggio di conformità separato. Unity Catalog controlla l'accesso ai dati e alle risorse AI. Unity AI Gateway gestisce il traffico verso modelli e servizi di strumenti.

La guida alla governance dell'AI dell'azienda afferma che il gateway può instradare richieste verso modelli e Model Context Protocol. Può inoltre applicare limiti, politiche e registrare l'utilizzo tra diversi provider.

Model Context Protocol, o MCP, è uno standard che consente alle applicazioni AI di connettersi a strumenti e fonti dati. In un ambiente di sicurezza, un servizio MCP potrebbe esporre threat intelligence, funzioni di ticketing, registri degli asset o strumenti di risposta approvati.

Il controllo centralizzato offre un vantaggio pratico. Un'organizzazione può governare un modello esterno, un agente di coding o un servizio MCP attraverso lo stesso livello di accesso usato per altre risorse dati. Databricks afferma che ciò può includere modelli di Google, Anthropic e OpenAI.

Alcune funzionalità restano in beta. Databricks descrive politiche di servizio che possono consentire, negare o richiedere approvazione per le richieste in base al contenuto. Lo stato di anteprima è importante quando ci si aspetta che tali politiche blocchino l'esposizione di dati sensibili o l'uso pericoloso degli strumenti.

Nessun responsabile della sicurezza dovrebbe trattare una protezione beta come l'unica barriera a tutela di un'azione di risposta in produzione. La difesa richiede controlli sovrapposti. Restrizioni di identità, strumenti con ambito limitato, barriere di approvazione, logging, limiti di frequenza e azioni reversibili dovrebbero rafforzarsi a vicenda.

Anche la revisione umana necessita di una definizione precisa. Richiedere a un analista di approvare ogni suggerimento può preservare il controllo, ma potrebbe ricreare la coda che l'automazione avrebbe dovuto ridurre. Consentire un'ampia autonomia può migliorare la velocità aumentando al contempo l'impatto di una decisione errata.

Un progetto pratico divide le azioni in base alle conseguenze. Il recupero in sola lettura comporta meno rischi della disabilitazione di un account. Redigere una regola di rilevamento è diverso dal distribuirla. Mettere in quarantena un singolo endpoint è diverso dal modificare una policy estesa all'intera rete.

Ogni categoria necessita del proprio confine di autorizzazione. Le azioni reversibili e ad alta confidenza possono ricevere maggiore automazione. Le azioni ambigue o ad alto impatto dovrebbero richiedere prove aggiuntive e approvazione esplicita.

L'esposizione dei dati crea un'altra preoccupazione. Un agente di indagine necessita spesso di attività degli utenti, dettagli dei dispositivi, log delle applicazioni e contesto organizzativo. Questa combinazione può rivelare informazioni personali o aziendali sensibili anche quando ogni fonte, isolatamente, sembra innocua.

Databricks afferma nella sua documentazione sulla fiducia nell'AI che i provider partner dei modelli non conservano prompt o risposte. Afferma inoltre che le autorizzazioni di Unity Catalog regolano quali dati le sue funzionalità AI possono inviare.

La documentazione riconosce che i modelli possono allucinare o produrre risposte errate. Questo avviso è particolarmente importante nella sicurezza, dove un riepilogo fluente ma inaccurato può deviare un'indagine o implicare erroneamente un utente.

Il recupero consapevole delle autorizzazioni riduce gli accessi non autorizzati. Non dimostra l'accuratezza fattuale. I team necessitano di valutazioni basate su modelli di incidente reali, input avversari, telemetria incompleta e prove contrastanti.

Il prompt injection aggiunge un altro rischio. Un attaccante potrebbe inserire testo malevolo in un ticket, in un campo di log, in un repository o in un documento che un agente recupera successivamente. Se il sistema tratta quel contenuto come un'istruzione, il flusso di lavoro dell'indagine può essere manipolato.

Le politiche di governance possono filtrare alcuni attacchi, ma una difesa affidabile dipende anche dalla separazione architetturale. I dati recuperati dovrebbero rimanere non attendibili. Gli strumenti dovrebbero applicare l'autorizzazione al di fuori del modello. Le azioni sensibili non dovrebbero dipendere esclusivamente da una decisione generata.

L'auditabilità diventa la verifica finale. I team necessitano di registri che mostrino quali dati ha consultato un agente, quale modello li ha elaborati, quali strumenti sono stati chiamati e chi ha approvato il risultato. Senza questa catena, la revisione degli incidenti e le prove normative diventano difficili.

Questo è rilevante anche per il lavoro della conoscenza al di fuori del centro operativo di sicurezza. I team che utilizzano una base di conoscenza AI affrontano domande simili su autorizzazioni, qualità delle fonti e tracciabilità. La sicurezza innalza le conseguenze, ma il principio di governance rimane lo stesso.

Databricks ha assemblato componenti credibili per questo problema. L'azienda non ha dimostrato che ogni cliente possa combinarli in una difesa autonoma sicura. Questo risultato dipende dalla disciplina di implementazione, dalla misurazione e dalla responsabilità operativa.

Tre segnali mostreranno se la strategia funziona

Il prossimo test non è un'altra dimostrazione AI; è la prova che Databricks può migliorare la difesa senza trasferire costi e rischi altrove.

Il primo segnale è una prestazione dei clienti comprensibile in modo indipendente. Databricks necessita di più casi di studio che definiscano il riferimento di base, il carico di lavoro, l'ambito di distribuzione e il periodo di misurazione. Una percentuale senza questi dettagli attira l'attenzione ma offre indicazioni limitate.

I responsabili della sicurezza dovrebbero cercare copertura di rilevamento, tempo medio di indagine, tassi di falsi positivi, profondità di conservazione e impegno ingegneristico totale. Le affermazioni sui costi dovrebbero includere lavoro di migrazione, manutenzione dei connettori, infrastruttura e personale.

Se i clienti mantengono una telemetria più ampia riducendo sia il tempo di indagine sia la spesa operativa, Databricks acquisisce argomenti più forti. Se i risparmi dipendono da una sostanziale ingegneria personalizzata, l'argomento diventa meno persuasivo per i team più piccoli.

Il secondo segnale è la maturità delle operazioni degli agenti governate. Politiche di servizio, controlli di approvazione, restrizioni sugli strumenti e registri di audit devono andare oltre le dimostrazioni. Gli acquirenti necessitano di comportamenti documentati in caso di guasto, attacco e prove ambigue.

Una convalida utile mostrerebbe un agente che incontra contenuti recuperati malevoli senza seguirli. Un'altra mostrerebbe un'azione di risposta bloccata perché l'identità richiedente non disponeva dell'autorizzazione. I team necessitano inoltre di procedure chiare per rollback e revisione degli incidenti.

Se questi controlli diventano generalmente disponibili e superano i test avversari, la tesi della difesa guidata dall'AI si rafforza. Se le protezioni critiche restano anteprime o richiedono un esteso lavoro personalizzato, l'autonomia dovrebbe rimanere strettamente delimitata.

Il terzo segnale è la risposta competitiva. Google, Microsoft, Splunk, CrowdStrike e Palo Alto Networks controllano già importanti flussi di lavoro della sicurezza. Possono adeguare i modelli di conservazione, aprire l'accesso ai dati, espandere la governance degli agenti o approfondire le integrazioni cloud.

Google merita particolare attenzione perché è sia un partner infrastrutturale sia un concorrente nel settore delle piattaforme di sicurezza. Un cliente Databricks Google può combinare i rispettivi servizi, ma piani di controllo sovrapposti possono creare responsabilità poco chiare.

Un'interoperabilità più stretta favorirebbe Databricks. I dati di sicurezza potrebbero rimanere portabili mentre avvisi, casi, threat intelligence e azioni di risposta si muovono attraverso interfacce definite. Gli acquirenti otterrebbero scelta architetturale senza ricostruire ogni flusso di lavoro.

Un bundling più stretto delle piattaforme potrebbe indebolire l'argomento. Se i fornitori consolidati abbinano un'economia dello storage accettabile ad agenti di sicurezza maturi, i clienti potrebbero preferire un'unica suite operativa. Durante gli incidenti, comodità e responsabilità contano spesso più dell'eleganza architetturale.

I responsabili della sicurezza non devono scegliere immediatamente un'architettura definitiva. Possono testare il modello Databricks su un carico di lavoro costoso o frammentato. La threat hunting storica, l'analisi degli audit cloud e lo sviluppo dei rilevamenti offrono punti di partenza delimitati.

Il progetto pilota dovrebbe preservare il flusso di lavoro esistente producendo al contempo misurazioni comparabili. I team dovrebbero definire il successo prima di spostare i dati. Dovrebbero anche registrare il lavoro necessario per normalizzare la telemetria e mantenere affidabili i rilevamenti.

Una revisione utile pone cinque domande. Il nuovo sistema ha conservato più dati rilevanti? Gli analisti hanno indagato più rapidamente? I rilevamenti sono migliorati? L'impegno operativo totale è diminuito? La governance è rimasta comprensibile?

Le risposte mostreranno se il lakehouse sta diventando un livello operativo di sicurezza o semplicemente un'altra destinazione per i log. Separano inoltre il valore dell'AI dal valore dello storage, che i fornitori spesso presentano insieme.

Databricks ha individuato un vincolo reale. Gli agenti non possono compensare dati di sicurezza frammentati, inaccessibili o governati in modo inadeguato. La sua guida offre ai responsabili della sicurezza un motivo per riconsiderare dove risiedono tali dati e chi li controlla.

La questione irrisolta è la fiducia operativa. Un'azienda di piattaforme dati può offrire l'affidabilità, i contenuti di sicurezza, i controlli di risposta e la responsabilità attesi da un sistema di difesa in prima linea?

Per i team che valutano un'architettura databricks google, la prossima mossa è un confronto misurato, non una sostituzione immediata. Scegliete un flusso di lavoro di indagine, definite le relative autorizzazioni e raccogliete risultati di riferimento. Poi verificate se il contesto unificato migliora le decisioni senza ampliare l'accesso o aumentare il lavoro nascosto. Queste prove conteranno più del numero di agenti in una dimostrazione di prodotto.