Contracten voor AI-agentservices: 9 clausules om af te spreken voordat je in 2026 tekent

De meeste AI-agentprojecten falen niet door het model. Ze falen door een document dat drie maanden voordat er ook maar één regel code werd geschreven, al was ondertekend.

Wij bouwen voor ons werk AI-agents, waardoor we aan de andere kant van deze contracten staan. We hebben de werkomschrijvingen ondertekend die eindigen met een systeem dat geruisloos in productie draait, en we hebben de projecten gezien die eindigen in een geschil over de vraag of het ding wel werkt. Het verschil zit bijna nooit in de keuze van het model. Het zit in de vraag of iemand heeft opgeschreven wat 'werken' precies betekent, wie de evaluatieset bezit, wie betaalt als de inferentiekosten verdrievoudigen en wat er gebeurt op de dag dat het gekozen model wordt uitgefaseerd.

Gartner verwacht dat meer dan 40% van de agentic AI-projecten tegen eind 2027 zal worden geannuleerd, vanwege stijgende kosten, onduidelijke bedrijfswaarde en ontoereikende risicobeheersing, aldus hun voorspelling van juni 2025. Lees die lijst nog eens. Geen van die drie is een machine learning-probleem. Alle drie zijn zaken die in een contract kunnen worden vastgelegd voordat de bouw begint.

Dit artikel is bedoeld voor oprichters, CTO's en operationeel leiders die een voorstel voor AI-agentdiensten op hun bureau hebben liggen en willen dat de samenwerking eindigt in productie in plaats van in een demo. Je krijgt de 9 clausules die de uitkomst bepalen, hoe een eerlijke versie van elk daarvan eruitziet, hoe je de betalingen spreidt zodat het risico wordt gedeeld, en de 5 vragen die onthullen of een leverancier daadwerkelijk een agent in productie heeft draaien. Als je nog aan het beslissen bent of AI-agents relevant zijn voor jouw bedrijf, dan is dit niet het artikel voor jou. Als je op het punt staat te tekenen, dan wel.

De verandering waar je naar moet streven is simpel. Je gaat van een vaag pilotproject dat een gepolijste demo oplevert waar je zelf niets aan hebt, naar een getekende scope waarbij de agent een afgesproken score moet behalen op je eigen data, binnen je eigen systemen, met de prompts en de evaluatieset op jouw naam.

‍

Belangrijkste inzichten

• De meeste AI-agentprojecten falen door de scope en acceptatievoorwaarden, niet door de kwaliteit van het model.

• Acceptatie moet een gemeten slagingspercentage zijn op een bevroren set van jouw eigen praktijkgevallen, waarover overeenstemming is bereikt voordat de ontwikkeling begint.

• Jij moet eigenaar zijn van de systeemprompts, de orchestratiecode, de evaluatieset, de gouden antwoorden en de logs, niet alleen van de output.

• Het uitfaseren van modellen is een gepland evenement, dus het contract moet een clausule bevatten voor herkwalificatie en hertesten.

• Inferentiekosten horen in het contract thuis, met een aangenomen volume en een mechanisme voor wanneer dat volume verandert.

• Autonomielimieten, escalatie en rollback zijn commerciële voorwaarden, geen technische voorkeuren.

• Onder de EU AI Act hebben de bouwer en de koper meestal verschillende rollen, en het contract moet benoemen wie welke rol vervult.

• Een leverancier die geen nauwkeurigheidscijfer op jouw data wil garanderen, geeft je gratis nuttige informatie.

‍

Waarom AI-agentprojecten falen in het contract, niet in de code

AI-agentprojecten mislukken omdat het contract de inspanning meet in plaats van het resultaat, en omdat niemand vooraf heeft afgesproken hoe een voltooide agent eruitziet.

Dit patroon herhaalt zich bijna woord voor woord in alle sectoren. Een logistiek bedrijf tekent een overeenkomst voor 12 weken voor een agent die inkomende e-mails met bestellingen moet afhandelen. In week 10 werkt de demo uitstekend op 20 zorgvuldig gekozen berichten. In week 14 bereikt het systeem het operatieteam en binnen enkele dagen merkt iemand op dat het stilletjes leveringsvensters in gescande pdf's verkeerd leest. Niemand had opgeschreven welke documenttypen binnen de scope vielen. Niemand was een streefnauwkeurigheid overeengekomen. Niemand had gezegd wie de extra 6 weken werk betaalt. De leverancier vindt dat de opdracht is opgeleverd omdat de demo slaagde. De klant vindt dat het systeem kapot is omdat een medewerker nog steeds elk bericht moet controleren. Onder het contract dat daadwerkelijk is getekend, hebben ze allebei gelijk.

Traditionele softwarecontracten werken omdat het resultaat deterministisch is. Een functie toont de factuurlijst wel of niet, dus acceptatie kan een checklist zijn die voor iedereen hetzelfde betekent. Een agent is probabilistisch. Hij haalt in 94% van de gevallen het juiste leveringsvenster eruit, en of die 94% een succes of een mislukking is, hangt volledig af van een getal dat in de meeste opdrachten door niemand ooit is vastgelegd.

Dat ene gat creëert de andere vier. Zonder een overeengekomen drempelwaarde is er geen objectief voltooiingspunt, dus is er geen helder moment om de laatste betaling vrij te geven, geen basis om een regressie na de lancering te beoordelen en geen manier om een echt defect te onderscheiden van een wijzigingsverzoek. Elke discussie die volgt, gaat in feite over een ontbrekende zin.

Het goede nieuws is dat dit goedkoop op te lossen is. Deze voorwaarden goed vastleggen kost een paar dagen extra tijdens het inkoopproces en neemt de meest voorkomende reden weg waarom deze projecten na 6 maanden stilletjes in de ijskast belanden.

‍

Wat een servicecontract voor AI-agents daadwerkelijk dekt

Een servicecontract voor AI-agents is de overeenkomst die definieert wat een AI-agent moet doen, hoe goed hij dat moet doen, wie de onderdelen bezit die het systeem laten werken en wie de verantwoordelijkheid draagt wanneer het systeem zich in productie misdraagt. Het vormt een aanvulling op een standaard softwareovereenkomst en voegt de voorwaarden toe die alleen relevant zijn omdat het systeem probabilistisch is en zelfstandig acties onderneemt.

In de praktijk bestaat het papierwerk meestal uit drie documenten. Een hoofdovereenkomst (MSA) die de commerciële relatie, aansprakelijkheid en vertrouwelijkheid dekt. Een werkomschrijving (SOW) per fase, met daarin de scope, de acceptatiecriteria en de prijs. Een verwerkersovereenkomst plus een AI-addendum, met daarin verwerkingslocaties, subverwerkers, uitsluitingen van trainingsdata en rollen op het gebied van regelgeving.

Wat je meestal in plaats daarvan krijgt, is een standaard software-werkomschrijving waar het woord AI in de lijst met deliverables is ingevoegd. Dat sjabloon is geschreven voor deterministische systemen. Het bevat geen taal voor nauwkeurigheid, geen taal voor drift, geen taal voor het uitfaseren van modellen, geen taal voor autonomie en geen taal voor de kosten van inferentie. Die vijf gaten zijn waar het geld weglekt, en dat is precies wat de onderstaande clausules dichten.

‍

De 9 clausules waar je afspraken over moet maken voordat je tekent

Gebruik dit als een checklist voor elk voorstel voor AI-agentservices. Je hoeft niet voor elk punt een volledig juridisch document op te stellen voor een kleine pilot, maar je moet elke vraag in één zin kunnen beantwoorden voordat er geld van eigenaar wisselt.

1. Een benoemd proces, geen use case

De scope moet één proces, één proceseigenaar, één bronsysteem en één getal dat moet veranderen benoemen.

Klantenservice verbeteren met AI is een ambitie, geen scope, en het kan niet worden opgeleverd of geweigerd. Vergelijk het hiermee: de agent sorteert inkomende support-e-mails in de Benelux-wachtrij, wijst een categorie en prioriteit toe uit een vaste lijst van 6, stelt voor 4 van die categorieën een antwoord op en verlaagt de mediane responstijd van 4 uur naar minder dan 30 minuten. Nu weten beide partijen wat 'klaar' betekent en kan een beoordelaar zien of het is gebeurd.

Schrijf de lijst met zaken die buiten de scope vallen met dezelfde zorg. Het is de meest waardevolle helft van de sectie, omdat elk wijzigingsverzoek en elk ongemakkelijk gesprek in de derde maand voortkomt uit iets dat werd aangenomen in plaats van uitgesloten. Benoem de kanalen, documenttypen, talen en randgevallen die de agent in deze fase niet hoeft af te handelen.

2. Acceptatie als een gemeten slagingspercentage op een bevroren testset

Acceptatie moet een gemeten slagingspercentage zijn op een geversioneerde set van je eigen echte cases, waarbij de drempelwaarde is afgesproken voordat de ontwikkeling begint.

Dit is de meest waardevolle clausule in het hele document. Voordat de bouw begint, bevriezen beide partijen een set echte historische cases uit je bedrijf, meestal 200 tot 500 stuks, schrijven ze voor elk de juiste uitkomst op en spreken ze de score af die de agent moet behalen. De laatste betalingstermijn is afhankelijk van het behalen van die score. Niets anders in het contract is zo effectief.

Een bevroren dataset is essentieel omdat een demo vrijwel niets bewijst. Een agent die slaagt voor een live demonstratie, heeft slechts één steekproef uit één distributie op één dag doorstaan, meestal gekozen door de partij die betaald krijgt. Een versiebeheerde testset kan na negen maanden opnieuw worden gedraaid om aan te tonen dat het systeem nog steeds presteert. Zo verandert acceptatie in een instrument dat je ook voor onderhoud kunt gebruiken.

Nuttige zaken om te meten, gekozen op basis van het proces in plaats van alles tegelijk:

• Taakvoltooiingspercentage op de volledige set, het belangrijkste cijfer

• Veldnauwkeurigheid wanneer de agent gestructureerde gegevens extraheert

• Escalatiepercentage, oftewel hoe vaak de agent correct doorverwijst in plaats van te gokken

• Latentie op het 95e percentiel, omdat een correct antwoord dat 4 minuten te laat komt, het proces alsnog kan laten falen

• Een nultolerantielijst met uitkomsten die nooit mogen voorkomen; elk van deze zorgt direct voor het falen van de test

Twee beschermingen horen bij de drempelwaarde. Er mag geen sprake zijn van stilzwijgende acceptatie, wat betekent dat het werk niet wordt geaccepteerd enkel omdat je niet binnen 10 dagen bezwaar hebt gemaakt. Daarnaast moet er een vastgelegd herstelrecht zijn, meestal 2 rondes met correcties binnen een vastgesteld tijdsbestek voordat een van beide partijen de samenwerking kan beëindigen. Als je de technische details wilt weten achter het bepalen van deze cijfers, lees dan onze gids over AI-agent evaluatie vóór productie.

3. Eigendom van prompts, evaluatiesets en fine-tuned artefacten

Jij hoort eigenaar te zijn van de systeemprompts, tooldefinities, orchestratiecode, de evaluatieset met de bijbehorende gouden antwoorden en de productielogs.

De meeste eigendomsgeschillen ontstaan niet door kwade opzet, maar door onduidelijkheid. Een leverancier ontwikkelt een promptbibliotheek die bij meerdere klanten wordt hergebruikt, en in het contract wordt geen onderscheid gemaakt tussen hun generieke framework en de versie die jouw escalatieregels, producttaxonomie en 40 uur aan correcties van jouw team bevat. Wanneer de samenwerking eindigt, blijken beide partijen er andere aannames op na te hebben gehouden.

Vraag om overdracht van alle voor jou gecreëerde werkproducten, met een beperkte licentie terug naar de leverancier voor puur generieke tools indien nodig. Voeg een expliciete clausule toe dat jouw data en output nooit worden gebruikt om een model te trainen dat anderen bedient, en zet die zin in de opdrachtbevestiging in plaats van deze te verstoppen in de verwerkersovereenkomst, waar hij makkelijk over het hoofd wordt gezien.

Besteed extra aandacht aan de evaluatieset. Deze bevat jouw definitie van 'correct', is kostbaar om opnieuw op te bouwen, en wie deze in handen heeft, bepaalt of een toekomstige leverancier eerlijk beoordeeld kan worden. Van alles wat tijdens de samenwerking wordt geproduceerd, is dit het meest waardevolle bezit om op te eisen.

‍

Als je nog in een vroeg stadium zit en bezig bent met de businesscase in plaats van het papierwerk, dan helpt onze SaaS AI Blueprint je bij het bepalen van de scope, kosten en volgorde van een AI-traject, zodat de commerciële voorwaarden op een solide basis rusten. Het is gratis en kost ongeveer 20 minuten om te lezen.

‍

4. Modelwijziging, uitfasering en herkwalificatie

Het contract moet het uitfaseren van een model behandelen als een gepland onderhoudsmoment, met benoemde verantwoordelijkheden en een aangewezen betaler.

Frontier-modellen worden volgens gepubliceerde tijdschema's uitgefaseerd, en een agent die is afgesteld op de ene versie kan meetbaar anders reageren op de volgende. Formatteringsverschillen, weigeringsgedrag en de betrouwbaarheid van tool-aanroepen veranderen. Dat is geen defect in iemands werk, maar een eigenschap van het bouwen op infrastructuur waar iemand anders versies van beheert.

De voorwaarden hiervoor zijn kort. Een opzegtermijn voordat de leverancier een model in productie wijzigt. Een verplichting om de volledige acceptatietest opnieuw uit te voeren voordat een modelwijziging live gaat. Een gedocumenteerd terugrolpad. En een duidelijk antwoord op wie betaalt voor de herkwalificatie; in een eerlijk contract valt dit onder de maandelijkse vergoeding wanneer de leverancier of aanbieder de wijziging initieert, en is het facturabel wanneer u om een overstap vraagt.

Stel de vraag direct tijdens de eerste vergadering: als het model dat u voorstelt over 9 maanden wordt uitgefaseerd, wie test het dan opnieuw en wie betaalt daarvoor? Een leverancier die daadwerkelijk een jaar lang een agent heeft beheerd, antwoordt hier direct op. Een leverancier die alleen demo's heeft gebouwd, zal improviseren, en dat zult u merken.

5. Wie betaalt voor tokens en wat gebeurt er bij volumewijzigingen

Benoem de verwachte kosten per run, het veronderstelde maandelijkse volume en het mechanisme dat van toepassing is wanneer het werkelijke volume buiten een afgesproken bandbreedte valt.

Inference-kosten zijn de post die mensen verrast, omdat deze op een manier met het gebruik schaalt die licentiekosten niet hebben. Een agent die 11 cent per run kost, is prima bij 4.000 runs per maand, maar leidt tot een serieus budgetgesprek bij 60.000. Het contract moet de aanname expliciet vermelden, zodat succes niet leidt tot een onaangename factuur.

Bepaal op wiens accounts de modellen draaien. Voor alles wat naar productie gaat, zijn door de klant beheerde accounts bij de aanbieder bijna altijd het juiste antwoord. U ziet de werkelijke rekening in plaats van een rekening met een opslag, u behoudt de relatie met de aanbieder als de leverancier vertrekt en u kunt uw eigen bestedingslimieten instellen. Een leverancier die erop staat de sleutels in handen te houden, moet in één zin kunnen uitleggen waarom.

Voeg vervolgens een verplichting tot kostenefficiëntie toe, want promptgrootte, modelroutering en caching zijn technische keuzes die de leverancier beheert en waarvoor u betaalt. Een redelijke clausule stelt dat als de werkelijke kosten per run de schatting met meer dan 25% overschrijden, de leverancier binnen een afgesproken aantal dagen optimalisaties voorstelt zonder extra kosten.

6. Autonomielimieten en het escalatiepad

Het contract moet vermelden welke acties de agent zelfstandig mag uitvoeren, waarvoor menselijke goedkeuring vereist is en wat de agent doet wanneer hij twijfelt.

Dit lijkt een technisch detail, maar het is in werkelijkheid een aansprakelijkheidskwestie, omdat het bepaalt wie verantwoordelijk is wanneer de agent iets verkeerds naar een klant stuurt. Drie niveaus dekken de meeste processen. Acties die de agent stilzwijgend uitvoert, zoals classificeren en verrijken. Acties die hij uitvoert en rapporteert, zoals het versturen van een standaardbevestiging. Acties die hij voorbereidt en die door een persoon worden vrijgegeven, zoals alles wat met geld, contracten of klantverplichtingen te maken heeft.

Definieer onzeker gedrag expliciet, want dit is waar agents echte schade aanrichten. Er moet een betrouwbaarheidsdrempel of een afwijzingspad zijn, een gedefinieerd gedrag wanneer een tool-aanroep mislukt of niets oplevert, en een aangewezen menselijke wachtrij die de overdracht ontvangt. Een agent zonder gespecificeerd gedrag voor onzekerheid zal zelfverzekerd gaan gokken, en die gok is wat uiteindelijk in een klacht eindigt.

7. Datasoevereiniteit, verwerking en rollen onder de EU AI Act

Het contract moet vermelden waar gegevens worden verwerkt, welke subverwerkers betrokken zijn en welke partij welke rol vervult onder de EU AI Act.

Onder het EU-regelgevingskader voor AIverschillen de verplichtingen afhankelijk van of u een systeem op de markt brengt of het in uw eigen bedrijfsvoering gebruikt. Bij een typische opdracht aan een bureau komen de bouwer en de koper in verschillende rollen terecht, en de plichten die gepaard gaan met het draaien van een systeem in uw bedrijf, inclusief menselijk toezicht en monitoring, komen bij u te liggen in plaats van bij de leverancier. Als niemand die rollen schriftelijk vastlegt, ontdekt u ze pas tijdens een audit.

De praktische voorwaarden zijn concreet in plaats van abstract. Benoemde verwerkingsregio's voor zowel de modelaanroepen als de opslag. Een lijst met subverwerkers met een opzegtermijn voor wijzigingen. Een bewaartermijn voor logs die overeenkomt met uw eigen beleid. Gedocumenteerde afspraken over menselijk toezicht. En een schriftelijke toezegging dat uw gegevens zijn uitgesloten van training aan de kant van de aanbieder.

Voor een Nederlandse of bredere Europese koper is dit geen administratieve rompslomp om de rompslomp. Het bepaalt vaak of de agent überhaupt klantgegevens mag verwerken, wat het tot een vraagstuk van reikwijdte maakt, en niet tot een juridische formaliteit die je aan het eind wel even regelt.

8. Monitoring na lancering, drift en de support-SLA

Spreek af wie de agent na de livegang in de gaten houdt, waar precies op gelet wordt en welke actie wordt ondernomen wanneer de kwaliteit afneemt, in plaats van alleen wanneer de dienst uitvalt.

Agents verslechteren geruisloos, en dat is waarom deze clausule zo belangrijk is. Niets geeft een foutmelding wanneer een agent plotseling 8% meer tickets onjuist categoriseert omdat je productmix is veranderd, of omdat een leverancier het factuurontwerp heeft aangepast dat de agent had leren lezen. Het systeem blijft draaien, de dashboards blijven groen en de schade stapelt zich op in een wachtrij die iemand anders stilletjes moet wegwerken.

De voorwaarden die dit ondervangen zijn een aangewezen verantwoordelijke voor monitoring, een maandelijkse regressietest van de vastgelegde acceptatieset, drempelwaarden voor de relevante statistieken en een vastgelegde reactie zodra een regressie wordt bevestigd. Uptime-garanties zijn op zichzelf niet voldoende, omdat een agent 100% beschikbaar en tegelijkertijd 100% onjuist kan zijn. Eis een kwaliteits-SLA die net zo dwingend is als de beschikbaarheidsgarantie.

9. Exit, transitie en overdraagbaarheid

Spreek bij ondertekening af wat je ontvangt als de samenwerking eindigt, en tegen welke prijs.

Exitclausules zijn saai, tot de week dat je ze nodig hebt. Eis een gedocumenteerde overdracht met daarin de architectuur, prompts, de evaluatieset en operationele runbooks. Eis export van logs en configuratie in een bruikbaar formaat in plaats van een verzameling screenshots. Spreek een transitieperiode af tegen vooraf overeengekomen tarieven, zodat de prijs niet op je zwakste moment hoeft te worden onderhandeld. En vermijd afhankelijkheden van de eigen hosting van de leverancier voor elk onderdeel dat je niet zelf opnieuw kunt inzetten.

Er is een simpele test om te zien of deze clausule echt is. Zou een bekwame engineer die het project nooit eerder heeft gezien, deze agent 30 dagen draaiende kunnen houden nadat je leverancier niet meer op e-mails reageert? Als het eerlijke antwoord nee is, heb je geen systeem gekocht, maar een afhankelijkheid, en dat moet in het contract worden verrekend.

‍

Hoe een contractklare scope eruitziet in vergelijking met een vage

Het verschil tussen een voorstel dat uitmondt in een werkende agent en een voorstel dat leidt tot een conflict, is meestal zichtbaar op één pagina. Zelfde budget, zelfde technologie, totaal andere resultaten.

De rechterkolom is niet moeilijker om te schrijven. Het is dezelfde informatie, maar specifiek genoeg om gecontroleerd te kunnen worden door iemand die niet bij het overleg aanwezig was. Als een leverancier zich verzet tegen de overgang van links naar rechts, is dat verzet het meest waardevolle signaal dat je tijdens het hele inkooptraject zult krijgen.

‍

‍

Hoe je de betalingen spreidt zodat het risico wordt gedeeld

Deel het traject op in 3 commerciële fasen en zorg dat het onzekere deel klein en makkelijk stop te zetten is.

Fase 1 is een betaalde discovery, tegen een vaste prijs en kort van duur. Het levert de benoemde procesdefinitie op, de bevroren evaluatieset met gouden antwoorden, een beoordeling van de datagereedheid en een gemodelleerde kostprijs per run. Dit is de fase waarin de meeste projecten zouden moeten kunnen sneuvelen, en een partner die je durft te adviseren om na deze fase niet door te gaan, is meer waard dan een partner die dat niet doet.

Fase 2 is de bouw, tegen een vaste prijs gebaseerd op de acceptatiedrempel die in fase 1 is afgesproken, waarbij de laatste 15% tot 25% pas wordt vrijgegeven wanneer de acceptatietest slaagt. Omdat het doel was vastgesteld voordat er met bouwen werd begonnen, is die laatste tranche een helder controlemoment in plaats van een discussiepunt.

Fase 3 is de run, een maandelijkse vergoeding die expliciet monitoring, regressietests, herkwalificatie van modellen en een vastgesteld budget voor verbeteringen dekt. Deze fase zichtbaar maken in het eerste voorstel is een kleine eerlijkheidstest. Agents hebben operationele kosten, of het contract dat nu erkent of niet, en de leveranciers die dit verbergen zijn degenen waar je in maand 4 achter komt.

This setup works because the uncertain part is priced cheaply, the expensive part is tied to a number both parties agreed upon when the relationship was still good, and the ongoing costs are laid on the table before anyone has committed.

‍

5 questions that reveal whether a vendor actually has an agent running in production

You don't need to be a technical expert to run this test. Ask these 5 questions during the first commercial meeting and pay attention to whether the answers are specific or generic.

• What accuracy do you guarantee on our data, and based on how many cases?

• Can you show an evaluation report from a previous project, anonymized if necessary?

• Who owns the prompts and the evaluation set when we are finished?

• What happens if the model you propose is discontinued, and who pays the costs for re-testing?

• What went wrong with one of your agents in production last quarter, and how did you find out?

The last question is the sharpest, which is why you should ask all 5 in the same conversation. Any agent that has been in production for a year has messed up at some point. A partner who has experienced this will tell you what went wrong, how they discovered it, and what they adjusted in their monitoring afterward. A partner who has only delivered demos will claim their agents work perfectly. One answer is evidence, the other is a brochure.

‍

How Codelevate structures AI agent trajectories

We work in the 3 phases described above and lock in the acceptance number in the order confirmation before we start building.

In practice, this means the discovery phase ends with a frozen evaluation set based on your own historical cases, a target we are willing to be held accountable for, and costs per run based on your actual volume. If the discovery phase shows that the process is not yet ready – usually because the data is inconsistent or the process itself was never clearly enough defined for a human to follow – then we will be honest about that. You will have spent a small amount to learn something valuable. The prompts, the evaluation set, and the orchestration code are yours from day one, and the model runs on your own accounts, so you see the actual costs.

That is also the standard we hold ourselves to when we are being evaluated. If you want to see in more detail how the delivery model works, you can find the phases, team composition, and how trajectories are typically priced on our AI development services page.

‍

The core message

A contract for AI agent services is not legal ballast standing between you and the interesting work. It is the mechanism that determines whether the interesting work actually makes it to production. Define the process, freeze the test set, agree on the number, take ownership of the results, plan for model changes, and record what happens if quality declines. Six sentences, and they remove most of the reasons why these projects are quietly shut down.

Als je één ding uit dit artikel meeneemt, laat het dan de bevroren evaluatieset zijn. Het verandert een subjectieve discussie over of een agent goed is in een objectieve uitspraak over of deze is geslaagd, en het blijft werken lang nadat de lancering heeft plaatsgevonden.

Twee manieren om verder te gaan. De SaaS AI Blueprint behandelt het bepalen van de scope en kosten van een AI-project voordat je bij de contractfase aankomt, en is gratis. En als er op dit moment een voorstel voor je ligt, ben je van harte welkom om een gratis gesprek met ons team te boeken en dit door te nemen met mensen die deze documenten aan de andere kant ondertekenen. Geen verkooppraatje; we vertellen je eerlijk of de scope op je bureau deugt.