De vraag is niet of een AI-model ooit een fout maakt of misleid wordt. De vraag is wat er dan gebeurt. Een goed ontwerp gaat ervan uit dat het model faalt, en zorgt dat dat geen gevolgen heeft.
Taalmodellen maken fouten, en ze zijn te misleiden. Een instructie kan verstopt zitten in een mail, een document of een webpagina die het model leest. Dat heet prompt-injectie, en het is geen kinderziekte die met een beter model verdwijnt: een model maakt geen hard onderscheid tussen de tekst die het moet verwerken en de opdracht die het moet uitvoeren.
Wie zijn beveiliging aan het model toevertrouwt, bouwt dus op het zwakste punt. Daarom ligt elke grens buiten het model, in gewone code die niet te overtuigen is. Dat is de AI-poort: dom, maar streng. Ze begrijpt de vraag niet; ze kijkt alleen of het mag.
| Wat er misloopt | Zonder poort | Met de AI-poort |
|---|---|---|
| Het model wordt misleid door tekst in een mail of document | Het voert de verstopte opdracht uit | Inhoud is data, geen instructie. Het model kan alleen voorstellen, en alleen binnen de rechten van de gebruiker |
| Iemand vraagt iets wat hij niet mag zien | Het model weigert misschien, misschien ook niet | De poort geeft de gegevens niet vrij. Wat het model niet krijgt, kan het niet lekken |
| Het model verzint een cijfer | Een fout bedrag in een rapport of een offerte | Cijfers komen uit vaste, gecertificeerde berekeningen. Het model rekent niet zelf |
| Het model wil iets doen wat niet terug kan | Een mail vertrekt, een factuur gaat buiten | Het blijft een voorstel. Een mens bevestigt, en wat onomkeerbaar is, vraagt een bevestigingstoken |
| Het model wordt vervangen of krijgt een update | Het gedrag verandert, ongemerkt | De grenzen hangen niet van het model af. Elk model gaat door dezelfde poort |
| Er gaat toch iets fout | Niemand weet wat er gebeurde | Het logboek toont wie wat vroeg, welke gegevens er gebruikt zijn en wat het kostte |
Ontwerpen voor het falen betekent ook: de schade klein houden als er toch iets door de mazen glipt.
Hoe dit er in een draaiend bedrijfsplatform uitziet, lees je in VediCore als architectuur. De algemene uitwerking, met de drie klassen van controle, staat in de referentiearchitectuur.
Wie met deze aanpak aan de slag gaat en op een vraag stuit, of het ergens grondig mee oneens is: ik hoor het graag. Een methode wordt beter van tegenspraak.
dodeurs@gmail.comof bel +32 478 544 682
The question is not whether an AI model will ever make a mistake or be misled. The question is what happens when it does. A good design assumes the model will fail, and makes sure that has no consequences.
Language models make mistakes, and they can be misled. An instruction can be hidden in an email, a document or a web page the model reads. That is called prompt injection, and it is not a teething problem that a better model will cure: a model draws no hard line between the text it has to process and the instruction it has to carry out.
Entrusting your security to the model means building on the weakest point. So every limit sits outside the model, in plain code that cannot be persuaded. That is the AI gate: dumb, but strict. It does not understand the question; it only checks whether it is allowed.
| What goes wrong | Without a gate | With the AI gate |
|---|---|---|
| The model is misled by text in an email or document | It carries out the hidden instruction | Content is data, not instruction. The model can only propose, and only within the user's permissions |
| Someone asks for something they may not see | The model might refuse, or might not | The gate does not release the data. What the model never gets, it cannot leak |
| The model makes up a number | A wrong amount in a report or a quote | Figures come from fixed, certified calculations. The model does not calculate itself |
| The model wants to do something irreversible | An email goes out, an invoice is sent | It stays a proposal. A person confirms, and anything irreversible requires a confirmation token |
| The model is replaced or updated | Behaviour changes, unnoticed | The limits do not depend on the model. Every model goes through the same gate |
| Something goes wrong anyway | Nobody knows what happened | The log shows who asked what, which data was used and what it cost |
Designing for failure also means keeping the damage small if something slips through anyway.
What this looks like in a running business platform is described in VediCore as architecture. The general design, with the three classes of control, is in the reference architecture.
If you put this approach to work and run into a question — or disagree with something — I would like to hear it. A method gets better through challenge.
dodeurs@gmail.comor call +32 478 544 682