Human-in-the-loop als ontwerpkeuze bij AI in Systems Engineering

Je kunt AI vertrouwen — tot op het niveau dat je het kunt verifiëren

AI kan Systems Engineering sneller maken: Requirements samenvatten, eisen opstellen, inconsistenties opsporen, changes analyseren, verificatieplannen voorbereiden. In bouw, infra, energietransformatie en andere complexe technische projecten is 'sneller' alleen waardevol als het controleerbaar blijft. SE is geen tekstproductieproces — het is een bewijs- en besluitvormingsproces. Precies daarom is human-in-the-loop niet optioneel, maar een expliciete ontwerpkeuze in je werkwijze.

Ik werk in dit artikel toe naar één praktisch uitgangspunt: ik kan AI vertrouwen tot op het niveau dat ik de output kan verifiëren, herleiden en auditen — en alles daarboven vraagt expliciet menselijk toezicht, met duidelijke acceptatieregels.

Waarom human-in-the-loop onmisbaar is bij AI in Systems Engineering

SE vraagt om bewijsvoering, niet alleen om plausibele tekst

SE draait om het beheersen van complexiteit met expliciete afspraken: wat is de eis, waarom bestaat die, wat is de impact van een wijziging, en hoe toon ik aantoonbaar aan dat het systeem voldoet? Requirements engineering — met kwaliteitskenmerken zoals eenduidigheid, traceability en volledigheid — is daarin fundamenteel. ISO/IEC/IEEE 29148 is een bekende standaard in dit domein.

AI-output, hoe goed geformuleerd ook, is daarmee nog geen bewijs. Het is een voorstel dat pas bruikbaar wordt als ik kan aantonen: welke bronnen zijn gebruikt, welke aannames zijn gemaakt, hoe het past in de baseline, en welke review en acceptatie zijn gedaan. Zonder die stap versnelt AI de tekstproductie — terwijl SE een versneller nodig heeft voor besluitvorming mét bewijs.

'Mensen maken ook fouten' klopt — maar SE is juist ontworpen om fouten gecontroleerd te vangen'
Mensen maken fouten, zeker onder tijdsdruk. SE-processen — reviews, baselines, change control, V&V, peer checks — bestaan juist om fouten systematisch te reduceren en zichtbaar te maken vóór acceptatie. AI voegt een nieuw foutpatroon toe dat buiten dat klassieke beeld valt: fouten die snel en op grote schaal worden geproduceerd, overtuigend geformuleerd zijn, en geen inherente bronvermelding of redeneerpad hebben.

Onjuiste aannames kunnen daarmee ongemerkt doorstromen naar eisen, interfaces, verificatieclaims of veiligheidsargumentatie. Als ze eenmaal in de keten zitten, zijn ze lastig en kostbaar te herstellen. Human-in-the-loop is in dit licht geen wantrouwen in AI — het is risicobeheersing die past bij hoe SE werkt.

Hallucinaties: het probleem is reëel — en niet weg te configureren

Wat onderzoek laat zien

'Hallucinatie' — modeloutput die feitelijk onjuist is of niet goed gegrond in bronmateriaal — is geen eenduidig begrip. Definities en meetmethoden verschillen per context en taak. Dat maakt het onrealistisch om te claimen dat het probleem met één configuratie, prompt of toolkeuze definitief is opgelost.

Voor SE is dit extra relevant omdat we werken met context-afhankelijke definities (interfaces, omgevingscondities, ontwerpbeperkingen), normatieve claims ('moet', 'zal', 'mag niet'), en ketens van afhankelijkheden waarbij een kleine fout grote downstream impact kan hebben.

Waar SE kwetsbaar is
In de praktijk zijn de risico's het hoogst op plekken waar:

• Getallen en grenzen belangrijk zijn — toleranties, load cases, performance-eisen.
• Verwijzingen cruciaal zijn — normen, contracteisen, systeem-eisen.
• Consistentie over documenten heen telt — CONOPS, requirement set, interface control, verificatieplan.
• Eisen-interpretatie onder tijdsdruk: AI geeft een nette interpretatie van een contracteis. Het team neemt het over als 'bedoeling is duidelijk', terwijl één nuance later tot rework of claims leidt.

Het gevaar is niet alleen dat de output fout is. Het gevaar is dat het team — door tijdsdruk — de output te snel als plausibel markeert en verwerkt in artefacten die later contractueel, safety-technisch of operationeel zwaar wegen. Overtuigende output is geen bewijs van correctheid. In SE, waar bewijsvoering de norm is, volstaat plausibiliteit niet.

De valkuil: snelheid plus overtuiging leidt tot sneller doorzetten

Automation bias als menselijk fenomeen

Human factors-onderzoek beschrijft al langer dat mensen die automatiseringsmiddelen gebruiken geneigd zijn te veel op de tool te vertrouwen, minder actief te verifiëren en afwijkingen te laat te detecteren. Dit heet automation bias of complacency — en het is geen kwestie van onzorgvuldigheid, maar een cognitief fenomeen dat optreedt zodra tooling als betrouwbaar wordt ervaren.

Wat dit bij AI-taalmodellen extra versterkt, is de presentatiekwaliteit. Een LLM produceert vloeiende, goed gestructureerde tekst in het juiste domeinregister. Dat verhoogt de gepercipieerde geloofwaardigheid — en daarmee het risico dat verificatiestappen worden overgeslagen.

Hoe dit zich vertaalt naar SE

In bouw, infra, energietransformatie en andere complexe technische projecten zijn drie situaties typisch riskant:

• Eisen-interpretatie onder tijdsdruk: AI geeft een nette interpretatie van een contracteis. Het team neemt het over als 'bedoeling is duidelijk', terwijl één nuance later tot rework of claims leidt.
• Change impact analyses: AI maakt een ogenschijnlijk complete impactlijst. Het team vertrouwt op de volledigheid en mist een interface-afhankelijkheid of een verificatie-artefact dat ook aangepast moet worden.
• V&V-artefacten: AI genereert testcases die logisch lijken, maar niet aansluiten bij de echte acceptatiecriteria of niet traceerbaar zijn naar requirements.

De kern: AI maakt het makkelijk om door te pakken — en dat vergroot juist de noodzaak voor expliciete review- en acceptatieregels.

Wat werkt wél: verificatie-loops en expliciete signoff

Het patroon: draft → verifieer → reviseer

Het meest robuuste patroon voor AI in bewijsgevoelige processen is de verificatie-loop. AI maakt nooit het eindproduct, maar altijd een reviewable voorstel. Dat voorstel doorloopt vervolgens een expliciete verificatiestap voordat het de baseline in mag. Dit sluit aan op bestaande SE-werkwijzen — maar moet expliciet worden gemaakt en verankerd zodra AI-tooling wordt ingezet.

Concrete controls die ik in SE zou borgen

1) Output-classificatie — wat is dit eigenlijk?

• Draft / idee: mag snel gedeeld worden, maar niet in de baseline.
• Voorstel voor requirement of beslissing: mag alleen naar review met bron en trace.
• Baseline-kandidaat: vereist expliciete sign-off door bevoegde rol.

2) Bron- en trace-eisen voor AI-output

• Geen bron of trace = geen acceptatie als requirement, interface-afspraak of verificatieclaim.
• Elke normatieve zin ('moet', 'zal') krijgt een trace-link naar bron: contract, norm, stakeholder requirement.

3) Verplichte tegenspraak-stap

• Laat AI (of een tweede prompt) expliciet zoeken naar tegenstrijdigheden of ontbrekende voorwaarden.
• Laat een engineer die stap beoordelen en aftekenen.

4) Vier-ogenprincipe op high-impact items

• Voor items met hoge impact — veiligheid, compliance, grote kosten, interface-afspraken — moet een tweede reviewer onafhankelijk checken.

5) Logging voor audit

• Bewaar prompt, context, output, gebruikte bronnen en wie welke acceptatie heeft gedaan — zodat je later kunt reconstrueren waarom iets is overgenomen.

Dit is human-in-the-loop als procesontwerp: de mens is niet het laatste redmiddel, maar een expliciete controlelaag met bevoegdheden en verantwoordelijkheden.

Governance: van AI gebruiken naar AI beheersen

NIST AI RMF als structurerend kader

Voor governance is het nuttig om AI-risico's te structureren in plaats van ad hoc op incidenten te reageren. NIST AI RMF 1.0 biedt daarvoor een bruikbaar raamwerk via vier functies: govern, map, measure en manage. De kern: AI-risico's zijn geen technisch probleem van de tool, maar een governancevraagstuk van de organisatie die de tool inzet.

Voor SE-projecten helpt dit om AI niet te positioneren als tooling, maar als een capability met scope (waar wel en niet inzetten), risico's (wat kan misgaan en met welke impact), controls (welke checks en wie tekent af) en monitoring (hoe detecteer je drift of kwaliteitsissues).

RACI voor acceptatie: wie mag wat 'gezien en geaccepteerd' zetten?

Als je één ding expliciet maakt, maak dan dit expliciet: acceptatiebevoegdheid. Zonder deze helderheid leidt AI-snelheid vrijwel automatisch tot sneller doorzetten.

• Responsible: wie maakt of actualiseert het artefact (met AI als hulpmiddel)?
• Accountable: wie accepteert en baselined (en draagt het risico)?
• Consulted: wie moet inhoudelijk reviewen — discipline owners, interface owners
• Informed: wie moet op de hoogte zijn — projectleiding, QA, opdrachtgever 

ISO/IEC/IEEE 29148 blijft als kwaliteitslat ongewijzigd van kracht. De norm verandert niet omdat requirements door een AI zijn opgesteld — de verificatielat blijft gelijk.

Conclusie

Je kunt AI vertrouwen tot op het niveau dat je het kunt verifiëren.

Dat is geen cynische conclusie — het is een hanteerbaar en praktisch uitgangspunt. Het betekent dat AI uitstekend ingezet kan worden om sneller tot analyses en concept-artefacten te komen, zolang het verificatieproces evengoed of beter is ingericht dan zonder AI.

Human-in-the-loop is daarin geen rem op innovatie en geen tijdelijke maatregel totdat AI 'goed genoeg' is. Het is een expliciete ontwerpkeuze in de SE-keten — net zo bewust als een verification milestone of een baseline-review. Organisaties die dit goed inrichten, combineren de snelheidswinst van AI met de bewijsvoering die complexe engineering vereist.

In high-impact projecten is vertrouwen geen gevoel. Het is iets dat je opbouwt met verificatie, traceability en aantoonbaarheid. AI mag versnellen — de mens blijft eigenaar van acceptatie.

Over Basewise: Basewise ondersteunt organisaties in bouw, infra, energietransformatie, scheepsbouw en offshore bij de toepassing van Systems Engineering. Wij combineren domeinkennis met methodische begeleiding — ook bij de verantwoorde inzet van AI in SE-processen.