FinOps voor AI: wie krijgt de factuur na de livegang?

FinOps voor AI is kostendiscipline voor de lopende rekening van een AI-systeem: de uitgaven zichtbaar maken, ze aan een eigenaar toewijzen en ze uitdrukken in een eenheid die de organisatie herkent. In de organisaties waarmee ik werk, is het rekenwerk het makkelijke deel. Het lastige is om vóór de livegang te besluiten wie de factuur krijgt. Zodra een AI-systeem draait, komt de rekening ergens binnen, en meestal op een plek die niemand heeft gekozen.

Ik schrijf dit voor degene die straks vragen over die factuur krijgt: de IT-manager, informatiemanager of CIO van een organisatie met 250 tot 5.000 medewerkers, met al een ICT-partner of een eigen IT-afdeling en een gespecialiseerde AI-leverancier op komst. Mijn bedrijf is zo'n leverancier. Wij bouwen AI-systemen; uw infrastructuur en uw cloudcontract beheren wij niet. Vanuit die positie zie ik van dichtbij een moment dat de meeste projecten slecht regelen: de eerste maand na de livegang, als de bouwfactuur betaald is en de verbruiksrekening begint binnen te komen.

Waarom past de lopende kostenpost van AI niet in een IT-begroting?

De meeste IT-begrotingen in organisaties van deze omvang bestaan uit posten die zich netjes gedragen. Licenties per gebruiker. Onderhoudscontracten per jaar. Hardware die over een vast aantal jaren wordt afgeschreven. Zelfs de publieke cloud, die dat patroon tien jaar geleden doorbrak, is inmiddels bij de meeste IT-afdelingen getemd met gereserveerde capaciteit, tags en een maandelijkse review.

De lopende kosten van een AI-systeem doorbreken dat patroon opnieuw, en wel op drie manieren tegelijk.

• Ze worden gefactureerd per verbruikseenheid die uw financiële administratie nooit eerder heeft gezien. Modelaanbieders rekenen per token, en een token zegt een controller niets.
• Ze bewegen mee met gedrag in plaats van met het aantal medewerkers. Hetzelfde systeem kost meer in een maand met langere documenten, meer uitzonderingen of een agent die bij elke stap veel meer context meeneemt dan de taak vraagt.
• Ze komen vaak terecht in een cloudabonnement dat de ICT-partner beheert, op een kostenplaats die voor infrastructuur is aangemaakt. Wie de piek ziet, is dan niet degene die hem veroorzaakt en ook niet degene die er iets aan kan veranderen.

Over de prijs is niets geheimzinnigs. Tarieven worden gepubliceerd. Wat niemand vooraf weet, is het volume: hoeveel dossiers, hoe lang elk dossier is, hoe vaak een stap opnieuw wordt geprobeerd, hoeveel context elke aanroep meekrijgt. Dat bepaalt de rekening, en juist die variabele wordt in de meeste businesscases niet ingevuld.

De discipline die dit oppakt, bestaat al. De zesde State of FinOps-enquête van de FinOps Foundation, gepubliceerd in februari 2026, meldt dat 98% van de 1.192 respondenten inmiddels AI-uitgaven beheert, tegen 31% twee jaar eerder. Lees dat cijfer zorgvuldig. Het is een enquête onder FinOps-specialisten, dus het laat zien dat AI-kosten een vast onderdeel zijn geworden van het werk in organisaties die al een FinOps-team hebben. Of uw organisatie zo'n team heeft, zegt het niet. Bij de middelgrote organisaties die ik spreek, is het eerlijke antwoord meestal dat één controller en één cloudengineer het naast hun andere werk doen.

Wat leerde het prijsplafond van 2023 over het begrenzen van een rekening?

Iedereen in Nederland herinnert zich het prijsplafond. Heel 2023 betaalden huishoudens en andere kleinverbruikers maximaal € 0,40 per kWh stroom tot 2.900 kWh en maximaal € 1,45 per m³ gas tot 1.200 m³. Boven die volumes betaalde u, zoals het kabinet in december 2022 bekendmaakte, het tarief uit uw eigen energiecontract. In hetzelfde bericht verwachtte het kabinet dat 50 tot 60 procent van de huishoudens met het volledige verbruik onder het plafond zou blijven. Het verwachtte dus ook dat de rest dat niet zou doen.

Dat is de eerste les, en die is één op één over te nemen. Een plafond op de prijs is geen plafond op de rekening. Het contract met een modelaanbieder, of het tarief dat uw leverancier noemt, legt de prijs per eenheid vast. Over het aantal eenheden zegt het niets. Ik heb in overleggen gezeten waarin de kosten van een AI-systeem als beheerst golden omdat er een lagere tokenprijs was bedongen, terwijl niemand aan tafel kon zeggen hoeveel documenten het systeem in een drukke maand zou lezen.

De tweede les is minder voor de hand liggend en bruikbaarder. Het verbruiksplafond werd niet gelijk over het jaar verdeeld. Omdat de meeste huishoudens in de winter veel meer gas stoken, werkte de regeling met dagvolumes: in de eerste en laatste maanden van het jaar mocht u een groter deel van het plafond verbruiken, in de maanden daartussen minder. Radar rekende uit wat dat per maand betekende en wees erop dat u binnen het jaartotaal kon blijven en er in één periode toch overheen kon gaan.

Een AI-budget dat in twaalf gelijke maandbedragen wordt opgedeeld, maakt de fout die de regeling juist vermeed. Een systeem voor factuurverwerking piekt aan het eind van de maand en nog sterker aan het eind van het jaar. Een klantenservice-agent piekt na een vakantie en na elke productwijziging. Een assistent die aanbestedingen leest, volgt de aanbestedingskalender. Is de maandelijkse begrotingsregel het jaarbedrag gedeeld door twaalf, dan gaat het alarm af in precies de maanden waarin het systeem zijn waardevolste werk doet, en komt iemand in de verleiding het systeem uit te zetten.

De vergelijking heeft grenzen, en die wil ik benoemen. Energie was een eerste levensbehoefte, en een huishouden kon zijn verbruik maar tot op zekere hoogte terugschroeven. Het verbruik van een AI-systeem is een ontwerpkeuze: welk model, hoeveel context, wanneer stoppen, wanneer een dossier naar een mens gaat. Dat is het goede nieuws. Het volume dat de rekening bepaalt, is veel beter te sturen dan een koude februarimaand. Een opmerking voor Vlaamse lezers: het prijsplafond was een Nederlandse regeling, en België heeft dezelfde energiecrisis met eigen maatregelen aangepakt. Dit is dus een Nederlandse herinnering, geen gedeelde herinnering.

Wie krijgt de factuur van een AI-systeem?

Kosten toewijzen begint met een simpele vraag: wie betaalt de lopende rekening? In de praktijk komt die op een van drie plekken terecht.

• Op het account van de leverancier. De leverancier heeft het contract met de modelaanbieder en belast de kosten door, soms met een marge, meestal als één regel op een maandfactuur. Makkelijk om mee te beginnen, maar u verliest het zicht op wat het bedrag bepaalt.
• In het abonnement van de ICT-partner. De kosten zijn technisch zichtbaar, maar voor de partij die het systeem niet heeft gebouwd en niets te zeggen heeft over hoe het zich gedraagt. Het alarm gaat naar een mailbox, en die mailbox is van iemand die over beschikbaarheid gaat.

• In uw eigen tenant, onder uw eigen overeenkomst met de modelaanbieder of uw bestaande cloudcontract, getagd per systeem en toegewezen aan een budgethouder binnen uw organisatie.

Ik vind dat de rekening op de derde plek hoort, en dat zeg ik in het eerste gesprek, ook al worden de facturen van mijn eigen bedrijf daar kleiner en eenvoudiger van. De redenen zijn praktisch. U ziet het ruwe verbruik in plaats van een samenvatting ervan. Niemand verdient een marge op volume, dus niemand heeft er stilletjes belang bij dat het volume stijgt. En het account hoort bij uw exitstrategie: in de AI-capaciteit die u niet moet uitbesteden betoogde ik dat wie de evaluatieset in handen heeft, van leverancier kan wisselen. Wie het modelaccount in handen heeft, kan wisselen zonder eerst een migratieproject te starten.

De budgethouder hoort de eigenaar te zijn van het proces dat het systeem ondersteunt: het hoofd financiën bij factuurverwerking, het hoofd klantenservice bij de service-agent. IT hoort de uitgaven te zien en de technische maatregelen te beheren, omdat IT daar om twee uur 's nachts op kan ingrijpen. Die verdeling volgt wat de meeste organisaties al doen bij een bedrijfsapplicatie. Wat in elk geval niet werkt, is een kostenpost zonder budgethouder, geparkeerd op een infrastructuurkostenplaats tot hij bij de jaarlijkse review boven water komt.

Er is een redelijk argument om op het account van de leverancier te beginnen. In een pilot kan de goedkeuring van een nieuwe cloudresource langer duren dan de pilot zelf. Daar heb ik geen bezwaar tegen, mits er een datum op papier staat waarop het account naar u overgaat, en de leverancier in de tussentijd het ruwe maandelijkse verbruiksoverzicht stuurt in plaats van één factuurregel.

Moet Financiën tokens of dossiers zien?

Tokens zijn voor engineers. Een controller kan niet beoordelen of 40 miljoen tokens in maart veel of weinig was, en hoeft dat ook niet te kunnen. Wat een controller wel kan beoordelen, zijn de kosten per verwerkte factuur, per beantwoord ticket of per afgehandeld dossier, afgezet tegen wat hetzelfde dossier kost als een medewerker het afhandelt. Dat getal vertelt u of het systeem het draaien waard is, en het is dezelfde eenheid waarmee u de pilot had moeten beoordelen. Heeft u dat niet gedaan, dan begint het meten van AI-rendement op dezelfde plek.

Dat getal komt niet uit een rapport; het moet in het systeem worden gebouwd. De cloudkant van de rekening wordt gestandaardiseerd: de FinOps Foundation meldt in hetzelfde persbericht dat alle grote cloudaanbieders inmiddels zelf data leveren in FOCUS, haar open formaat voor kosten en verbruik. Dat geeft u kosten per resource. Kosten per dossier geeft het niet, want één modeldeployment bedient vaak meerdere toepassingen, en een resourcetag kan die niet uit elkaar houden. Het systeem zelf moet elke modelaanroep labelen met de toepassing en het dossier waar hij bij hoort, en dat wegschrijven naar een log dat uw controller kan lezen. Laat u een AI-systeem bouwen, zet dat dan in de specificatie. Het achteraf toevoegen betekent dat elke aanroep in het systeem moet worden aangepast.

Rapporteer de kosten per dossier als mediaan en staart, niet als gemiddelde. De meeste dossiers kosten weinig. Een paar kosten heel veel: het contract van 300 pagina's, de mailwisseling met veertig bijlagen, het dossier waarbij de agent het zes keer opnieuw probeerde. Het gemiddelde verbergt beide, en juist in de staart leveren ontwerpkeuzes iets op. Een regel die elk dossier boven een bepaalde omvang naar een mens stuurt, of eerst door een kleiner model laat lezen, doet vaak meer voor de rekening dan welke korting op het tarief ook.

Showback of doorbelasting: waar begint een IT-organisatie?

De gebruikelijke volgorde in cloudkostenbeheer loopt van showback, waarbij elk team ziet wat het verbruikt zonder ervoor te betalen, naar doorbelasting, waarbij de kosten op het budget van de verbruikende afdeling worden geboekt. Bij AI zou ik de eerste stap langer aanhouden dan de meeste organisaties willen.

Een afdeling laten betalen voor kosten waar zij geen invloed op heeft, levert discussie op en geen besparing. In de eerste maanden na de livegang bewegen de kosten per dossier om redenen waar de proceseigenaar niet over gaat: de leverancier stelt een prompt bij, de ICT-partner verandert een logginginstelling, er komt een nieuwe modelversie uit. Laat de cijfers elke maand zien, met de kosten per dossier en het volume naast elkaar, tot beide gedurende minstens één volledige bedrijfscyclus stabiel zijn gebleven, de piek inbegrepen. Ga daarna over op doorbelasting, en alleen voor het deel van de kosten dat het eigen volume van de afdeling volgt.

Stel naast de showback een maandplafond in, met een alarm dat al afgaat voordat het plafond bereikt is. In wie er wordt gebeld als de AI het begeeft noemde ik een kostenpiek een van de vier soorten AI-incidenten en legde ik die bij IT, met een plafond dat vóór de livegang is afgesproken. Dit is de andere helft van dat besluit: wat het systeem doet als het plafond bereikt is.

Een harde stop legt een bedrijfsproces stil, en het is een factuurdrempel die daarover beslist. Soms is dat terecht. Vaker is het beter om terug te schakelen: overstappen op een kleiner model, de optionele stappen overslaan, of nieuwe dossiers tot de volgende periode bij een medewerker in de wachtrij zetten. Elk van die opties moet vooraf worden gebouwd. Besluit dus welke u wilt voordat het systeem wordt ontworpen, niet als het alarm afgaat.

Wat moet er in het leverancierscontract staan over lopende kosten?

De meeste AI-contracten die ik zie, beschrijven de bouw uitvoerig en de lopende kosten in één zin. Dit zijn de punten die ik op papier zou willen hebben, welke leverancier u ook kiest.

• Op wiens account het modelverbruik draait, en wie aan het eind van het contract eigenaar is van dat account.
• Een raming van de lopende kosten per dossier, met de aannames erbij: maandvolume, gebruikelijke documentlengte, het aandeel dossiers dat naar verwachting meer dan één ronde nodig heeft.
• Een maandelijks verbruiksoverzicht in een formaat dat uw controller of FinOps-verantwoordelijke kan inlezen, gelabeld per toepassing.
• Wie het model, de prompt of de contextomvang mag wijzigen, want elk daarvan verandert de kosten per dossier, en de afspraak dat zo'n wijziging net als elke andere door uw wijzigingsproces gaat.
• Wat het systeem doet bij het budgetplafond: stoppen, terugschakelen of in de wachtrij zetten voor een medewerker.
• Of de leverancier een marge rekent op doorbelast verbruik, en zo ja, hoeveel.

Niets hiervan is exotisch, en elk punt is vóór ondertekening eenvoudig af te spreken. Achteraf is elk ervan duur. Wat de bouwkant van hetzelfde budget bepaalt, leest u bij de bouw- en exploitatiekosten van maatwerk-AI.

Wat ik een IT-manager in het eerste gesprek vertel

De vraag in het eerste gesprek is zelden wat het draaien van het systeem kost. De vraag is waar de factuur binnenkomt en wie het bedrag erop kan veranderen. Is het antwoord een kostenplaats waar niemand eigenaar van is en een leverancier bij wie niemand kan meekijken, dan heeft het project een probleem dat geen tarief oplost.

Daarom vraag ik om drie dingen voordat we iets ontwerpen. Een budgethouder uit de organisatie, met naam. Een account in uw tenant, of een datum waarop het daarheen verhuist. En de eenheid waarop u het systeem gaat beoordelen, op papier gezet als dossier en niet als token. Staan die drie, dan is de rest van FinOps voor AI dezelfde discipline die uw organisatie al op de cloud toepast, uitgebreid tot een rekening die met gedrag meebeweegt. Ontbreken ze, dan wordt de eerste maand na de livegang een zoektocht naar degene die eigenaar is van de piek. Op dat raakvlak werken wij, naast uw IT-afdeling en uw ICT-partner: zie AI-implementatie voor middelgrote organisaties.

Veelgestelde vragen