Hoe een AI-agent uw bedrijfsproces kent: de zes bouwblokken
Een AI-agent kent uw bedrijfsproces via zes bouwblokken: het model zelf, de systeeminstructie, opgehaalde kennis (RAG), de tooldefinities, de orchestration en het geheugen. Elk bouwblok is een ontwerpkeuze over wat waar leeft en hoeveel het model beslist, en elke keuze bepaalt welke risico's het proces draagt en hoe de controleomgeving eruit moet zien.
Bijgewerkt: juli 2026
De vraag achter elke inzet van een agent
Wanneer een organisatie een bedrijfsproces overdraagt aan een AI-agentAI-agentEen systeem dat zijn omgeving waarneemt, beslist en handelingen verricht richting een doel, tools aanroept, plannen uitvoert. Autonomie van handelen vereist allowlists, goedkeuringspoorten, sandboxing, logging en een kill switch. Zie agentic AI, kill switch.Open full entry →, komt één vraag eerst: hoe kent de agent dat proces? Een taalmodel weet uit zichzelf niets over uw organisatie. Het weet wat een factuur is en wat "goedkeuren" betekent, maar niet wat uw goedkeuringslimiet is, wie tekenbevoegd is, of welke leverancier op de uitzonderingslijst staat.
Alles wat de agent over uw proces weet, komt binnen via zes bouwblokken, en elk bouwblok is een ontwerpkeuze: wat leeft waar, en hoeveel bepaalt het model zelf. Die keuzes bepalen hoe goed de agent het proces uitvoert. Ze bepalen ook hoe de controleomgeving eromheen eruit moet zien, want waar kennis en beslissingen leven, bepaalt waar controlscontrolDe concrete, toetsbare maatregel die een specifiek risico vermindert en daarmee het achterliggende principe beschermt. Ook wel risicobeheersmaatregel, risicorespons of risicobehandeling genoemd. Altijd herleidbaar tot het risico dat het adresseert: onder EU AI Act Art. 9 moet elke control terug te voeren zijn op een specifiek risico, en controls die los van hun risico's worden vastgelegd vormen een erkende compliance-fout. Het werkt in een van drie typen: preventief, detectief of correctief. Zie risico, control-typen, bewijs.Open full entry → kunnen leven.
De architectuur van een agent, in gewone taal
Een AI-agent is een kleine stapel onderdelen die samenwerken.
In het midden staat het taalmodel, het "brein" dat tekst begrijpt en produceert en de keuzes van de agent maakt. Daaromheen staat gewone, vaste software: de orchestrationorchestrationDe vaste programmacode rond een AI-model die bepaalt welke stappen in welke volgorde lopen, wat verplicht is, en waar een mens betrokken is. Omdat het gewone software is, gedraagt het zich voorspelbaar en kan het afdwingbare controls dragen, en daarom hoort processtructuur daar en niet in prompttekst. Zie afdwingpunt, guardrail.Open full entry →, programmacode die bepaalt welke stappen in welke volgorde lopen en waar een mens betrokken moet zijn. De agent handelt in de buitenwereld via tools: functies die hij kan aanroepen om iets te doen of op te vragen, een zoekfunctie, een koppeling met het ERP-systeem, een mailfunctie. Hij krijgt zijn opdracht via een systeeminstructie, de vaste tekst die hij bij elke run meekrijgt en die zijn rol en werkwijze beschrijft. Hij zoekt dingen op via opgehaalde kennis (RAG): per taak haalt hij eerst de relevante documenten op, de juiste procedure, de productvoorwaarden, en leest die als context. En hij kan geheugen dragen: informatie die hij vasthoudt over eerdere stappen of eerdere runs.
Niet elke agent gebruikt elk onderdeel. Een agent kan draaien zonder RAG, en veel agents draaien zonder langetermijngeheugen. Het praktische verschil met een gewone chatbot zit in de tools: een chatbot antwoordt, een agent kan naar dat antwoord handelen.
Twee soorten onderdelen, en waarom dat verschil ertoe doet
Nu de onderdelen namen hebben, kan er één lijn doorheen worden getrokken, en dat is de meest bepalende lijn in het hele ontwerp.
Deterministische onderdelen zijn gewone software: de orchestration, de checks binnen tools, en de toegangsrechten die begrenzen wat de agent kan bereiken. Hun regels zijn expliciet vastgelegd in code, dus bij dezelfde relevante input, toestand en configuratie passen ze die regels voorspelbaar en reproduceerbaar toe. Als de betaaltool is geconfigureerd om bedragen boven 10.000 euro te weigeren, past het die limiet vandaag toe, morgen, en bij de duizendste factuur.
Probabilistische onderdelen zijn alles wat door het taalmodel gaat: hoe het de instructie leest, wat het met de opgehaalde documenten doet, welke tool het besluit aan te roepen. Het model kiest de meest waarschijnlijke voortzetting; het volgt geen vaste regels. Dezelfde vraag, twee keer gesteld, kan twee licht verschillende antwoorden opleveren.
Elk bouwblok hieronder draagt een van deze twee labels. Het label bepaalt waarop u kunt vertrouwen, en hoe u het ooit kunt toetsen.
De labels beschrijven gedrag, geen kwaliteit. Een deterministische laag is niet automatisch veilig: hij vraagt nog steeds een correct ontwerp, dekking van elk pad dat ertoe doet, een veilige configuratie en change management. Wat het label u oplevert, is dat de regels afdwingbaar zijn en als regels toetsbaar.
Wat er verandert wanneer een agent het proces overneemt
Een agent voert het proces niet alleen sneller uit. Hij verandert het risicoprofiel van het proces, op vier manieren.
Schaal en snelheid. Een mens maakt één fout tegelijk; een agent maakt dezelfde fout duizend keer per uur. SchadeschadeDe concrete schade die een AI-systeem kan aanrichten en die een principe van verantwoorde AI beoogt te voorkomen: in de termen van de EU AI Act schade aan iemands gezondheid, veiligheid of grondrechten. Schade is de brug tussen een abstract principe en een bestuurbaar risico; governance wordt operationeel op het moment dat een organisatie de specifieke schades benoemt die ze wil voorkomen. Voor eerlijkheid is een schade dat een groep stelselmatig slechtere uitkomsten krijgt vanwege een kenmerk dat niet had mogen meetellen. Zie principe, risico.Open full entry →-inschattingen die uitgaan van menselijk tempo houden geen stand.
Geen natuurlijke aarzeling. Een medewerker die iets vreemds ziet, stopt en vraagt na. Een agent doet dat alleen als hij daar expliciet op is ontworpen. Het ongeschreven vangnet van gezond verstand verdwijnt met de mens.
Nieuw aanvalsoppervlak. Het proces wordt manipuleerbaar via kanalen die er eerder niet waren: verborgen instructies in een binnenkomende e-mail, een bijgevoegde pdf, een webpagina, of een vervuild document in de kennisbank. De aanvalskant staat in het artikel over het agentic aanvalsoppervlak.
Gecorreleerde fouten. Waar tien medewerkers tien verschillende fouten maken, maakt één agent dezelfde fout overal tegelijk. Hun fouten heffen elkaar niet langer op.
Daarom begint het ontwerp bij het risicorisicoIn de termen van de EU AI Act de combinatie van de waarschijnlijkheid dat een schade optreedt en de ernst ervan als dat gebeurt. De schakel tussen een principe (via de schade die het zou schenden) en een control (de maatregel die het vermindert). Het benoemen van de schade en het inschatten van het risico is op grond van Art. 9 vereist voordat een maatregel wordt gekozen. Zie schade, control, restrisico.Open full entry → en niet bij de bestaande procedure: de agent tekent het risico opnieuw voordat er één control is opgeschreven.
De zes bouwblokken: waar proceskennis kan leven
De architectuur hierboven is de machine. Deze sectie loopt dezelfde onderdelen door als de plekken waar kennis over uw proces leeft. Het getal zes is een compleetheidsclaim: als proceskennis ergens in een agent leeft, leeft die in een van deze zes bouwblokken. Het IMDA Model AI Governance Framework for Agentic AIIMDA Model AI Governance Framework for Agentic AIEen governance-raamwerk voor agentic AI van de Singaporese Infocomm Media Development Authority, verschenen in januari 2026 en bijgewerkt in juni 2026. Het ontleedt agents in modellen, geheugen, tools en acties, en spreekt een voorkeur uit voor structurele en regelgebaseerde controls boven guardrails in de promptlaag. Het is guidance, geen wetgeving. Zie agentic AI, guardrail, least agency.Open full entry →, gepubliceerd door de Singaporese Infocomm Media Development Authority, deelt agents anders in, in modellen, geheugen, tools en acties, maar dekt dezelfde elementen.
Eén laag ontbreekt bewust in de lijst. Permissies en policyregels, of dat nu toegangsrechten, rolgebaseerde autorisatie of een policy enginepolicy engineEen component die vastgelegde regels automatisch toepast op elke actie, bijvoorbeeld de eis dat betalingen boven een drempel aparte goedkeuring vragen. Omdat de regel buiten het model staat, kan het model hem niet negeren of wegredeneren. Die regels vastleggen als machineleesbare code, onder versiebeheer zoals andere productiecode, heet policy-as-code.Open full entry → zijn, leren de agent niets over uw proces; ze begrenzen wat hij kan bereiken en doen, ongeacht wat hij weet. Daarmee zijn ze een control-laag en geen bouwblok, en het is de laag waar een groot deel van de controleomgeving uiteindelijk landt.
1. Het model zelf (probabilistisch)
De generieke kennis en redeneervaardigheid die tijdens de training is verworven. Bij een standaardinzet van een general-purpose model hoort er niets van u in: u kiest een model, u vult het niet. Het model weet wat een factuur is. Het weet niet dat uw organisatie nooit betaalt aan een leverancier van wie vorige week het rekeningnummer wijzigde. Fine-tuningfine-tuningEen bestaand model verder trainen op je eigen data om zijn gedrag aan te passen, wat jou verantwoordelijk maakt voor de wijziging, mogelijk tot op aanbiederniveau. Zie aanbieder, foundation model.Open full entry → of doortrainen op eigen data is een aparte ontwerpkeuze, en die verandert dat beeld: organisatiespecifieke kennis leeft dan in het model zelf, waar die aanzienlijk lastiger te inspecteren, te corrigeren of te verwijderen is dan een document in een kennisbank.
- De risico's: het model vult gaten in uw instructies met plausibele aannames, dus wat u niet expliciet regelt, verzint het aannemelijk. En het model is geen vast gegeven: de aanbiederaanbiederDe actor die een AI-systeem ontwikkelt (of laat ontwikkelen) en het onder eigen naam op de markt brengt of in gebruik neemt, met fabrikantachtige plichten: ontwerpcontrols, documentatie, conformiteit. Zie gebruiksverantwoordelijke, AI-verplichtingen.Open full entry → kan het bijwerken of vervangen, waarna het gedrag verschuift terwijl al uw eigen artefactenartefactHet concrete record dat bewijst dat een control is uitgevoerd: een testrapport, een impactassessment, een monitoringlog, een release-sign-off. Een artefact is de tastbare vorm die bewijs aanneemt, het ding waar een auditor naar grijpt om te bevestigen dat een control niet alleen is ontworpen maar ook echt heeft gewerkt. Elke fase van de AI-levenscyclus levert haar eigen anker-artefact op. Onderscheiden van bewijs als geheel: bewijs is het bewijsmateriaal, een artefact is er één stuk van. Zie bewijs, levenscyclus.Open full entry → hetzelfde blijven. Veel organisaties zetten daarom een specifieke modelversie vast waar de aanbieder dat toestaat, waardoor een modelwijziging van een gebeurtenis een besluit wordt.
- De vast te leggen ontwerpkeuze: welk model, welke versie, of die versie is vastgezet, en wat er gebeurt als de aanbieder hem wijzigt.
2. De systeeminstructie (probabilistisch)
Het vaste "functieprofiel" dat bij elke run meegaat: rol, doel, werkwijze, toon, wat te doen bij twijfel. Eén regel erin kan het karakter van het hele proces bepalen. Een instructie die zegt "bij twijfel over de leverancier of het bedrag: stop en leg de zaak voor aan een mens" levert een agent op die escaleert; zonder die regel gokt dezelfde agent.
- Wat erin hoort: de taak op hoofdlijnen, escalatieregels, en verwijzingen naar waar de gedetailleerde kennis leeft.
- De risico's: harde regels die hier worden geplaatst zijn verzoeken aan een probabilistisch systeem, geen beperkingen, dus het model kan ze verkeerd wegen, ze kwijtraken tussen concurrerende instructies, of eruit worden gemanipuleerd. En de instructie veroudert terwijl het proces verandert, omdat de tekst vaak in een configuratiebestand leeft buiten het reguliere change management.
- De vast te leggen ontwerpkeuze: wat de functiebeschrijving van de agent zegt, welke escalatieregels hij draagt, en wie hem onderhoudt onder welk wijzigingsproces.
3. Opgehaalde kennis, RAG (probabilistisch)
De agent haalt per taak de relevante documenten op, procedures, werkinstructies, productvoorwaarden, en gebruikt die als context. De vuistregel: de systeeminstructie zegt hoe de agent werkt, RAG levert waarmee hij werkt.
Technisch is ophalen eenvoudig: de tekst van de opgehaalde documenten wordt naast uw instructie in het contextvenster van het model geplaatst, en het model leest beide op dezelfde manier. Dat mechanisme is meteen de kwetsbaarheid: verborgen tekst in een document komt precies daar terecht waar instructies leven.
- De risico's: de agent haalt het verkeerde of een verouderd document op; de bron is vervuild of draagt verborgen instructies; en versieverloop, want als de procedure verandert en de kennisbank niet, werkt de agent aantoonbaar op een oude processversie.
- De vast te leggen ontwerpkeuze: welke bronnen de agent voeden, en hoe die synchroon blijven met het werkelijke proces.
4. Tooldefinities (deterministisch, met één precisering)
De lijst functies die de agent kan aanroepen, elk met een naam, beschrijving en parameters. De agent leest die beschrijvingen om te bepalen wat hij doet, waarmee tooldefinities uitvoerbare procesarchitectuur worden: ze beschrijven het proces en begrenzen het tegelijk. process_invoice(amount, supplier, cost_center) vertelt de agent al veel over hoe uw proces werkt.
De precisering die ertoe doet: de check binnen een tool is deterministisch en afdwingbaar, maar of de tool wordt aangeroepen, en met welke waarden, is een modelbeslissing.
- De risico's: te brede tools zoals
run_query(sql)geven de agent feitelijk onbeperkte macht in een systeem. Het model kan ook verzinnen: een tool aanroepen dat niet bestaat, of parameters vullen met plausibele maar verkeerde waarden, wat een extra reden is dat de validatie binnen de tool niet optioneel is. En tooldefinities van derden, vaak geleverd via MCPMCPEen open standaard om AI-toepassingen op een uniforme manier te koppelen aan externe tools en gegevensbronnen. Voor governance is dit relevant omdat een tooldefinitie via een MCP-server proceskennis is die de agent leest: wie die definitie beheert, beïnvloedt het gedrag van de agent, waarmee toolbronnen van derden een supply chain-vraagstuk worden. Zie agentic AI.Open full entry →-servers (een standaardmanier om een agent te koppelen aan externe systemen en gegevensbronnen), vormen een supply chain-kanaal: wie de toolbeschrijving beheert, stuurt het gedrag van uw agent. - De vast te leggen ontwerpkeuze: de exacte toolset, wat elke tool zelfstandig weigert, en welke tools van buiten komen.
5. De orchestration (deterministisch)
De vaste code om het model heen die de processtructuur afdwingt. Hier blijft een proces een proces in plaats van een gesprek te worden: eerst matchen, dan goedkeuren; boven een drempel beoordeelt een mens; stoppen na drie mislukte pogingen.
De orchestration is de enige plek waar volgorde en menselijke betrokkenheid gegarandeerd zijn in plaats van gevraagd. Hij kan de verplichte volgorde van stappen dragen, een goedkeuringsmoment vóór een impactvolle actie, functiescheiding over stappen heen, retry-limieten, stopcondities en de escalatieroute. Elk daarvan is óf structuur in code óf een zin in de prompt, en maar één van de twee houdt elke keer stand.
- De risico's: ontwerpers laten te veel aan het model over, omdat orchestration bouwen meer werk is dan een zin aan de prompt toevoegen. Elke processtap die alleen in prompttekst bestaat, is een stap die kan worden overgeslagen.
- De vast te leggen ontwerpkeuze: welke delen van het proces structuur in code zijn, welke aan het model worden overgelaten, en waar een mens beoordeelt, goedkeurt of de run kan stoppen.
6. Geheugen (probabilistisch)
Wat de agent vasthoudt binnen een taak (kort geheugen) of over taken en runs heen (lang geheugen). Geheugen is nuttig en stilletjes gevaarlijk: een verouderde leveranciersuitzondering in het geheugen kan elke goedkeuring daarna kleuren, zonder dat iemand ziet waar die invloed vandaan komt.
Veel workflow agents in een bedrijfsomgeving hebben kort geheugen binnen een taak nodig en helemaal geen lang geheugen. In andere situaties, klantenservice, coaching, onderwijs of zorg, is duurzaam geheugen juist het doel van de agent. Daar vraagt het een eigen governancegovernanceHet stelsel waarmee een organisatie zichzelf bestuurt: corporate governance, risicobeheer, compliance, verantwoordingslijnen, risicobereidheid en het besturingsmodel. Het bestaat over alles wat de organisatie doet, voor en los van AI. AI governance is ditzelfde stelsel, uitgebreid voor AI. Zie AI governance, governance design, execution level.Open full entry → in plaats van vermijding.
- De risico's: memory poisoningmemory poisoningHet risico dat vervuilde, verouderde of bewust geplaatste informatie die een AI-agent onthoudt, doorwerkt in alle latere beslissingen. Het is achteraf lastig te herleiden, omdat de invloed niet zichtbaar is in de individuele zaak die misgaat, en daarom is wat een agent bewaart en hoe lang een ontwerpbeslissing en geen technisch detail. Zie agentic AI, drift.Open full entry →, waarbij vervuilde, verouderde of kwaadwillend geplaatste informatie doorwerkt in alle latere beslissingen en achteraf lastig te herleiden is.
- De vast te leggen ontwerpkeuze: of lang geheugen überhaupt bestaat, wat wordt bewaard, hoe lang, en wie het mag inzien en wissen.
De autonomiekeuze
De zes bouwblokken bepalen niet hoeveel het model zelf vaststelt. Dat is een aparte keuze, en de grootste.
| Workflow agent | Planning agent | |
|---|---|---|
| Stappen | Vastgelegd in code | Het model bepaalt ze |
| Taak van het model | Inhoud invullen per stap | Het werk plannen en de tools kiezen |
| Zekerheid komt uit | De structuur om het model heen | Voorwaarden bij elke afzonderlijke actie |
| Autonomie | Lager | Hoger |
| Governance-inspanning | Lager | Hoger |
Tussen die twee zit een spectrum, en de positie daarop bepaalt waar zekerheid kan leven. Bij een workflow agent draagt de orchestration de processtructuur. Bij een planning agent bestaat er geen vaste plek meer waar "stap 2 pas na stap 1" technisch afdwingbaar is, dus moet de zekerheid komen uit voorwaarden bij elke afzonderlijke actie.
Voor de meeste eerste toepassingen is dit ook een risicokeuze: een workflow agent is aanzienlijk makkelijker te beheersen en te toetsen. Kies hogere autonomie alleen waar de taak dat vraagt, en behandel die keuze als een expliciet, onderbouwd besluit in de risicoanalyse in plaats van als technische default. Dit is wat het agentic security-werk van OWASPOWASPThe Open Worldwide Application Security Project, een non-profitstichting die open securityrichtlijnen publiceert. Twee publicaties zijn relevant voor AI governance: de OWASP Top 10 for LLM Applications, met prompt injection als eerste vermelding, en de OWASP Top 10 for Agentic Applications, over de securityrisico's die specifiek zijn voor agents die tools gebruiken en zelfstandig handelen. Zie prompt injection, least agency, agentic AI.Open full entry → least agencyleast agencyHet principe uit het agentic security-werk van OWASP dat een agent de kleinste set capabilities en de minste autonomie krijgt die de taak vraagt. Toegepast op architectuurniveau is het een risicobesluit en geen technische voorkeur: minder autonomie laat meer van het proces afdwingbaar in code. Zie OWASP, agentic AI, afdwingpunt.Open full entry → noemt, toegepast op architectuurniveau; de voorkeur van IMDA voor structurele controls boven prompt-layer guardrailsguardrailEen barrière die ongewenst gedrag van een AI-systeem moet tegenhouden. Wat de waarde bepaalt, is waar hij leeft: een guardrail in de prompt is een verzoek dat het model verkeerd kan wegen of waaruit het kan worden gemanipuleerd, terwijl een guardrail in code of configuratie een afdwinging is. Het woord wordt in de markt ook gebruikt voor outputfilters, schemavalidatie, classifiers en policy engines, dus het benoemen van de laag doet ertoe. Zie afdwingpunt, policy engine, prompt injection.Open full entry → komt vanuit de governance-kant op hetzelfde neer.
Zeven keuzes, één ontwerp
Lees de bouwblokken opnieuw en elk eindigt op dezelfde manier, met iets om vast te leggen. Welk model en welke versie. Wat de functiebeschrijving zegt. Welke bronnen de agent voeden. Welke tools bestaan en wat ze weigeren. Wat structuur in code is en wat aan het model wordt overgelaten. Wat wordt onthouden. En boven dat alles: hoe autonoom de agent mag zijn.
Elk van die keuzes heeft ook een naam nodig erachter. De systeeminstructie, de kennisbank, de toolset en de orchestration zijn productieartefacten, en een artefact zonder benoemde eigenaar verandert zonder dat iemand besluit dat het moet. De keuze vastleggen en vastleggen wie hem bezit, zijn één handeling.
Samen vormen de vastgelegde keuzes de architectuur van uw agent, zeven beslissingen in totaal, en ze zijn de invoer voor alles wat eromheen beheerst moet worden, want elke keuze bepaalt welke risico's bestaan en in welke laag, deterministisch of probabilistisch, een passende control ooit kan leven. Een agent ontwerpen gaat daarom minder over het prompten van een model dan over bewust bepalen waar proceskennis, beslissingen en bevoegdheid horen. Governance begint niet wanneer de eerste control wordt gebouwd; ze begint hier, met die keuzes op papier. De architectuur vastleggen is nog geen risicoanalyse, maar het maakt er wel één mogelijk: het laat zien hoe de agent kan falen, welke schade daaruit volgt, en welke control objectivescontrol objectiveEen uitspraak over de uitkomst die een control moet bereiken, bijvoorbeeld "ongeautoriseerde betalingen mogen technisch niet uitvoerbaar zijn". Het benoemt wat waar moet zijn in plaats van wat er gebouwd moet worden, waardoor meer dan één control activity eraan kan voldoen. Het objective gescheiden houden van de activity is wat een controlregister toetsbaar houdt. Zie control activity, afdwingpunt.Open full entry → de organisatie nodig heeft. Waar die objectives vervolgens worden afgedwongen, en hoe u aantoont dat ze werken, verdient een eigen behandeling: de controleomgeving van agentic AI.
Veelgestelde vragen
- Uit welke onderdelen bestaat een AI-agent?
- Een typische agent combineert maximaal zes onderdelen: een taalmodel (het "brein" dat beslist), orchestration-code die de stappen structureert, tools die hij aanroept om te handelen, een systeeminstructie die zijn rol vastlegt, opgehaalde documenten (RAG) die hem per taak informeren, en geheugen. Niet elke agent gebruikt alle zes; een onderdeel weglaten is zelf een ontwerpkeuze. Het praktische verschil met een gewone chatbot zit in de tools: een chatbot antwoordt, een agent kan handelen.
- Hoe kent een AI-agent mijn bedrijfsproces?
- Via zes bouwblokken: de generieke trainingskennis van het model, de systeeminstructie, opgehaalde documenten (RAG), de tooldefinities die hij leest, de orchestration-code eromheen, en zijn geheugen. Niets over uw specifieke proces zit in het model zelf; alles komt binnen via de andere vijf, en elk bouwblok is een ontwerpkeuze met eigen risico's.
- Wat verandert er in een bedrijfsproces wanneer een AI-agent het overneemt?
- Vier dingen: fouten schalen (dezelfde fout duizend keer per uur), de natuurlijke aarzeling van een mens verdwijnt tenzij die is ingebouwd, het proces krijgt aanvalsoppervlak dat er eerder niet was (verborgen instructies in e-mails, documenten of webpagina's), en fouten worden gecorreleerd waar menselijke fouten verspreid zijn. Het risicoprofiel verandert voordat er één control is opgeschreven.
- Wat is het verschil tussen een workflow agent en een planning agent?
- Een workflow agent volgt processtappen die in code zijn vastgelegd, waarbij het model per stap de inhoud invult. Een planning agent bepaalt zelf zijn stappen en toolgebruik. De keuze bepaalt waar zekerheid kan leven: in de structuur om het model heen, of alleen in voorwaarden bij elke afzonderlijke actie. Hogere autonomie is een risicobesluit dat in de risicoanalyse hoort, geen technische default.
- Waar horen bedrijfsregels te leven in een AI-agent?
- Proceskennis (hoe u een verzoek behandelt, toon, context) kan leven in de systeeminstructie en in opgehaalde documenten. Regels waarvan u zeker moet zijn horen in deterministische lagen: in de tools, de permissies of de orchestration, want tekst in een prompt is een verzoek dat het model kan negeren of waaruit het kan worden gemanipuleerd. Hoe die vertaling volledig werkt, is een eigen onderwerp: de controleomgeving van agentic AI.