Managed LLM-dienst

Wat is een managed LLM-dienst?

Een managed LLM-dienst is een afspraak waarbij je via een zakelijk contract toegang koopt tot het taalmodel van iemand anders, bij een cloudleverancier of bij de modelbouwer zelf. Je krijgt een endpoint, een sleutel en een factuur. De gewichten blijven op hun machines, de versie is van hen, en GPU's draaien is jouw zorg niet.

Je koopt dus geen model. Je koopt een endpoint met papieren erachter. Dezelfde gewichten zitten meestal ook in een consumenten-app en in nog drie of vier zakelijke routes, en het verschil zit in wat het contract over jouw tekst zegt, niet in wat het model kan.

Twee buren bakenen het veld af. Een consumentenabonnement is dezelfde technologie, verkocht aan een persoon, met voorwaarden geschreven voor een persoon. Een lokale LLM is de andere kant: het model draait op hardware die jij beheert en er staat geen contract tussen jou en je data. Op de volumes die een KMO draait, is de managed route in euro's bijna altijd de goedkoopste, dus geld beslist dit zelden. Wat wel beslist: of er data is die het gebouw niet uit mag, en of je ermee kan leven dat de leverancier het model verandert wanneer het hen past.

Wat je in de praktijk koopt

Er komen vier dingen mee met de dienst, en alleen het eerste is technisch.

Een endpoint, met de beschikbaarheidsbelofte die er echt is. Lees die belofte, ga er niet van uit. Anthropic beschrijft zijn standaardtier in de eigen documentatie als best-effort beschikbaarheid, en de Priority Tier die op 99,5 procent uptime mikte, wordt niet meer verkocht. Ga je via een cloudleverancier naar hetzelfde model, dan valt het endpoint onder de dienstvoorwaarden van die cloud.

De papieren. Een verwerkersovereenkomst, een geschreven standpunt over bewaring, een lijst van subverwerkers waarover je verwittigd wordt als ze verandert, en een uitspraak over welke regio je aanvragen verwerkt. Voor de meeste zakelijke kopers zijn die vier documenten het eigenlijke product. Of de leverancier op je tekst traint en hoelang hij ze bijhoudt, zijn de twee vragen die het lemma over zero data retention in detail uitwerkt.

Beheer. Sleutels per team in plaats van één gedeeld geheim, verbruik dat je aan een persoon of een project kan toewijzen, uitgavelimieten en een spoor dat achteraf te lezen valt.

Een factuur die een controle overleeft. Bedrijfsnaam, btw-nummer, lijnen per model en per project. Een afschrijving op de privékaart van een collega is geen bewijsstuk voor werk dat klantendossiers aanraakt.

Wat je niet koopt, is controle over de versie. Dat is de prijs van geen hardware bezitten.

Hetzelfde model via vier deuren

Neem één modelfamilie, Claude van Anthropic, en kijk naar de routes waarlangs een bedrijf ze kan afnemen. De capaciteit is grotendeels dezelfde. Het contract niet. Dit staat in september 2026 op de pagina's van de leveranciers zelf.

• De API van Anthropic zelf. Anthropic is de verwerker. Je kan de inferentie vastzetten met de parameter inference_geo, maar alleen op us of global, en inferentie die enkel in de VS draait kost 1,1 keer het standaardtarief op Claude 4.6 en later. Zero data retention wordt per organisatie toegekend via het salesteam, en dekt de Fable- en Mythos 5-modellen niet: die vragen dertig dagen bewaring.

• Amazon Bedrock. Hier is AWS de verwerker, niet de modelbouwer. AWS documenteert zero operator access en zero data retention als het standaardgedrag, en zegt dat modelleveranciers geen toegang hebben tot Bedrock-logs, prompts of antwoorden van klanten. Bewaring is een modus die je per account of per project zet en die je organisatiebreed kan afdwingen met een service control policy. Claude Fable 5 en 5.1 zijn de uitzondering met naam: al het verkeer blijft tot dertig dagen binnen de AWS-grens, en het model wordt onbeschikbaar als jouw instelling strenger is dan het model nodig heeft.

• Microsoft Foundry. Prompts en antwoorden worden niet gebruikt om de modellen te trainen, en de verwerking blijft in de geografie die je opgeeft, tenzij je kiest voor een Global- of DataZone-deployment. Een DataZone-deployment die je in een EU-lidstaat aanmaakt, mag in die of in eender welke andere EU-lidstaat verwerkt worden. Voor deployments in de Europese Economische Ruimte zitten de Microsoft-medewerkers die gemarkeerde inhoud mogen bekijken zelf in de EER. Die opslag uitzetten is een aanvraag, geen schakelaar.

• Microsoft 365 Copilot. Hier is Anthropic een subverwerker van Microsoft, dus de Product Terms en de Data Protection Addendum van Microsoft dekken het gebruik. Microsoft zet die modellen standaard aan in de commerciële cloud, maar niet in de EU, de EVA of het Verenigd Koninkrijk: daar moet een beheerder ze zelf aanzetten, en ze vallen momenteel buiten de EU Data Boundary. Sommige modellen komen apart als "Anthropic models with Data Retention", en daar treedt Anthropic op als zelfstandige verwerker onder eigen voorwaarden, met bewaring van de meeste inputs en outputs tot dertig dagen en gemarkeerde inhoud tot twee jaar.

Eén modelfamilie, vier contracten, en drie verschillende antwoorden op de vraag wie jouw verwerker is. Bij een cloudroute is de cloudleverancier je verwerker en zit de modelbouwer eronder als subverwerker; bij een directe route is de modelbouwer zelf je verwerker. Dat bepaalt tegen welk bedrijf je een vordering hebt en wiens subverwerkerslijst je opvolgt. Zegt een leverancier je dus dat hij Claude gebruikt, dan weet je nog bijna niets over je eigen blootstelling zolang je niet weet langs welke deur hij binnenkwam.

Met de regio moet je even voorzichtig zijn. Een parameter die je kan zetten is geen grens die je niet kan overschrijden. Anthropic laat je per workspace vastleggen welke geo's toegelaten zijn, zodat een losse aanvraag er niet buiten kan, en Microsoft laat je een deployment-type kiezen dat de verwerking inperkt. Vraag welk mechanisme het afdwingt, niet enkel welke waarde er vandaag staat.

De leverancier verandert het model onder je, op zijn kalender

Model versioning en deprecation behandelt wat de modelbouwers op hun eigen API beloven. Hier gaat het erom dat een managed route daar een tweede klok bovenop legt, en je kan verzetten zonder het te vragen. Microsoft zet in Foundry de einddatum van een model automatisch vast zodra het algemeen beschikbaar wordt, achttien maanden later. Modellen van Anthropic, DeepSeek, Fireworks en Mistral AI volgen in plaats daarvan een cyclus van twaalf maanden. Op de einddatum geeft elke aanvraag 410 Gone terug. Eigenaars van abonnementen met actieve deployments krijgen minstens zestig dagen vooraf bericht, en Microsoft is kort over uitstel: einddatums zijn niet verlengbaar.

Wat mensen verrast, is de automatische upgrade. Op Standard-, Global Standard- en Data Zone Standard-deployments zet Microsoft je regio per regio over naar het vervangmodel, tenzij je versionUpgradeOption op NoAutoUpgrade zet, en dan valt de deployment stil op de einddatum. Provisioned deployments worden nooit automatisch overgezet en moeten met de hand mee. Op het goedkoopste deployment-type verandert het model achter je productiestroom dus zonder dat er aan jouw kant iets uitgerold wordt, en het alternatief is dat het stilvalt. Geen van beide is fout, maar bij allebei hoort een naam: iemand die de meldingsmails van de leverancier leest, een testset met je eigen voorbeelden, en elke model-identifier in configuratie waar je ze in een minuut terugvindt.

Managed dienst tegenover consumentenabonnement: wie draagt de plicht

Het onderscheid dat telt is niet de prijs en niet het model. Het is wie verantwoordelijk is voor de persoonsgegevens in de prompt, en wat je kan tonen als iemand ernaar vraagt.

Onder de GDPR ben jij de verwerkingsverantwoordelijke voor de klantnamen, personeelsdossiers en facturen die je mensen in een chatvenster plakken, en dat verandert niet met het gereedschap. Wat wel verandert, is of de partij die dat voor jou verwerkt gebonden is door een schriftelijke afspraak met je bedrijf. Bij een managed dienst is dat zo: de verwerkersovereenkomst staat op naam van de organisatie, het bewaarstandpunt staat op papier, de regio is een instelling die iemand gezet heeft, en het verbruik hangt vast aan identiteiten die jij beheert. Onder de AI Act ben je de gebruiksverantwoordelijke, en diezelfde papieren tonen dat je die rol ernstig genomen hebt.

Bij een consumentenabonnement bestaat daar bijna niets van op jouw naam. De voorwaarden zijn aanvaard door een individu, vaak met een privémailadres. Je kan geen verwerkersovereenkomst voorleggen, je weet niet welke regio de aanvraag behandeld heeft, je kan niet zeggen wie het vorige maand gebruikt heeft, en vertrekt die collega, dan krijg je zijn geschiedenis niet terug en kan je ze ook niet wissen. Misschien gaat de leverancier keurig met de data om, maar je kan het niet aantonen, en voor een audit of een vragenlijst van een klant komt dat op hetzelfde neer als niets hebben. In dat gat leeft shadow AI: een onderhandeld contract voor een werkruimte waar niemand inlogt, terwijl het echte werk in privéaccounts gebeurt.

Waar moet je op letten bij een managed LLM-dienst

De afhankelijkheid zit niet in de API. Het ene chat completions-endpoint inruilen voor het andere is een dag werk, en met een LLM-gateway is het een configuratiewijziging. Wat je echt vasthoudt, is alles wat rond het gedrag van één model gebouwd is: prompts die op zijn gewoontes afgestemd zijn, parsers die op zijn opmaak passen, en een evaluatieset die je alleen vertelt of dít model goed is. Dat heropbouwen is de echte migratiekost, en ze groeit stilletjes aan.

Een budgetmelding is geen uitgavelimiet. Een budget in Azure Cost Management verwittigt je zodra de uitgaven het bedrag bereiken dat je instelde, maar het stopt niets. Bij Anthropic Enterprise stopt het wel: elk lid heeft een maandelijkse limiet die op de eerste van de maand om 00:00 UTC opnieuw begint, en wie ze raakt moet een verhoging aanvragen bij een beheerder. Zoek uit welke van de twee je hebt voor je een agent onbewaakt laat lopen.

Lees de voorwaarden van het abonnement waar je op zit, niet die van het bedrijf. Dezelfde leverancier verkoopt tegengestelde voorwaarden op een gratis quotum en een betalend, en een sleutel van de verkeerde kant ziet er in je code identiek uit.

Functies met geheugen vallen uit de strenge afspraak. Alles wat tussen twee oproepen iets onthoudt, moet dat ergens neerschrijven. Zodra je geheugen, bewaarde gesprekken of lange agentsessies toevoegt, geldt het bewaarantwoord dat je voor gewone oproepen kreeg misschien niet meer.

Een subverwerkerslijst verandert. Modelbouwers duiken op onder producten waar je al voor betaalt, in de ene regio standaard aan en in de andere standaard uit. Vraag hoe je verwittigd wordt, en leg dat adres op het bureau van iemand in plaats van in een gedeelde mailbox.