Val Bercovici, Chief AI Officer hos WEKA – Interviewserie

Val Bercovici, Chief AI Officer hos WEKA, er en leder inden for AI‑ og datainfrastruktur, der fokuserer på at fremme de teknologier, som understøtter næste generations kunstig intelligens. Siden han tiltrådte WEKA som Chief AI Officer i januar 2025, har han koncentreret sig om at bygge AI‑agent‑infrastruktur, accelerere trænings‑ og inferens‑arbejdsbelastninger og forbedre økonomien i AI‑beregning. Ved siden af sin rolle i WEKA fungerer Bercovici som AI‑rådgiver for Home Dock, strategisk rådgiver for FermiHDI og The Hive samt formand for PencilDATA, hvor hans arbejde spænder over AI, cybersikkerhed, blockchain, cloud‑computing og datainfrastruktur. Hans karriere afspejler et langvarigt fokus på at udvikle og rådgive om nye teknologier, der er designet til at understøtte stadig mere dataintensive AI‑systemer.

WEKA er et AI‑native datainfrastruktur‑firma, der bygger en software‑defineret platform designet til de krævende databehov inden for kunstig intelligens, maskinlæring, high‑performance computing og andre accelererede arbejdsbelastninger. WEKA Data Platform giver organisationer en samlet arkitektur, der kan fungere på on‑premise, i skyen, i hybride og edge‑miljøer, og hjælper med at fjerne lagerflaskehalse, forbedre GPU‑udnyttelse og accelerere træning og inferens af AI‑modeller. Virksomheden positionerer i stigende grad sin teknologi omkring den fremvoksende inferensekonomi og agent‑AI, med infrastruktur designet til at levere høj‑gennemløb, lav‑latens adgang til data i massiv skala, samtidig med at komplekse AI‑datapipelines forenkles. WEKA betjener virksomheder, cloud‑udbydere, forskningsorganisationer og AI‑udviklere, der driver nogle af verdens mest performance‑intensive computer‑miljøer.

Din karriere har ført dig fra at forme NetApps tidlige cloud‑strategi og tjene i Kubernetes’ grundlæggende styringsråd til at bygge AI‑infrastruktur hos WEKA. Hvordan har den udvikling påvirket din måde at tænke på, når du forbereder infrastruktur til den næste fase af AI?

Hver epoke i min karriere har været præget af det samme mønster: flaskehalsen flytter sig, og branchen tager år at bemærke det. I de tidlige cloud‑ og Kubernetes‑dage så vi, hvordan beregning blev elastisk, og orkestrering blev det nye knækpunkt. Da jeg kom fra NetApp, hvor jeg var CTO efter SolidFire‑opkøbet, troede jeg, at jeg vidste, hvordan hastighed så ud: lavt antal millisekunder for en fuldstændig tilfældig første‑byte‑læsning under produktionsarbejdsbelastninger.

Grunden til, at jeg gik ind i WEKA, er ægte geek‑mæssig. Det var en statistik: den første ukodede tilfældige byte‑læsning er 70 mikrosekunder, hvilket ikke er et tal fra lagerklassen. Jeg havde aldrig overvejet muligheden for latens på mikrosekund‑niveau fra denne type system. Det var lyspæren: denne teknologi kunne betjene hukommelses‑applikationer, DRAM‑klasse applikationer som Redis og KV‑cache, ikke kun lager. Og præcis på det tidspunkt begyndte inferens at overgå træning, fordi branchen skulle tjene penge på disse modeller, og agenter kom ind for at gøre hukommelse til hele spillet.

Det er den vinkel, jeg bringer til AI‑infrastruktur. Vi har set denne film før. Cloud FinOps opstod, fordi virksomheder opsatte infrastruktur uden nogen streng unit‑economics, og så fik regningen. AI befinder sig på samme kurve, men bevæger sig hurtigere.   Når virksomheder uundgåeligt skubber tilbage på token‑maksimering med ankomsten af API‑forbrugsregninger, der langt overstiger de planlagte token‑budgetter, er vi vidne til fremkomsten af AI FinOps. Dette er punktet, hvor organisationer holder op med at betragte inferens som en billig nytte og begynder at styre token‑effektivitet som en finansiel disciplin. AI FinOps starter med tokenomics: optimering af hver hardware‑ og softwarelag i inferens‑stacken, der påvirker enhedsomkostningen pr. token. Lige nu er den største spild i den stack dyre GPU‑er og nye ASIC‑er, der sidder uvirksomme og venter på hukommelse og data (dvs. ‘decode’) i stedet for FLOPS (dvs. ‘prefill’). Den, der løser dette, ejer den næste fase af AI.

Det Hvide Hus holder detaljerne i sin nye AI‑sikkerhedsramme fortrolige. Hvordan kan virksomheder forberede sig på regulatoriske krav, når de endnu ikke ved præcis, hvad der vil blive testet eller krævet?

Virksomheder bør ikke vente på den endelige tjekliste. De specifikke tests vil ændre sig, men forpligtelsen under dem vil ikke: du skal kunne demonstrere, hvad din AI‑model gjorde, hvilke data den berørte, og hvordan den opførte sig på et bestemt tidspunkt. Og ventetid er allerede ingen mulighed globalt. EU‑AI‑loven trådte i kraft denne måned, og den klassificerer de fleste agent‑orkestreringer som højrisiko.

Det betyder, at forberedelsesarbejdet er infrastrukturarbejde. Datatræk, observerbarhed, reproducerbarhed og evnen til at rekonstruere modeltilstand på forespørgsel er alle kritiske for, at virksomheder får det rigtigt. Endelig skal organisationer implementere guardrail‑modeller før output, med tilhørende latens‑ og token‑budgetter for de semantiske forsvarslag. Hvis du bygger disse kapaciteter nu, bliver enhver ramme blot en formateringsøvelse. Hvis du venter på de endelige regler, vil du eftermontere ansvarlighed i systemer, der aldrig var designet til at forklare sig selv. Den eftermontering er altid dyrere end at bygge det ind fra starten.

I sidste ende er løsningen på at bygge sikker AI mere AI, anvendt optimalt og meget bevidst.

Hvilke typer af nye infrastrukturkrav kan AI‑sikkerhedstest skabe, og hvordan kan disse arbejdsbelastninger adskille sig fra konventionel modeltræning eller inferens?

Træning er som en brandslange. Du skubber enorme datamængder gennem en model i et vedvarende, forudsigeligt mønster. Sikkerhedstest er det modsatte: tusindvis af evalueringsscenarier, gentagne sonderinger, version‑over‑version adfærdssammenligninger og adversarial red‑team‑arbejde, der aldrig rigtig slutter.

Den profil er vigtig. Sikkerhedstræning og -test er bursty, læsetung og komparativ. Den genererer og forbruger enorme mængder af mellemliggende tilstand. Guardrail‑modeller skal være iboende heterogene og lagdelte, implementeret inden for stramme latensbudgetter, og forstærke evalueringerne med denne nye dimension af sikkerhedskriterier. For så avancerede eller cyber‑dygtige modeller er arbejdsbelastningsprofilen 24/7 vedvarende snarere end episodisk. Du kører ikke kun en test én gang og arkiverer resultaterne. Du kører kontinuerlige agent‑sværm‑arbejdsbelastninger, der konkurrerer i produktion med beregning, hukommelse og data‑båndbredde om de kritiske applikationer, de beskytter. Efter kvalitet og hastighed er de fleste infrastrukturer i dag ikke designet til dette tredje princip.

Der er også et måleproblem under dette. De fleste AI‑benchmarks i dag kører 8.000 tokens eller færre, én prompt, ét svar. Jeg joker med, at de er kunstige benchmarks for kunstig intelligens. I midten af 2026 kører reelle agent‑arbejdsbelastninger 100.000 til 400.000 tokens af kontekst på tværs af tusindvis af vendinger. Hvis sikkerhedsevalueringer arver disse legetøjs‑benchmarks, vil vi certificere systemer for en verden, der ikke eksisterer. Regulatorer bygger allerede bedre kapacitet her: NIST har gjort agent‑sikkerhedsevalueringsværktøjer open‑source, og tidlige offentliggjorte resultater viser, at nye agent‑hijack‑angreb lykkes flere gange hurtigere end kendte baselines. Det er præcis den type kontinuerlig, adversarial, dyr test, jeg forventer, at sikkerhedsrammer vil konvergere mod.

Skal organisationer bygge overskydende beregnings‑ og datakapacitet specifikt til fremtidige overholdelses‑ og sikkerheds‑arbejdsbelastninger, eller er der en mere effektiv måde at designe til den usikkerhed på?

At købe overskydende GPU‑er og håbe på, at udnyttelsen indhenter, efterlader blot kapital låst i afskrivende hardware.

Det effektive svar er infrastruktur, der kan skifte mellem produktions‑ og evaluerings‑arbejdsbelastninger uden en separat stack. Det er grundlæggende et data‑problem. Hvis du kan flytte og genbruge data effektivt, bevare kontekst mellem arbejdsbelastninger og holde dine acceleratorer beskæftiget med reelt arbejde, bliver overholdelse en inkrementel omkostning i stedet for en parallel opbygning. Økonomien i AI handler i stigende grad om, hvor meget værdi du udvinder fra hver token, byte og watt. Gør du det rigtigt, kan du generere 3–4 gange mere værdi fra den samme infrastruktur, eller reducere dit rack‑fodaftryk med op til 75 %. Overholdelse bør holdes til samme standard.

Den nuværende ramme fokuserer angiveligt på avancerede lukkede modeller, mens åbne vægtmodeller udelades. Hvilke infrastruktur‑ eller sikkerhedsudfordringer kan opstå ved at behandle de to kategorier forskelligt?

Hvis du behandler lukkede modeller og åbne vægtmodeller forskelligt, ender du med to overholdelses‑rammer for teknologier, der gør de samme ting, og hullet mellem dem er, hvor risikoen lever.

En åben vægtmodel kan fin‑tunes og implementeres i miljøer, hvor den oprindelige leverandør har nul synlighed. At regulere leverandøren gør intet der. Og opdelingen er allerede synlig: eksportkontroller ramte de nyeste lukkede frontmodeller i år, mens åbne vægtmodeller krydser grænser frit og nu befinder sig nær toppen af offentlige kapabilitets‑leaderboards. Men administrationen ender med at definere frontmodeller, og styring kan ikke stoppe ved selve modellen. Du har brug for synlighed i, hvor modeller kører, hvilke data de tilgår, hvilke prompts, svar og metadata der gemmes, hvordan de er blevet modificeret, og om den underliggende infrastruktur faktisk kan understøtte styret AI i skala. Nye opdateringer til ISO27001 og SOC2 vil blive påkrævet.

Mit svar er tillid men verifikation. Hvis din infrastruktur giver dig token‑kapacitet, kan du køre heterogene guardrails mod enhver model, før dens output sendes: indenlandsk eller udenlandsk, åben eller lukket. Objektiv verifikation slår blind tillid eller blind mistillid baseret på, hvor en model kommer fra. Når åbne modeller spreder sig, lever denne verifikationskapacitet i infrastruktur‑laget, og det er her, virksomheder vil differentiere sig. Politik kan bestemme, hvilke modeller der er tilladt. Infrastruktur bestemmer, om disse modeller kan implementeres ansvarligt og økonomisk.

Efterhånden som AI‑agenter bliver mere autonome og opererer over længere kontekster, hvordan ændrer det mængden af data, hukommelse og beregning, som organisationer skal afsætte til overvågning og sikkerhed?

En chatbot er en prompt og et svar. En autonom agent er en kørende proces. Den berører dusinvis af systemer, henter information, træffer mellemliggende beslutninger og akkumulerer tilstand over timer eller dage, før den afslutter en opgave.

Du kan ikke overvåge det ved at sample enkelte tokens eller svar. Du skal indfange den fulde sekvens: hvad agenten vidste, hvornår den vidste det, og hvad den gjorde derefter. Hver time en agent kører, vokser dens tilstand, og det samme gør hukommelsen, data‑bevægelsen og infrastrukturen, der kræves for at indfange og analysere den. Overvågning ophører med at være en log‑funktion og bliver en førsteklasses arbejdsbelastning med sit eget ressourcebudget.

Forsvar er, hvor dette bliver akut. AI‑s hukommelsesproblem bliver til et sikkerhedsproblem. En kodningsagent kan starte op, levere og lukke ned. En cybersikkerheds‑agent kan det ikke. Den skal holde kontekst på tværs af daglige skifteovergange i et security‑operations‑center, hyppige modelopdateringer og sofistikerede flertrins‑angrebskampagner, der tidligere strakte sig over uger, men i dag også opererer med koordinerede maskinhastigheder. Når AI‑arbejdshukommelsen bliver fjernet og genberegnet fra bunden hver få minutter, har en agent, der opdagede anomal adfærd i den første time af en hændelse, ingen hukommelse om den i den anden time. Angribere har ikke dette problem. Deres agenter identificerer og forfølger svagheder vedvarende, og dræbte kæder afsluttes nu ved tokenomics‑optimerede maskinhastigheder, så AI‑drevet cyberforsvar skal køre autonomt døgnet rundt. Og dette er ikke teoretisk. Sikkerhedsleverandører forbereder nu 24/7‑vedvarende cyber‑agenter, og det første, de opdager, er, at økonomien ser helt anderledes ud end chat‑arbejdsbelastninger. Nogle organisationer har brug for disse agenter kørende i edge‑miljøer, i faciliteter hvor du ikke kan sende et GPU‑rack eller endda en køler i år. Den reelle test for enterprise‑AI er vedvarende kontekst‑bevaring, ikke punkt‑i‑tid inferens. Dette bliver en kamp om token‑attrition, og den, der løser vedvarende kontekst‑hukommelse i skala, vil drive den første horisontale killer‑app i enterprise‑AI: altid‑på blå agent‑sværme.

Du har talt om den voksende betydning af “kontekst‑hukommelse”, efterhånden som AI‑arbejdsbelastninger bevæger sig ud over simpel chat mod vedvarende agenter. Kan kontekst‑hukommelse også blive vigtig for revision, reproduktion eller undersøgelse af AI‑adfærd?

Absolut, og det er et vigtigt anvendelsesområde. I årevis var hukommelse en præstationshistorie: hvor hurtigt du kunne fodre GPU‑en, hvor meget kontekst du kunne holde. Når agenter begynder at handle autonomt, bliver den samme hukommelse til beviset. Hvis en agent træffer en beslutning baseret på kontekst, den har akkumuleret over dage, fortæller den sidste prompt og output dig næsten intet om, hvorfor den handlede. Forklaringen ligger i den akkumulerede tilstand.

Teknisk set leverer størstedelen af den tilstand i KV‑cachen, og branchen behandler den stadig som engangs‑scratch‑space i stedet for holdbare data. Hvis du bevarer den tilstand og kan hente den effektivt, kan du rekonstruere, hvad systemet vidste i det øjeblik, det handlede. Teams vil først bruge det til debugging, derefter til sikkerhedsevalueringer, og til sidst vil nogen have brug for det i en efterforskning. At kassere kontekst‑hukommelsen betyder at kassere den eneste registrering, der forklarer, hvorfor din AI gjorde, hvad den gjorde.

Kan AI‑regulering i sidste ende tvinge virksomheder til at bevare væsentligt mere information om model‑input, -output, checkpoints, datatræk og agent‑aktivitet? Hvad vil det betyde for AI‑infrastruktur‑arkitekturen?

Retningsmæssigt, ja. Efterhånden som AI‑systemer bliver mere betydningsfulde, vil synlighedskravene udvide sig til at dække hvert trin i pipeline’en. Du kan allerede se de tidlige signaler: teams planlægger at bevare forældet kontekst‑hukommelse i billigere objekt‑lagringsniveauer udelukkende til revisionsformål, før nogen regulering kræver det.

Autentificering af overvågning med uforanderlighed er afgørende. Manipulation af log‑filer og andre retsmedicinske artefakter af ondsindede agenter er blevet rutine, hvilket kræver omfattende kryptografiske verifikationssystemer, der ikke er sårbare over for koncentrerede, centraliserede integritetsmål for angreb. Simple gennemsigtighedslog‑filer eller hash‑kæder er ikke tilstrækkelige til at forsvare mod samarbejdsevnerne hos koordinerede agent‑sværme. Højt decentraliserede, offentlige blockchain‑arkitekturer er ideelt egnet til dette og fremhæver den ofte oversete integritetsværdi i midten af cybersikkerhedens C‑I‑A‑triade.

Bevaring er ikke kun et skræmmende, uforanderligt lagringsproblem i skala. Den svære del er at holde den information betroet, organiseret, indekseret og hurtig nok til at kunne hentes under en deadline, uanset om den deadline kommer fra en regulator, en hændelsesrespons eller en retssal. En petabyte af agent‑aktivitet, du ikke kan forespørge, er en forpligtelse, ikke en registrering. Det arkitektoniske skift går fra “mere lager” til infrastruktur designet omkring objektivt verificerbare, vedvarende, forespørgbare AI‑data som en kerne‑arbejdsbelastning.

Mange organisationer fokuserer på at købe flere GPU‑er, men hvor ser du de mindre åbenlyse infrastruktur‑flaskehalse opstå, efterhånden som AI‑arbejdsbelastninger skalerer, og sikkerhedskravene bliver mere krævende?

GPU‑en får overskrifterne, fordi den ikke er en ubetydelig budgetpost. Men GPU‑er og især nye decode‑optimerede acceleratorer (ASIC+SRAM) er sjældent den egentlige begrænsning. Hukommelses‑båndbredde, data‑tyngde og -bevægelse, lager‑performance og netværk bestemmer, om disse acceleratorer udfører produktivt arbejde eller venter underudnyttede.

Efterhånden som AI bliver mere kontekst‑tung, bliver hukommelsesvæggen den afgørende begrænsning. Du kan fortsætte med at tilføje GPU‑er, men hvis de bruger deres cyklusser på at genberegne tokens eller flytte kontekst mellem systemer, betaler du for spildt arbejde, gentagne gange. Skalering af hukommelsesvæggen betyder at få datalaget til at opføre sig som delt lager, men præstere ved ægte hukommelseshastigheder. Den HBM‑nære hastighedsbjælke er vigtig for bølgen af profit‑center‑løsninger til KV‑cache‑offloading, der ankommer nu: hver af dem skal levere ægte hukommelses‑klasse performance for at få tokenomics til at gå op. Bevaringsværdien for KV‑cache er en omkostnings‑center‑diskussion, sekundær til profit‑centret. Og hvis læsning af cache‑kontekst er langsommere end blot at genberegne den, er cachen værdiløs for forretningsligningen. Det, der betyder noget, er ikke hvor mange GPU‑er du ejer, men hvor produktiv hver enkelt er. Økonomien i AI handler om den værdi, du udvinder fra hver token, byte og watt, og sikkerhedskrav vil kun hæve indsatsen i den matematik.

Ser du fremad, at AI‑sikkerhed og overholdelse vil blive en særskilt infrastruktur‑arbejdsbelastning, ligesom cybersikkerhed udviklede sig til et dedikeret lag i enterprise‑teknologi?

Vi vil se AI‑sikkerhed og overholdelse blive en særskilt arbejdsbelastning, og cybersikkerheds‑parallellen går begge veje. Sikkerhed blev sit eget lag, da branchen accepterede, at det ikke kunne være en lejlighedsvis øvelse. Cyber‑forsikringsbranchen gjorde det ufrivilligt. AI‑sikkerhed er på samme obligatoriske bane, efterhånden som modeller bliver mere kapable og mere autonome.

Men vi bør lære af, hvor sikkerhed gik galt. Det blev et tillæg: en separat stack, et separat budget, et separat team, der opdagede problemer efterfølgende. Sikkerhedsinfrastruktur bør ikke gentage den fejl. Overvågning, evaluering, auditabilitet og uforanderlig bevaring hører hjemme i AI‑infrastrukturen selv, med‑designet fra starten.

Her er den del, de fleste overser: sikker AI kræver mere AI. Guardrail‑modeller er ikke gratis. De skal kontinuerligt trænes, fin‑tunes og infereres på hvert trin af agent‑kørslen. Token‑latensbudgetter gør dette konkret: hvert svar har et fast vindue, og jo flere tokens du kan behandle inden for det vindue, desto mere verifikation kan du have råd til at køre, før outputtet sendes ud. Og den reelle trussel fra front‑modeller er deres agent‑applikation. Agenter kører som høj‑volumen inferens‑loops, der foretager gentagne kald til modeller over lange horisonter. Hvert loop er observe, orient, decide, act, og hvert trin forbrænder tokens. Det gør AI‑sikkerhed til en krig om token‑attrition. Angribere udsender røde agent‑sværme, forsvarere røde blå agent‑sværme, og den side, der har råd til at generere flere tokens pr. dollar og pr. watt, vinder. Tokenomics ligger på den kritiske sti for både angreb og forsvar. Dette ophørte med at være et tanke‑eksperiment i sommer, da et rødt agent‑sværm‑angreb mod et stort model‑repository skræmte branchen til rette, og en dedikeret sikker AI‑alliance blev dannet inden for dage. Imens fortsætter volumenene med at vokse: industriens token‑behandling er gået fra trillioner til kvadrillioner.

Når sikkerhed bliver et altid‑tændt krav, stopper dets beregnings‑, hukommelses‑ og datakost at være overhead. De bliver en del af de grundlæggende enhedsøkonomier ved at køre AI. De virksomheder, der internaliserer det tidligt, vil betragte sikkerhed som en design‑input. Alle andre vil betragte det som en skat.

Tak for det fantastiske interview, læsere der ønsker at lære mere, bør besøge WEKA.