Val Bercovici, Chief AI Officer la WEKA – Serie de interviuri

Val Bercovici, Chief AI Officer la WEKA, este un executiv în domeniul AI și al infrastructurii de date, concentrat pe avansarea tehnologiilor care susțin inteligența artificială de generație următoare. De când s-a alăturat WEKA în calitate de Chief AI Officer în ianuarie 2025, s-a axat pe construirea infrastructurii pentru agenți AI, accelerarea sarcinilor de antrenament și inferență și îmbunătățirea economiei calculului AI. Pe lângă rolul său la WEKA, Bercovici este consilier AI la Home Dock, consilier strategic la FermiHDI și The Hive și președinte al PencilDATA, unde activitatea sa acoperă AI, securitate cibernetică, blockchain, cloud computing și infrastructură de date. Cariera sa reflectă un interes de lungă durată pentru dezvoltarea și consilierea tehnologiilor emergente concepute să susțină sisteme AI tot mai intensive din punct de vedere al datelor.

WEKA este o companie de infrastructură de date nativă AI care construiește o platformă definită prin software, concepută pentru cerințele exigente de date ale inteligenței artificiale, învățării automate, calculului de înaltă performanță și alte sarcini accelerate. Platforma WEKA Data oferă organizațiilor o arhitectură unificată care poate funcționa în medii on-premises, cloud, hibride și edge, ajutând la eliminarea blocajelor de stocare, îmbunătățirea utilizării GPU-urilor și accelerarea antrenamentului și inferenței modelelor AI. Compania își poziționează tot mai mult tehnologia în jurul economiei emergente a inferenței și AI-ului agentic, cu infrastructura proiectată să ofere acces de mare viteză și latență scăzută la date la scară masivă, simplificând în același timp conductele de date AI complexe. WEKA deservește întreprinderi, furnizori de cloud, organizații de cercetare și dezvoltatori AI care operează în unele dintre cele mai intensive medii de calcul din lume.

Cariera ta te-a purtat de la conturarea strategiei timpurii de cloud a NetApp și de la servirea în consiliul fondator al Kubernetes, până la construirea infrastructurii AI la WEKA. Cum a modelat această evoluție modul în care te gândești la pregătirea infrastructurii pentru următoarea fază a AI?

Fiecare epocă a carierei mele a fost definită de același tipar: blocajul se mută, iar industria durează ani să îl observe. În zilele timpurii ale cloud-ului și Kubernetes, am văzut cum calculul devine elastic și orchestrarea devine noul punct de blocare. Venind din NetApp, unde am fost CTO după achiziția SolidFire, credeam că știu cum arată viteza: câteva milisecunde pentru o citire aleatorie de prim octet în condiții de producție.

Motivul pentru care m-am alăturat WEKA este cu adevărat geeky. Era un singur indicator: prima citire aleatorie de octet necache‑ată este de 70 de microsecunde, o valoare care nu aparține clasei de stocare. Nu m-am gândit niciodată la latență la nivel de microsecunde pentru acest tip de sistem. A fost revelația: această tehnologie ar putea servi aplicații de memorie, aplicații de tip DRAM precum Redis și cache‑ul KV, nu doar stocare. Și, la momentul potrivit, inferența a început să depășească antrenamentul, deoarece industria trebuia să monetizeze aceste modele, iar agenții au apărut pentru a transforma memoria în tot jocul.

Aceasta este perspectiva pe care o aduc în infrastructura AI. Am mai văzut acest scenariu. Cloud FinOps a apărut deoarece companiile au lansat infrastructură fără o rigurozitate a economiei unitare, apoi au primit factura. AI se află pe aceeași curbă, dar se mișcă mai repede.   Pe măsură ce afacerile au împins în mod inevitabil înapoi limitele de tokenuri odată cu apariția facturilor de consum API mult peste bugetele planificate de tokenuri, asistăm la ascensiunea AI FinOps. Acesta este momentul în care organizațiile încetează să trateze inferența ca pe o utilitate ieftină și încep să gestioneze eficiența tokenurilor ca disciplină financiară. AI FinOps începe cu tokenomics: optimizarea fiecărui strat hardware și software al stivei de inferență care influențează costul unitar per token. În prezent, cel mai mare deșeu din acea stivă sunt GPU‑urile scumpe și ASIC‑urile noi care stau nefolosite, așteptând memoria și datele (cunoscut ca „decode”) în loc de FLOPS (cunoscut ca „prefill”). Cel care rezolvă această problemă deține următoarea fază a AI.

Casa Albă păstrează confidențial detaliile noului său cadru de siguranță AI. Cum pot întreprinderile să se pregătească pentru cerințele de reglementare când încă nu știu exact ce va fi testat sau cerut?

Companiile nu ar trebui să aștepte lista finală de verificare. Testele specifice se vor schimba, dar obligația de bază nu va: va trebui să demonstrați ce a făcut modelul AI, ce date a accesat și cum s‑a comportat la un moment specific în timp. Iar așteptarea nu este deja o opțiune la nivel global. Regulamentul UE privind AI a devenit aplicabil în această lună și clasifică majoritatea orchestrărilor de agenți ca fiind cu risc ridicat.

Asta înseamnă că munca de pregătire este muncă de infrastructură. Trasabilitatea datelor, observabilitatea, reproductibilitatea și capacitatea de a reconstrui starea modelului la cerere sunt esențiale pentru ca întreprinderile să le gestioneze corect. În final, organizațiile trebuie să implementeze modele de tip guardrail înainte de ieșiri, cu latență și bugete de token asociate pentru straturile de apărare semantică. Dacă construiești aceste capabilități acum, orice cadru devine un exercițiu de formatare. Dacă aștepți regulile finale, vei adăuga responsabilitate în sisteme care nu au fost niciodată concepute să se explice. Această adaptare este întotdeauna mai costisitoare decât construirea din start.

În final, soluția pentru construirea unui AI sigur constă în mai mult AI, aplicat optim și foarte intenționat.

Ce tipuri de noi cerințe de infrastructură ar putea genera testarea siguranței AI și cum ar putea arăta aceste sarcini diferit față de antrenamentul sau inferența convențională a modelelor?

Antrenamentul este ca un furtun cu apă sub presiune. Împingi volume enorme de date printr-un model într-un tipar susținut și predictibil. Testarea siguranței este opusul: mii de scenarii de evaluare, sondări repetate, comparații comportamentale versiune peste versiune și red teaming adversarial care nu se termină niciodată.

Acest profil contează. Antrenamentul și testarea siguranței sunt sarcini cu explozii, cu citiri intensive și comparative. Ele generează și consumă cantități enorme de stare intermediară. Modelele de tip guardrail trebuie să fie inerent eterogene și stratificate, implementate în bugete stricte de latență, amplificând evaluările cu această nouă dimensiune a criteriilor de siguranță. Pentru astfel de modele avansate sau capabile din punct de vedere cibernetic, profilul de sarcină este persistent 24/7, nu episodic. Nu rulezi un test o singură dată și nu depui rezultatele. Rulezi sarcini continue de roi de agenți care concurează în producție cu calcul, memorie și lățime de bandă pentru aplicațiile critice pe care le protejează. După calitate și viteză, majoritatea infrastructurii de astăzi nu este proiectată pentru acest al treilea principiu.

Există și o problemă de măsurare subiacente. Majoritatea benchmark‑urilor AI de astăzi rulează 8.000 de tokeni sau mai puțin, un prompt, un răspuns. Glumesc spunând că sunt benchmark‑uri artificiale ale inteligenței artificiale. În mijlocul anului 2026, sarcinile reale ale agenților rulează între 100.000 și 400.000 de tokeni de context pe mii de tururi. Dacă evaluările de siguranță moștenesc acele benchmark‑uri de jucărie, vom certifica sisteme pentru o lume care nu există. Regulatorii construiesc deja un mecanism mai bun aici: NIST a open‑sourcat instrumente de evaluare a securității agenților, iar rezultatele timpurii publicate arată atacuri noi de hijack ale agenților care reușesc de câteva ori mai des decât bazele cunoscute. Acesta este exact tipul de testare continuă, adversarială și costisitoare pe care mă aștept ca cadrele de siguranță să îl convergă.

Ar trebui organizațiile să construiască capacitate în exces de calcul și date specific pentru sarcini viitoare de conformitate și siguranță, sau există o modalitate mai eficientă de a proiecta pentru această incertitudine?

Achiziționarea de GPU‑uri în exces și speranța că utilizarea va crește lasă capitalul blocat în hardware care se depreciază.

Răspunsul eficient este o infrastructură care se flexează între sarcinile de producție și cele de evaluare fără un stack separat. Este în esență o problemă de date. Dacă poți muta și reutiliza datele eficient, păstra contextul între sarcini și menține acceleratoarele ocupate cu muncă reală, conformitatea devine un cost incremental în loc de o construcție paralelă. Economia AI se reduce tot mai mult la câtă valoare extragi din fiecare token, octet și watt. Dacă o faci corect, poți genera de 3–4 ori mai multă valoare din aceeași infrastructură sau poți reduce amprenta rack‑ului cu până la 75 %. Conformitatea ar trebui să fie ținută la același standard.

Cadru actual se concentrează, conform rapoartelor, pe modele închise avansate, excluzând modelele cu greutăți deschise. Ce provocări de infrastructură sau securitate ar putea apărea din tratarea diferită a acestor două categorii?

Dacă tratezi modelele închise și cele cu greutăți deschise diferit, ajungi la două cadre de conformitate pentru tehnologii care fac aceleași lucruri, iar diferența dintre ele este locul în care există riscul.

Un model cu greutăți deschise poate fi ajustat fin și implementat în medii în care furnizorul original nu are nicio vizibilitate. Reglementarea furnizorului nu are efect acolo. Iar diviziunea este deja vizibilă: controalele de export au vizat cele mai noi modele închise în acest an, în timp ce modelele cu greutăți deschise traversează frontierele liber și se află acum în topul clasamentelor publice de capabilități. Totuși, administrația definește modelele de frontieră, guvernanța nu se poate opri la model în sine. Ai nevoie de vizibilitate asupra locului unde rulează modelele, ce date accesează, ce prompturi, răspunsuri și metadate sunt păstrate, cum au fost modificate și dacă infrastructura de bază poate susține AI guvernat la scară. Vor fi necesare noi actualizări ale ISO27001 și SOC2.

Răspunsul meu este să ai încredere, dar să verifici. Dacă infrastructura ta îți oferă capacitatea de token, poți rula guardrail‑uri eterogene împotriva oricărui model înainte ca ieșirea sa să fie livrată: intern sau extern, deschis sau închis. Verificarea obiectivă depășește încrederea totală sau neîncrederea totală bazată pe originea modelului. Pe măsură ce modelele deschise proliferă, această capacitate de verificare trăiește în stratul de infrastructură, și acolo întreprinderile se vor diferenția. Politica poate decide ce modele sunt permise. Infrastructura decide dacă acele modele pot fi implementate în mod responsabil și economic.

Pe măsură ce agenții AI devin mai autonomi și operează pe contexte mai lungi, cum se modifică cantitatea de date, memorie și calcul pe care organizațiile trebuie să le aloce pentru monitorizare și siguranță?

Un chatbot este un prompt și un răspuns. Un agent autonom este un proces în execuție. Acesta atinge zeci de sisteme, recuperează informații, ia decizii intermediare și acumulează stare pe parcursul orelor sau zilelor înainte de a finaliza o sarcină.

Nu poți monitoriza asta prin eșantionarea tokenurilor sau răspunsurilor individuale. Trebuie să capturezi secvența completă: ce știa agentul, când a știut și ce a făcut apoi. În fiecare oră în care rulează un agent, starea lui crește, la fel și memoria, mișcarea datelor și infrastructura necesară pentru a le captura și analiza. Monitorizarea nu mai este o funcție de logging, ci devine o sarcină de prim rang cu propriul buget de resurse.

Apărarea este zona în care situația devine urgentă. Problema de memorie a AI devine o problemă de securitate. Un agent de codare poate porni, livra și se poate opri. Un agent de securitate cibernetică nu poate. Trebuie să păstreze contextul pe parcursul schimbărilor de tură zilnice într-un centru de operațiuni de securitate, actualizări frecvente ale modelului și campanii sofisticate de atac multi‑etapă care obișnuiau să se întindă pe săptămâni, dar astăzi operează la viteze coordonate ale mașinilor. Când memoria de lucru a AI este evacuată și recalculată de la zero la fiecare câteva minute, un agent care a detectat un comportament anormal în prima oră a unui incident nu își amintește în a doua oră. Atacatorii nu au această problemă. Agenții lor identifică și urmăresc vulnerabilitățile în mod persistent, iar lanțurile de atac se finalizează acum la viteze optimizate tokenomic, așa că apărarea cibernetică alimentată de AI trebuie să ruleze autonom 24/7. Și nu este teoretic. Furnizorii de securitate se pregătesc acum pentru agenți cibernetici persistenți 24/7, iar primul lucru pe care îl descoperă este că economia nu seamănă deloc cu sarcinile de chat. Unele organizații au nevoie de acei agenți la margine, în facilități în care nu poți livra un rack GPU sau chiar un sistem de răcire anul acesta. Testul real pentru AI în întreprindere este păstrarea contextului pe termen lung, nu inferența punctuală. Aceasta devine o luptă a epuizării tokenilor, iar cine rezolvă memoria de context persistentă la scară va alimenta prima aplicație orizontală de tip killer în AI enterprise: roiuri de agenți albaștri mereu active.

Ai vorbit despre importanța tot mai mare a „memoriei de context” pe măsură ce sarcinile AI trec de la simple chaturi la agenți persistenți. Poate memoria de context să devină importantă și pentru auditarea, reproducerea sau investigarea comportamentului AI?

Absolut, și este un caz de utilizare important. Ani de zile, memoria a fost o poveste de performanță: cât de repede poți alimenta GPU‑ul, cât context poți păstra. Odată ce agenții încep să acționeze autonom, aceeași memorie devine dovada. Dacă un agent ia o decizie bazată pe context acumulat pe parcursul zilelor, promptul și ieșirea finală nu îți spun aproape nimic despre motivul acțiunii. Explicația trăiește în starea acumulată.

Din punct de vedere tehnic, cea mai mare parte a acelei stări locuiește în cache‑ul KV, iar industria încă o tratează ca spațiu de lucru de unică folosință în loc de date durabile. Dacă păstrezi acea stare și poți să o recuperezi eficient, poți reconstrui ce știa sistemul în momentul în care a acționat. Echipele vor folosi asta mai întâi pentru depanare, apoi pentru evaluări de siguranță și, în cele din urmă, cineva va avea nevoie de ea într-o investigație. Aruncarea memoriei de context înseamnă aruncarea singurului înregistrări care explică de ce AI a făcut ceea ce a făcut.

Ar putea reglementarea AI să oblige în final companiile să rețină mult mai multe informații despre intrările, ieșirile, punctele de control, trasabilitatea datelor și activitatea agenților? Ce ar însemna asta pentru arhitectura infrastructurii AI?

În direcție, da. Pe măsură ce sistemele AI devin tot mai consecvente, cerințele de vizibilitate se vor extinde pentru a acoperi fiecare pas al pipeline‑ului. Poți deja să vezi semnalele timpurii: echipele planifică să păstreze memoria de context veche în tier‑uri de stocare obiect mai ieftine exclusiv pentru audit, înainte ca orice reglementare să o ceară.

Autentificarea monitorizării cu imuabilitate este esențială. Manipularea jurnalelor și a altor artefacte forensice de către agenți rău intenționați a devenit o practică obișnuită, necesitând sisteme elaborate de verificare criptografică care să nu fie vulnerabile la ținte centralizate de atac. Jurnalele simple de transparență sau lanțurile de hash nu sunt suficiente pentru a se apăra împotriva capacităților de coluziune ale roiurilor de agenți coordonați. Arhitecturi publice, descentralizate, bazate pe blockchain sunt ideale pentru acest scop, subliniind valoarea de Integritate, în mijlocul triadei C‑I‑A a securității cibernetice.

Păstrarea nu este doar o problemă copleșitoare de stocare imuabilă la scară. Partea dificilă este să menții acea informație de încredere, organizată, indexată și recuperabilă suficient de rapid pentru a fi utilă sub un termen limită, fie că provine de la un regulator, un răspuns la incident sau o sală de judecată. Un petabyte de activitate a agenților pe care nu îl poți interoga este o povară, nu o înregistrare. Schimbarea arhitecturală trece de la „mai mult stocare” la infrastructură proiectată în jurul datelor AI verificabile obiectiv, persistente și interogabile ca sarcină de bază.

Multe organizații se concentrează pe achiziționarea de GPU‑uri suplimentare, dar unde vezi blocajele de infrastructură mai puțin evidente pe măsură ce sarcinile AI se scalează și cerințele de siguranță devin mai stricte?

GPU‑ul primește atenția pentru că nu este un element de buget neînsemnat. Dar GPU‑urile și în special noile acceleratoare optimizate pentru decode (ASIC+SRAM) sunt rar constrângerea reală. Lățimea de bandă a memoriei, gravitatea datelor și mișcarea acestora, performanța stocării și rețelistică determină dacă acele acceleratoare lucrează productiv sau așteaptă neutilizate.

Pe măsură ce AI devine tot mai dependent de context, peretele de memorie devine constrângerea definitorie. Poți continua să adaugi GPU‑uri, dar dacă acestea își petrec ciclurile recalculând tokeni sau mutând contextul între sisteme, plătești pentru muncă irosită, în mod repetat. Scalarea peretelui de memorie înseamnă transformarea stratului de date într-un stocare partajată, dar cu performanțe la viteza reală a memoriei. Această bară de viteză adiacentă HBM contează pentru valul de profit al soluțiilor de offloading al cache‑ului KV care apar acum: oricare dintre ele trebuie să ofere performanță adevărată de clasă memorie pentru ca tokenomics‑ul să fie sustenabil. Valoarea de retenție pentru cache‑ul KV este o discuție de cost, secundară profitului. Și dacă citirea contextului cache‑at este mai lentă decât recalcularea, cache‑ul nu are valoare în ecuația de afaceri. Ce contează nu e câte GPU‑uri deții, ci cât de productiv este fiecare. Economia AI se reduce la valoarea extrasă din fiecare token, octet și watt, iar cerințele de siguranță vor ridica miza acestui calcul.

Privind spre viitor, te aștepți ca siguranța și conformitatea AI să devină o sarcină de infrastructură distinctă, similar cu modul în care securitatea cibernetică a evoluat într-un strat dedicat al tehnologiei enterprise?

Vom vedea siguranța și conformitatea AI devenind o sarcină distinctă, iar paralela cu securitatea cibernetică funcționează în ambele sensuri. Securitatea a devenit un strat propriu odată ce industria a acceptat că nu poate fi un exercițiu ocazional. Industria asigurărilor cibernetice a făcut acest lucru obligatoriu. Siguranța AI urmează aceeași traiectorie obligatorie pe măsură ce modelele devin mai capabile și mai autonome.

Dar ar trebui să învățăm din greșelile securității. A devenit un element suplimentar: un stack separat, un buget separat, o echipă separată care descoperă problemele după fapt. Infrastructura de siguranță nu ar trebui să repete această greșeală. Monitorizarea, evaluarea, auditabilitatea și păstrarea imuabilă trebuie să facă parte din infrastructura AI în sine, co-proiectate din start.

Iată partea pe care majoritatea oamenilor o ratează: AI sigur necesită mai mult AI. Modelele de tip guardrail nu sunt gratuite. Ele trebuie să fie antrenate continuu, ajustate fin și inferate la fiecare pas al rulării agenților. Bugetele de latență ale tokenilor fac acest lucru concret: fiecare răspuns are o fereastră fixă, iar cu cât poți procesa mai mulți tokeni în acea fereastră, cu atât poți rula mai multe verificări înainte ca ieșirea să fie trimisă. Iar adevărata amenințare a modelelor de frontieră este aplicația lor agentică. Agenții rulează bucle de inferență cu volum mare, efectuând apeluri repetate la modele pe orizonturi lungi. Fiecare buclă este observe‑orient‑decide‑act și fiecare pas consumă tokeni. Aceasta transformă securitatea AI într-un război al epuizării tokenilor. Atacatorii lansează roiuri de agenți roșii, apărătorii roiuri de agenți albaștri, iar partea care poate genera mai mulți tokeni pe dolar și pe watt câștigă. Tokenomics este pe calea critică atât a atacului, cât și a apărării. Acest lucru a încetat să fie un experiment de gândire vara aceasta, când un atac de roi roșu asupra unui depozit major de modele a speriat industria și s‑a format în câteva zile o alianță dedicată AI sigur. Între timp, volumele continuă să se compună: procesarea tokenilor în industrie a trecut de la trilioane la cvadrilioane.

Odată ce siguranța devine o cerință permanentă, costurile sale de calcul, memorie și date încetează să fie costuri indirecte. Ele devin parte din economia unitară fundamentală a rulării AI. Companiile care internalizează acest lucru devreme vor trata siguranța ca un input de design. Toate celelalte o vor trata ca pe un impozit.

Vă mulțumim pentru interviul excelent, cititorilor care doresc să afle mai multe ar trebui să viziteze WEKA.