Ido Livneh, Amministratore Delegato e Co-Fondatore di Jazz – Serie di Interviste

Ido Livneh, Amministratore Delegato e Co-Fondatore di Jazz, è un leader di prodotto esperto e imprenditore con una solida esperienza nel costruire e far crescere piattaforme tecnologiche ad alto impatto, tra cui la guida del prodotto in Laminar attraverso il suo acquisto da parte di Rubrik e l’aiuto a guidare la vendita di successo di Tapingo a Grubhub per 150 milioni di dollari; la sua carriera include ruoli senior in Axonius e in precedenti imprese come KnuPo, e si basa su una solida fondazione tecnica sviluppata durante quasi un decennio nelle Forze di Difesa israeliane, dove è passato dall’ingegneria alla guida della R&S di software, un’esperienza che ora plasma la sua attenzione per la costruzione di soluzioni di sicurezza native AI.

Jazz è un’azienda di sicurezza nativa AI che ripensa la Prevenzione della Perdita di Dati (DLP) andando oltre i sistemi basati su regole legacy e introducendo una piattaforma consapevole del contesto che comprende come i dati fluiscono all’interno delle organizzazioni, analizzando il comportamento degli utenti, dei sistemi e dei flussi di lavoro per identificare i rischi reali invece di generare allarmi eccessivi; utilizzando l’AI per indagare sugli incidenti alla loro fonte e fornire informazioni azionabili, la piattaforma consente ai team di sicurezza snelli di gestire ambienti complessi e prevenire l’esposizione di dati sensibili in tutta la gamma di applicazioni cloud, endpoint e sistemi interni, posizionando Jazz come parte di una nuova generazione di aziende che ricostruiscono la sicurezza aziendale per l’era AI.

Ha guidato il prodotto in aziende come Laminar attraverso il suo acquisto e ha ricoperto ruoli di leadership in Axonius e Grubhub, mentre ha anche fondato diverse startup. Qual è l’esatto gap o l’intuizione specifica derivata da quelle esperienze che l’ha spinto a fondare Jazz, e perché era il momento giusto per reinventare la Prevenzione della Perdita di Dati (DLP)?

Ho trascorso l’ultimo decennio costruendo prodotti di sicurezza e sedendo al tavolo con i CISO. Tre ruoli di VP Product, due uscite – compresa Laminar, che abbiamo venduto a Rubrik. E se c’è una cosa che ho imparato in tutto questo, è che assolutamente nessuno ama il proprio DLP.

In Laminar, abbiamo costruito i primi inning della categoria DSPM – data security posture management. Grande problema, ma abbiamo trascorso tre anni educando il mercato prima che gli ingressi inizassero. Me ne sono andato pensando: la prossima volta, voglio un problema vecchio. Un problema che ogni consiglio già conosce, ogni CISO già ha un budget per, e che nessuno ha realmente risolto.

DLP è quel problema. Ha vent’anni. Ogni organizzazione di sicurezza conosce il rischio. E le soluzioni presenti sul mercato sono universalmente odiate – non perché i vendor sono incompetenti, ma perché l’intero framework è sbagliato. Abbiamo chiesto alle macchine di abbinare modelli e agli esseri umani di fornire il contesto. Quel modello era destinato a fallire.

Il timing era ovvio. L’AI ci ha dato la capacità di fare qualcosa che era letteralmente impossibile prima – costruire un sistema che comprende i dati come farebbe un analista senior, ma in modo autonomo e su larga scala. Quando l’abbiamo visto, i quattro co-fondatori – tutti ex allievi di Unit 81 – sapevano che era il momento giusto per tornare ai principi fondamentali e ricostruire il DLP da zero. E questa volta, farlo funzionare, e facilmente.

I sistemi DLP tradizionali sono stati a lungo criticati per generare allarmi eccessivi. Cosa si rompe fondamentalmente nei sistemi DLP basati su regole, e perché l’industria ha faticato a risolvere questo problema?

Il problema non è che il DLP basato su regole necessita di regole migliori. Il problema è che le regole erano lo strumento sbagliato per questo lavoro fin dall’inizio.

Ecco come funziona in realtà. Si distribuisce un sistema che comprende i modelli – regex, tipi di file, parole chiave. Si scrivono regole. La macchina abbina i dati a quelle regole, e ogni volta che c’è un abbinamento, dice a un analista umano: “Vieni a vedere questo.” L’analista deve poi portare tutto il contesto – chi è questa persona, cosa stava facendo, perché lo stava facendo – e prendere una decisione.

Quella seconda parte, l’indagine umana, non si scala mai. La fisica del DLP è troppo rumorosa. I dati si muovono costantemente all’interno di qualsiasi grande azienda. Un numero a nove cifre non è sempre un numero di sicurezza sociale. Un upload di file non è sempre esfiltrazione. Una lettera di valutazione “A” attiva le regole FERPA. Un trasferimento interno tra reparti viene bloccato. Il sistema non può dire se una condivisione di file sensibili è collaborazione aziendale vitale o se i tuoi gioielli più preziosi stanno uscendo dalla porta.

Cosa fanno le aziende? Aggiungono eccezioni. Ogni eccezione è un momento in cui lo strumento non ha capito il loro business. E ognuna è essenzialmente una backdoor autorizzata. Zoom out dopo diciotto mesi e ciò che stai eseguendo non è un programma di sicurezza – è un registro di compromessi mascherato da un rapporto di conformità.

Circa il 30% del mercato ha un programma DLP maturo, e anche loro sanno che è il massimo che possono fare – soddisfare i framework di conformità e nulla più. Li chiamiamo “i bloccati”. Gli altri 70% non hanno mai provato o hanno provato e fallito. I precedenti tentativi di risolvere questo problema hanno aggiunto un po’ di AI alla stessa struttura basata su regole. È come mettere una mano di vernice fresca su una macchina con un motore che tutti sanno non può gestire il carico. La struttura stessa è ciò che deve cambiare.

Jazz si posiziona come fornitore di risposte invece di allarmi. Può spiegare come il suo sistema indaga sugli incidenti e cosa lo rende diverso dai flussi di rilevamento legacy?

Il DLP legacy ti dà un allarme antincendio e poi ti consegna una lente d’ingrandimento. “Qualcosa è successo in quell’edificio. Buona fortuna a scoprire su quale piano.”

Jazz non fa questo. Abbiamo costruito un investigatore autonomo, il suo nome è Melody, che fa il lavoro che farebbe un analista umano, ma su scala sovrumana.

Quando si verifica una transazione di dati, Melody non si limita a segnalarla. Esegue una piena indagine su quattro dimensioni. Prima, i dati stessi – non con regex e modelli, ma comprendendo profondamente cosa sono questi dati, a chi appartengono, quale è il rischio di perderli per questa azienda specifica. Secondo, i sistemi – da dove provengono i dati, dove stanno andando e, criticamente, quale tenant. C’è una differenza enorme tra l’upload di un file su un Google Drive aziendale e uno personale, e Melody comprende quella distinzione.

Terzo, le persone – impariamo come gli individui operano, come utilizzano i dati nel tempo, cosa è normale per il loro ruolo. E quarto, il processo aziendale – perché sta avvenendo questa transazione? Fa parte di un flusso di lavoro noto o è qualcosa che non possiamo spiegare?

Questi agenti multipli si uniscono e ricostruiscono la storia completa: cosa è successo, perché è successo e quale era l’intento dell’attore. Quando un umano lo vede, non è un allarme – è una narrazione pre-indagata con prove, contesto e un verdetto. In un tipico deployment, Jazz elabora circa 2 milioni di segnali al mese per ogni mille dipendenti, indaga centinaia di migliaia di potenziali eventi e porta in superficie circa 80 incidenti che richiedono effettivamente l’attenzione umana. È un rapporto segnale-rumore di 20.000 a 1. È così che mettiamo fine agli allarmi in azione e alla fatica degli allarmi.

La sua piattaforma analizza il contesto attraverso i dati, i sistemi, le persone e il business. Come unifica tecnicamente queste dimensioni, e quale ruolo giocano gli agenti AI o i sistemi di ragionamento in questo processo?

L’architettura è costruita intorno a più agenti AI specializzati, ciascuno dei quali analizza una singola transazione di dati da una prospettiva diversa.

Un agente si concentra sul comprendere profondamente i dati – il loro contenuto, la sensibilità, la proprietà e la rilevanza per l’azienda. Un altro guarda al paesaggio dei sistemi – non solo i nomi delle applicazioni, ma i tenant specifici, il livello di fiducia, se è aziendale o personale. Un terzo costruisce e aggiorna continuamente profili di come gli individui operano e utilizzano i dati, in modo da poter valutare se un’azione data è coerente con il loro ruolo o completamente anomala. E un quarto mappa i processi aziendali – collegando le transazioni di dati ai flussi di lavoro noti e identificando quelli che non possono essere spiegati.

Questi agenti poi convergono e sintetizzano i loro risultati in un’indagine unificata – una narrazione completa di cosa è successo, perché e se è un rischio genuino.

Tutto ciò si basa su due innovazioni fondamentali. Primo, quello che chiamiamo vault di contesto endpoint – un nuovo tipo di segnali che abbiamo brevettato specificamente per il DLP. Questi catturano non solo la transazione di dati stessa, ma l’intera storia intorno ad essa: cosa è successo prima, cosa è successo dopo, quali applicazioni erano coinvolte, la catena completa di attività dell’utente. Questi segnali sono contesto incredibilmente ricco e ci consentono di fornire non solo cosa è successo, ma anche perché è successo e l’intento dell’attore, che erano sempre sfuggenti per le macchine da capire su larga scala.

Secondo, un motore di politiche in linguaggio naturale che sostituisce i tradizionali set di regole rigide. Invece di scrivere regole tecniche con regex e soglie, i team di sicurezza descrivono cosa è accettabile e cosa non lo è nel modo in cui lo farebbe un umano – in linguaggio semplice. Melody utilizza questo per prendere decisioni nuance su situazioni che potrebbero non essere menzionate esplicitamente in alcuna politica. Perché la realtà delle pratiche aziendali quotidiane in un’organizzazione spesso differisce enormemente da ciò che è effettivamente scritto in un documento di politica standard. Colmiamo quel divario, e per coloro che hanno una lunga esperienza con i programmi DLP, questo sembra magia.

Molte aziende stanno ora distribuendo agenti AI autonomi che interagiscono con dati sensibili. Come questo cambiamento modifica il panorama delle minacce, e perché richiede un nuovo approccio al DLP?

Questo è una bomba a orologeria.

L’esplosione del SaaS stava già sovraccaricando i team di sicurezza – ogni settimana, cinque nuovi strumenti appaiono nell’ambiente, molti adottati dagli dipendenti senza l’approvazione dell’IT. Abbiamo avuto clienti che hanno scoperto oltre 400 strumenti GenAI in esecuzione in tutta la loro organizzazione che nessuno conosceva. Ora aggiungi agenti AI autonomi su tutto ciò.

Gli agenti AI non gestiscono solo passivamente i dati – li tirano attivamente, li trasformano, li inviano ad altri servizi, prendono decisioni su dove vanno. Un dipendente che collega un assistente di codifica AI al codice base di un’azienda, utilizzando un account personale e poi inviando output a un repository personale – abbiamo visto esattamente questo sul campo. O qualcuno che incolla documenti di strategia proprietari in una sessione ChatGPT personale perché l’azienda non ha fornito un account aziendale. Anche qualcosa di semplice come un plugin Grammarly personale che esamina tutto ciò che si digita, compresi i dettagli del trasferimento bancario e i dati dei clienti.

Il DLP basato su regole è stato costruito per un mondo in cui i dati si muovevano attraverso pochi canali noti – allegati di posta elettronica, chiavette USB, forse un upload web. L’era AI ha fatto saltare in aria quel modello. I dati ora fluiscono attraverso dozzine di vettori che i sistemi legacy non possono nemmeno vedere, figuriamoci capire. Hai bisogno di un sistema che possa comprendere cosa sta succedendo in modo contestuale – non solo che i dati si sono mossi, ma perché, attraverso cosa e se la destinazione è autorizzata.

È fondamentalmente il motivo per cui il vecchio framework non può essere corretto. Hai bisogno di un approccio che comprenda il contesto aziendale in modo nativo, perché la superficie di attacco non è più un elenco di canali, ma ogni interazione tra esseri umani, strumenti AI e dati sensibili.

La spiegabilità rimane una grande barriera all’adozione dell’AI nella sicurezza. Come assicura che le decisioni del suo sistema siano comprensibili e degne di fiducia per i team di sicurezza che operano in ambienti ad alto rischio?

Questo è qualcosa a cui abbiamo pensato fin dal primo giorno, perché l’ultima cosa di cui un CISO ha bisogno è un’altra scatola nera.

Ogni indagine che Melody produce è una narrazione – non un punteggio, non un codice colore, non un numero di rischio criptico. Legge come una relazione da un analista senior. Ecco cosa è successo. Ecco chi era coinvolto. Ecco perché pensiamo che l’abbiano fatto. Ecco le prove. Ecco la politica a cui si riferisce. Ecco la nostra valutazione.

Il motore di politiche in linguaggio naturale è fondamentale per questo. Perché le politiche stesse sono scritte in linguaggio semplice, i team di sicurezza possono vedere esattamente a quale politica una decisione si riferisce e perché. Se Melody segnala qualcosa, il team può tracciare la catena di ragionamento dalle segnalazioni grezze all’analisi contestuale all’abbinamento della politica. E se non sono d’accordo, possono raffinare la politica in linguaggio semplice – non debuggando un set di regole.

Mostriamo anche le prove direttamente, la catena completa di attività. Non è “fidati dell’AI”, è “ecco cosa l’AI ha visto, ecco cosa ha concluso e ecco i dati grezzi in modo che tu possa verificare”. I nostri clienti ci dicono che sembra più come rivedere il output di un AI e più come ricevere un briefing da un collega molto scrupoloso.

Quello è il livello. I team di sicurezza operano in ambienti in cui una decisione errata può significare conseguenze regolamentari, esposizione legale o la carriera di un dipendente. Il sistema deve guadagnare fiducia essendo trasparente su come raggiunge le sue conclusioni.

Jazz descrive il suo sistema come più simile a un investigatore umano che a un motore di regole. Cosa significa questo nella pratica, e quanto siamo vicini a vere operazioni di sicurezza autonome?

Quando dico che Melody si comporta come un investigatore umano, intendo letteralmente.

Un grande analista DLP non vede solo che un file è stato caricato. Guarda chi l’ha caricato, cosa c’era dentro, dove è andato, se questa persona normalmente gestisce questo tipo di dati, se c’è un motivo aziendale per farlo e cosa è successo prima e dopo. Utilizza un giudizio in contesto – non solo regole – e ciò richiede una comprensione contestuale del loro business. È esattamente ciò che fa Melody, ma su ogni transazione di dati in un’azienda, continuamente e su larga scala.

Nella pratica, i nostri clienti descrivono Melody come un altro membro del loro team. Ci mostra situazioni che sono al di fuori della politica, fornisce l’indagine completa con prove ed evidence, e chiede il loro giudizio sui casi che richiedono effettivamente un input umano. Impara l’organizzazione nel tempo – i processi aziendali, le eccezioni, le cose che sono tecnicamente una violazione ma operativamente normali.

Per quanto riguarda le vere operazioni di sicurezza autonome – siamo più vicini di quanto la maggior parte delle persone pensi, ma voglio essere precisi su cosa significa. Melody già opera in modo autonomo nella fase di indagine. Prende segnali grezzi e produce verdetti completamente indagati e contestualizzati senza coinvolgimento umano. Per scenari ad alto rischio e alta fiducia, può anche intraprendere azioni di prevenzione in modo autonomo – bloccando un’esfiltrazione prima che si completi.

L’umano rimane nel loop per le decisioni e per il processo di apprendimento umano nel loop. E questo è per design. L’obiettivo non è rimuovere gli esseri umani dalla sicurezza, ma rimuovere il lavoro tedioso e ripetitivo che li brucia e lasciarli concentrarsi sulle decisioni che richiedono effettivamente un giudizio umano. È dove siamo oggi, ed è già trasformativo per come i nostri clienti gestiscono i loro programmi.

Da un punto di vista produttivo e ingegneristico, quali sono stati i sfidi tecnici più difficili nel costruire una piattaforma DLP nativa AI da zero invece di iterare sulle architetture esistenti?

La parte più dura è stata resistere alla tentazione di prendere scorciatoie.

Quando si inizia da zero, c’è sempre pressione per prendere in prestito pezzi dell’architettura vecchia perché sono provati e veloci, e sono più allineati con le aspettative dei clienti esistenti. Ma ogni volta che lo fai, erediti i limiti del vecchio modello. Abbiamo preso una decisione deliberata di tornare ai principi fondamentali – pensare alla fisica di base del problema e ricostruire.

L’agente endpoint è stato una delle sfide più grandi. Dovevamo ripensare la sfida della raccolta dei segnali e raggiungere un contesto sufficiente, e non prendere la strada testata dei segnali legacy – mantenendo al tempo stesso un impatto basso sulle prestazioni del sistema. Costruire questo su tutti i sistemi operativi è stato uno sforzo ingegneristico serio. Siamo finiti con un approccio brevettato che ci dà una visibilità che nessun altro ha.

Il sistema AI multi-agente è stata un’altra grande sfida. Ottenere più agenti AI specializzati per analizzare la stessa transazione da prospettive diverse e poi convergere su una narrazione coerente e precisa – ciò ha richiesto molto pensiero architettonico. Non è solo lanciare un LLM su un flusso di dati. Il livello di orchestrazione, il modo in cui gli agenti condividono il contesto, il modo in cui risolvono segnali in conflitto – è lì che vive la maggior parte della sfida.

E poi il motore di politiche in linguaggio naturale. Tradurre descrizioni in linguaggio umano di cosa è accettabile e cosa non lo è in qualcosa che un’AI può applicare in modo affidabile a migliaia di casi limite – è un problema fondamentalmente difficile. Le pratiche aziendali quotidiane spesso divergono notevolmente da ciò che è scritto in un documento di politica standard. Il sistema deve colmare quel divario, e deve farlo correttamente, perché le conseguenze dell’errore nel DLP sono gravi.

Abbiamo scelto ogni uno di quei problemi difficili intenzionalmente, perché sono quelli che fanno la differenza tra un DLP marginalmente migliore e qualcosa di fondamentalmente nuovo.

In ciascuna di quelle sfide e in molte altre, ci sono ancora ostacoli aperti da superare, e insiemi di problemi unici per il talento giusto da affrontare. Risolvere bene il DLP è un viaggio di scoperta e affascinante.

Jazz è stato selezionato come vincitore dell’Acceleratore di Startup di Sicurezza 2026 supportato da CrowdStrike, AWS e NVIDIA. Cosa ha validato quell’esperienza riguardo al suo approccio, e come ha influenzato la sua roadmap in avanti?

Mille startup hanno presentato la loro candidatura. Sei sono arrivate in finale. Noi abbiamo vinto.

Sarò onesto, il momento prima di salire sul palco, il tuo cervello ti ricorda tutto ciò che potrebbe andare storto. E poi inizi a parlare del problema su cui abbiamo lavorato, e tutto si fa silenzioso. Ogni notte tardi a discutere di come Melody dovrebbe funzionare, ogni decisione architettonica difficile, ogni conversazione con i clienti che ha plasmato il prodotto, tutto si è compresso in quei minuti.

I giudici, George Kurtz, CJ Moses, Bartley Richardson e il leggendario squalo, Robert Herjavec, l’hanno visto. Hanno menzionato specificamente il modello di indagine agente e la nostra rapida adozione da parte dei clienti. Per noi, la validazione dei leader del settore è contata più del trofeo. Queste sono persone che hanno costruito e gestito programmi di sicurezza al più alto livello, e hanno riconosciuto che ciò che stiamo facendo è fondamentalmente diverso da ciò che è stato tentato prima – e che la nostra presa è reale.

In termini di roadmap, l’acceleratore ha rafforzato ciò che i nostri clienti già ci stavano dicendo – il mercato è pronto per questo, e vogliono che ci muoviamo velocemente. Stiamo raddoppiando gli sforzi per espandere le capacità dell’investigatore e mettere il prodotto di fronte al maggior numero possibile di team di sicurezza.

Guardando avanti, crede che il DLP evolva in un sistema completamente autonomo e guidato da agenti, e cosa rappresenta il futuro a lungo termine della sicurezza dei dati in un’azienda nativa AI?

Credo che il DLP diventerà completamente autonomo in fasi. Il livello di indagine è già lì – Melody lo fa oggi. La prevenzione per scenari ad alta fiducia sta avvenendo ora. Nel tempo, il sistema diventa più intelligente sull’organizzazione, impara i flussi di lavoro, comprende le persone e la superficie che richiede effettivamente un giudizio umano si riduce.

Ma voglio essere chiaro – “autonomo” non significa “non supervisionato”. Significa che il sistema gestisce il lavoro che gli esseri umani non dovrebbero fare, in modo che possano concentrarsi sulle decisioni che realmente contano. Il CISO del futuro non sta annegando in allarmi. Sta esaminando valutazioni di rischio strategiche da un’AI che comprende il loro business quanto il loro miglior analista. Prende azioni chirurgiche che sono rilevanti per la loro organizzazione, basate su informazioni aggregate sul loro paesaggio di perdita di dati attiva, e non su ipotesi. Ciò consente loro di ridurre il rischio dei dati senza rallentare il loro business.

L’immagine più grande è questa: in un’azienda nativa AI, i dati si muovono più velocemente, attraverso più canali, in modi più complessi di quanto qualsiasi team umano possa tracciare. Le organizzazioni che vincono saranno quelle il cui sistema di sicurezza può comprendere il contesto alla velocità dell’AI, non quelle che stanno ancora scrivendo regole regex e sperando nel meglio.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Jazz.