Dit artikel zet uiteen wat elke post werkelijk waard is, waar de schattingen in beide richtingen misgaan, en wat er in een beheerafspraak hoort zodat de doorlopende verplichting zichtbaar is voordat je voor de bouw tekent.<\/p>\n\n\n\n
Waarom gaan schattingen van beheerkosten mis?<\/h2>\n\n\n\n
Omdat twee van de vier posten in tegengestelde richting verkeerd worden ingeschat, en die fouten heffen elkaar niet op.<\/p>\n\n\n\n
Infrastructuur wordt overschat. Bij een recent project had de klant ongeveer tweehonderd euro per maand begroot voor de Azure-onderdelen, terwijl onze engineer dichter bij zestig uitkwam omdat de verwerking event-gedreven was in plaats van doorlopend draaiend. Dat verschil is geen onderhandeling maar architectuur: een workflow die wakker wordt zodra er een document binnenkomt verbruikt een fractie van een dienst die de hele dag staat te pollen. Niemand had iets fout gedaan, ze hadden simpelweg de vorm begroot die ze gewend waren.<\/p>\n\n\n\n
Onderhoud wordt onderschat, meestal tot nul. De aanname is dat een afgerond systeem af is, en AI-systemen zijn minder af dan de meeste software omdat hun invoer blijft bewegen. Een leverancier past een factuurindeling aan, een bronsysteem krijgt een upgrade, een regel wijzigt, er verschijnt een nieuw documenttype in een stroom die een jaar lang stabiel was. Geen van die dingen is een fout en allemaal kosten ze werk.<\/p>\n\n\n\n
Er is nog een derde patroon dat lastiger te zien is. De kosten die pas bij de oplevering opduiken, zoals hosting, inloggegevens en toegang tot de repository, horen in de meeste contracten bij noch de bouw noch het beheer, en blijven daardoor zonder eigenaar tot iemand ze nodig heeft.<\/p>\n\n\n\n
Welke vier kostenposten zijn er?<\/h2>\n\n\n\n![\"\"](\"https:\/\/datanorth.ai\/wp-content\/uploads\/2026\/09\/waar-de-beheerkosten-van-een-ai-systeem-na-livegang-in-zitten.png\")
<\/figure>\n\n\n\n\n- Cloud- en modelverbruik<\/strong> is de post waar iedereen als eerste aan denkt en meestal de kleinste. De belangrijkste variabele is niet volume maar architectuur. Event-gedreven verwerking, waarbij de workflow wordt getriggerd door een binnenkomend document of bericht, is goedkoop omdat er tussen gebeurtenissen niets draait. Doorlopend beschikbare diensten kosten aanzienlijk meer, en rekenintensieve taken ook. Een routeoptimalisatie die een half uur staat te rekenen heeft een ander kostenprofiel dan een documentclassificatie, en het loont om te weten welke van de twee je bouwt.<\/li>\n\n\n\n
- Onderhoudsuren<\/strong> is bij de meeste systemen de dominante post. Die dekt wijzigingen die van buiten komen, kleine verbeteringen die uit het gebruik voortkomen, en het incidentele incident. Een werkbare planningsaanname is een bescheiden aantal engineeringuren per maand tegen een normaal tarief. Ter ori\u00ebntatie: een senior engineeringuur ligt in de Nederlandse markt rond de honderdvijftig euro, dus zelfs een paar uur per maand is een groter bedrag dan de infrastructuurpost.<\/li>\n\n\n\n
- Eigenaarschap en co\u00f6rdinatie<\/strong> is echt werk dat zelden in een begroting staat. Iemand moet beslissen wat er gebeurt zodra er een patroon in de uitzonderingen zichtbaar wordt, wijzigingsverzoeken prioriteren en beoordelen of de kwaliteit van de uitkomst nog klopt. Als vuistregel rekenen wij ongeveer tien procent van de ontwikkelinspanning voor projectmanagement tijdens een bouw, en iets in die orde geldt daarna voor de kleinere maar doorlopende taak van dingen beslissen.<\/li>\n\n\n\n
- Hertraining en evaluatie<\/strong> speelt alleen wanneer er daadwerkelijk een model op jouw data getraind is. Prompt-gebaseerde oplossingen op een algemeen model hertrainen niet, al hebben ze wel opnieuw evaluatie nodig zodra de onderliggende modelversie verandert, en dat is een echte gebeurtenis met echte gevolgen. Waar wel een getraind model in zit, is de cyclus van hertrainen, evalueren en opnieuw uitrollen terugkerend werk dat ergens moet landen, en het bouwen van die pijplijn hoort bij naar productie gaan in plaats van erna.<\/li>\n<\/ul>\n\n\n\n
Hoe schat je dit voordat er iets draait?<\/h2>\n\n\n\n
Begin bij de vorm van het systeem in plaats van bij een percentage van de bouwkosten, want de verhouding tussen bouwen en beheren varieert enorm. Drie vragen brengen je een heel eind.<\/p>\n\n\n\n
\n- Wacht het systeem op gebeurtenissen of draait het doorlopend?<\/li>\n\n\n\n
- Hangt het af van externe formaten die anderen beheren, zoals leveranciersdocumenten of partnersystemen?<\/li>\n\n\n\n
- En zit er een model in dat op jouw eigen data getraind is?<\/li>\n<\/ul>\n\n\n\n
Een ja op de eerste en nee op de andere twee beschrijft het goedkoopst mogelijke profiel. Een nee, ja, ja beschrijft iets dat je fatsoenlijk moet begroten.<\/p>\n\n\n\n
Volume telt minder mee dan mensen verwachten zodra de architectuur vaststaat. Een proces met enkele honderden documenten per week en een met enkele duizenden zitten vaak in dezelfde kostenklasse, omdat de vaste kosten domineren en de kosten per stuk klein zijn. Dat is de moeite waard om vroeg te controleren, want volumeangst houdt soms projecten tegen die prima betaalbaar waren.<\/p>\n\n\n\n
E\u00e9n post schaalt wel degelijk mee: de menselijke controlestap. Controleert iemand een deel van de uitkomst, dan is dat deel een beheerkost in loonkosten, en die overtreft doorgaans alle andere posten samen. De controlestap zo ontwerpen dat hij krimpt naarmate het vertrouwen groeit, is daarom net zozeer een kostenbeslissing als een kwaliteitsbeslissing.<\/p>\n\n\n\n
Wat hoort er in een beheerafspraak?<\/h2>\n\n\n\n
Vijf dingen, en het vijfde is het onderdeel dat problemen geeft wanneer het ontbreekt.<\/p>\n\n\n\n
\n- De reikwijdte van gedekte wijzigingen, geformuleerd als categorie\u00ebn en niet als lijst, zodat “leverancier past zijn indeling aan” er duidelijk in zit en “een tweede taal toevoegen” er duidelijk buiten valt.<\/li>\n\n\n\n
- Een reactietijd bij incidenten, met een definitie van wat als incident telt.<\/li>\n\n\n\n
- Wie een verzoek mag indienen, want een open kanaal wordt een onbeheerde wachtrij.<\/li>\n\n\n\n
- Een maandelijkse urenruimte met een tarief voor alles daarboven.<\/li>\n\n\n\n
- En of model- en infrastructuurverbruik wordt doorbelast of inbegrepen is, wat de grootste bron van discussie is juist omdat het de post is waar tijdens de bouw niemand over sprak.<\/li>\n<\/ol>\n\n\n\n
Het is opmerkelijk dat beheerafspraken een vrij recente toevoeging zijn aan AI-werk. In ons eigen voorstellenarchief duiken ze pas in 2026 op, naast implementatietrajecten, en die opkomst is een redelijk signaal dat de markt voorbij het experimenteren is. Een klant die naar beschikbaarheid vraagt, is een klant die van plan is erop te gaan leunen.<\/p>\n\n\n\n
Welke kosten duiken pas bij de oplevering op?<\/h2>\n\n\n\n
Drie, en elk ervan is vooraf goedkoop te regelen en achteraf ongemakkelijk.<\/p>\n\n\n\n
\n- Hosting is de eerste. Een oplossing die als broncode wordt overgedragen verhuist naar de eigen infrastructuur van de klant, wat betekent dat iemand hem daar moet draaien, en dat is een andere afspraak dan het bouwcontract. Het kan beide kanten op geregeld worden, maar het gat in aannames is echt: de leverancier gaat ervan uit dat de klant host, de klant gaat ervan uit dat hosting inbegrepen was.<\/li>\n\n\n\n
- Repositoryhistorie en logs zijn de tweede. Die vallen vaak buiten de standaard projectscope, ook bij ons, en niemand denkt eraan te vragen tot een audit of een storingsanalyse ze nodig heeft. Dit v\u00f3\u00f3r de eindfactuur beslissen kost niets.<\/li>\n\n\n\n
- Inloggegevens en toegang zijn de derde. Een applicatie waar niemand in kan is niet echt overgedragen, en serviceaccounts die tijdens de ontwikkeling zijn aangemaakt hebben de neiging te horen bij degene die ze aanmaakte.<\/li>\n<\/ol>\n\n\n\n
De bruikbare toets voor alle drie is of een vakbekwame engineer die het systeem nooit heeft gezien het kan uitrollen, draaien en een veelvoorkomende storing verhelpen met alleen wat er is overgedragen. Vergt dat een telefoontje, dan is de oplevering onvolledig en zijn de kosten van dat telefoontje zojuist iemands probleem geworden.<\/p>\n\n\n\n
Hoe past dit in het grotere beeld?<\/h2>\n\n\n\n
<\/figure>\n\n\n\n- \n
- Cloud- en modelverbruik<\/strong> is de post waar iedereen als eerste aan denkt en meestal de kleinste. De belangrijkste variabele is niet volume maar architectuur. Event-gedreven verwerking, waarbij de workflow wordt getriggerd door een binnenkomend document of bericht, is goedkoop omdat er tussen gebeurtenissen niets draait. Doorlopend beschikbare diensten kosten aanzienlijk meer, en rekenintensieve taken ook. Een routeoptimalisatie die een half uur staat te rekenen heeft een ander kostenprofiel dan een documentclassificatie, en het loont om te weten welke van de twee je bouwt.<\/li>\n\n\n\n
- Onderhoudsuren<\/strong> is bij de meeste systemen de dominante post. Die dekt wijzigingen die van buiten komen, kleine verbeteringen die uit het gebruik voortkomen, en het incidentele incident. Een werkbare planningsaanname is een bescheiden aantal engineeringuren per maand tegen een normaal tarief. Ter ori\u00ebntatie: een senior engineeringuur ligt in de Nederlandse markt rond de honderdvijftig euro, dus zelfs een paar uur per maand is een groter bedrag dan de infrastructuurpost.<\/li>\n\n\n\n
- Eigenaarschap en co\u00f6rdinatie<\/strong> is echt werk dat zelden in een begroting staat. Iemand moet beslissen wat er gebeurt zodra er een patroon in de uitzonderingen zichtbaar wordt, wijzigingsverzoeken prioriteren en beoordelen of de kwaliteit van de uitkomst nog klopt. Als vuistregel rekenen wij ongeveer tien procent van de ontwikkelinspanning voor projectmanagement tijdens een bouw, en iets in die orde geldt daarna voor de kleinere maar doorlopende taak van dingen beslissen.<\/li>\n\n\n\n
- Hertraining en evaluatie<\/strong> speelt alleen wanneer er daadwerkelijk een model op jouw data getraind is. Prompt-gebaseerde oplossingen op een algemeen model hertrainen niet, al hebben ze wel opnieuw evaluatie nodig zodra de onderliggende modelversie verandert, en dat is een echte gebeurtenis met echte gevolgen. Waar wel een getraind model in zit, is de cyclus van hertrainen, evalueren en opnieuw uitrollen terugkerend werk dat ergens moet landen, en het bouwen van die pijplijn hoort bij naar productie gaan in plaats van erna.<\/li>\n<\/ul>\n\n\n\n
Hoe schat je dit voordat er iets draait?<\/h2>\n\n\n\n
Begin bij de vorm van het systeem in plaats van bij een percentage van de bouwkosten, want de verhouding tussen bouwen en beheren varieert enorm. Drie vragen brengen je een heel eind.<\/p>\n\n\n\n
- \n
- Wacht het systeem op gebeurtenissen of draait het doorlopend?<\/li>\n\n\n\n
- Hangt het af van externe formaten die anderen beheren, zoals leveranciersdocumenten of partnersystemen?<\/li>\n\n\n\n
- En zit er een model in dat op jouw eigen data getraind is?<\/li>\n<\/ul>\n\n\n\n
Een ja op de eerste en nee op de andere twee beschrijft het goedkoopst mogelijke profiel. Een nee, ja, ja beschrijft iets dat je fatsoenlijk moet begroten.<\/p>\n\n\n\n
Volume telt minder mee dan mensen verwachten zodra de architectuur vaststaat. Een proces met enkele honderden documenten per week en een met enkele duizenden zitten vaak in dezelfde kostenklasse, omdat de vaste kosten domineren en de kosten per stuk klein zijn. Dat is de moeite waard om vroeg te controleren, want volumeangst houdt soms projecten tegen die prima betaalbaar waren.<\/p>\n\n\n\n
E\u00e9n post schaalt wel degelijk mee: de menselijke controlestap. Controleert iemand een deel van de uitkomst, dan is dat deel een beheerkost in loonkosten, en die overtreft doorgaans alle andere posten samen. De controlestap zo ontwerpen dat hij krimpt naarmate het vertrouwen groeit, is daarom net zozeer een kostenbeslissing als een kwaliteitsbeslissing.<\/p>\n\n\n\n
Wat hoort er in een beheerafspraak?<\/h2>\n\n\n\n
Vijf dingen, en het vijfde is het onderdeel dat problemen geeft wanneer het ontbreekt.<\/p>\n\n\n\n
- \n
- De reikwijdte van gedekte wijzigingen, geformuleerd als categorie\u00ebn en niet als lijst, zodat “leverancier past zijn indeling aan” er duidelijk in zit en “een tweede taal toevoegen” er duidelijk buiten valt.<\/li>\n\n\n\n
- Een reactietijd bij incidenten, met een definitie van wat als incident telt.<\/li>\n\n\n\n
- Wie een verzoek mag indienen, want een open kanaal wordt een onbeheerde wachtrij.<\/li>\n\n\n\n
- Een maandelijkse urenruimte met een tarief voor alles daarboven.<\/li>\n\n\n\n
- En of model- en infrastructuurverbruik wordt doorbelast of inbegrepen is, wat de grootste bron van discussie is juist omdat het de post is waar tijdens de bouw niemand over sprak.<\/li>\n<\/ol>\n\n\n\n
Het is opmerkelijk dat beheerafspraken een vrij recente toevoeging zijn aan AI-werk. In ons eigen voorstellenarchief duiken ze pas in 2026 op, naast implementatietrajecten, en die opkomst is een redelijk signaal dat de markt voorbij het experimenteren is. Een klant die naar beschikbaarheid vraagt, is een klant die van plan is erop te gaan leunen.<\/p>\n\n\n\n
Welke kosten duiken pas bij de oplevering op?<\/h2>\n\n\n\n
Drie, en elk ervan is vooraf goedkoop te regelen en achteraf ongemakkelijk.<\/p>\n\n\n\n
- \n
- Hosting is de eerste. Een oplossing die als broncode wordt overgedragen verhuist naar de eigen infrastructuur van de klant, wat betekent dat iemand hem daar moet draaien, en dat is een andere afspraak dan het bouwcontract. Het kan beide kanten op geregeld worden, maar het gat in aannames is echt: de leverancier gaat ervan uit dat de klant host, de klant gaat ervan uit dat hosting inbegrepen was.<\/li>\n\n\n\n
- Repositoryhistorie en logs zijn de tweede. Die vallen vaak buiten de standaard projectscope, ook bij ons, en niemand denkt eraan te vragen tot een audit of een storingsanalyse ze nodig heeft. Dit v\u00f3\u00f3r de eindfactuur beslissen kost niets.<\/li>\n\n\n\n
- Inloggegevens en toegang zijn de derde. Een applicatie waar niemand in kan is niet echt overgedragen, en serviceaccounts die tijdens de ontwikkeling zijn aangemaakt hebben de neiging te horen bij degene die ze aanmaakte.<\/li>\n<\/ol>\n\n\n\n
De bruikbare toets voor alle drie is of een vakbekwame engineer die het systeem nooit heeft gezien het kan uitrollen, draaien en een veelvoorkomende storing verhelpen met alleen wat er is overgedragen. Vergt dat een telefoontje, dan is de oplevering onvolledig en zijn de kosten van dat telefoontje zojuist iemands probleem geworden.<\/p>\n\n\n\n
Hoe past dit in het grotere beeld?<\/h2>\n\n\n\n
- Onderhoudsuren<\/strong> is bij de meeste systemen de dominante post. Die dekt wijzigingen die van buiten komen, kleine verbeteringen die uit het gebruik voortkomen, en het incidentele incident. Een werkbare planningsaanname is een bescheiden aantal engineeringuren per maand tegen een normaal tarief. Ter ori\u00ebntatie: een senior engineeringuur ligt in de Nederlandse markt rond de honderdvijftig euro, dus zelfs een paar uur per maand is een groter bedrag dan de infrastructuurpost.<\/li>\n\n\n\n