Val Bercovici, Chief AI Officer di WEKA – Serie di Interviste

Val Bercovici, Chief AI Officer at WEKA, è un dirigente specializzato in AI e infrastrutture dati, focalizzato sull’avanzamento delle tecnologie che sostengono l’intelligenza artificiale di nuova generazione. Da quando è entrato in WEKA come Chief AI Officer nel gennaio 2025, si è concentrato sulla costruzione di infrastrutture per agenti AI, sull’accelerazione dei carichi di lavoro di addestramento e inferenza e sul miglioramento dell’economia del calcolo AI. Oltre al suo ruolo in WEKA, Bercovici è consulente AI per Home Dock, consulente strategico per FermiHDI e The Hive, e Presidente di PencilDATA, dove il suo lavoro spazia tra AI, cybersecurity, blockchain, cloud computing e infrastrutture dati. La sua carriera riflette un impegno di lungo periodo nello sviluppo e nella consulenza di tecnologie emergenti progettate per supportare sistemi AI sempre più intensivi di dati.

WEKA è un’azienda di infrastrutture dati nativa AI che costruisce una piattaforma definita dal software, progettata per le esigenti necessità di dati dell’intelligenza artificiale, del machine learning, del calcolo ad alte prestazioni e di altri carichi di lavoro accelerati. La WEKA Data Platform fornisce alle organizzazioni un’architettura unificata in grado di operare su ambienti on‑premise, cloud, ibridi ed edge, contribuendo a eliminare i colli di bottiglia di storage, a migliorare l’utilizzo delle GPU e ad accelerare l’addestramento e l’inferenza dei modelli AI. L’azienda posiziona sempre più la sua tecnologia attorno all’emergente economia dell’inferenza e all’AI agentica, con un’infrastruttura progettata per offrire accesso ai dati ad alta velocità e bassa latenza su scala massiva, semplificando al contempo pipeline di dati AI complesse. WEKA serve imprese, fornitori di cloud, organizzazioni di ricerca e sviluppatori AI che operano negli ambienti informatici più ad alte prestazioni al mondo.

La tua carriera ti ha portato a modellare la prima strategia cloud di NetApp e a far parte del consiglio fondante di Kubernetes, fino a costruire infrastrutture AI in WEKA. Come ha influenzato questa evoluzione il modo in cui pensi alla preparazione dell’infrastruttura per la prossima fase dell’AI?

Ogni fase della mia carriera è stata definita dallo stesso schema: il collo di bottiglia si sposta e l’industria impiega anni a renderne conto. Nei primi giorni del cloud e di Kubernetes, abbiamo visto il calcolo diventare elastico e l’orchestrazione diventare il nuovo punto critico. Dopo NetApp, dove ero CTO dopo l’acquisizione di SolidFire, pensavo di sapere cosa significasse “veloce”: pochi millisecondi per una lettura casuale del primo byte in ambienti di produzione.

Il motivo per cui sono entrato in WEKA è genuinamente “geek”. C’era una statistica: la prima lettura casuale non memorizzata è di 70 microsecondi, un valore che non appartiene alla classe di storage. Non avevo mai considerato una latenza a livello di microsecondi per questo tipo di sistema. È stato il lampo di intuizione: questa tecnologia poteva servire applicazioni di memoria, applicazioni di classe DRAM come Redis e cache KV, non solo storage. E, al momento giusto, l’inferenza ha iniziato a superare l’addestramento perché l’industria doveva monetizzare questi modelli, e sono arrivati gli agenti per rendere la memoria l’intero gioco.

Questo è il punto di vista che porto all’infrastruttura AI. Abbiamo già visto questo film. Il FinOps del cloud è emerso perché le aziende hanno messo in piedi infrastrutture senza rigore economico unitario, per poi ricevere il conto. L’AI segue la stessa curva, ma più velocemente.  Man mano che le imprese hanno iniziato a spingere contro il “token‑maxxing” con l’arrivo di fatture di consumo API ben oltre i budget di token pianificati, stiamo assistendo all’ascesa del FinOps AI. È il momento in cui le organizzazioni smettono di trattare l’inferenza come un’utilità a basso costo e cominciano a gestire l’efficienza dei token come disciplina finanziaria. Il FinOps AI parte dalla tokenomica: ottimizzare ogni livello hardware e software dello stack di inferenza che incide sul costo unitario per token. Al momento lo spreco più grande in quello stack sono le GPU costose e i nuovi ASIC inattivi, in attesa di memoria e dati (cioè “decode”) anziché di FLOPS (cioè “prefill”). Chi risolve questo possiede la prossima fase dell’AI.

La Casa Bianca sta mantenendo riservati i dettagli del suo nuovo quadro di sicurezza AI. Come possono le imprese prepararsi ai requisiti normativi quando non sanno ancora esattamente cosa verrà testato o richiesto?

Le aziende non dovrebbero attendere la checklist finale. I test specifici cambieranno, ma l’obbligo sottostante rimarrà: dovrete dimostrare cosa ha fatto il vostro modello AI, quali dati ha toccato e come si è comportato in un determinato momento. E l’attesa non è più un’opzione a livello globale. Il AI Act dell’UE è diventato applicabile questo mese e classifica la maggior parte dell’orchestrazione di agenti come ad alto rischio.

Ciò significa che il lavoro di preparazione è lavoro di infrastruttura. Tracciabilità dei dati, osservabilità, riproducibilità e capacità di ricostruire lo stato del modello su richiesta sono tutti elementi critici che le imprese devono gestire correttamente. Infine, le organizzazioni devono implementare modelli di guardrail prima dell’output, con latenza e budget di token associati per i livelli di difesa semantica. Se costruite queste capacità ora, qualsiasi quadro diventa un esercizio di formattazione. Aspettare le regole definitive significherebbe retrofittare la responsabilità in sistemi che non sono mai stati progettati per spiegarsi. Quel retrofitting è sempre più costoso rispetto a costruirlo fin dall’inizio.

In definitiva, la soluzione per costruire AI sicura è più AI, applicata in modo ottimale e molto intenzionale.

Quali nuovi requisiti infrastrutturali potrebbe generare il testing di sicurezza AI, e in che modo quei carichi di lavoro differiranno dall’addestramento o dall’inferenza tradizionali?

L’addestramento è un tubo di fuoco. Si spingono enormi volumi di dati attraverso un modello in modo sostenuto e prevedibile. Il testing di sicurezza è l’opposto: migliaia di scenari di valutazione, probing ripetuto, confronti comportamentali versione‑su‑versione e red‑teaming avversario che non finisce mai.

Quel profilo è importante. La sicurezza nell’addestramento e nel testing è a scoppi, pesante in letture e comparativa. Genera e consuma enormi quantità di stato intermedio. I modelli di guardrail devono essere intrinsecamente eterogenei e stratificati, implementati entro budget di latenza stretti, amplificando le valutazioni con questa nuova dimensione di criteri di sicurezza. Per modelli così avanzati o cyber‑capaci, il profilo di carico è persistente 24/7 anziché episodico. Non si esegue un test una volta e si archivia il risultato. Si eseguono carichi di lavoro continui di sciami di agenti che competono in produzione per CPU, memoria e larghezza di banda dei dati per le app critiche che proteggono. Dopo qualità e velocità, la maggior parte dell’infrastruttura odierna non è progettata per questo terzo principio.

C’è anche un problema di misurazione sottostante. La maggior parte dei benchmark AI oggi gira su 8.000 token o meno, un prompt, una risposta. Scherzo sul fatto che siano benchmark artificiali di intelligenza artificiale. A metà 2026, i veri carichi di lavoro degli agenti gestiscono da 100.000 a 400.000 token di contesto su migliaia di turni. Se le valutazioni di sicurezza erediteranno quei benchmark giocattolo, certificheremo sistemi per un mondo che non esiste. I regolatori stanno già costruendo muscoli migliori: il NIST ha rilasciato in open source strumenti di valutazione della sicurezza degli agenti, e i primi risultati pubblicati mostrano attacchi di hijack di agenti novelli con tassi diverse dalle baseline note. È esattamente il tipo di testing continuo, avversario e costoso che mi aspetto converga nei quadri di sicurezza.

Le organizzazioni dovrebbero costruire capacità di calcolo e dati in eccesso specificamente per futuri carichi di lavoro di conformità e sicurezza, oppure esiste un modo più efficiente di progettare per tale incertezza?

Acquistare GPU in eccesso sperando che l’utilizzo si riallinei lascia semplicemente capitale bloccato in hardware che si deprezza.

La risposta efficiente è un’infrastruttura che flessibilizzi tra carichi di lavoro di produzione e di valutazione senza stack separato. È fondamentalmente un problema di dati. Se potete spostare e riutilizzare i dati in modo efficiente, preservare il contesto tra i carichi e tenere gli acceleratori occupati a fare lavoro reale, la conformità diventa un costo incrementale anziché una costruzione parallela. L’economia dell’AI scende sempre più a quanto valore si estrae da ogni token, byte e watt. Fatelo bene e potete generare 3‑4× più valore dalla stessa infrastruttura, o ridurre l’ingombro del rack fino al 75 %. La conformità dovrebbe essere tenuta allo stesso standard.

Il quadro attuale si concentra apparentemente su modelli chiusi avanzati escludendo i modelli a peso aperto. Quali sfide infrastrutturali o di sicurezza potrebbero emergere dal trattare queste due categorie in modo differente?

Se trattate i modelli chiusi e quelli a peso aperto in modo diverso, finite con due quadri di conformità per tecnologie che fanno le stesse cose, e il divario tra loro è dove risiede il rischio.

Un modello a peso aperto può essere fine‑tuned e distribuito in ambienti dove il fornitore originale non ha alcuna visibilità. Regolare il fornitore non serve lì. E la spaccatura è già visibile: i controlli all’esportazione hanno colpito i più recenti modelli di frontiera chiusi quest’anno, mentre i modelli a peso aperto attraversano le frontiere liberamente e ora si trovano in cima alle classifiche pubbliche di capacità. Tuttavia l’amministrazione finisce per definire i modelli di frontiera, la governance non può fermarsi al modello stesso. Serve visibilità su dove i modelli sono in esecuzione, quali dati accedono, quali prompt, risposte e metadati vengono conservati, come sono stati modificati e se l’infrastruttura sottostante può effettivamente supportare AI governata su larga scala. Saranno necessari nuovi aggiornamenti a ISO27001 e SOC2.

La mia risposta è “fidarsi ma verificare”. Se la vostra infrastruttura vi dà la capacità di token, potete eseguire guardrail eterogenei su qualsiasi modello prima che il suo output venga rilasciato: domestico o estero, aperto o chiuso. La verifica oggettiva supera la fiducia cieca o la sfiducia totale basata sull’origine del modello. Man mano che i modelli aperti proliferano, quella capacità di verifica vive nello strato infrastrutturale, ed è lì che le imprese si differenzieranno. La politica può decidere quali modelli sono permessi. L’infrastruttura decide se quei modelli possono essere distribuiti in modo responsabile ed economico.

Man mano che gli agenti AI diventano più autonomi e operano su contesti più lunghi, come cambia la quantità di dati, memoria e calcolo che le organizzazioni devono destinare al monitoraggio e alla sicurezza?

Un chatbot è un prompt e una risposta. Un agente autonomo è un processo in esecuzione. Interagisce con decine di sistemi, recupera informazioni, prende decisioni intermedie e accumula stato per ore o giorni prima di completare un compito.

Non potete monitorare ciò campionando token o risposte singole. Dovete catturare l’intera sequenza: cosa sapeva l’agente, quando lo sapeva e cosa ha fatto dopo. Ogni ora di esecuzione di un agente fa crescere il suo stato, così come la memoria, il movimento dei dati e l’infrastruttura necessaria per catturare e analizzarlo. Il monitoraggio smette di essere una semplice funzione di logging e diventa un carico di lavoro di prima classe con il proprio budget di risorse.

La difesa è dove la questione diventa urgente. Il problema di memoria dell’AI sta diventando un problema di sicurezza. Un agente di codifica può avviarsi, spedire e spegnersi. Un agente di cybersecurity non può. Deve mantenere il contesto attraverso i turni giornalieri di un security operations center, aggiornamenti frequenti del modello e campagne di attacco multi‑stage sofisticate che una volta si estendevano per settimane, ma oggi operano a velocità di macchina coordinate. Quando la memoria operativa di quell’AI viene espulsa e ricomputata da zero ogni pochi minuti, un agente che ha rilevato un comportamento anomalo nella prima ora di un incidente non ne ha più memoria nella seconda ora. Gli aggressori non hanno questo problema. I loro agenti identificano e perseguono vulnerabilità in modo persistente, e le catene di attacco ora si completano a velocità ottimizzate per la tokenomica, così la difesa AI deve operare autonomamente 24/7. E non è teoria: i fornitori di sicurezza stanno già preparando agenti cyber 24/7, e la prima cosa che scoprono è che l’economia è ben diversa da quella dei carichi di lavoro di chat. Alcune organizzazioni hanno bisogno di quegli agenti in edge, in strutture dove non è possibile installare rack di GPU o nemmeno un refrigeratore quest’anno. Il vero test per l’AI enterprise è la conservazione del contesto sostenuta, non l’inferenza puntuale. Questo diventa una guerra di attrito di token, e chi risolve la memoria di contesto persistente su larga scala alimenterà la prima applicazione killer orizzontale nell’AI enterprise: sciami di agenti blu sempre attivi.

Hai parlato dell’importanza crescente della “memoria di contesto” man mano che i carichi di lavoro AI passano da semplici chat a agenti persistenti. La memoria di contesto potrebbe diventare importante anche per audit, riproduzione o indagine del comportamento AI?

Assolutamente, ed è un caso d’uso cruciale. Per anni la memoria è stata una questione di performance: quanto velocemente si poteva alimentare la GPU, quanto contesto si poteva mantenere. Quando gli agenti iniziano ad agire in modo autonomo, quella stessa memoria diventa la prova. Se un agente prende una decisione basandosi su contesto accumulato per giorni, il prompt finale e l’output dicono quasi nulla sul perché ha agito così. La spiegazione vive nello stato accumulato.

In termini tecnici, la maggior parte di quello stato risiede nella cache KV, e l’industria la tratta ancora come spazio di lavoro usa‑e‑butta anziché come dato durevole. Se preservate quello stato e potete recuperarlo efficientemente, potete ricostruire ciò che il sistema sapeva nel momento in cui ha agito. I team lo useranno prima per il debugging, poi per le valutazioni di sicurezza e, infine, qualcuno ne avrà bisogno in un’indagine. Scartare la memoria di contesto significa scartare l’unico registro che spiega perché la vostra AI ha fatto quello che ha fatto.

La regolamentazione AI potrebbe alla fine costringere le aziende a conservare molto più informazioni su input, output, checkpoint, tracciabilità dei dati e attività degli agenti? Cosa significherebbe per l’architettura dell’infrastruttura AI?

Direzionalmente, sì. Man mano che i sistemi AI diventano più consequenziali, i requisiti di visibilità si espanderanno per coprire ogni fase della pipeline. Si vedono già i primi segnali: i team stanno pianificando di conservare la memoria di contesto “stale” in tier di storage oggetto più economici esclusivamente per scopi di audit, prima che qualsiasi normativa lo richieda.

L’autenticazione del monitoraggio con immutabilità è essenziale. La manipolazione di log e altri artefatti forensi da parte di agenti maligni è ormai routine, richiedendo sistemi di verifica crittografica elaborati che non siano vulnerabili a bersagli di integrità concentrati e centralizzati. Log di trasparenza semplici o catene di hash non sono sufficienti a difendersi dalle capacità collusive di sciami di agenti coordinati. Architetture blockchain pubbliche, altamente decentralizzate, sono ideali per questo, evidenziando il valore di “Integrity” spesso trascurato, al centro della triade C‑I‑A della cybersecurity.

La conservazione non è solo un problema di archiviazione immutabile su larga scala. La parte più difficile è mantenere quell’informazione affidabile, organizzata, indicizzata e recuperabile abbastanza velocemente da essere utile entro una scadenza, sia essa imposta da un regolatore, da una risposta a un incidente o da un tribunale. Un petabyte di attività di agente che non potete interrogare è una passività, non un registro. Il cambiamento architetturale passa da “più storage” a un’infrastruttura progettata attorno a dati AI verificabili oggettivamente, persistenti e interrogabili come carico di lavoro centrale.

Molte organizzazioni si concentrano sull’acquisto di più GPU, ma dove vedi emergere i colli di bottiglia infrastrutturali meno evidenti man mano che i carichi di lavoro AI scalano e i requisiti di sicurezza diventano più stringenti?

Le GPU sono al centro dell’attenzione perché non sono un elemento di budget trascurabile. Però le GPU e, soprattutto, i nuovi acceleratori ottimizzati per il decode (ASIC+SRAM) raramente sono il vero vincolo. La larghezza di banda della memoria, la gravità e il movimento dei dati, le prestazioni di storage e la rete determinano se quegli acceleratori stanno svolgendo lavoro produttivo o attendono inutilizzati.

Con l’AI che diventa sempre più “heavy” sul contesto, il muro della memoria diventa il vincolo definente. Potete continuare ad aggiungere GPU, ma se spendono i cicli a ricomputare token o a spostare contesto tra sistemi, state pagando per lavoro sprecato, ripetutamente. Scalare il muro della memoria significa far comportare lo strato dati come storage condiviso, ma operare a vere velocità di memoria. Quel livello di prestazioni vicino a HBM è cruciale per la nuova ondata di soluzioni di offloading della cache KV che stanno arrivando ora: ognuna deve fornire prestazioni di classe memoria per rendere la tokenomica sostenibile. Il valore della conservazione per la cache KV è una discussione di costi, secondaria al profit center. E se leggere il contesto cache è più lento che ricomputarlo, la cache è inutile per l’equazione di business. Ciò che conta non è quante GPU possedete, ma quanto produttivo è ciascuno. L’economia dell’AI si riduce al valore che estraete da ogni token, byte e watt, e i requisiti di sicurezza alzeranno solo la posta in gioco di quel calcolo.

Guardando al futuro, prevedi che la sicurezza e la conformità AI diventeranno un carico di lavoro infrastrutturale a sé stante, simile a come la cybersecurity è evoluta in un livello dedicato della tecnologia enterprise?

Vedremo la sicurezza e la conformità AI trasformarsi in un carico di lavoro distinto, e il parallelo con la cybersecurity funziona in entrambe le direzioni. La sicurezza è diventata un livello a sé quando l’industria ha accettato che non potesse più essere un esercizio occasionale. L’industria dell’assicurazione cyber l’ha reso obbligatorio. La sicurezza AI è sulla stessa traiettoria obbligatoria man mano che i modelli diventano più capaci e più autonomi.

Ma dobbiamo imparare dagli errori della sicurezza. È diventata un “bolt‑on”: uno stack separato, un budget separato, un team separato che scopre i problemi a posteriori. L’infrastruttura di sicurezza non dovrebbe ripetere questo errore. Monitoraggio, valutazione, auditabilità e conservazione immutabile devono far parte dell’infrastruttura AI stessa, co‑progettati fin dall’inizio.

Ecco la parte che la maggior parte delle persone perde: l’AI sicura richiede più AI. I modelli di guardrail non sono gratuiti. Devono essere addestrati, fine‑tuned e inferiti continuamente ad ogni fase del runtime dell’agente. I budget di latenza dei token rendono questo concreto: ogni risposta ha una finestra fissa, e più token potete processare entro quella finestra, più verifiche potete eseguire prima che l’output venga inviato. E la vera minaccia dei modelli di frontiera è la loro applicazione agentica. Gli agenti operano come loop di inferenza ad alto volume, facendo chiamate ripetute ai modelli su orizzonti lunghi. Ogni loop è osserva‑orienta‑decidi‑agisci, e ogni passo consuma token. Questo trasforma la sicurezza AI in una guerra di attrito di token. Gli aggressori schierano sciami di agenti rossi, i difensori sciami di agenti blu, e la parte che può generare più token per dollaro e per watt vince. La tokenomica è sul percorso critico sia dell’attacco sia della difesa. Questo ha smesso di essere un esperimento teorico quest’estate, quando un attacco di sciame di agenti rossi contro un grande repository di modelli ha spaventato l’industria, e un’alleanza AI sicura dedicata si è formata in pochi giorni. Nel frattempo, i volumi continuano a compounding: l’elaborazione di token dell’industria è passata da trilioni a quadrilioni.

Una volta che la sicurezza diventa un requisito sempre attivo, i suoi costi di calcolo, memoria e dati smettono di essere overhead. Diventano parte dell’economia di unità fondamentale del funzionamento dell’AI. Le aziende che internalizzano questo concetto in anticipo tratteranno la sicurezza come input di progettazione. Tutti gli altri la tratteranno come una tassa.

Grazie per la fantastica intervista, lettori che desiderano approfondire dovrebbero visitare WEKA.