Val Bercovici, Chief AI Officer bij WEKA – Interviewreeks

Val Bercovici, Chief AI Officer bij WEKA, is een executive op het gebied van AI en data‑infrastructuur die zich richt op het vooruitstuwen van de technologieën die ten grondslag liggen aan de volgende generatie kunstmatige intelligentie. Sinds hij in januari 2025 als Chief AI Officer bij WEKA begon, heeft hij zich geconcentreerd op het bouwen van AI‑agentinfrastructuur, het versnellen van trainings‑ en inferentiewerkbelastingen, en het verbeteren van de economie van AI‑computatie. Naast zijn rol bij WEKA, dient Bercovici als AI‑adviseur voor Home Dock, als strategisch adviseur voor FermiHDI en The Hive, en als voorzitter van PencilDATA, waar zijn werk zich uitstrekt over AI, cyberbeveiliging, blockchain, cloud‑computing en data‑infrastructuur. Zijn loopbaan weerspiegelt een langdurige focus op het ontwikkelen en adviseren van opkomende technologieën die zijn ontworpen om steeds data‑intensievere AI‑systemen te ondersteunen.

WEKA is een AI‑native data‑infrastructuurbedrijf dat een software‑gedefinieerd platform bouwt dat is ontworpen voor de veeleisende data‑eisen van kunstmatige intelligentie, machine learning, high‑performance computing en andere versnelde workloads. Het WEKA Data Platform biedt organisaties een eenduidige architectuur die kan opereren in on‑premises, cloud, hybride en edge‑omgevingen, en helpt opslagknelpunten te elimineren, GPU‑benutting te verbeteren en AI‑modeltraining en -inference te versnellen. Het bedrijf positioneert zijn technologie steeds meer rond de opkomende inference‑economie en agent‑AI, met een infrastructuur die is ontworpen om hoge doorvoersnelheden en lage latentie toegang tot data op enorme schaal te bieden, terwijl complexe AI‑datapijplijnen worden vereenvoudigd. WEKA bedient ondernemingen, cloud‑providers, onderzoeksinstellingen en AI‑ontwikkelaars die enkele van ’s werelds meest prestatie‑intensieve computeromgevingen exploiteren.

Uw carrière heeft u van het vormgeven van NetApp’s vroege cloudstrategie en het dienen in de oprichtende bestuursraad van Kubernetes tot het bouwen van AI‑infrastructuur bij WEKA gebracht. Hoe heeft die evolutie uw manier van denken over het voorbereiden van infrastructuur voor de volgende fase van AI gevormd?

Elke fase van mijn carrière werd gekenmerkt door hetzelfde patroon: de knelpunt verschuift, en de industrie doet er jaren over om het te merken. In de vroege cloud‑ en Kubernetes‑dagen zagen we hoe rekenkracht elastisch werd en orkestratie het nieuwe knelpunt werd. Na NetApp, waar ik CTO was na de overname van SolidFire, dacht ik dat ik wist hoe snel eruitzag: enkele milliseconden voor een echt willekeurige eerste‑byte‑lezen onder productie‑workloads.

De reden dat ik bij WEKA kwam, is echt nerdy. Het kwam neer op één statistiek: de eerste niet‑gecachede willekeurige byte‑lezen duurt 70 microseconden, wat geen opslag‑klasse getal is. Ik had nooit de gedachte aan latentie op microseconden‑niveau voor dit type systeem overwogen. Dat was de aha‑moment: deze technologie kon geheugen‑toepassingen bedienen, DRAM‑klasse toepassingen zoals Redis en KV‑cache, niet alleen opslag. En precies op dat moment begon inference training te overtreffen omdat de industrie deze modellen moest monetariseren, en agents verschenen om geheugen tot het hele spel te maken.

Dat is het perspectief dat ik meebreng naar AI‑infrastructuur. We hebben deze film al eerder gezien. Cloud FinOps ontstond omdat bedrijven infrastructuur opschalen zonder rigoureuze eenheids‑economische analyse, waarna ze de rekening kregen. AI bevindt zich op dezelfde curve, maar beweegt sneller. Naarmate bedrijven onvermijdelijk terugduwen op token‑maximalisatie met de komst van API‑verbruikskosten die ver boven de geplande tokenbudgetten uitkomen, zien we de opkomst van AI FinOps. Dit is het moment waarop organisaties inference niet langer als een goedkope utility behandelen, maar token‑efficiëntie gaan managen als een financiële discipline. AI FinOps begint met tokenomics: het optimaliseren van elke hardware‑ en softwarelaag van de inference‑stack die de eenheids‑kost per token beïnvloedt. Op dit moment is de grootste verspilling in die stack dure GPU’s en nieuwe ASIC’s die idle wachten op geheugen en data (aka ‘decode’) in plaats van FLOPS (aka ‘prefill’). Wie dat oplost, bezit de volgende fase van AI.

Het Witte Huis houdt de details van zijn nieuwe AI‑veiligheidskader vertrouwelijk. Hoe kunnen bedrijven zich voorbereiden op regelgevende eisen wanneer ze nog niet precies weten wat er getest of vereist zal worden?

Bedrijven moeten niet wachten op de definitieve checklist. De specifieke tests zullen veranderen, maar de onderliggende verplichting blijft bestaan: u moet kunnen aantonen wat uw AI‑model deed, welke data het raakte, en hoe het zich op een bepaald moment gedroeg. En wachten is wereldwijd al geen optie meer. De EU‑AI‑Act werd deze maand afdwingbaar, en classificeert de meeste agent‑orchestratie als hoog risico.

Dat betekent dat de voorbereidingswerkzaamheden infrastructuurwerk zijn. Data‑lineage, observeerbaarheid, reproduceerbaarheid en het vermogen om de modelstatus op verzoek te reconstrueren, zijn allemaal cruciaal voor bedrijven. Ten slotte moeten organisaties guardrail‑modellen vóór de output implementeren, met bijbehorende latentie‑ en tokenbudgetten voor de semantische verdedigingslagen. Als u die mogelijkheden nu bouwt, wordt elk kader een formatterings‑oefening. Wacht u op de definitieve regels, dan past u verantwoording toe op systemen die nooit zijn ontworpen om zichzelf uit te leggen. Die retrofit is altijd duurder dan het vanaf het begin inbouwen.

Uiteindelijk is de oplossing voor het bouwen van veilige AI meer AI, optimaal en zeer bewust toegepast.

Welke soorten nieuwe infrastructuur‑eisen zou AI‑veiligheidstesten kunnen creëren, en hoe zouden die workloads er anders uitzien dan conventionele modeltraining of -inference?

Training is een waterval. Je duwt enorme hoeveelheden data door een model in een gestage, voorspelbare reeks. Veiligheidstesten is het tegenovergestelde: duizenden evaluatiescenario’s, herhaalde probing, versie‑na‑versie gedragsvergelijkingen, en adversariële red‑team‑aanvallen die nooit echt eindigen.

Dat profiel is belangrijk. Veiligheidstraining en -testing is bursty, leesintensief en vergelijkend. Het genereert en verbruikt enorme hoeveelheden tussenliggende status. Guardrail‑modellen moeten van nature heterogeen en gelaagd zijn, geïmplementeerd binnen strakke latentie‑budgetten, waarbij evaluaties worden versterkt met deze nieuwe dimensie van veiligheidscriteria. Voor zulke geavanceerde of cyber‑capabele modellen is het workload‑profiel 24/7 persistent in plaats van episodisch. U voert niet één test uit en archiveert de resultaten. U draait continue agent‑zwerm‑workloads die in productie concurreren met rekenkracht, geheugen en databandbreedte voor die kritieke applicaties die ze beschermen. Na kwaliteit en snelheid is de meeste infrastructuur vandaag niet ontworpen voor dit derde principe.

Er zit ook een meetprobleem onder. De meeste AI‑benchmarks van vandaag draaien 8.000 tokens of minder, één prompt, één respons. Ik maak een grap dat het kunstmatige benchmarks van kunstmatige intelligentie zijn. Halverwege 2026 draaien echte agent‑workloads 100.000 tot 400.000 tokens context over duizenden beurten. Als veiligheidsevaluaties die speelgoed‑benchmarks overnemen, certificeren we systemen voor een wereld die niet bestaat. Regelgevers bouwen hier al meer capaciteit op: NIST heeft agent‑beveiligingsevaluatietools open‑source gemaakt, en vroege gepubliceerde resultaten tonen dat nieuwe agent‑hijack‑aanvallen slagen met een veelvoud van de snelheid van bekende baselines. Dat is precies het type continue, adversariële, dure testing waar ik verwacht dat veiligheidskaders op zullen convergeren.

Moeten organisaties overtollige reken‑ en datacapaciteit bouwen specifiek voor toekomstige compliance‑ en veiligheidsworkloads, of is er een efficiëntere manier om voor die onzekerheid te ontwerpen?

Het kopen van overtollige GPU’s en hopen dat de benutting inhaalt, laat kapitaal vastzitten in afschrijvend hardware.

Het efficiënte antwoord is infrastructuur die tussen productie‑ en evaluatieworkloads kan schakelen zonder een aparte stack. Dat is in wezen een dataprobleem. Als u data efficiënt kunt verplaatsen en hergebruiken, context tussen workloads kunt behouden, en uw accelerators bezig houdt met echt werk, wordt compliance een incrementele kost in plaats van een parallelle uitrol. De economie van AI komt steeds meer neer op hoeveel waarde u uit elke token, byte en watt haalt. Als u het goed doet, kunt u 3‑4 × meer waarde genereren uit dezelfde infrastructuur, of uw rack‑voetafdruk met tot 75 % verkleinen. Compliance moet aan dezelfde norm worden gehouden.

Het huidige kader richt zich volgens berichten op geavanceerde gesloten modellen, terwijl open‑weight modellen worden uitgesloten. Welke infrastructuur‑ of beveiligingsuitdagingen kunnen ontstaan door die twee categorieën anders te behandelen?

Als u gesloten modellen en open‑weight modellen anders behandelt, eindigt u met twee compliance‑kaders voor technologieën die hetzelfde doen, en de kloof daartussen is waar het risico leeft.

Een open‑weight model kan worden gefinetuned en ingezet in omgevingen waar de oorspronkelijke provider geen zicht heeft. Het reguleren van de provider doet daar niets. En de scheiding is al zichtbaar: exportcontroles werden dit jaar toegepast op de nieuwste gesloten frontier‑modellen, terwijl open‑weight modellen vrij over grenzen bewegen en nu dicht bij de top van openbare capaciteitsranglijsten staan. Echter, de administratie definieert uiteindelijk frontier‑modellen; governance kan niet stoppen bij het model zelf. U heeft zicht nodig op waar modellen draaien, welke data ze benaderen, welke prompts, reacties en metadata worden bewaard, hoe ze zijn aangepast, en of de onderliggende infrastructuur AI op schaal kan ondersteunen. Nieuwe updates van ISO27001 en SOC2 zullen vereist zijn.

Mijn antwoord is vertrouwen, maar verifiëren. Als uw infrastructuur u de token‑capaciteit biedt, kunt u heterogene guardrails draaien tegen elk model voordat de output wordt verzonden: binnenlands of buitenlands, open of gesloten. Objectieve verificatie overtreft blinde vertrouwen of wantrouwen gebaseerd op de herkomst van een model. Naarmate open modellen zich vermenigvuldigen, leeft die verificatie‑capaciteit in de infrastructuurlag, en daar zullen ondernemingen zich onderscheiden. Beleid kan bepalen welke modellen zijn toegestaan. Infrastructuur beslist of die modellen verantwoord en economisch kunnen worden ingezet.

Naarmate AI‑agents autonoom worden en over langere contexten opereren, hoe verandert dat de hoeveelheid data, geheugen en rekenkracht die organisaties moeten toewijzen aan monitoring en veiligheid?

Een chatbot bestaat uit een prompt en een respons. Een autonome agent is een lopend proces. Het raakt tientallen systemen, haalt informatie op, maakt tussenbeslissingen, en verzamelt status over uren of dagen voordat het een taak voltooit.

U kunt dat niet monitoren door individuele tokens of responsen te bemonsteren. U moet de volledige reeks vastleggen: wat de agent wist, wanneer hij het wist, en wat hij vervolgens deed. Elk uur dat een agent draait, groeit zijn status, en daarmee ook het geheugen, de dataverplaatsing en de infrastructuur die nodig is om het vast te leggen en te analyseren. Monitoring stopt met een log‑functie te zijn en wordt een workload van de eerste orde met een eigen resource‑budget.

Verdediging is waar dit urgent wordt. Het geheugenprobleem van AI wordt een beveiligingsprobleem. Een codeer‑agent kan opstarten, leveren en afsluiten. Een cybersecurity‑agent kan dat niet. Hij moet context behouden over dagelijkse ploegwisselingen in een security‑operations‑center, frequente modelupdates, en geavanceerde meer‑fasen‑aanvalscampagnes die vroeger weken duurden, maar nu ook op gecoördineerde machinale snelheden opereren. Wanneer dat werkgeheugen van AI wordt uitgeveegd en elke paar minuten opnieuw wordt berekend, heeft een agent die anomalie‑gedrag detecteerde in uur één van een incident, geen geheugen meer in uur twee. Aanvallers hebben dat probleem niet. Hun agents identificeren en exploiteren voortdurend zwaktes, en kill‑chains voltooien nu op tokenomics‑geoptimaliseerde machinale snelheden, dus AI‑gedreven cyberverdediging moet 24/7 autonoom draaien. En dit is niet theoretisch. Beveiligingsleveranciers bereiden zich nu voor op 24/7 persistente cyber‑agents, en het eerste dat ze ontdekken is dat de economie er totaal anders uitziet dan bij chat‑workloads. Sommige organisaties hebben die agents nodig aan de rand, in faciliteiten waar je dit jaar geen GPU‑rack of zelfs geen koeler kunt verzenden. De echte test voor enterprise‑AI is het behouden van context over langere tijd, niet inference op een specifiek moment. Dit wordt een strijd om token‑attritie, en wie de persistente context‑memory op schaal oplost, zal de eerste horizontale killer‑app in enterprise‑AI aandrijven: altijd‑aanstaande blauwe agent‑zwermen.

U heeft gesproken over het groeiende belang van “context‑memory” nu AI‑workloads verder gaan dan eenvoudige chat naar persistente agents. Kan context‑memory ook belangrijk worden voor het auditen, reproduceren of onderzoeken van AI‑gedrag?

Absoluut, en het is een belangrijk gebruiksgeval. Jarenlang was geheugen een prestatie‑verhaal: hoe snel u de GPU kon voeden, hoeveel context u kon vasthouden. Zodra agents autonoom gaan handelen, wordt datzelfde geheugen het bewijs. Als een agent een beslissing neemt op basis van context die hij over dagen heeft verzameld, vertellen de uiteindelijke prompt en output bijna niets over waarom hij handelde. De verklaring zit in de geaccumuleerde status.

In technische termen bevindt het grootste deel van die status zich in de KV‑cache, en de industrie behandelt het nog steeds als wegwerpscratch‑ruimte in plaats van duurzame data. Als u die status bewaart en efficiënt kunt ophalen, kunt u reconstrueren wat het systeem wist op het moment dat het handelde. Teams zullen dat eerst gebruiken voor debugging, daarna voor veiligheidsevaluaties, en uiteindelijk zal iemand het nodig hebben bij een onderzoek. Het weggooien van context‑memory betekent het weggooien van het enige record dat verklaart waarom uw AI deed wat hij deed.

Zou AI‑regulering uiteindelijk bedrijven kunnen dwingen om aanzienlijk meer informatie over model‑inputs, -outputs, checkpoints, data‑lineage en agent‑activiteit te bewaren? Wat zou dat betekenen voor de AI‑infrastructuurarchitectuur?

Richtinggevend, ja. Naarmate AI‑systemen consequentialer worden, zullen de zichtbaarheidseisen zich uitbreiden tot elke stap van de pijplijn. U ziet al de vroege signalen: teams plannen om verouderde context‑memory te bewaren in goedkopere object‑storage‑lagen puur voor auditdoeleinden, nog voordat regelgeving dat vereist.

Authenticatie van monitoring met onveranderlijkheid is essentieel. Het manipuleren van logs en andere forensische artefacten door kwaadwillende agents is routine geworden, wat gecompliceerde cryptografische verificatiesystemen vereist die niet kwetsbaar zijn voor geconcentreerde, gecentraliseerde integriteitsdoelen van aanvallen. Simpele transparantielogs of hash‑chains zijn niet voldoende om zich te verdedigen tegen de samenzweringsmogelijkheden van gecoördineerde agent‑zwermen. Zeer gedecentraliseerde, publieke blockchain‑architecturen zijn hiervoor ideaal, en benadrukken de vaak over het hoofd geziene integriteitswaarde, in het midden van de C‑I‑A‑triade van cyberbeveiliging.

Bewaring is niet alleen een ontmoedigend, onveranderlijk opslagprobleem op schaal. Het moeilijke deel is die informatie betrouwbaar, georganiseerd, geïndexeerd en snel genoeg opvraagbaar te houden om bruikbaar te zijn binnen een deadline, of die deadline nu van een regulator, een incident‑respons of een rechtbank komt. Een petabyte aan agent‑activiteit die u niet kunt opvragen, is een aansprakelijkheid, geen record. De architecturale verschuiving gaat van “meer opslag” naar infrastructuur die is ontworpen rond objectief verifieerbare, persistente, doorzoekbare AI‑data als kern‑workload.

Veel organisaties richten zich op het kopen van meer GPU’s, maar waar ziet u de minder voor de hand liggende infrastructuurknelpunten ontstaan naarmate AI‑workloads opschalen en veiligheidsvereisten veeleisender worden?

De GPU krijgt de krantenkoppen omdat het geen onbeduidend budgetitem is. Maar GPU’s en vooral nieuwe decode‑geoptimaliseerde accelerators (ASIC+SRAM) zijn zelden de daadwerkelijke beperking. Geheugenbandbreedte, datagraviteit en -verplaatsing, opslagprestaties en netwerken bepalen of die accelerators productief werk doen of onderbenut wachten.

Naarmate AI meer context‑intensief wordt, wordt de geheugen‑wall de bepalende beperking. U kunt blijven GPU’s toevoegen, maar als ze hun cycli besteden aan het opnieuw berekenen van tokens of het verplaatsen van context tussen systemen, betaalt u voor verspild werk, keer op keer. Het opschalen van de geheugen‑wall betekent dat de datalaag zich gedraagt als gedeelde opslag, maar presteert op echte geheugensnelheden. Die HBM‑nabije snelheidsbalk is belangrijk voor de winst‑centergolf van KV‑cache‑offloading‑oplossingen die nu verschijnen: elk van hen moet echte geheugen‑klasse prestaties leveren om de tokenomics rendabel te maken. De retentiewaarde voor KV‑cache is een discussie over kostenposten, secundair aan de winst‑centra. En als het lezen van gecachete context langzamer is dan het gewoon opnieuw berekenen, is de cache waardeloos voor de bedrijfsvergelijking. Wat telt, is niet hoeveel GPU’s u bezit, maar hoe productief elke GPU is. De economie van AI komt neer op de waarde die u uit elke token, byte en watt haalt, en veiligheidsvereisten zullen alleen de inzet van die wiskunde verhogen.

Kijkend naar de toekomst, verwacht u dat AI‑veiligheid en compliance een eigen, aparte infrastructuur‑workload zullen worden, vergelijkbaar met hoe cyberbeveiliging is uitgegroeid tot een dedicated laag binnen enterprise‑technologie?

We zullen zien dat AI‑veiligheid en compliance een aparte workload worden, en de parallel met cyberbeveiliging werkt beide kanten op. Beveiliging werd een eigen laag zodra de industrie accepteerde dat het geen incidentele oefening kon blijven. De cyber‑verzekeringsindustrie maakte dat niet‑optioneel. AI‑veiligheid volgt dezelfde verplichte traject als modellen steeds capabeler en autonomer worden.

Maar we moeten leren van waar beveiliging fout ging. Het werd een bolt‑on: een aparte stack, een apart budget, een apart team dat problemen achteraf ontdekte. Veiligheidsinfrastructuur mag die fout niet herhalen. Monitoring, evaluatie, auditbaarheid en onveranderlijke bewaring horen binnen de AI‑infrastructuur zelf, vanaf het begin mede‑ontworpen.

Dit is het deel dat de meeste mensen missen: veilige AI vereist meer AI. Guardrail‑modellen zijn niet gratis. Ze moeten continu getraind, gefinetuned en geïnferreerd worden bij elke stap van de agent‑runtime. Token‑latentie‑budgetten maken dit concreet: elke respons heeft een vaste tijds‑window, en hoe meer tokens u binnen dat window kunt verwerken, hoe meer verificatie u kunt uitvoeren voordat de output wordt vrijgegeven. En de echte dreiging van frontier‑modellen is hun agent‑toepassing. Agents draaien als high‑volume inference‑loops, maken herhaalde calls naar modellen over lange tijdshorizonten. Elke loop is observe, orient, decide, act, en elke stap verbrandt tokens. Dat maakt AI‑beveiliging een oorlog van token‑attritie. Aanvallers zetten rode agent‑zwermen in, verdedigers blauwe agent‑zwermen, en de kant die meer tokens per dollar en per watt kan genereren, wint. Tokenomics staan op het kritieke pad van zowel aanval als verdediging. Dit was deze zomer geen gedachte‑experiment meer, toen een rode agent‑zwerm‑aanval op een grote model‑repository de industrie wakker schudde, en binnen enkele dagen een dedicated secure AI‑alliantie werd gevormd. Ondertussen blijven de volumes zich opstapelen: de industriële token‑verwerking is van triljoenen naar quadriljoenen gegaan.

Zodra veiligheid een altijd‑aan vereiste wordt, stoppen de reken‑, geheugen‑ en datakosten een overhead te zijn. Ze worden onderdeel van de fundamentele eenheids‑economie van AI‑uitvoering. De bedrijven die dat vroeg internaliseren, zullen veiligheid zien als een ontwerpinvoer. Alle anderen zullen het zien als een belasting.

Dank u voor het geweldige interview, lezers die meer willen weten, kunnen WEKA bezoeken.