Val Bercovici, Chief AI Officer hos WEKA – Intervjuserie

Val Bercovici, Chief AI Officer hos WEKA, er en leder innen AI‑ og datainfrastruktur med fokus på å fremme teknologiene som ligger til grunn for neste generasjons kunstig intelligens. Siden han begynte i WEKA som Chief AI Officer i januar 2025, har han konsentrert seg om å bygge AI‑agentinfrastruktur, akselerere trenings‑ og inferensarbeidsbelastninger, og forbedre økonomien rundt AI‑beregning. Ved siden av sin rolle i WEKA fungerer Bercovici som AI‑rådgiver for Home Dock, strategisk rådgiver for FermiHDI og The Hive, samt styreleder i PencilDATA, hvor hans arbeid spenner over AI, cybersikkerhet, blokkjedeteknologi, sky‑computing og datainfrastruktur. Karrieren hans viser et langvarig fokus på å utvikle og gi råd om fremvoksende teknologier som er designet for å støtte stadig mer datakrevende AI‑systemer.

WEKA er et AI‑native datainfrastruktur‑selskap som bygger en programvaredefinert plattform designet for de krevende databehovene til kunstig intelligens, maskinlæring, høyytelses‑computing og andre akselererte arbeidsbelastninger. WEKA Data Platform gir organisasjoner en samlet arkitektur som kan operere på lokalt, i skyen, i hybride og edge‑miljøer, og hjelper med å eliminere lagringsflaskehalser, forbedre GPU‑utnyttelse og akselerere trening og inferens av AI‑modeller. Selskapet posisjonerer teknologien stadig mer rundt den fremvoksende inferensekonomien og agentisk AI, med infrastruktur designet for å gi høy gjennomstrømning og lav latens tilgang til data i massiv skala, samtidig som komplekse AI‑datapipelines forenkles. WEKA betjener bedrifter, skyleverandører, forskningsorganisasjoner og AI‑utviklere som opererer i noen av verdens mest ytelsesintensive datamiljøer.

Din karriere har tatt deg fra å forme NetApps tidlige skystrategi og tjene i Kubernetes’ grunnleggende styringsstyre til å bygge AI‑infrastruktur i WEKA. Hvordan har den utviklingen påvirket måten du tenker på når du forbereder infrastruktur for neste fase av AI?

Hver epoke i karrieren min har blitt definert av det samme mønsteret: flaskehalsen flytter seg, og industrien bruker år på å legge merke til det. I de tidlige sky‑ og Kubernetes‑dagene så vi at beregning ble elastisk og orkestrering ble det nye begrensningspunktet. Etter å ha kommet fra NetApp, hvor jeg var CTO etter SolidFire‑oppkjøpet, trodde jeg at jeg visste hvordan raskt så ut: lave millisekunder for en virkelig tilfeldig første‑byte‑lesning under produksjonsbelastninger.

Grunnen til at jeg ble med i WEKA er genuint geeky. Det var ett tall: den første ukontrollerte tilfeldige byte‑lesningen er 70 mikrosekunder, noe som ikke er et lagringsklassetall. Jeg hadde aldri vurdert muligheten for latens på mikrosekundnivå fra denne typen system. Det var lyspæren: denne teknologien kunne betjene minne‑applikasjoner, DRAM‑klassetjenester som Redis og KV‑cache, ikke bare lagring. Og akkurat i tide begynte inferens å overgå trening fordi industrien måtte tjene penger på disse modellene, og agenter kom for å gjøre minnet til hele spillet.

Det er dette perspektivet jeg bringer til AI‑infrastruktur. Vi har sett denne filmen før. Cloud FinOps oppstod fordi selskaper satte opp infrastruktur uten streng enhetsøkonomi, og så fikk regningene. AI er på samme kurve, men beveger seg raskere. Når bedrifter uunngåelig presser tilbake på token‑maksing med ankomsten av API‑forbruksregninger som langt overstiger planlagte token‑budsjetter, ser vi fremveksten av AI FinOps. Dette er punktet hvor organisasjoner slutter å behandle inferens som en billig nytte, og begynner å styre token‑effektivitet som en finansiell disiplin. AI FinOps starter med tokenomics: optimalisering av hver maskinvare‑ og programvarelag i inferens‑stakken som påvirker enhetskostnaden per token. Akkurat nå er den største sløsing i den stakken dyre GPU‑er og nye ASIC‑er som står i ro, venter på minne og data (aka ‘decode’) i stedet for FLOPS (aka ‘prefill’). Den som løser det, eier neste fase av AI.

Det hvite hus holder detaljene i sitt nye AI‑sikkerhetsrammeverk konfidensielt. Hvordan kan virksomheter forberede seg på regulatoriske krav når de ennå ikke vet nøyaktig hva som vil bli testet eller krevd?

Bedrifter bør ikke vente på den endelige sjekklisten. De spesifikke testene vil endre seg, men forpliktelsen under dem vil ikke: du må kunne demonstrere hva AI‑modellen din gjorde, hvilke data den berørte, og hvordan den oppførte seg på et bestemt tidspunkt. Og å vente er allerede ikke et alternativ globalt. EU AI‑loven trådte i kraft denne måneden, og den klassifiserer mesteparten av agent‑orkestrering som høy risiko.

Det betyr at forberedelsesarbeidet er infrastrukturarbeid. Datatracing, observabilitet, reproduserbarhet og evnen til å rekonstruere modelltilstand på forespørsel er alle kritiske for at virksomheter skal få dette riktig. Til slutt må organisasjoner implementere guardrail‑modeller før utdata, med tilhørende latens‑ og token‑budsjetter for de semantiske forsvars­lagene. Hvis du bygger disse evnene nå, blir ethvert rammeverk bare en formateringsøvelse. Å vente på de endelige reglene betyr at du må ettermontere ansvarlighet i systemer som aldri ble designet for å forklare seg selv. Denne ettermonteringen er alltid dyrere enn å bygge det inn fra starten.

Til syvende og sist er løsningen for å bygge sikker AI mer AI, anvendt optimalt og svært bevisst.

Hvilke typer nye infrastrukturkrav kan AI‑sikkerhetstesting skape, og hvordan kan disse arbeidsbelastningene se annerledes ut enn tradisjonell modelltrening eller inferens?

Trening er som en brannslange. Du skyver enorme datamengder gjennom en modell i et vedvarende, forutsigbart mønster. Sikkerhetstesting er det motsatte: tusenvis av evalueringsscenarioer, gjentatte sonderinger, versjon‑over‑versjon atferds­sammenligninger, og adversarial rødt‑team‑arbeid som aldri egentlig slutter.

Den profilen er viktig. Sikkerhetstrening og -testing er burst‑aktig, lese‑tung og komparativ. Den genererer og konsumerer enorme mengder mellomliggende tilstand. Guardrail‑modeller må være iboende heterogene og lagdelte, implementert innen stramme latens‑budsjetter, og forsterke evalueringer med dette nye sikkerhetskriteriet. For så avanserte eller cyber‑dyktige modeller er arbeidsbelastningsprofilen 24/7 vedvarende i stedet for episodisk. Du kjører ikke en test én gang og arkiverer resultatene. Du kjører kontinuerlige agent‑svær‑arbeidsbelastninger som konkurrerer i produksjon med beregning, minne og databåndbredde for de kritiske appene de beskytter. Etter kvalitet og hastighet er de fleste infrastrukturer i dag ikke designet for dette tredje prinsippet.

Det er også et måleproblem under dette. De fleste AI‑benchmarkene i dag kjører 8 000 token eller mindre, én prompt, ett svar. Jeg spøker med at de er kunstige benchmarker for kunstig intelligens. Midt i 2026 kjører ekte agent‑arbeidsbelastninger 100 000 til 400 000 token kontekst over tusenvis av turer. Hvis sikkerhetsevalueringer arver disse lekebenchmarkene, vil vi sertifisere systemer for en verden som ikke eksisterer. Reguleringsmyndigheter bygger allerede bedre kompetanse her: NIST har gjort agent‑sikkerhetsevalueringsverktøy åpent tilgjengelig, og tidlige publiserte resultater viser at nye agent‑kapringsangrep lykkes flere ganger hyppigere enn kjente referanser. Det er akkurat den typen kontinuerlig, adversarial, kostbar testing jeg forventer at sikkerhetsrammeverk vil konvergere mot.

Bør organisasjoner bygge overskudd av beregning og datakapasitet spesifikt for fremtidige etterlevelses‑ og sikkerhetsarbeidsbelastninger, eller finnes det en mer effektiv måte å designe for den usikkerheten?

Å kjøpe overskudd av GPU‑er og håpe at utnyttelsen tar seg opp, etterlater bare kapital bundet i avskrivende maskinvare.

Det effektive svaret er infrastruktur som kan veksle mellom produksjons‑ og evalueringsarbeidsbelastninger uten en separat stabel. Det er i bunn og grunn et data‑problem. Hvis du kan flytte og gjenbruke data effektivt, bevare kontekst mellom arbeidsbelastninger, og holde akseleratorene opptatt med reelt arbeid, blir etterlevelse en inkrementell kostnad i stedet for en parallell utbygging. Økonomien i AI handler i økende grad om hvor mye verdi du trekker ut av hver token, hver byte og hver watt. Får du det riktig, kan du generere 3–4 ganger mer verdi fra samme infrastruktur, eller kutte rack‑fotavtrykket med opptil 75 %. Etterlevelse bør holdes til samme standard.

Det nåværende rammeverket fokuserer angivelig på avanserte lukkede modeller mens åpne vekstmodeller ekskluderes. Hvilke infrastruktur‑ eller sikkerhetsutfordringer kan oppstå ved å behandle disse to kategoriene forskjellig?

Hvis du behandler lukkede modeller og åpne vekstmodeller forskjellig, ender du opp med to etterlevelsesrammeverk for teknologier som gjør de samme tingene, og gapet mellom dem er hvor risikoen ligger.

En åpen‑vektormodell kan finjusteres og distribueres i miljøer hvor den opprinnelige leverandøren har null synlighet. Å regulere leverandøren gjør ingenting der. Og splittingen er allerede synlig: eksportkontroller ble innført på de nyeste lukkede frontmodellene i år, mens åpne vekstmodeller krysser grenser fritt og nå sitter nær toppen av offentlige kapabilitets‑rangeringer. Imidlertid ender administrasjonen med å definere frontmodeller, og styring kan ikke stoppe ved selve modellen. Du trenger innsikt i hvor modeller kjører, hvilke data de får tilgang til, hvilke prompts, svar og metadata som beholdes, hvordan de er blitt endret, og om infrastrukturen under kan støtte styrt AI i skala. Nye oppdateringer til ISO27001 og SOC2 vil bli påkrevd.

Mitt svar er tillit, men verifiser. Hvis infrastrukturen din gir deg token‑kapasitet, kan du kjøre heterogene guardrails mot hvilken som helst modell før dens utdata sendes: innenlands eller utenlands, åpen eller lukket. Objektiv verifisering slår blind tillit eller blind mistillit basert på hvor en modell kommer fra. Etter hvert som åpne modeller sprer seg, lever verifiseringskapasiteten i infrastrukturnivået, og det er her bedrifter vil skille seg. Politikk kan bestemme hvilke modeller som er tillatt. Infrastruktur bestemmer om disse modellene kan distribueres ansvarlig og økonomisk.

Etter hvert som AI‑agenter blir mer autonome og opererer over lengre kontekster, hvordan endrer det mengden data, minne og beregning organisasjoner må sette av til overvåking og sikkerhet?

En chatbot er en prompt og et svar. En autonom agent er en kjørende prosess. Den berører dusinvis av systemer, henter informasjon, tar mellomliggende beslutninger, og akkumulerer tilstand over timer eller dager før den fullfører en oppgave.

Du kan ikke overvåke dette ved å prøve ut individuelle token eller svar. Du må fange hele sekvensen: hva agenten visste, når den visste det, og hva den gjorde videre. Hver time en agent kjører, vokser dens tilstand, og det samme gjelder minne, databevegelse og infrastruktur som kreves for å fange og analysere den. Overvåking slutter å være en loggefunksjon og blir en førsteklasses arbeidsbelastning med eget ressursbudsjett.

Forsvar er der dette blir presserende. AI‑minneproblemet blir et sikkerhetsproblem. En kode‑agent kan starte opp, levere og avslutte. En cybersikkerhets‑agent kan ikke. Den må holde kontekst gjennom daglige skiftendringer i et sikkerhetsoperasjons‑senter, hyppige modelloppdateringer, og sofistikerte flertrinns angrep som tidligere strakte seg over uker, men i dag også opererer med koordinerte maskinhastigheter. Når AI‑arbeidsminnet blir kastet og rekonstruert fra bunnen hvert par minutter, har en agent som oppdaget avvikende atferd i time én av en hendelse ingen minne om det i time to. Angripere har ikke dette problemet. Deres agenter identifiserer og forfølger svakheter vedvarende, og drapskjeder fullføres nå ved tokenomics‑optimaliserte maskinhastigheter, så AI‑drevet cybersikkerhetsforsvar må kjøre autonomt døgnet rundt. Og dette er ikke teoretisk. Sikkerhetsleverandører forbereder seg nå på 24/7 vedvarende cyber‑agenter, og det første de oppdager er at økonomien ser helt annerledes ut enn chat‑arbeidsbelastninger. Noen organisasjoner trenger disse agentene i kanten, i anlegg hvor du ikke kan sende en GPU‑rack eller til og med en kjøler i år. Den virkelige testen for bedrifts‑AI er vedvarende kontekst‑bevaring, ikke punkt‑i‑tid‑inferens. Dette blir en kamp om token‑attrisjon, og den som løser vedvarende kontekst‑minne i skala vil drive den første horisontale killer‑appen i bedrifts‑AI: alltid‑på blå agent‑svær.

Du har snakket om den økende betydningen av «kontekst‑minne» etter hvert som AI‑arbeidsbelastninger går utover enkel chat mot vedvarende agenter. Kan kontekst‑minne også bli viktig for revisjon, reproduksjon eller etterforskning av AI‑atferd?

Absolutt, og det er et viktig bruksområde. I flere år har minne vært en ytelseshistorie: hvor raskt du kunne mate GPU‑en, hvor mye kontekst du kunne holde. Når agenter begynner å handle autonomt, blir det samme minnet beviset. Hvis en agent tar en beslutning basert på kontekst den har samlet opp over dager, gir den siste prompten og resultatet deg nesten ingenting om hvorfor den handlet. Forklaringen ligger i den akkumulerte tilstanden.

I tekniske termer ligger mesteparten av den tilstanden i KV‑cachen, og industrien behandler den fortsatt som engangs‑scratch‑space i stedet for varige data. Hvis du bevarer den tilstanden og kan hente den effektivt, kan du rekonstruere hva systemet visste i øyeblikket det handlet. Team vil bruke det først til feilsøking, deretter til sikkerhetsevalueringer, og til slutt vil noen trenge det i en etterforskning. Å kaste bort kontekst‑minnet betyr å kaste bort den eneste posten som forklarer hvorfor AI-en din gjorde det den gjorde.

Kan AI‑regulering til slutt tvinge selskaper til å beholde betydelig mer informasjon om modell‑input, -output, sjekkpunkter, datatracing og agent‑aktivitet? Hva vil det bety for AI‑infrastrukturarkitekturen?

Retningsmessig, ja. Etter hvert som AI‑systemer blir mer konsekvensfulle, vil kravene til synlighet utvides til å dekke hvert steg i datapipelinen. Du kan allerede se de tidlige signalene: team planlegger å beholde foreldet kontekst‑minne i billigere objektlagringsnivåer kun for revisjonsformål, før noen regulering krever det.

Autentisering av overvåking med uforanderlighet er essensielt. Manipulering av logger og andre rettsmedisinske artefakter av ondsinnede agenter har blitt rutine, og krever omfattende kryptografiske verifiseringssystemer som ikke er sårbare for konsentrerte, sentraliserte integritetsmål for angrep. Enkle transparens‑logger eller hash‑kjeder er ikke tilstrekkelige for å forsvare mot samarbeidsmulighetene til koordinerte agent‑svær. Høyt desentraliserte, offentlige blokkjedearkitekturer er ideelt egnet for dette, og fremhever den ofte oversette integritetsverdien i midten av cybersikkerhetens C‑I‑A‑triade.

Bevaring er ikke bare et skremmende, uforanderlig lagringsproblem i skala. Den vanskelige delen er å holde den informasjonen pålitelig, organisert, indeksert og raskt hentbar nok til å være nyttig innen en tidsfrist, enten den tidsfristen kommer fra en regulator, en hendelsesrespons eller en rettssal. En petabyte med agent‑aktivitet du ikke kan søke i, er en forpliktelse, ikke en post. Den arkitektoniske skiftet går fra «mer lagring» til infrastruktur designet rundt objektivt verifiserbare, vedvarende, spørrbare AI‑data som en kjernearbeidsbelastning.

Mange organisasjoner fokuserer på å kjøpe flere GPU‑er, men hvor ser du de mindre åpenbare infrastrukturflaskehalsene dukke opp når AI‑arbeidsbelastninger skalerer og sikkerhetskrav blir mer krevende?

GPU‑en får overskriftene fordi den ikke er en ubetydelig budsjettpost. Men GPU‑er og spesielt nye dekode‑optimaliserte akseleratorer (ASIC+SRAM) er sjelden den egentlige begrensningen. Minnebåndbredde, datagravitasjon og -bevegelse, lagringsytelse og nettverk bestemmer om disse akseleratorene gjør produktivt arbeid eller står ubenyttet.

Etter hvert som AI blir mer kontekst‑tung, blir minneveggen den definerende begrensningen. Du kan fortsette å legge til GPU‑er, men hvis de bruker syklene på å rekalkulere token eller flytte kontekst mellom systemer, betaler du for bortkastet arbeid, gjentatte ganger. Å skalere minneveggen betyr å få datalaget til å oppføre seg som delt lagring, men med ekte minnehastigheter. Den HBM‑nære hastighetsbaren er viktig for profitt‑senter‑bølgen av KV‑cache‑offloading‑løsninger som kommer nå: hver av dem må levere ekte minne‑klasset ytelse for at tokenomics skal gå opp. Bevaringsverdien for KV‑cache er en kostnadssenter‑diskusjon, sekundær til profitt‑senteret. Og hvis lesing av cache‑kontekst er tregere enn å bare rekalkulere den, er cachen verdiløs for forretningsmodellen. Det som betyr noe er ikke hvor mange GPU‑er du eier, men hvor produktiv hver enkelt er. Økonomien i AI handler om verdien du trekker ut av hver token, byte og watt, og sikkerhetskrav vil bare øke innsatsen i denne matematikken.

Ser du for deg at AI‑sikkerhet og etterlevelse vil bli en egen infrastruktur‑arbeidsbelastning, likt hvordan cybersikkerhet utviklet seg til et dedikert lag i bedrifts‑teknologi?

Vi vil se AI‑sikkerhet og etterlevelse bli en egen arbeidsbelastning, og parallellen med cybersikkerhet går begge veier. Sikkerhet ble sitt eget lag da industrien aksepterte at det ikke kunne være en sporadisk øvelse. Cyber‑forsikringsbransjen gjorde det obligatorisk. AI‑sikkerhet er på samme pålagte bane ettersom modeller blir mer kapable og mer autonome.

Men vi bør lære av hvor sikkerhet gikk galt. Den ble et pålegg: en separat stabel, et separat budsjett, et separat team som oppdaget problemer i etterkant. Sikkerhetsinfrastruktur bør ikke gjenta den feilen. Overvåking, evaluering, revisjonsmuligheter og uforanderlig bevaring bør være en del av AI‑infrastrukturen selv, med‑designet fra starten.

Her er delen de fleste overser: sikker AI krever mer AI. Guardrail‑modeller er ikke gratis. De må kontinuerlig trenes, finjusteres og infereres i hvert steg av agentens kjøretid. Token‑latens‑budsjetter gjør dette konkret: hvert svar har et fast vindu, og jo flere token du kan behandle innenfor det vinduet, desto mer verifisering har du råd til å kjøre før utdata sendes. Og den reelle trusselen fra frontmodeller er deres agent‑applikasjon. Agenter kjører som høy‑volum inferens‑sløyfer, og gjør gjentatte kall til modeller over lange horisonter. Hver sløyfe er observe, orient, decide, act, og hvert steg brenner token. Det gjør AI‑sikkerhet til en krig om token‑attrisjon. Angripere bruker røde agent‑svær, forsvarere bruker blå agent‑svær, og den siden som kan generere flere token per dollar og per watt vinner. Tokenomics ligger på den kritiske banen for både angrep og forsvar. Dette var ikke lenger et tankeeksperiment i sommer, da et rødt agent‑svær‑angrep mot et stort modell‑repo skremte industrien, og en dedikert sikker AI‑allianse ble dannet innen dager. I mellomtiden fortsetter volumene å vokse eksponentielt: industriens token‑behandling har gått fra trillioner til kvadrillioner.

Når sikkerhet blir et alltid‑på krav, slutter beregnings‑, minne‑ og datakostnadene å være overhead. De blir en del av den grunnleggende enhetsøkonomien ved å kjøre AI. De selskapene som internaliserer dette tidlig vil behandle sikkerhet som en design‑input. Alle andre vil behandle det som en skatt.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke WEKA.