AI-agents verschuiven razendsnel van vragen beantwoorden naar acties uitvoeren. Ze halen klantgegevens op, starten workflows, maken documenten aan, communiceren met bedrijfssystemen en automatiseren beslissingen. Met die nieuwe macht komt een nieuwe uitdaging: naarmate agents capabeler worden, worden ook de gevolgen van falen een stuk groter.

Op de recente OutSystems ONE 2026-conferentie kwamen security en governance keer op keer terug in de gesprekken over agentic systemen. Het patroon is moeilijk te missen: een agent bouwen wordt elke maand makkelijker, terwijl hem beveiligen echt moeilijk blijft.
‍

Bij Harmony Group werken we steeds vaker met organisaties die agentic willen werken, en één les bewijst zich steeds opnieuw: security mag geen bijzaak zijn.

‍
‍

De grote misvatting

‍

Wie het over AI-risico's heeft, denkt vaak meteen aan dataprivacy. Vragen zoals:
‍

• Worden onze eigen data gebruikt om publieke modellen te trainen?
• Maskeren we persoonsgegevens (PII)?
• Kan gevoelige klantinformatie in prompts lekken?
  ‍

Dat zijn belangrijke vragen, en degelijke privacycontroles blijven onmisbaar.
‍

Maar privacy en security zijn niet hetzelfde.
‍

De incidenten die organisaties het meest verrassen, zijn vaak helemaal geen privacyproblemen, maar fouten in systeemontwerp, governance en security. Aanvallers richten zich steeds vaker op AI-systemen via technieken als prompt injection, jailbreak-pogingen, vergiftigde content en gecompromitteerde integraties. Het doel is vaak niet om rechtstreeks bij data te komen, maar om het gedrag van de agent te manipuleren.
‍

Als een AI-agent zo wordt gemanipuleerd dat hij zijn instructies negeert, gevoelige processen blootlegt of onbedoelde acties uitvoert, dan is niet alleen de modelleverancier daarvan de dupe. De organisatie die de agent inzet, draagt de verantwoordelijkheid, en ook het reputatierisico.

‍
‍

Hoe dit er in de praktijk uitziet

‍

Abstracte waarschuwingen over "prompt injection" worden pas echt tastbaar met een concreet voorbeeld. Neem EchoLeak (CVE-2025-32711), een kwetsbaarheid in Microsoft 365 Copilot die in 2025 werd ontdekt.

‍

Het gevaarlijke hieraan? Het was een zero-click aanval. Het slachtoffer hoefde alleen maar een kwaadaardige e-mail te ontvangen; openen was niet eens nodig. Zodra de gebruiker Copilot later vroeg om bijvoorbeeld documenten samen te vatten, las de AI op de achtergrond ook die e-mail mee. De verborgen instructies van de aanvaller werden direct uitgevoerd, wat ongemerkt leidde tot het lekken van bedrijfsgegevens.

‍

Er werd geen firewall doorbroken en er zijn geen wachtwoorden gestolen. De assistent deed simpelweg wat hij moest doen: content lezen en verwerken. Alleen kwamen de instructies van de verkeerde persoon.

‍

Dit fenomeen heet indirecte prompt injection: vijandige instructies die niet van de gebruiker zelf komen, maar verstopt zitten in externe content die de AI binnenhaalt.

‍

Al in 2023 werd dit theoretisch beschreven (Greshake e.a.), maar EchoLeak bewijst dat het inmiddels een reëel risico is voor enterprise-software.

‍

Securityonderzoeker Simon Willison verklaart deze kwetsbaarheid door de "lethal trifecta". Elk AI-systeem dat de volgende drie eigenschappen combineert, is by design vatbaar voor datadiefstal:

1. Toegang tot privédata.
2. Blootstelling aan niet-vertrouwde content (zoals e-mails of websites).
3. De mogelijkheid om extern te communiceren.

‍

Omdat de meeste nuttige enterprise-agents precies deze drie functies nodig hebben om hun werk te doen, is het beveiligen ervan zo extreem complex.

‍

Architectuurprobleem

Een van de grootste fouten die organisaties maken, is daarom ook aannemen dat AI-security kan worden uitbesteed aan de modelleverancier.
‍

Moderne AI-systemen zijn veel meer dan één LLM. Ze bestaan uit prompts, orchestratielagen, API's, databases, vector stores, externe tools, businesslogica en gebruikersinterfaces die samenwerken.
‍

Zelfs het meest geavanceerde model kan een securityrisico worden zodra het in een onveilige architectuur wordt ingebouwd.

De echte uitdaging is dus niet het model zelf beveiligen, maar het hele ecosysteem eromheen. En dat vraagt om een bredere blik op hoe agentic systemen worden ontworpen, uitgerold en bestuurd.

‍
‍

Een manier om naar de AI-stack te kijken

‍

Het helpt om agentic systemen te zien als een gelaagd probleem, waarbij elke laag andere risico's introduceert en andere bescherming vraagt. Het is minder een eigen framework dan een praktische manier om te zorgen dat niets over het hoofd wordt gezien.

‍

Grofweg valt het uiteen in drie domeinen.
‍

1. De capability-laag (modellen)

‍

Deze laag bevat de large language models, embeddingmodellen en reasoning-engines die de agent aandrijven.

Deze modellen zijn ongelooflijk capabel, maar het zijn geen deterministische securitysystemen. Ze zijn te beïnvloeden met zorgvuldig opgestelde input en blijven gevoelig voor prompt injection en jailbreak-technieken. Prompt injection staat bovenaan de OWASP Top 10 voor LLM-applicaties, en die beperkingen begrijpen is de eerste stap naar een veilige implementatie.
‍

2. De intelligence-laag (pipelines en orchestratie)

‍

Hier leeft de echte businesslogica. De intelligence-laag verbindt modellen met API's, databases, bedrijfsapplicaties, kennisbronnen en andere agents. Ze orchestreert workflows en bepaalt hoe informatie door het systeem stroomt.

Klassieke cybersecurityzorgen blijven hier volop relevant. Gecompromitteerde inloggegevens, blootgestelde API-sleutels, kwetsbare integraties of onvoldoende toegangscontrole kunnen aanvallers in staat stellen de gebruikersinterface volledig te omzeilen en rechtstreeks met backendservices te communiceren.
‍

Hier leeft ook het meest onderschatte agentic risico: excessive agency (te veel handelingsvrijheid). OWASP noemt dit een apart top-tien-risico voor LLM-applicaties, en het is misschien wel dé bepalende agentic kwetsbaarheid. Een agent heeft excessive agency wanneer hij meer capaciteit, rechten of autonomie heeft dan de taak vereist: te veel tools, te ruime API-scopes, of de mogelijkheid om ingrijpende acties (versturen, verwijderen, betalen, escaleren) uit te voeren zonder menselijke controle.

‍

EchoLeak is gevaarlijk omdat Copilot zowel privécontent kon lezen als kon handelen binnen een context die niet-vertrouwde input kon bereiken. Verbreek die combinatie (scheid lezen van elke externe actie, vraag bevestiging vóór ingrijpende stappen, geef de krapst mogelijke rechten die de taak nodig heeft) en dezelfde injectiepoging mislukt zonder schade. Agentic security draait in de praktijk grotendeels om het gedisciplineerd beheren van wat een agent mag doen, niet alleen wat hij mag lezen. Naarmate agents toegang krijgen tot meer bedrijfssystemen, wordt governance op deze laag cruciaal.

‍

3. De experience-laag (interactie met de gebruiker)

‍

De experience-laag omvat de applicaties, portalen en interfaces waarmee gebruikers met agents interacteren.

‍

Dit is vaak waar kwaadaardige input het systeem binnenkomt. Gebruikers kunnen, bewust of onbewust, misleidende, tegenstrijdige of manipulatieve instructies aanleveren. En zoals EchoLeak laat zien, komt vijandige input niet altijd van de persoon achter het toetsenbord; hij kan meeliften op elke content die de agent binnenhaalt. Zonder de juiste waarborgen kunnen die inputs het gedrag verderop in de keten beïnvloeden en onverwachte uitkomsten veroorzaken.

‍

Publiek toegankelijke agents zouden daarom ontworpen moeten worden vanuit de aanname dat vijandige input uiteindelijk onvermijdelijk is.

‍

‍

Hoe wij AI veilig aanpakken bij Harmony

‍

Er bestaat geen universeel securityframework dat je zomaar op elk AI-project kunt loslaten. Security begint bij context.

‍

Definieer eerst het dreigingsmodel. Een klantgerichte support-agent loopt totaal andere risico's dan een interne HR-assistent of een AI-gestuurde klinische beslissingsondersteuning. Vóór je controles inbouwt, moet je de specifieke risico's van de use case begrijpen die je oplost.

‍

Vertrouw geen enkele input, waar hij ook vandaan komt. Gebruikersprompts, opgehaalde documenten, e-mails en antwoorden van externe API's verdienen dezelfde behandeling als externe input in een klassieke applicatie. Validatie, scheiding van verantwoordelijkheden en gecontroleerde toegang blijven essentieel.

‍

Beperk bewust de handelingsvrijheid. Geef een agent de minste tools en de krapste rechten die zijn taak vereist, scheid leestoegang van schrijf- en verzendtoegang, en zet een human in the loop bij ingrijpende of onomkeerbare acties.

‍

Zet guardrails en governance in. Moderne AI-platformen bieden steeds vaker dedicated governance-mogelijkheden. Waar een low-code platform zoals OutSystems met Agent Guardrails focust op het monitoren en beschermen van prompts en responses op applicatieniveau, trekt MuleSoft die governance door naar de data- en integratielaag. Via MuleSoft kun je strikte API-policies afdwingen op de gateways die LLM's en (externe) AI-services verbinden met je enterprise systemen. Zulke controles elimineren het risico niet, maar vormen een belangrijke laag binnen een bredere defence-in-depth-strategie.

‍

Blijf dicht bij het onderzoek. Het AI-securitylandschap verandert in een opmerkelijk tempo, en veel opkomende aanvalstechnieken duiken op in onderzoekspublicaties lang voordat ze mainstream worden in de sector. Op de hoogte blijven betekent academisch onderzoek, securitycommunity's en frameworks volgen zoals de OWASP-richtlijnen voor de security van LLM- en agentic applicaties.

‍

‍

Bouwen voor enterprise-eisen

‍

Bij Harmony IT helpen we klanten niet alleen AI te adopteren. We zoeken ook uit hoe je het draaiende houdt in streng gereguleerde omgevingen, met private ontwikkelomgevingen, gecontroleerde CI/CD-pipelines en herbruikbare AI-assets die aansluiten op echte compliance-eisen.

‍

We experimenteren ook via intern onderzoek en communityprojecten, waaronder werk aan AI-benchmarking en evaluatietooling, want je kunt niet beveiligen of vertrouwen wat je niet kunt meten.

‍
‍

De weg vooruit

‍

AI-agents worden razendsnel onderdeel van het IT-landschap. De vraag is niet langer óf organisaties ze gaan inzetten, maar hoe ze dat verantwoord doen.

‍

Security kan niet langer een compliance-vinkje zijn dat je aan het einde van een project toevoegt. Het moet vanaf dag één in de architectuur zitten.

‍

Want terwijl een agent bouwen elke maand makkelijker wordt, is een agent bouwen die onder druk betrouwbaar blijft de échte engineeringuitdaging.

‍

Zet je agents in productie en wil je een frisse blik op waar ze mogelijk te veel rechten hebben? Daar praten we graag over mee.

‍

Tijdens de recente ONE Conference van OutSystems deelden Matthijs van Hagen (Product Lead bij Cordaan) en ik het podium om een fundamenteel probleem in de zorgsector te adresseren. Voor wie de organisatie niet kent: Cordaan is een van de grootste zorgverleners in en rondom Amsterdam. Met circa 6.000 medewerkers ondersteunen zij meer dan 20.000 cliënten binnen de ouderenzorg, gehandicaptenzorg en geestelijke gezondheidszorg.
‍

De operationele complexiteit van een dergelijke organisatie is enorm. Matthijs schetste een uitdaging die elke CTO zal herkennen: een overvloed aan gefragmenteerde point solutions. De zorgmedewerkers van Cordaan verloren zichzelf in een doolhof van apps voor medicatie, zorgplannen en protocollen.
‍

Met Cordaan Werkt hebben we met OutSystems een centrale "superapp" gebouwd om die versnippering tegen te gaan. De nieuwste toevoeging hieraan is een geavanceerde implementatie van RAG (Retrieval Augmented Generation).
‍

Wat is RAG en waarom is het cruciaal voor de zorg?
‍

Voor wie de term nog niet dagelijks gebruikt: RAG is een architecturaal patroon dat een Large Language Model (zoals GPT-5) koppelt aan een specifieke, externe informatiebron.

‍

Het gebruik van generatieve AI in een klinische of zorggerelateerde context is riskant als je uitsluitend vertrouwt op publieke LLM’s. De kans op hallucinaties is simpelweg te groot. Tegelijkertijd is de digitale bibliotheek van een grote zorginstelling vaak een kerkhof van ongebruikte PDF-protocollen.

‍

RAG slaat de brug tussen deze twee werelden. In plaats van te hopen dat een model de juiste informatie 'weet', dwingen we de AI om antwoorden te formuleren die exclusief zijn gebaseerd op de eigen, gevalideerde brondocumenten van Cordaan. Dit proces verloopt via een strak gedefinieerde pipeline: retrieval van relevante chunks, augmentatie van de prompt en tenslotte de generatie van het antwoord.
‍

Wanneer een zorgverlener een vraag stelt, zoekt het systeem eerst de meest relevante fragmenten op in de interne protocollen (Retrieval). Deze feitelijke informatie wordt vervolgens als context meegegeven aan het AI-model (Augmented), dat op basis daarvan een accuraat antwoord formuleert (Generation). Dit minimaliseert de kans op hallucinaties en zorgt ervoor dat de output altijd direct verifieerbaar is aan de bron.
‍

De architectuur: Van testfase naar evolutie

‍

Tijdens onze presentatie op de ONE Conference toonden we de blauwdruk die we tijdens de initiële testfase hebben gehanteerd. Het is belangrijk om te vermelden dat deze architectuur de basis vormde voor onze proof-of-concept. Inmiddels is de architectuur deels geshift terwijl we richting brede productie schalen, wat illustratief is voor de snelheid van deze technologie.

‍

De fundamenten van die fase waren:

‍

• Azure AI Search als orchestrator: Tijdens de testfase gebruikten we de indexeringsmogelijkheden van Azure. We benutten toen vooral BM25 Search voor lexicale precisie en vullen dit aan met Semantic Search om de contextuele relevantie te verhogen zonder de overhead van een volledige vector-database.
  ‍
• Intelligente Chunking: We ontwikkelden een eigen chunking-mechanisme op karakterbasis met een strategische overlap. Dit zorgt ervoor dat de semantische waarde niet verloren gaat bij het opknippen van documenten, wat essentieel is voor de accuratesse.
  ‍
• OutSystems AI Workbench: Deze fungeerde als de veilige gateway naar het LLM, waarbij we volledige controle hielden over de datastromen en de integriteit van de prompts.
  ‍

Lessons Learned: Strategische inzichten voor AI in de zorg

‍

Uit onze journey met Matthijs bij Cordaan zijn een aantal cruciale lessen naar voren gekomen die essentieel zijn voor elke zorginstelling die met AI start:
‍

1. Start met een 'Human-in-the-loop' mindset: AI moet assisteren, niet dicteren. De feedback loop waarbij zorgmedewerkers antwoorden kunnen beoordelen als 'nuttig' of 'niet nuttig' is niet alleen een technische validatie, maar ook een essentieel onderdeel van het adoptieproces op de werkvloer.
   ‍
2. Pragmatisme wint van complexiteit: In de testfase is de verleiding groot om direct voor de duurste vector-databases te gaan. Onze les? Begin simpel met lexicaal zoeken en breid uit naar semantisch zoeken wanneer de use case daarom vraagt. Dat bespaart aanzienlijke kosten in de vroege stadia.
   ‍
3. Data-hygiëne is de bottleneck: Het model is slechts zo goed als de bron. We ontdekten dat het opschonen van oude PDF-protocollen meer impact heeft op de kwaliteit van het antwoord dan het finetunen van het AI-model zelf.
   ‍
4. Architecturale flexibiliteit is een vereiste: Zoals onze eigen shift na de testfase bewijst: de AI-markt verandert wekelijks. Bouw je oplossing modulair zodat je relatief eenvoudig van provider of model kunt wisselen zonder je hele applicatielogica te herschrijven.
   ‍

Guardrails en de menselijke maat
‍

Zoals Matthijs benadrukte, is AI bij Cordaan een assistent en geen vervanger. Dit vertaalt zich in harde technische kaders: de bot is expliciet geconfigureerd als een niet-medisch hulpmiddel, elk antwoord bevat directe citaties naar de bron en privacy-filters waarborgen de anonimiteit voordat data het domein verlaat.
‍

Vooruitblik: Van RAG naar Self-RAG

‍

Hoewel de architectuur rondom de provider en implementatie inmiddels is geshift ten opzichte van onze eerste presentatie, blijft de visie ongewijzigd. We kijken nu naar patronen zoals Self-RAG, waarbij het model zelf de kwaliteit van de opgehaalde informatie beoordeelt voordat de gebruiker het ziet.
‍

De les voor de sector is simpel: de techniek is een middel, geen doel. Door pragmatisch te starten, kritisch te leren van je testfase en bereid te zijn je architectuur aan te passen aan de praktijk, kun je de zorgmedewerker vandaag al tijd teruggeven voor waar het echt om gaat: de cliënt.
‍

Bent u benieuwd naar hoe onze huidige architectuur eruitziet na de laatste shifts, of wilt u sparren over de specifieke lessons learned, of AI binnen uw eigen organisatie? Neem gerust contact op!

‍

App design en development zag er lang ongeveer zo uit: designers leveren mockups aan. Developers stellen vragen. Er ontstaat een pingpongspel. Een vergeten status hier, de verkeerde spacing daar. Nog meer overleg. Gevolg? Vertraging.

‍

Bij Harmony hebben we jarenlang ervaring mehoe een eerste idee transformeert naar een volwaardige applicatie. De bottleneck in dat proces was zelden de code zelf: de helderheid tussen de intentie van de designer en de uitvoering door de developer speelde vaak een belangrijkere rol.

‍

Dus stelden we onszelf de vraag: wat als designers en developers samenwerken *tijdens* het ontwerpen, in plaats van erna?
Die simpele vraag veranderde onze manier van werken in Figma volledig. Figma is de tool waarin we bouwen nog voordat iemand OutSystems opent. Vanaf dag één zitten designers en developers nu in dezelfde Figma-files. Dankzij Dev Mode zien developers in real-time precies wat de designer bedoelt. Daardoor tackelen we misverstanden vroegtijdig, beperken het heen-en-weer gepraat tot een minimum en shippen we sneller en met minder bugs.

‍

De drie strategische voordelen van Figma

‍

• Real-time samenwerking
  In tegenstelling tot Sketch of Adobe XD is Figma browser-native. Stakeholders sluiten aan zonder gedoe: geen downloads, geen plug-ins, geen wachttijden. Voor organisaties met verspreide teams is dit transformatief. We zien design-review-cycli krimpen van **5 dagen naar 2 dagen**, simpelweg omdat de betrokkenheid hoger is.
• Schaalbare design systemen
  Onze applicaties moeten consistent blijven over honderden schermen. Dankzij Figma’s design system-mogelijkheden (shared components en variabelen) worden wijzigingen direct overal doorgevoerd. Moet een button-stijl worden aangepast voor de branding of toegankelijkheid? Eén wijziging in Figma is voldoende. Voor OutSystems-developers neemt dit alle giswerk weg.
• Makkelijkere handoff
  Figma’s Dev Mode toont CSS-classes en stylingdetails direct aan de developers. Deze stijlen vertalen zich bijna één-op-één naar OutSystems. Dit verkort de bouwtijd en voorkomt communicatiefouten. In onze projecten verlaagt Dev Mode de frictie bij de overdracht met zo’n **25–30%**.

‍

Hoe zit het met AI? Figma Make vs. Figma Design
‍

De markt verandert razendsnel. Tools zoals Framer investeren zwaar in *prompt-driven* UI-generatie: je beschrijft wat je wilt en de tool bouwt het. Figma reageert hierop met **Figma Make**, een AI-functie die interface-concepten genereert op basis van tekst.
‍

Dit is het tijdperk van "vibe coding": werken vanuit een helder doel en de tool gebruiken om de eerste versie te versnellen.
‍

Figma Make ondersteunt exploratie: Je beschrijft de intentie, de AI genereert opties, en jij kiest de koers. Het gaat om de "vibe" en de essentie, zonder dat je in een vroeg stadium verzandt in pixels.
‍

Figma Design ondersteunt consolidatie: Zodra de richting vaststaat, verfijn je de lay-outs en pas je de regels van het design system toe. Hier is de precisie nodig die essentieel is voor een productie-ready OutSystems build.
‍

Samen dichten ze de kloof. Figma Make versnelt de "vibe," terwijl Figma Design de kwaliteit waarborgt.
‍

Figma reality check?

‍

Waarom wij voorlopig voor Figma blijven kiezen

Vinger aan de pols

‍
We gaan dus zeker niet op de eerstvolgende hype springen, maar we houden de concurrentie wel scherp in de gaten.

De snelheid van generatieve UI is onmiskenbaar. Over 12 tot 24 maanden kan het gesprek er heel anders uitzien. Voor nu biedt Figma de balans die we nodig hebben: solide fundamenten plus opkomende AI, zonder de strikte regels op te offeren die enterprise-applicaties vereisen.

‍