AI Ops: zo houd je AI-systemen gezond na de livegang

De meeste AI-projecten zijn gepland tot de dag van de livegang. Daarna begint het echte werk – en daar heeft niemand op gepland. Prijzen in de kennisbank veranderen, de modelaanbieder rolt een update uit, klanten vragen ineens naar een nieuw product, een veld in het CRM krijgt een andere naam, en de agent die in week één schitterde, wordt ongemerkt slechter.

Marktcijfers laten zien hoe vaak dat misgaat. Verslagen over AI-projecten in Russischtalige markten beschrijven een bekend patroon: na zes maanden is de waarde onzichtbaar, medewerkers zijn geïrriteerd, klanten klagen en het budget is overschreden (CNews). Gartner verwacht dat eind 2027 meer dan 40% van de agentic AI-projecten is stopgezet (Gartner). Bedrijven die AI als beheerd systeem behandelen, investeren gericht: in de KPMG-pulse over het derde kwartaal van 2026 gebruikt 70% van de grote Amerikaanse bedrijven dashboards, monitoring en kwaliteitsbeoordeling voor hun agents, en werkt 43% met tokenbudgetten (KPMG).

AI Ops is de discipline die AI-systemen na de livegang juist, betaalbaar, veilig en compliant houdt. Hieronder lees je wat erbij hoort, wat je moet monitoren, wat het kost en hoe je het inricht.

Waarom AI-systemen na de livegang achteruitgaan

1. Kennisdrift

Prijzen, beleid, openingstijden en assortimenten veranderen; de kennisbank werkt zichzelf niet bij. Verouderde kennis is de meest voorkomende oorzaak van hallucinaties maanden na de livegang – en zodra klanten het systeem op een fout betrappen, keldert het vertrouwen.

2. Modeldrift

Aanbieders werken modellen bij, wijzigen standaardversies en faseren oudere modellen uit volgens hun eigen planning. Dezelfde prompt levert dan ineens langere antwoorden op, gebruikt tools anders of krijgt een andere toon. Verwijst je systeem naar een ‘latest’-alias, dan kan het veranderen zonder dat er één regel van je eigen code wijzigt.

3. Drift in de vragen

Nieuwe producten, een marketingcampagne, een seizoenspiek of een nieuwe markt brengen vragen die het systeem nooit heeft gezien. Een dekking van 80% in maand één kan in maand zes op 60% liggen zonder dat er technisch iets kapot is.

4. Koppelingen die breken

Velden in het CRM worden hernoemd, API-versies verlopen, OAuth-tokens vervallen, een webhook verandert van formaat. Agents falen hier vaak geruisloos: ze blijven beleefd antwoorden, maar maken geen ticket of afspraak meer aan.

5. Kostendrift

Het gebruik groeit, gesprekken worden langer, iemand zet ‘tijdelijk’ een groter model aan. Alleen al groeiende context kan lange telefoonsessies per minuut veel duurder maken dan korte – in één meting tot $0,146 per minuut tegenover typisch $0,05–0,08 (HackerNoon).

6. Kanaal- en infrastructuurproblemen

Telefonie heeft eigen faalpatronen: latentiepieken op gedeelde infrastructuur; limieten voor gelijktijdige gesprekken – Retell bijvoorbeeld bevat 20 gelijktijdige gesprekken en rekent elke extra lijn apart (Retell); en in de VS markeren providers zakelijke nummers zonder branding als ‘Spam Likely’.

Vroege waarschuwingssignalen

Eén grote, dramatische storing is zeldzaam. Let in plaats daarvan op kleine signalen: het escalatiepercentage kruipt elke maand een paar punten omhoog; medewerkers controleren het werk van de agent ‘voor de zekerheid’ na; klanten schrijven ‘dat heb ik je bot al verteld’; de maandfactuur groeit harder dan het aantal gesprekken. Vroeg opgemerkt is elk van deze signalen goedkoop te herstellen – duur wordt het als het opduikt als klacht van je grootste klant.

De vijf pijlers van AI Ops

Wat je monitort: een praktische set kengetallen

Bedrijfsresultaten – de cijfers waar de directie om geeft:

• oplos- of automatiseringspercentage, geboekte afspraken, verwerkte documenten;
• escalatiepercentage naar mensen, en de redenen daarvoor;
• herhaalcontact binnen 48 uur – een opgelost ticket dat terugkomt, was niet opgelost.

Kwaliteit:

• online evalscores op een dagelijkse of wekelijkse steekproef van echte gesprekken (zie onze gids over AI-evals);
• onderbouwing en hallucinatiemarkeringen, beleidsovertredingen;
• gebruikersfeedback en handmatige correcties in systemen verderop in de keten.

Techniek:

• fout- en time-outpercentages per aanbieder en per tool;
• p95-latentie – aan de telefoon is het doel ongeveer één seconde per beurt, omdat mensen normaal maar zo’n 200 milliseconden stilte laten (PNAS);
• fallbackpercentage, dat problemen bij aanbieders laat zien voordat gebruikers ze merken.

Kosten:

• kosten per resultaat – per opgelost ticket, afspraak of document;
• tokens per gesprek en cache-hitrate;
• budgetverbruik tegen maandlimieten, bij voorkeur afgedwongen door een LLM-gateway.

Beveiliging:

• geblokkeerde injectionpogingen, ongebruikelijke tool-aanroepen, bulkopvragingen van data, nieuwe bestemmingen voor uitgaand verkeer (zie verdediging tegen prompt injection).

Handmatige kwaliteitscontrole in contactcenters bekijkt doorgaans maar 1–2% van de gesprekken (AssemblyAI). Met geautomatiseerde beoordeling wordt het realistisch om elk gesprek te bekijken en alleen de gemarkeerde aan mensen voor te leggen. Een Nederlands aandachtspunt: beoordeel je daarbij ook gesprekken of gebruiksgegevens van je eigen medewerkers, dan heeft de ondernemingsraad instemmingsrecht op grond van artikel 27 WOR – neem dat vanaf het begin mee.

Wijzigingsbeheer: behandel AI-wijzigingen als releases

De meeste AI-incidenten zijn zelf veroorzaakt: een promptwijziging op vrijdagmiddag, een stapel nieuwe documenten die zonder controle is geïmporteerd, een model dat is gewisseld ‘omdat het goedkoper is’. De oplossing is saai en effectief:

1. Versiebeheer op alles: prompts, tooldefinities, retrieval-instellingen, model-ID’s vastgezet op exacte versies, snapshots van de kennisbank.
2. Elke wijziging door evals laten gaan. Geen release als kritieke kengetallen dalen.
3. Geleidelijk uitrollen. Schaduwmodus – de nieuwe versie antwoordt parallel en wordt alleen gelogd – of een canary op 5–10% van het verkeer vóór de volledige overstap.
4. Terugdraaien moet met één klik kunnen.
5. Modelupgrades plannen. Kondigt een aanbieder een nieuwe versie of uitfaseringsdatum aan, draai dan de volledige evalsuite, vergelijk kosten en latentie en plan de overstap. Wacht niet tot de deadline.
6. Geef de kennisbank een eigenaar en een kalender. Iemand vanuit de business is verantwoordelijk voor prijzen, beleid en productdata; wijzigingen bereiken de AI volgens een vast ritme, met een korte controle.

Incidentbeheer: als de AI het mis heeft

Vroeg of laat vertelt het systeem een klant iets wat niet klopt. Waar het om gaat, is hoe snel je het opmerkt, indamt en ervan leert:

• Ernstniveaus. Een onhandige zin is iets anders dan een verkeerde prijstoezegging of de gegevens van een andere klant in een antwoord.
• Noodschakelaar. Een manier om acties – terugbetalingen, boekingen, e-mails – uit te zetten terwijl informatieve antwoorden doorlopen, of om alles naar mensen te sturen.
• Overdracht aan mensen. Duidelijke escalatie bij lage zekerheid of als de klant om een mens vraagt.
• Evaluatie achteraf. Wat is er gebeurd, waarom hebben de evals het niet gezien, en welke nieuwe testcase beschermt er voortaan tegen?
• Juridische check. Zijn persoonsgegevens geraakt, dan geldt de meldplicht datalekken – binnen 72 uur bij de Autoriteit Persoonsgegevens. Controleer in de EU ook of de AI-melding die artikel 50 van de AI Act voorschrijft er stond.

De AI Ops-kalender

Een systeem overnemen dat al live is: de eerste 30 dagen

Veel bedrijven komen bij AI Ops met een systeem dat al in productie draait – gebouwd door een vorig bureau, een intern hackathonteam of een leverancier die verder is getrokken. Een praktisch overnameplan van 30 dagen:

1. Week 1 – inventarisatie en toegang. Verzamel alle prompts, workflows, koppelingen, API-sleutels en accounts bij aanbieders. Zet sleutels in een secrets-manager en zorg dat de accounts bij aanbieders van je bedrijf zijn, niet van het privémailadres van een freelancer. Leg vast welke modelversies daadwerkelijk draaien.
2. Week 2 – nulmeting. Zet tracing en kostenlogging aan als die ontbreken. Neem een steekproef van 100–200 recente gesprekken of documenten en beoordeel ze met de hand of met een gekalibreerde beoordelaar. Dit is je eerlijke ‘voor’-foto – vaak ontnuchterend.
3. Week 3 – vangnet. Bouw uit die steekproef een eerste evalset, inclusief de gevonden fouten. Voeg budgetalarmen, een noodschakelaar voor acties en een duidelijke overdracht aan mensen toe. Zet modelversies vast.
4. Week 4 – snelle winst en roadmap. Los de meest voorkomende foutoorzaken op – meestal verouderde kennis, een kapotte koppeling of een ontbrekende escalatieregel. Spreek daarna een maandritme af, een eigenaar aan beide kanten en de kengetallen die in elk rapport terugkomen.

Na 30 dagen weet je wat het systeem echt doet, wat het kost en waar het faalt – het vertrekpunt voor elke verbetering.

Wat AI Ops kost – en wie het moet doen

Marktijkpunten voor doorlopend AI-beheer:

Ter vergelijking: een senior AI-ontwikkelaar in loondienst kost inclusief bijkomende kosten zo’n $8.300 per maand (Lets-Viz) – en één persoon kan piketdienst, evals, koppelingen en compliance niet alleen dragen. Voor klassieke software wordt voor volledig onderhoud vaak 15–30% van de bouwkosten per jaar begroot (BPA Develop). AI-systemen zitten aan de bovenkant, omdat hun kwaliteit doorlopend opnieuw gemeten moet worden in plaats van alleen draaiende gehouden.

Wie moet het doen? Meestal een verdeling. Jouw team is eigenaar van de businesskant: inhoud van de kennisbank, beleid, afhandeling van escalaties en het laatste woord over wijzigingen. Een intern platformteam of een externe partner is eigenaar van monitoring, evals, modelupdates, kostenbeheersing en incidenten. Hoe je het ook verdeelt: leg het schriftelijk vast – reactietijden, wat als incident telt, welke kengetallen worden gerapporteerd en, als je per resultaat betaalt, wat precies als ‘opgelost’ geldt. De analisten van HFS verwachten dat juist die definitie het volgende grote strijdpunt in SLA’s wordt (HFS Research).

Veelgemaakte fouten

• Geen eigenaar aan de businesskant, waardoor de kennisbank vanaf dag één veroudert.
• Alleen beschikbaarheid monitoren. Het systeem staat op ‘groen’ terwijl de antwoorden slechter worden.
• Naar ‘latest’-aliassen verwijzen zonder bij elke wissel evals te draaien.
• Incidenten oplossen zonder testcases toe te voegen, waardoor dezelfde fout terugkomt.
• Geen budgetalarmen tot de factuur binnenkomt.
• Contracten zonder SLA-definities voor reactietijden en resultaten.
• AI Ops als optioneel zien en er als eerste op bezuinigen als het budget krap wordt – precies wanneer de drift begint te bijten.

Conclusie

Een AI-systeem lijkt meer op een nieuwe collega dan op een stuk software: het heeft inwerken, begeleiding, regelmatige feedback en updates nodig zodra het bedrijf verandert. AI Ops maakt daar routine van – monitoring, evals, kostenbeheersing, gedisciplineerde releases en een rustige aanpak van incidenten. Begroot het vanaf het begin, wijs duidelijke eigenaren aan, en je AI is in maand twaalf beter dan in maand één in plaats van stilletjes slechter. Is je project nooit zo ver gekomen? Lees dan waarom AI-pilots vastlopen en hoe je naar productie komt.

Ons Systems-team verzorgt AI Ops voor service-, spraak- en documentagents – monitoring, maandelijkse evals, kostenrapporten en modelupgrades, met je data in je eigen accounts. Plan een gratis audit van 15 minuten en we controleren de gezondheid van je AI-systeem en laten zien welke drie dingen je als eerste moet aanpakken.