Modellen & evaluatie

Toegang is geen controle

24 augustus 20267 min lezen

Je kunt een AI-capability gebruiken zonder grip op het model dat hem levert. Die afstand is geen implementatiedetail maar een architectuurvariabele.

Het stuk over modelkeuze eindigt op een vaststelling: de model-ID die je opschrijft is het model dat je krijgt. Dat is een geruststelling, en het roept meteen twee vragen op die daar niet thuishoren. Hoe ver reikt die grip precies? En wat doe je als je hem niet hebt?

Want dat advies rust op één aanname die ik daar niet heb uitgesproken, en die steeds vaker niet opgaat — namelijk dat jij het model aanroept.

Je kunt toegang hebben tot een capability zonder controle te hebben over het model, de versie, de uitvoering of de manier waarop het resultaat tot stand komt.

Die afstand tussen jou en de uitvoering is geen implementatiedetail. Het is een variabele die je bij het ontwerpen kiest, vaak zonder dat je merkt dat je kiest.

Een casus waarin die afstand expliciet is

Anthropic kondigde op 21 augustus 2026 een uitbreiding aan van de toegang tot Claude Mythos 5, een model dat volgens het modeloverzicht de specificaties en de prijs van Fable 5 deelt, maar alleen op uitnodiging beschikbaar is en zonder self-service.

Uit de aankondiging springt één zin eruit voor wie systemen bouwt: partners kunnen het model in hun eigen producten opnemen, waarbij eindgebruikers via een speciaal gebouwde interface werken die het model op de achtergrond voor een afgebakende taak draait — en alleen het artefact terugkrijgen dat het product bedoeld is te leveren. In dit geval een lijst bevindingen met een CWE-categorie plus een zekerheids- en ernstinschaling.

Zo'n gebruiker gebruikt het model dus wel, en heeft er geen enkele grip op. Dat is een scherp voorbeeld, maar het is geen uitzondering — het is de expliciete versie van iets wat in gewone platformarchitectuur al gebruikelijk is.

Drie niveaus van controle

De indeling die ik sindsdien gebruik heeft drie treden. Bij elke trede blijft de capability gelijk en verdwijnt er iets anders.

Model — je kiest de ID, de prompt en de parameters, en je kunt ze alle drie vastleggen. Een wijziging is een commit. Dit is het geval waar het modelkeuze-stuk over gaat.
Dienst — je kiest de leverancier en de interface, maar niet de versie erachter. Verandert die, dan merk je het aan het gedrag, als je ernaar kijkt.
Artefact — je krijgt een uitkomst. Wat die produceerde staat buiten je bereik, en de interface bepaalt wat je überhaupt kunt vragen.

Hoe verder van het model, hoe minder van de uitvoering je kunt vastleggen. Dat is de hele indeling, en het is mijn eigen ordening — geen model dat ik uit een bron overneem.

Nuance bij de derde trede

Het is niet zo dat een interface je taakdefinitie wegneemt en een API die intact laat. Een product kan een rijke interface bieden en een API kan schraal zijn. Wat verschuift is hoevéél van de taakdefinitie bij jou blijft: hoe verder een interface van het onderliggende model abstraheert, hoe meer van de uitvoering door de dienst wordt bepaald.

Wat een gepinde ID werkelijk vastzet

Hier moet ik mijn eigen eerdere formulering bijstellen. “Pin je model-ID en je reproduceerbaarheid is geregeld” is te ruim. Reproduceerbaarheid van een agentuitkomst hangt aan een hele rij:

het model — de ID, en dat is de enige die je met één regel vastlegt;
de prompt, inclusief alles wat er dynamisch in gerenderd wordt;
de parameters, zoals de effort-stand die je niet zelf hebt gezet;
de tools die beschikbaar waren, en hun versies;
de context die is meegegeven, en wat er via retrieval bij kwam;
de serving-laag: router, classificatoren, sampling.

Een gepinde ID fixeert er dus één van de zes. Dat is nog steeds de meest waardevolle van de zes — het is de enige die je met een commit vastzet — maar het is niet hetzelfde als een reproduceerbaar systeem.

Waarom afstand soms juist het doel is

Tot hier leest dit alsof dichter bij het model beter is. Dat is niet mijn punt, en de architectuurpraktijk zegt iets anders.

AWS beschrijft in de Generative AI Atlas een LLM gateway als een gestandaardiseerde abstractielaag die organisaties tussen hun applicaties en meerdere modelleveranciers zetten. Wat die laag centraliseert is precies wat een directe aanroep bij de aanroeper laat liggen: limieten en kostentoerekening per team, normalisatie van API-verschillen, routering met terugval, en governance — beveiligingscontroles, compliance en audittrails op één punt.

In hun platformrichtlijn staat de reden erbij: geen enkel model dekt alle toepassingen, organisaties moeten capaciteit tegen kosten en prestaties afwegen, en dat vraagt om een aanpak die flexibel is én gecontroleerd. Toegang tot modellen is daar een eigen laag met eigen toegangsbeslissingen — wie welk model mag aanzetten.

Het echte argument

Meer controle is niet vanzelf beter. Een directe modelaanroep geeft je maximale grip op versie en configuratie, en legt observability, beveiliging, routering en governance bij de aanroeper neer. Een gateway neemt die grip bewust over om die functies centraal te kunnen doen. Het punt is niet welke kant je kiest, maar dat je weet welke controle je weggeeft.

Vier soorten verandering waar je niets van hoort

“Reken op stille verandering” is te vaag om iets mee te doen. De indeling hieronder is van mij, niet van een bron — maar ze maakt de vraag beantwoordbaar, want elke soort vraagt een ander soort waarneming.

Modelverandering — het onderliggende model wordt een ander. Bij een gepinde ID gebeurt dit niet; op de andere twee treden kan het elk moment.
Interfaceverandering — de taakdefinitie of het uitvoerschema verschuift. Dit is de enige van de vier die je code doorgaans zelf merkt, omdat er iets breekt.
Beleidsverandering — wat je mag vragen verandert, of wie erbij mag. De aankondiging hierboven is er zelf een voorbeeld van: die kondigt de volgende verruiming alweer aan.
Gedragsverandering — dezelfde invoer levert een andere uitkomst, terwijl model, interface en beleid ongewijzigd lijken. Dit is de gevaarlijkste, want er is niets dat afgaat.

Vanaf hier: mijn interpretatie

De casus, de gateway-beschrijving en de platformrichtlijn staan in de bronnen onderaan. De drie treden, de zes variabelen en de vier soorten verandering zijn mijn ordening, en wat nu volgt zijn de gevolgtrekkingen die ik eruit trek. Neem ze als voorstel, niet als bevinding.

Wat hieruit volgt

Pin het model waar dat kan. Eén regel configuratie die je met een commit verandert, is de goedkoopste grip die er bestaat.
Pin het gedrag waar dat niet kan. Bewaar op invoer die niet verandert een referentie-uitkomst — met de configuratie, het tijdstip en het uitvoerschema erbij — en haal die periodiek opnieuw op. Het verschil is je signaal. Dat is dezelfde gedragsvergelijking als bij het valideren van patches, nu tegen een dienst in plaats van tegen een vorige versie.
Kies je trede bewust. Ga dichter naar het model waar reproduceerbaarheid telt, en verder weg waar governance, routering en kosten het zwaarst wegen. Beide zijn verdedigbaar; onbewust ergens uitkomen is dat niet.
Deel afhankelijkheden in op grip, niet op leverancier. De vraag is niet van wie iets komt, maar of je kunt vastleggen wát je gebruikt.

Waar het ophoudt

Wat ik hier niet kan controleren, en wat sneller veroudert dan de rest

Over de casus: beide Anthropic-bronnen komen van de leverancier zelf, en dat is voor een toegangsbeleid niet te vermijden. Dit stuk zegt daarom niets over hoe capabel het model werkelijk is — “frontier” en “most capable” zijn beschrijvingen van de maker, en de aankondiging bevat geen evaluatiecijfers. Wat controleerbaar is, is de vorm van de regeling: welke toegang bestaat, via welke route, en wat een gebruiker terugkrijgt.

De AWS-bronnen zijn architectuurrichtlijnen, geen metingen. Ze beschrijven wat een gateway centraliseert en waarom organisaties er een neerzetten; ze tonen niet aan dat het beter uitpakt. Dat onderscheid is hier relevant, want ze dragen in dit stuk het tegenargument, en een tegenargument mag niet steviger klinken dan z'n onderbouwing.

En de tiers verouderen sneller dan de redenering. De aankondiging kondigt de volgende verruiming zelf al aan. Wat ik verwacht dat blijft staan is de vorm — capaciteit, toegang en controle als drie dingen die je apart kiest.

Toets het op je eigen systeem

Laat je eigen systeem indelen op hoeveel grip het werkelijk heeft op de capaciteit waarop het leunt.

Je gaat de externe afhankelijkheden van dit project indelen naar grip, niet naar leverancier.

Stap 1 — inventariseer. Zoek elke plek waar dit project functionaliteit gebruikt die ergens anders draait: modelaanroepen, hosted analyses, scanners, API's — alles waar we een resultaat krijgen zonder de berekening zelf te doen. Geef per vindplaats het pad en wat er terugkomt.

Stap 2 — deel ze in op drie niveaus, en onderbouw elke indeling met wat je in de code ziet:
  a) MODEL — wij kiezen de versie, de prompt en de parameters, en kunnen die vastleggen;
  b) DIENST — wij kiezen de leverancier en de interface, maar niet de versie erachter;
  c) ARTEFACT — wij krijgen alleen een uitkomst; wat die produceerde is voor ons niet zichtbaar.

Stap 3 — beoordeel per afhankelijkheid welke soorten verandering ons zouden raken en of we die zouden merken:
  - het onderliggende model verandert;
  - de interface of het uitvoerschema verandert;
  - het gebruiks- of veiligheidsbeleid verandert;
  - dezelfde invoer levert ander gedrag op, zonder dat een van bovenstaande zichtbaar veranderde.

Stap 4 — stel per geval voor hoe je verandering zichtbaar zou maken: een opgeslagen referentie-uitkomst op invoer die niet verandert, een periodieke vergelijking, of een expliciete acceptatie dat dit mag driften. Zeg erbij wat dat kost.

Zeg expliciet welke afhankelijkheden je niet kunt beoordelen zonder toegang tot de kant van de leverancier.

Bekijk als Markdown

Bronnen

Layer 2: Approved set of foundation models and toolsAWS · AWS Prescriptive Guidance — enterprise-ready generative AI platform · 2026
LLM GatewayAWS Labs · Generative AI Atlas · 2026
Bringing the cybersecurity capabilities of Claude Mythos 5 to more defendersAnthropic · Claude blog, 21 augustus 2026 · 2026
Models overviewAnthropic · Claude Platform docs · 2026