Unite AI: Nikunj Bajaj, medeoprichter en CEO van TrueFoundry – Interviewreeks

Nikunj Bajaj is medeoprichter en CEO van TrueFoundry, waar hij de visie en strategie van het bedrijf leidt rond het bouwen van betrouwbare, enterprise-grade AI-platforms. Met ervaring in het opschalen van technologieproducten en teams, richt hij zich op het in staat stellen van organisaties om AI-systemen veilig en efficient te implementeren en te beheren. Hij schrijft over de adoptie van enterprise AI, AI-platformstrategie en opkomende trends in productie-AI.

TrueFoundry is een platform voor enterprise AI-infrastructuur dat organisaties helpt machine learning- en generatieve-AI-applicaties te bouwen, te implementeren, te beheren en op te schalen op Kubernetes-gebaseerde omgevingen, of dat nu in de cloud, on-premises of hybride is, met sterke governance, beveiliging en kostenbeheersing. Het combineert een AI Gateway om toegang tot modellen, LLM's en agentworkflows te centraliseren met tools voor modelfinetuning, implementatie, monitoring en autoscaling, met als doel MLOps te vereenvoudigen en de time-to-value voor data science- en engineeringteams te versnellen. De developer-first, cloud-onafhankelijke aanpak van TrueFoundry benadrukt enterprise-compliance en flexibiliteit, waardoor teams complexe AI-workloads kunnen beheren zonder leveranciersafhankelijkheid, terwijl normen zoals SOC 2, HIPAA en ITAR worden afgedwongen.

Je hebt gewerkt aan machine learning-onderzoek, productie-AI bij Facebook en grootschalige aanbevelingssystemen voordat je TrueFoundry oprichtte — welke ervaringen hebben je het meest rechtstreeks richting het bouwen van een enterprise AI-infrastructuurbedrijf geduwd, en welke pijn voelde je destijds dat niet werd aangepakt?

Bij Meta beschouwden we machine learning als een speciaal geval van software, en GenAI als een speciaal geval van machine learning, wat resulteerde in een verticale stack met software onderaan, machine learning in het midden, en GenAI bovenaan. In deze opzet volgen de modellen die ik bouw, als ik een machine learning-ontwikkelaar ben, hetzelfde implementatiepatroon als de rest van de software, wat het opschalen van systemen heel eenvoudig maakt.

De meeste ondernemingen implementeerden echter parallelle stacks, wat betekent dat ze aparte stacks hadden voor software, machine learning en GenAI. Zodra je deze parallelle stacks hebt, wordt opschalen complexer vanwege de overdrachten die nodig zijn tussen de machine learning-wereld en de softwarewereld.

Ons team heeft altijd gewerkt op het snijvlak van het bouwen van machine learning-modellen en machine learning-infrastructuur, dus hadden we een uniek perspectief dat we vergelijkbare verticale stacks naar ondernemingen konden brengen en ze konden aanpassen aan hun specifieke vereisten. We hadden ook eind 2021 de hypothese dat machine learning een kantelpunt naderde, en dat wanneer dat gebeurde, meer bedrijven een verticaal geintegreerde stack nodig zouden hebben om deze systemen effectief te implementeren en op te schalen. Dit is uiteindelijk wat ons ertoe bracht TrueFoundry op te richten, en onze hypothese bleek juist. De adoptie van AI versnelde na de lancering van ChatGPT eind 2022.

Nu AI-systemen verschuiven van experimenteren naar dagelijkse operaties, wat is er veranderd in hoe organisaties zouden moeten nadenken over betrouwbaarheid en falen?

De inzet bij Gen AI is aanzienlijk hoger vergeleken met traditionele machine learning-systemen. Naarmate deze systemen in productie gaan, hebben organisaties te maken met een veel hoger niveau van ambiguiteit en non-determinisme, omdat LLM's van nature stochastisch zijn. Agentic systemen die hierop zijn gebouwd, voegen nog meer ambiguiteit toe.

Bovendien zijn storingen niet langer binair. In plaats van dat systemen simpelweg falen of niet falen, verschijnen veel problemen als gedeeltelijke storingen of stille degradaties. Systemen kunnen reageren met hogere latentie, verminderde kwaliteit of onjuist gedrag na verloop van tijd. In veel gevallen kunnen deze degradaties lastiger te detecteren zijn en soms zelfs schadelijker dan een harde storing.

Organisaties moeten betrouwbaarheid niet alleen in termen van uptime zien, maar ook in termen van prestatiedegradatie na verloop van tijd.

TrueFailover werd gelanceerd te midden van een golf van spraakmakende verstoringen bij cloud- en AI-diensten. Welke recente gebeurtenissen maakten het duidelijk dat AI-betrouwbaarheid was verschoven van een “nice to have” naar een kernvereiste in de architectuur?

Een van onze zorgklanten die real-time, tijdgevoelige patiëntverzoeken over recepten verwerkt, werd getroffen door een storing veroorzaakt door een modelstoring. Hun workflows genereren duizenden dollars aan omzet per seconde, en de storing verstoorde enkele van deze kritieke workflows. Als vroege TrueFailover-klant konden we helpen met snel herstel, en de impact werd ingeperkt.

Incidenten zoals dit werpen een belangrijke vraag op. Nu de inzet van Gen AI-systemen blijft stijgen, waarom zijn herstelprocessen nog grotendeels handmatig? Het versterkte het idee dat systemen moeten worden gebouwd met de aanname dat storingen zullen optreden, en dat ze zo ontworpen moeten worden dat ze zichzelf automatisch corrigeren. Betrouwbaarheid moet ook in de AI-stack zelf worden ingebouwd, via het gebruik van AI Gateways, die gecentraliseerde routering, observability, guardrails en intelligente modelswitching tussen providers kunnen bieden.

Veel AI-storingen worden nog steeds gezien als technische hikjes. Waar zie je de werkelijke economische en menselijke kosten ontstaan wanneer AI-systemen uitvallen?

Enterprise-AI heeft zich ontwikkeld tot het punt waarop deze hikjes niet langer alleen interne workflows raken. Vandaag de dag hebben storingen en degradaties directe en onmiddellijke invloed op publieke perceptie en winst, omdat de productie-use-cases nu klantgericht zijn. Deze verschuiving van interne tests naar hoog-risico, publiekgerichte applicaties is waarom we toenemende vraag naar bestuurlijke aandacht en toezicht zien.

Naarmate AI-systemen dieper verweven raken met operationele workflows, zijn storingen niet langer alleen technische kwesties. Ze hebben steeds vaker directe gevolgen voor het bedrijf, de klant en de reputatie.

In bedrijfskritische omgevingen zoals apotheken, zorgoperaties of klantenservice: hoe snel kan AI-downtime escaleren tot operationeel of reputatierisico?

In bedrijfskritische omgevingen gebeurt escalatie bijna onmiddellijk, omdat deze systemen real-time, tijdgevoelige workflows ondersteunen. Zelfs een korte verstoring kan kritieke processen stilleggen, de dienstverlening vertragen of downstream-systemen onderbreken die afhankelijk zijn van die output, wat leidt tot cascaderende operationele effecten binnen de hele organisatie.

In sectoren zoals de zorg strekt de impact zich uit voorbij operationele verstoring tot klantervaring en dienstverleningsresultaten. Als een patiënt zijn recept niet op tijd kan ophalen, kunnen er echte gevolgen zijn. Dit is niet alleen een probleem voor de patiënt, maar kan ook de reputatie van een apotheek of zorgaanbieder schaden. In bedrijfskritische omgevingen waar vertrouwen een factor is, is het essentieel dat systemen online blijven. Daarom erkennen organisaties steeds meer dat AI-systemen moeten worden ontworpen met de aanname dat storingen zullen optreden en dat herstelmechanismen automatisch moeten activeren om risico's te minimaliseren.

Je hebt gezegd dat veel teams ontwerpen voor capaciteit in plaats van continuiteit. Waarom denk je dat veerkracht historisch gezien lager geprioriteerd is in AI-systeemontwerp?

Dit komt grotendeels neer op prikkels binnen organisaties. Nieuwe mogelijkheden zijn zichtbaar en opwindend. Ze ontsluiten demo's, functies en productmogelijkheden die het management meteen kan zien.

Continuiteit is, per definitie, onzichtbaar wanneer dingen goed werken. Hierdoor zijn beloningssystemen vaak scheefgetrokken in de richting van het uitbrengen van nieuwe functies, in plaats van ervoor te zorgen dat niets kapotgaat. Als gevolg hiervan investeren organisaties vaak disproportioneel in capaciteitsontwikkeling in plaats van in veerkracht-engineering.

Nu ondernemingen steeds meer vertrouwen op externe modellen en API's, welke nieuwe kwetsbaarheden worden in de AI-stack geintroduceerd die leiders mogelijk nog niet volledig doorgronden?

LLM's zijn fundamenteel gedeelde resources, en ondernemingen bezitten ze niet zoals ze traditionele infrastructuur bezitten. Bovendien draaien belangrijke bedrijfskritische systemen van ondernemingen op externe systemen die niet volledig tijdgetest zijn. LLM's zelf ontwikkelen zich snel, wat betekent dat een modelprovider niet verantwoordelijk kan worden gehouden voor zaken als latentie of een lichte daling in modelprestaties, omdat ze zeer snel itereren op hun onderzoek.

Omdat LLM's gedeelde resources zijn, kan de latentie pieken omdat een andere gebruiker van deze LLM's een specifieke actie onderneemt. Er worden veel van dit soort faalpunten geintroduceerd vanwege de fundamentele aard van LLM's, en ondernemingen in deze nieuwe wereld hebben simpelweg geen volledige controle. Zonder volledige controle is het beste wat een onderneming kan doen, voldoende systeemredundanties creeren om een veerkrachtig systeem te ontwerpen.

Zonder je te richten op specifieke producten, hoe zouden organisaties AI-architectuur moeten heroverwegen om falen als uitgangspunt te nemen in plaats van storingen als zeldzame uitzonderingen te behandelen?

Organisaties zouden moeten terugkeren naar de eerste beginselen van ontwerp voor gedistribueerde systemen. Softwaresystemen zijn gebouwd met de aanname dat netwerkcomponenten en machines zouden falen, en dat een hele regio zou kunnen uitvallen.

AI-systemen zouden niet anders moeten zijn. We moeten ervan uitgaan dat modelproviders latentieproblemen, degradaties of storingen zullen ervaren, en redundantie inbouwen zodat applicaties veerkrachtig blijven over verschillende faalscenario's heen.

Verwacht je dat AI-veerkracht een doorslaggevende factor wordt bij platform- en leverancierskeuze, vergelijkbaar met hoe uptime en redundantie beslissingen over cloudinfrastructuur vormgaven?

Naarmate meer AI-systemen in productie gaan, wordt veerkracht een basisvereiste. Als een leverancier zijn grafieken en statistieken over uptime en algehele veerkracht niet kan tonen, zal hij niet eens in overweging worden genomen. Zodra veerkracht een basisverwachting wordt bij alle leveranciers, zullen de doorslaggevende factoren verschuiven naar gebruikerservaring, prestatieoptimalisatie, observability en mogelijkheden op een hoger productniveau. Na verloop van tijd zullen componenten zoals een AI Gateway en geautomatiseerde failover-mogelijkheden fundamentele kernelementen worden van enterprise AI-infrastructuur.

Wat betekent “productierijpe” AI eigenlijk, vooruitkijkend, in een wereld waarin van AI wordt verwacht dat ze continu beschikbaar is, niet slechts incidenteel behulpzaam?

Productierijpe AI-systemen moeten observeerbaar, beheersbaar en herstelbaar zijn. Al deze drie vakjes moeten worden afgevinkt.

Om productie-AI observeerbaar te laten zijn, hebben teams diep inzicht nodig in modelgedrag, latentie, foutpercentages, tokengebruik, drift en faalpatronen. Zonder sterke observability wordt het heel lastig om degradaties te detecteren voordat gebruikers ze beginnen op te merken.

Om systemen beheersbaar te maken, omvat dat verkeersvormgeving, rate limiting, guardrails, beleidshandhaving en intelligente routering over modellen en providers heen. Hier wordt een AI Gateway fundamenteel, als een gecentraliseerd controlepaneel dat guardrails afdwingt, consistente governance biedt en dynamische modelswitching mogelijk maakt wanneer prestaties of betrouwbaarheid dalen.

En tot slot, als het gaat om herstelbaarheid, zouden systemen gebouwd moeten worden met de aanname dat componenten gedeeltelijk of volledig kapot kunnen gaan, of het nu komt door storingen bij providers, verminderde modelkwaliteit, rate limits of onverwachte input van kwaadwillende actoren. Geautomatiseerde failover- en self-healing-mechanismen zouden native onderdeel van de architectuur moeten zijn, geen handmatige draaiboeken die worden geactiveerd nadat er al iets misging.

Dit is de richting waarin we bij TrueFoundry werken. Leveranciers die productiegereedheid op deze manier definieren — waarbij observability, gecentraliseerde controle en geautomatiseerd herstel worden gecombineerd — zullen langdurig klantvertrouwen verdienen en in staat blijven nieuwe problemen op te lossen naarmate ze zich voordoen.

Over TrueFoundry:

TrueFoundry biedt een AI Gateway van enterprise-niveau die een LLM Gateway, MCP Gateway en Agent Gateway omvat, waarmee ondernemingen op een veilige manier verbinding kunnen maken met, toezicht kunnen houden op en controle kunnen uitoefenen over de toegang tot modellen, tools, guardrails en agents vanuit één centraal controlepaneel. De AI Gateway maakt agentic workloads mogelijk die veilig, efficient en toekomstbestendig zijn dankzij uniforme en samenstelbare verbindingen tussen verschillende aanbieders.

Naast de gatewaylaag stelt TrueFoundry organisaties in staat om aangepaste LLM's op GPU's te implementeren en te trainen, MCP-servers te hosten en eigen agents te draaien — allemaal via een Kubernetes-native interface. Het ondersteunt on-premise- en VPC-installaties voor zowel de AI Gateway als implementatieomgevingen. TrueFoundry zorgt voor enterprise-grade compliance met SOC 2, HIPAA en ITAR-normen. Met ingebouwde autoscaling, caching en resource-optimalisatie stelt TrueFoundry organisaties in staat om AI-systemen veilig, efficient en op een toekomstbestendige stack te bouwen, te implementeren en te beheren. Ga voor meer informatie naar truefoundry.com