Shahar Azulay, CEO en mede-oprichter van groundcover

Shahar Azulay, CEO en mede-oprichter van groundcover is een serie R&D-leider. Shahar brengt ervaring in de wereld van cybersecurity en machine learning met zich mee, nadat hij als leider heeft gewerkt bij bedrijven zoals Apple, DayTwo en Cymotive Technologies. Shahar heeft vele jaren in de Cyber-divisie van het Israëlische kantoor van de premier gewerkt en heeft drie diploma’s in natuurkunde, elektrotechniek en informatica van het Technion Israel Institute of Technology en de Universiteit van Tel Aviv. Shahar streeft ernaar om technologische kennis uit deze rijke achtergrond te gebruiken en deze te brengen naar het moderne, cloud-gebaseerde slagveld in de scherpste, meest innovatieve vorm om de wereld van dev een betere plek te maken.

groundcover is een cloud-native observability-platform dat is ontworpen om engineering-teams volledige, real-time zicht te geven in hun systemen zonder de complexiteit of kosten van traditionele monitoringtools. Gebouwd op eBPF-technologie, verzamelt en correleert het logs, metrics, traces en events in cloud-native en Kubernetes-omgevingen zonder code-wijzigingen, waardoor snellere root-cause-analyse en duidelijker systeeminzicht mogelijk wordt. Het platform benadrukt voorspelbare prijzen, flexibele implementatie die gegevens in de cloud van de klant houdt, en end-to-end observability die infrastructuur, applicaties en moderne AI-gedreven workloads omvat.

Als we terugkijken op uw reis – van het leiden van cyber R&D-teams in het Israëlische kantoor van de premier tot het beheren van ML-initiatieven bij Apple – welke ervaringen hebben u uiteindelijk ertoe aangezet om groundcover op te richten, en wanneer hebt u voor het eerst de kloof in observability voor moderne AI-systemen herkend?

De drang om groundcover op te richten kwam voort uit mijn tijd bij Apple en DayTwo. Zelfs met enorme budgetten waren we vastgeroest tussen het betalen van een fortuin om alles te loggen of te bemonsteren en blind te vliegen. Toen waren we op zoek naar een technologie die dat zou oplossen. Zodra we Extended Berkeley Packet Filter (eBPF) tegenkwamen, was het duidelijk dat het alles zou veranderen. eBPF laat ons zien wat er in de kernel gebeurt zonder afhankelijk te zijn van applicatiewijzigingen. Ik kon niet begrijpen waarom observability-tools daar geen gebruik van maakten. De AI-kloof werd later duidelijk. Toen onze Kubernetes-platform volwassen was, zagen we klanten die zich haastten om GenAI-implementaties uit te voeren, terwijl ze LLM’s als black boxes behandelden. Ze wisten dat het model reageerde, maar niet waarom het onvoorspelbaar gedrag vertoonde of waarom de kosten omhoog schoten. We realiseerden ons dat agentic workflows simpelweg complexe, niet-deterministische microservices zijn die dezelfde zero-touch-zichtbaarheid nodig hebben die we al hadden gebouwd.

Hoe heeft uw achtergrond in cybersecurity, embedded systems en machine-learning R&D de visie achter groundcover beïnvloed, en welke vroege uitdagingen hebt u ondervonden bij het opbouwen van een bedrijf dat zich richt op observability voor LLM-gedreven en agentic applicaties?

Mijn cyber-achtergrond heeft de DNA van het bedrijf gevormd. In de inlichtingenveld wordt ervan uitgegaan dat u de applicatie niet controleert. Die aanpak is de reden waarom groundcover geen instrumentatie vereist. Ik weet uit ervaring dat het vragen van ontwikkelaars om code te wijzigen de snelste manier is om adoptie te blokkeren. De moeilijkste vroege uitdaging bij het monitoren van LLM was privacy. Observability voor AI verzamelt prompts die mogelijk gevoelige PII of IP bevatten. Mijn achtergrond maakte het voor mij duidelijk dat ondernemingen die gegevens niet buiten hun omgeving wilden hebben. Daarom hebben we onze in-cloud-architectuur gebouwd, waardoor we diepe zichtbaarheid in agent-gedrag kunnen bieden terwijl alle gegevens binnen de omgeving van de klant blijven.

Hoe definieert u LLM-observability, en wat maakt het anders dan traditionele monitoring of ML-monitoring?

LLM-observability is de praktijk van het instrumenteren en monitoren van productiesystemen die grote taalmodellen gebruiken, zodat u de volledige context van elke inferentie kunt vastleggen: de prompt, context, voltooiing, tokengebruik, latentie, fouten, modelmetadata en idealiter downstream-feedback of kwaliteitssignalen. In plaats van alleen te vragen “Is de service up en snel?” of “Is deze aanvraag gefaald?”, helpt LLM-observability u om vragen te beantwoorden zoals “Waarom is deze specifieke aanvraag geslaagd of mislukt?”, “Wat is er eigenlijk gebeurd binnen deze multi-step-workflow?” en “Hoe beïnvloeden wijzigingen in prompts, context of modelversies de kosten, latentie en uitvoerkwaliteit?” Dat is heel anders dan traditionele monitoring of zelfs klassieke ML-monitoring. Legacy-benaderingen zijn afgestemd op deterministische systemen, infrastructuurmetrieken en statische drempels. LLM-toepassingen zijn niet-deterministisch, open-ended en hooguit context-afhankelijk. Succes is vaak semantisch en subjectief, niet alleen een 200 vs 500-statuscode. Dat betekent dat u inputs en outputs moet traceren, toolaanroepen en ophaalstappen moet evalueren, antwoorden moet beoordelen op hallucinaties of beleidsschendingen en tokenkosten en vertragingen moet koppelen aan de omliggende applicatie en infrastructuur.

Welke uitdagingen introduceren LLM-geactiveerde toepassingen die traditionele observability-tools ontoereikend maken?

LLM-geactiveerde systemen introduceren verschillende uitdagingen die de beperkingen van traditionele tools blootleggen:

• Complexe, multi-step-workflows – We zijn overgestapt van eenvoudige “bel een model, krijg een reactie”-stromen naar multi-turn-agents, multi-step-pipelines, retrieval-verrijkte generatie en toolgebruik. Een stille fout in een van die stappen, zoals ophalen, verrijking, insluiting, toolaanroep of modelaanroep, kan de hele ervaring breken. Traditionele monitoring biedt meestal geen complete, trace-niveau-weergave van die ketens met prompts en reacties inbegrepen.
• Snel evoluerende AI-stacks – Teams voegen constant nieuwe modellen, tools en leveranciers toe op een tempo dat ze nog nooit eerder hebben gezien. In veel bedrijven kan niemand met zekerheid zeggen welke modellen op dit moment in productie zijn. Klassieke observability gaat ervan uit dat u de tijd heeft om SDK’s te instrumenteren, opnieuw te implementeren en zorgvuldig te cureren wat u meet. Dat houdt gewoon geen gelijke tred met de snelheid waarmee AI wordt geadopteerd.
• Token-gebaseerde economie en quotas – Prijzen en limieten zijn gekoppeld aan tokens en contextlengte, die vaak worden gecontroleerd door ontwikkelaars, prompts of gebruikersgedrag, niet door centrale ops. Traditionele tools zijn niet gebouwd om u te laten zien “wie hoeveel tokens op welk model, voor welke workflow, met welke latentie” verbrandt.
• Semantische correctheid in plaats van binaire succes – Een LLM kan een 200 retourneren en toch hallucineren, afwijken van uw prompt of langzaam degradatie van uitvoerkwaliteit vertonen. Traditionele tools zien dat als een succes. U hebt observability nodig die prompts en reacties naar boven kan brengen en u voldoende context kan geven om gedrag te inspecteren en, met het verstrijken van de tijd, geautomatiseerde kwaliteitscontroles in te bouwen.
• Gevoelige invoergegevens die naar derden stromen – LLM’s nodigen gebruikers uit om zeer gevoelige informatie te delen via chat-achtige interfaces. Nu bent u verantwoordelijk voor die gegevens, waar ze worden opgeslagen en welke onderaannemers ze zien. Conventionele SaaS-gebaseerde observability die alle telemetrie naar een derde partij verzendt, is vaak onaanvaardbaar voor deze workloads.

Al deze factoren betekenen dat LLM-systemen observability vereisen die AI-georiënteerd, contextrijk en minder afhankelijk zijn van handmatige instrumentatie dan de tools die de meeste teams vandaag gebruiken.

Welke signalen of metrieken zijn het meest belangrijk voor het begrijpen van de prestaties en kwaliteit van LLM-systemen, inclusief latentie, tokengebruik en prompt/reactie-gedrag?

Er zijn een paar categorieën signalen die in de praktijk veel betekenen:

Latentie en doorvoer

• Eind-tot-eind-latentie per aanvraag, inclusief modeltijd en omliggende applicatietijd.
• Staartlatentie (P90, P95, P99) per model en per workflow.
• Doorvoer per model, route en service, zodat u weet waar de belasting echt naartoe gaat.

Tokengebruik en kostendrijvers

• Invoer- en uitvoertokens per aanvraag, onderverdeeld per model.
• Geaggregeerd tokengebruik over tijd per model, team, gebruiker en workflow.
• Contextgrootte voor ophaling-intensieve pipelines, zodat u kunt zien wanneer prompts exploderen.
• Dit is wat u in staat stelt om te antwoorden “Wie verbruikt ons AI-budget en waarvoor?”

Prompt- en reactiegedrag

• De daadwerkelijke prompt- en reactiepayloads op representatieve traces, inclusief toolaanroepen en redeneringspaden.
• Welke tools de LLM heeft geselecteerd en in welke volgorde.
• Variatie in reacties voor soortgelijke prompts, zodat u kunt zien hoe stabiel het gedrag is.

Betrouwbaarheid en fouten

• Modelspecifieke fouttarieven en -typen (providerfouten, time-outs, auth-problemen, quotafouten).
• Fouten in de omliggende workflow, zoals tooltime-outs of ophalingsfouten, gekoppeld aan de LLM-aanroep.

Klassieke infra-context

• Container-CPU-, geheugen- en netwerkmetrieken voor de services die uw LLM-aanroepen orkestreren.
• Gecorreleerde logs die beschrijven wat de applicatie probeerde te doen.

Wanneer u al dit ziet op één plaats, verandert LLM-observability van “Ik weet dat iets langzaam of duur is” naar “Ik weet precies welk model, promptpatroon en service verantwoordelijk zijn en waarom”.

Hoe kan observability helpen bij het detecteren van stille fouten zoals promptdrift, hallucinaties of geleidelijke degradatie van uitvoerkwaliteit?

Stille fouten in LLM-systemen gebeuren meestal wanneer alles “groen” lijkt op infra-niveau, maar het daadwerkelijke gedrag afwijkt. Observability helpt op een paar manieren:

• Traceren van de volledige workflow, niet alleen de modelaanroep – Door de hele pad van een aanvraag van client naar service naar ophalen naar model naar tools te traceren, kunt u zien waar het gedrag veranderde. Misschien begon ophalen bijvoorbeeld minder documenten terug te geven, of faalde een toolaanroep af en toe, en improviseerde het model.
• Prompts, context en reacties in beeld houden – Wanneer u prompts en reacties naast traces kunt inspecteren, wordt het veel gemakkelijker om gevallen te detecteren waarin een nieuwe promptversie, een nieuwe systeeminstructie of een nieuwe contextbron het gedrag veranderde, zelfs als latentie en fouttarieven hetzelfde bleven.
• Filteren en snijden op semantische voorwaarden – Zodra u rijke LLM-telemetrie heeft, kunt u filteren op dingen zoals “bedrock-aanroepen langer dan één seconde”, “aanvragen die dit modelgezin gebruiken” of “traces die deze specifieke route betreffen”, en vervolgens prompts en reacties lezen om te zien of het model afwijkt of hallucineert in een specifiek scenario.
• Waarschuwen op business-niveau SLO’s – U kunt SLO’s definiëren zoals “elke LLM-aanroep langer dan één seconde schendt onze gebruikersgerichte SLA” en waarschuwingen activeren wanneer die voorwaarden worden vervuld. Met het verstrijken van de tijd kunnen soortgelijke SLO’s worden gekoppeld aan kwaliteitsscores of beleidscontroles, zodat u wordt gewaarschuwd wanneer de kwaliteit afneemt, niet alleen wanneer de infrastructuur faalt.

Omdat het observability-laag toegang heeft tot zowel AI-specifieke signalen als klassieke logs, metrics en traces, wordt het een natuurlijke plek om problemen te detecteren die anders zouden kunnen verergeren.

Hoe ondersteunt groundcover’s aanpak het diagnosticeren van onvoorspelbare latentie of onverwacht gedrag binnen multi-step-agent-workflows en toolaanroepen?

groundcover gebruikt een aanpak die is ontworpen voor moderne AI-systemen. We gebruiken een eBPF-gebaseerde sensor op kernel-niveau om verkeer over microservices te observeren zonder code-wijzigingen of opnieuw te implementeren. Zodra u een LLM-workflow introduceert, kunnen we die aanroepen automatisch ontdekken. Als u morgen een nieuw model zoals Anthropic, OpenAI of Bedrock gaat gebruiken, verzamelt groundcover die verkeer automatisch. Dat geeft u:

• Eind-tot-eind-traces van multi-hop-workflows – U ziet het volledige pad van een aanvraag over services, inclusief waar een LLM of tool wordt gebruikt.
• Diepe context over elke LLM-aanroep – Elke aanroep bevat het gebruikte model, latentie, tokengebruik, prompts, reacties en gecorreleerde logs en infra-metrieken.
• Krachtig filteren op latentie en voorwaarden – U kunt bijvoorbeeld filteren op alle Claude 3.5-aanroepen langer dan één seconde en onmiddellijk de traces inspecteren die uw SLA hebben geschonden.
• Waarschuwingen en dashboards gekoppeld aan LLM-gedrag – Zodra de gegevens beschikbaar zijn, kunt u waarschuwingen maken voor SLA-schendingen of dashboards bouwen die latentie, doorvoer, tokengebruik en fouten volgen.

Omdat alles wordt verzameld aan de rand door eBPF en wordt opgeslagen in uw eigen cloud, krijgt u deze hoogwaardige weergave zonder instrumentatie toe te voegen binnen elke agent of toolaanroep.

Welke gegevensbeveiligings- en nalevingsrisico’s ziet u ontstaan bij LLM-implementaties, en hoe kan observability helpen om die risico’s te verminderen?

LLM-implementaties brengen enkele unieke gegevensrisico’s met zich mee:

• Onbeperkte gebruikersinvoer – Gebruikers kunnen zeer gevoelige informatie typen in chatbots en AI-geactiveerde interfaces. Dat kan persoonlijke gegevens, klantgegevens of gereguleerde informatie omvatten die u nooit had bedoeld te verzamelen.
• Derde partij-modelaanbieders – Zodra u die gegevens naar een externe LLM-aanbieder verzendt, bent u verantwoordelijk voor waar ze naartoe gaan, hoe ze worden opgeslagen en welke onderaannemers ze zien. Dat heeft grote implicaties voor GDPR, gegevensresidu en klantvertrouwen.
• Telemetrie als tweede kopie van gevoelige gegevens – Als uw observability-stack volledige payloads naar een SaaS-aanbieder verzendt, hebt u nu een andere kopie van die gevoelige informatie die buiten uw omgeving staat.

groundcover’s architectuur is ontworpen om precies deze zorgen aan te pakken:

• We gebruiken een “bring your own cloud”-model waarbij de volledige observability-backend in uw cloud-account draait, in een sub-account, als een volledig beheerd dataplane. Het control-plane dat het schaalt en beheert, wordt door ons uitgevoerd, maar we hebben geen toegang tot, opslaan of verwerken van uw telemetriegegevens.
• Omdat we prompts, reacties en workflows veilig in uw eigen omgeving kunnen verzamelen, kunt u LLM-traces observeren zonder dat die gegevens ooit uw cloud verlaten. Er is geen derde partij-opslag van uw LLM-traces en geen extra gegevens-egress om u zorgen over te maken.
• Met die zichtbaarheid kunt u zien wie wat uploadt en waar het naartoe gaat, onverwacht gebruik van gevoelige gegevens detecteren en beleid afdwingen over welke modellen en regio’s zijn toegestaan.

Met andere woorden, observability wordt niet alleen een betrouwbaarheids- en kostentool, maar ook een sleutelbeheersingspunt voor privacy, gegevensresidu en naleving.

Als organisaties schalen van één LLM-integratie naar veel AI-geactiveerde diensten, welke operationele uitdagingen treden er op rond zichtbaarheid, betrouwbaarheid en kosten?

De eerste integratie is meestal één model in één workflow. Op dat moment voelt alles beheersbaar. Zodra teams waarde zien, explodeert het gebruik en verschijnen verschillende uitdagingen:

• Model- en leveranciersverspreiding – Teams testen constant nieuwe modellen. Het wordt al snel onduidelijk welke modellen in productie zijn en hoe ze worden gebruikt.
• Kostensurprises van tokengebruik – Tokenverbruik groeit met contextlengte en workflowcomplexiteit. Zonder zichtbaarheid in tokengebruik per model en workflow is het moeilijk om kosten te beheren.
• Betrouwbaarheidsafhankelijkheden van externe aanbieders – Gebruikersgerichte API’s worden gevoelig voor modellatentie of -fouten, die SLA’s kunnen schenden, zelfs als de kerninfrastructuur gezond is.
• Instrumentatie-schuld – Traditionele observability gaat ervan uit dat u de tijd heeft om instrumentatie toe te voegen wanneer dat nodig is. In snel evoluerende AI-stacks hebben ontwikkelaars zelden de tijd voor dat soort dingen.

groundcover adresseert deze door AI-verkeer automatisch te ontdekken en u vervolgens te geven:

• Centraal zicht op welke modellen en leveranciers worden gebruikt.
• Dashboards die latentie, doorvoer en tokengebruik over tijd laten zien.
• Correlatie tussen LLM-gedrag en de services die ervan afhankelijk zijn
• Waarschuwingen voor AI-gedreven SLO-schendingen.

Dat maakt het veel gemakkelijker om te schalen van “één cool AI-functie” naar “AI is ingebed in tientallen kritieke diensten” zonder de controle te verliezen.

Als we vooruitkijken, hoe verwacht u dat LLM-observability zal evolueren in de komende vijf jaar, aangezien agentic AI, multi-model-orchestratie en reguleringsdruk toenemen?

We zijn nog in de vroege dagen. In de komende vijf jaar verwacht ik een paar grote verschuivingen:

• Van request-niveau naar agent-niveau-begrip – Observability zal worden uitgebreid om toolsequenties, redeneringspaden en retry-logica te omvatten, niet alleen modelaanroepen.
• Rijkere semantische en beleidssignalen – Geautomatiseerde kwaliteitscontroles voor hallucinaties, veiligheidsproblemen en merkconsistentie zullen standaardmetrieken worden.
• Strakkere koppeling met governance en privacy – Naarmate regelgeving groeit, zal observability ook dienen als een handhavings- en auditlaag voor gegevensresidu, -retentie en -gebruik van goedgekeurde modellen.
• Multi-model, multi-leverancier-optimalisatie – Teams zullen verkeer dynamisch over modellen routeren op basis van prestaties en kosten, geleid door real-time observability-gegevens.
• Minder handmatige instrumentatie – Technieken zoals eBPF-gebaseerde verzameling en automatische ontdekking zullen de standaard worden, zodat teams kunnen innoveren zonder te vertragen.

Kortom, LLM-observability zal evolueren van “leuke dashboards voor AI” naar het centrale zenuwstelsel dat betrouwbaarheid, kostbeheersing, gegevensgovernance en productkwaliteit verbindt over alles wat een organisatie met AI doet.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten groundcover bezoeken.