19 sep 2025·8 min
Alan Turing en de grenzen van berekening uitgelegd
Ontdek Turings kernideeën — algoritmen, onbeslisbaarheid en codekraken — en hoe ze moderne computers, beveiliging en machine-intelligentie hebben gevormd.
Ontdek Turings kernideeën — algoritmen, onbeslisbaarheid en codekraken — en hoe ze moderne computers, beveiliging en machine-intelligentie hebben gevormd.
Het grootste deel van wat je op een telefoon of laptop doet—web zoeken, berichten sturen, accounts ontgrendelen, een assistent om hulp vragen—rust op vragen die Alan Turing hielp verduidelijken: Wat is berekening? Wat kan een computer in principe? En waar liggen de harde grenzen?
Turing is vandaag relevant omdat hij niet alleen slimme technieken uitvond; hij stelde de spelregels vast. Moderne software-engineering, cybersecurity en AI-onderzoek erven die regels, of men zijn naam nu noemt of niet.
Allereerst berekening: Turing’s eenvoudige model van een computer (de “Turingmachine”) geeft ons een heldere manier om te praten over programma’s, data en algoritmen. Daardoor kunnen we heel verschillende apparaten—laptops, servers, smartphones—zinvol vergelijken als varianten van hetzelfde basisidee: een general-purpose machine die instructies uitvoert.
Ten tweede beveiliging: tijdens WOII hielp Turing van codekraken een systematische, op engineering gerichte discipline te maken. Die denkwijze klinkt door in moderne cryptografie en security, waar succes afhangt van het begrijpen wat aanvallers kunnen berekenen—en hoe duur dat voor hen is.
Ten derde machine-intelligentie: Turing stelde een praktische vraag die nog steeds AI-discussies beïnvloedt: Hoe zouden we intelligent gedrag van buitenaf herkennen? Zijn “Turingtest” blijft een referentiepunt, zelfs als mensen de beperkingen ervan bespreken.
Deze gids houdt wiskunde licht en intuïtie zwaar. Het kernidee is simpel: computers zijn ongelooflijk krachtig, maar niet magisch. Sommige problemen zijn onmogelijk op te lossen met welk programma dan ook, en veel meer zijn alleen oplosbaar tegen kosten die ze onbruikbaar maken in de praktijk. Die grenzen begrijpen helpt je beter technologieclaims te beoordelen—en de juiste tools te kiezen.
Alan Turing (1912–1954) wordt vaak geïntroduceerd via dramatische verhalen, maar de meest bruikbare manier om hem te begrijpen gaat via wat hij bouwde en bewees. Hij was een wiskundige die vragen over “wat berekenbaar is” als precieze problemen behandelde—en de antwoorden doortrok tot in echte machines.
Zijn paper uit 1936, On Computable Numbers, deed twee blijvende dingen: het beschreef een abstract model voor berekening (nu de Turingmachine) en gebruikte dat model om aan te tonen dat sommige vragen over programma’s in het algemeen niet opgelost kunnen worden. Dit was geen sciencefiction; het was een zorgvuldige redenering over de grenzen van logica en rekenwerk.
Tijdens de Tweede Wereldoorlog werkte Turing in Bletchley Park aan cryptanalyse—manieren vinden om versleutelde berichten te kraken. Populaire verhalen suggereren soms dat hij “in zijn eentje” Enigma kraakte of “de computer” in één keer uitvond. De werkelijkheid is interessanter: hij was een cruciale bijdrager in een groot team, ontwierp methoden en hielp bij het vormgeven van elektromechanische hulpmiddelen die wiskundig inzicht omzettten in herhaalbaar, operationeel werk.
Turing’s kracht was het bewegen tussen bewijs en praktijk. Hij kon redeneren over een geïdealiseerde machine op papier en vervolgens procedures en hardware-ontwerpen helpen maken die een echt systeem sneller en betrouwbaarder maakten. Die mix—formeel denken plus praktische implementatie—is een blauwdruk voor moderne informatica.
Turing’s ideeën klinken door in meerdere gebieden: de fundamenten van moderne informatica (berekenbaarheid en beslisbaarheid), vroege veiligheidsdenken (systematische cryptanalyse) en latere debatten over machine-intelligentie. Zelfs wanneer mensen het oneens zijn met zijn conclusies, gebruiken ze vaak het kader dat hij hielp definiëren.
Een algoritme is simpelweg een duidelijke set stappen om tot een resultaat te komen. Het is niet automatisch “wiskundig” of zelfs computergerelateerd—gewoon een methode die je betrouwbaar kunt volgen.
Denk aan een basisrecept voor thee maken:
Dat is een algoritme: ondubbelzinnige stappen, in volgorde, met een voorspelbaar resultaat.
Vroege machines waren vaak enkelfunctioneel: gebouwd om één taak goed te doen, zoals bepaalde patronen weven, tabellen berekenen of berichten versleutelen/ontcijferen voor een specifiek systeem. Voor een andere taak had je meestal een andere machine of een ingrijpende verbouwing nodig.
Een general-purpose computer is anders. Hij is ontworpen om veel verschillende algoritmen uit te voeren, afhankelijk van de instructies die je geeft. De fysieke hardware blijft hetzelfde; wat verandert is het programma.
Software is in wezen een manier om algoritmen op te schrijven zodat een machine ze precies kan uitvoeren. In plaats van “wacht 3–5 minuten” zegt een programma misschien “wacht 240 seconden.” In plaats van “als je suiker wilt” kan het zeggen “als de gebruiker suiker selecteerde, voeg één theelepel toe.”
Die verschuiving—instructies behandelen als iets wat een machine kan opslaan, lezen en uitvoeren—legde het fundament voor moderne computing: één apparaat, ontelbare taken, allemaal gedreven door algoritmen.
Je ziet het general-purpose idee terug in hedendaagse vibe-coding-tools: in plaats van elke stap handmatig te schrijven, beschrijf je het doel en zet het systeem die specificatie om in uitvoerbare software.
Bijvoorbeeld, Koder.ai laat je web-, backend- en mobiele applicaties bouwen via een chatinterface—en vervolgens broncode exporteren, deployen en hosten. Onder de motorkap komt het nog steeds terug op Turing’s kader: het systeem genereert uiteindelijk programma’s (algoritmen + data + controleflow) die binnen echte beperkingen als tijd, geheugen, beveiliging en correctheid moeten draaien.
Een Turingmachine is het best te begrijpen als gedachte-experiment: een opzettelijk simpele “imaginaire computer” ontworpen om vast te leggen wat het betekent iets stap voor stap te berekenen. Turing probeerde niet dit apparaat fysiek te bouwen; hij wilde berekening zó definiëren dat je er dingen over kon bewijzen.
Stel je een oneindig lange strook papier voor (de tape) verdeeld in vakjes. Elk vakje kan een symbool bevatten—zoals een lege plek, een 0 of een 1. Een leeskop staat boven één vakje tegelijk.
Voeg nu een klein instructiekaartje toe dat de kop vertelt wat te doen. De machine bevindt zich altijd in één van een klein aantal toestanden (denk aan “op zoek naar het volgende cijfer” of “klaar”).
Voor elke combinatie van (huidige toestand + huidig tapesymbool) is er een regel die zegt:
Dat is alles—en toch kan de machine met de juiste regels elke berekening uitvoeren die wij als algoritme herkennen.
De Turingmachine geeft een scherpe definitie van berekening: een eindige set mechanische regels die op een geheugenruimte werken. Het is een wiskundig model, geen hardware-blauwdruk.
Omdat het model zo minimaal is, is het krachtig voor bewijzen: als iets niet eens door deze geïdealiseerde machine berekend kan worden, kan het ook niet door gewone computers worden berekend.
Moderne programma’s lijken nergens op een tape en een kop, maar de vertaling is direct: geheugen houdt data, controleflow verandert toestand, en instructies transformeren symbolen.
Zelfs “stored procedures” in databases passen in hetzelfde patroon: vaste regels die data lezen, bijwerken en door gedefinieerde stappen lopen—berekening als een herhaalbaar, regelgestuurd proces.
Sommige vragen over programma’s lijken alsof ze een heldere, mechanische oplossing zouden moeten hebben. Turing toonde aan dat voor een belangrijke klasse vragen die hoop onmogelijk is—niet omdat we niet slim genoeg zijn, maar omdat het antwoord niet kan bestaan als een algemene methode.
Een probleem is beslisbaar als er een procedure (een algoritme) is die altijd stopt en correct ja/nee antwoordt voor elke invoer.
Een probleem is onbeslisbaar als geen algoritme dat voor alle gevallen kan doen. Je kunt veel voorbeelden oplossen, maar je kunt geen enkele “altijd-kloppende, altijd-stoppende” beslisser bouwen.
Het haltingsprobleem vraagt:
Gegeven een willekeurig programma en zijn invoer, kunnen we altijd bepalen of het programma uiteindelijk stopt (halt) of oneindig doorgaat?
Turing bewees dat het antwoord nee is. Er is geen universele checker die elk programma en elke invoer kan bekijken en altijd correct het stoppen voorspelt.
Als je accepteert dat “voorspellen of elk programma terminaal is” onmogelijk is, worden veel schijnbaar redelijke “perfecte analyse”-tools ook onmogelijk.
Een “universele bugdetector” zou betekenen: voer hem elk programma toe en hij zegt betrouwbaar of het een bepaald soort bug bevat. Maar veel bug-eigenschappen zijn herformuleerbaar als “bereikt dit programma ooit een bepaalde toestand?”—en daarmee kun je het haltingsprobleem coderen.
Dus echte tools moeten concessies doen: ze zijn onvolledig (missen bugs), of geven soms vals alarm, of werken alleen voor beperkte programmatypes.
Neem de eigenschap: “Dit programma raakt nooit in een oneindige lus.” Als een tool dit perfect voor alle programma’s zou kunnen verifiëren, zou dat ook het haltingsprobleem oplossen. Omdat dat onbeslisbaar is, is perfecte controle in het algemeen niet beschikbaar.
Dit is waarom linters, typecheckers en statische analyzers waardevol zijn—maar niet magisch.
Een belangrijke les na Turing is dat “berekenbaar” niet hetzelfde is als “bruikbaar.” Sommige taken zijn in principe mogelijk—er bestaat een programma dat uiteindelijk stopt—maar nog steeds onrealistisch in de praktijk omdat het programma te veel tijd of geheugen vereist.
Stel je een programma voor dat een puzzel oplost door elke combinatie te proberen. Het werkt uiteindelijk, maar als het aantal combinaties sneller groeit dan computers verbeteren, kan “uiteindelijk” langer duren dan de leeftijd van het universum.
Dit is de praktische kant van grenzen van berekening: niet of er een oplossing bestaat, maar of die binnen echte beperkingen past.
Elk programma verbruikt middelen:
Een verschil dat op papier klein lijkt, kan in de praktijk enorm zijn. Een methode die het werk verdubbelt als de invoer verdubbelt blijft vaak beheersbaar; een methode die het werk kwadrateert (of erger) wordt snel onbruikbaar.
Computerwetenschappers groeperen problemen op basis van hoe hun benodigde tijd en ruimte groeien. Zonder zware wiskunde is het idee simpel:
Deze indelingen verschijnen vaak als complexiteitsklassen—labels die problemen scheiden die we efficiënt verwachten op te lossen van die we dat niet doen.
In cryptografie is moeilijkheid vaak een functie. Veel beveiligingssystemen leunen op taken die één kant makkelijk maken (vergrendelen) maar het omkeren zonder sleutel extreem duur maken (kraken).
Dus terwijl complexiteitsgrenzen bepalen wat we snel kunnen berekenen, verklaren ze ook waarom moderne beveiliging überhaupt werkt, zelfs bij krachtige aanvallers.
Cryptanalyse is het vak van geëncrypteerde boodschappen analyseren om hun betekenis te herstellen zonder de geheime sleutel te kennen. Tijdens WOII was dit belangrijk omdat versleutelde communicatie plannen en orders bevatte op een schaal waarbij manueel ontcijferen te traag werd.
Als je berichten niet op tijd kunt lezen, kun je er niet op reageren—dus snelheid en herhaalbaarheid werden net zo belangrijk als slimheid.
Goede ciphering probeert berichten eruit te laten zien als willekeurige ruis. Cryptanalyse zoekt naar manieren waarop de realiteit teruglekt: patronen in taal, herhaalde formats, voorspelbare headers of menselijke gewoonten. In plaats van elk bericht als een op zichzelf staande puzzel te zien, behandelden codebrekers interceptie als een data‑probleem.
Een praktische aanpak combineert drie ingrediënten:
Hier toont zich vroege computerwetenschappelijke denkwijze: definieer het probleem precies, reduceer het tot stappen, en bouw systemen die die stappen sneller uitvoeren dan een mens.
Moderne beveiliging begint nog steeds met dezelfde mentaliteit: neem een tegenstander aan die slim, vasthoudend is en onder beperkingen werkt. Verdedigers maken aannames (over geheimhouding, sleutelbeheer, gebruikersgedrag, device-integriteit) en aanvallers zoeken het zwakste punt.
Het is ook een wereld van afwegingen. Sterkere encryptie kan de gebruiksvriendelijkheid verminderen. Meer monitoring kan privacykwesties oproepen. Snellere detectie kan leiden tot meer valse alarmen.
De les uit Turing’s tijd blijft: beveiliging gaat niet alleen over “beste algoritmen”, maar over systemen, incentives en hoe echte mensen ze gebruiken.
Turing werkte in een tijd waarin berichten letterlijk leven-of-dood konden zijn—en die druk vertaalt zich goed naar moderne beveiligingsdoelen.
Beveiliging komt meestal neer op een paar eenvoudige ideeën:
Turing’s tijd benadrukte dat je deze eigenschappen zelden “gratis” krijgt. Je moet ze ontwerpen en onder druk testen.
Moderne cryptografie leunt op wiskundige moeilijkheid: problemen die één kant makkelijk maken maar terugvinden zonder sleutel zeer moeilijk. Dat is het “wiskundige slot”.
Maar de “sleutel” is vaak het echte zwakke punt. Sleutelbeheer betekent sleutels veilig genereren, opslaan zodat ze niet gekopieerd worden, roteren wanneer nodig en snel intrekken als er iets misgaat.
Briljante algoritmen kunnen ondermijnd worden door een gelekte sleutel, een hergebruikt wachtwoord of een niet-gepatchte server.
Aanvallers passen zich aan. Beveiliging draait meestal niet om perfectie maar om risicoreductie: aanvallen duur, detecteerbaar en beperkt maken.
Tegenwoordig automatiseren aanvallers wat ooit gespecialiseerde teams vergde: wachtwoord raden, phishing, en het scannen van miljoenen systemen. Op internetschaal worden kleine fouten grote incidenten—verkeerd geconfigureerde cloudopslag, gekopieerde credentials of één medewerker die op de verkeerde link klikt.
De blijvende les is praktisch: combineer goede wiskunde met gedisciplineerde operatie en ga ervan uit dat het systeem continu aangevallen wordt.
Wanneer mensen praten over wat een computer “kan” doen, bedoelen ze meestal iets preciezer dan “alles wat je kunt bedenken.” De Church–Turing-stelling is de praktische vuistregel die die lijn trekt: een taak is berekenbaar als er een stapsgewijze procedure (een algoritme) bestaat die stopt met het juiste antwoord, en die procedure uitgevoerd kan worden door een Turingmachine.
Ondanks de naam is dit niet iets wat je op de gebruikelijke wiskundige manier kunt bewijzen—omdat het een formeel model (zoals een Turingmachine) koppelt aan een informele gedachte (“elke effectieve rekenmethode”). In de decennia erna is het idee ondersteund door bewijs: elke keer dat mensen een nieuw redelijk rekencmodel voorstelden (programmeertalen, schakelingen, cellulaire automaten, moderne CPU's), bleek het dezelfde set van berekenbare problemen te vangen.
De stelling laat ons heel verschillende computers en talen vergelijken zonder in details te verdwalen. Als twee systemen “Turing-compleet” zijn, dan kunnen ze—gegeven genoeg tijd en geheugen—dezelfde functies berekenen.
Daarom verschillen je telefoon, laptop en een cloudserver vooral in snelheid, kosten en schaal, niet in de fundamentele soorten problemen die ze kunnen oplossen.
Church–Turing belooft niet dat elke vraag een algoritmische oplossing heeft. Sommige problemen zijn onberekenbaar (zoals het haltingsprobleem), wat betekent dat geen enkel programma ze voor alle gevallen kan beantwoorden.
En zelfs wanneer iets berekenbaar is, kan het zo traag zijn dat het onbruikbaar is in de praktijk—een apart thema dat complexiteitstheorie behandelt.
Turing merkte op dat de vraag “Kunnen machines denken?” glibberig is. “Denken” kan gevoelens, begrip, creativiteit, zelfbewustzijn of gewoon goede antwoorden betekenen. Zonder eensgezindheid over de definitie kun je geen duidelijke test bouwen.
Turing stelde voor om de vage vraag te vervangen door een praktische: kan een machine zich intelligent gedragen in een gesprek?
In de klassieke opzet chat een menselijke rechter (meestal via tekst) met twee verborgen deelnemers: één mens en één machine. De rechter mag alles vragen en moet dan beslissen wie wie is. Als de rechter het niet betrouwbaar kan onderscheiden, wordt gezegd dat de machine de test heeft doorstaan.
Dit draait minder om “bewijzen” van intelligentie en meer om het stellen van een meetbaar doel: niet te onderscheiden prestaties in een specifieke interactie.
De Turingtest richt zich op buitenwaarschijnlijk gedrag in een beperkte setting. Dat is een kracht (observeerbaar), maar ook een beperking:
De chatbots van vandaag kunnen in korte uitwisselingen opmerkelijk menselijk aanvoelen, wat Turing’s idee weer relevant maakt. Tegelijk toont het evaluatievalkuilen: benchmarks kunnen worden ‘gegamed’ door stijl of bekendheid met testformaten, en een systeem dat goed kan chatten faalt mogelijk op feitelijke nauwkeurigheid, langetermijnredenering of consistente besluitvorming.
De blijvende les is niet dat conversatie het ultieme meetinstrument is—maar dat we zorgvuldige, transparante tests nodig hebben en eerlijk moeten zijn over wat een test meet.
AI-systemen lijken open-eindig, maar ze draaien nog steeds op programma’s—dus ze erven de grenzen die Turing helder maakte. Die grenzen zijn belangrijk bij het beslissen wat realistisch is, wat duur is en wat in principe onmogelijk is.
Veel AI-taken zijn berekenbaar maar duur: een model trainen, een antwoord zoeken of een plan optimaliseren kan enorme hoeveelheden tijd en energie kosten. Meer data en snellere hardware helpen soms sterk.
Andere doelen botsen tegen diepere grenzen. Sommige vragen kunnen door geen algemene procedure voor alle gevallen beantwoord worden (in de geest van onbeslisbaarheid). Bijvoorbeeld: “bewijs dat dit willekeurige systeem nooit faalt” is niet alleen moeilijk; voor brede klassen systemen is dat niet volledig automatisch te doen zonder uitzonderingen en aannames.
Zelfs als een probleem berekenbaar is, kan het onhandelbaar zijn: de benodigde tijd kan zo snel groeien dat “meer data toevoegen” niet helpt. Dat zie je bij langetermijnplanning, uitputtende verificatie en bepaalde vormen van worst-case redenering.
AI kan benaderen of raden, maar garanties worden duur.
Omdat perfecte garanties beperkt zijn, draait evaluatie om onzekerheid managen: foutpercentages meten, zeldzame scenario’s stress-testen en falingsmodi in de loop van de tijd volgen. De moeilijkste bugs zitten vaak in randgevallen die niet in typische benchmarks voorkomen.
Beveiliging wordt ook door deze grenzen gevormd. Je kunt niet alle slecht gedrag alleen met regels uitfilteren en je kunt niet elke interactie volledig verifiëren.
Prompt injection, data poisoning en misbruik herinneren ons eraan dat verdedigingen gelaagd moeten zijn: monitoring, toegangscontrole, red-teaming en zorgvuldige systeemontwerpen—niet één perfecte test.
Turing’s werk wordt vaak als geschiedenis onderwezen, maar het is nuttiger als een set “spelregels” om helder na te denken over wat computers wel en niet kunnen.
1) Berekenbaarheid (wat überhaupt mogelijk is). De Turingmachine geeft een heldere manier om te praten over welke problemen door een stapsgewijze procedure opgelost kunnen worden. Het haltingsprobleem is hier het kopstuk: sommige vragen over programma’s zijn in het algemeen niet oplosbaar, hoe slim je ook bent.
2) Complexiteit (wat mogelijk is binnen echte tijd en middelen). Veel taken zijn berekenbaar maar worden onbruikbaar zodra invoer groeit—omdat tijd, geheugen of energie exploderen. Daarom betekent “werkt op een klein voorbeeld” nog niet “werkt in de echte wereld.”
3) Beveiliging (hoe grenzen ons kunnen beschermen). Moderne cryptografie leunt op praktische grenzen: niet dat het kraken onmogelijk is, maar dat het te duur of te traag is om op schaal te doen. Turing’s codekraken herinnert ons eraan dat aanvallers wiskunde, engineering en operationele shortcuts gebruiken—niet alleen brute kracht.
Als je voor een rekenprobleem staat, stel dan drie vragen op volgorde:
Als je dieper wilt duiken, zijn goede volgende onderwerpen:
Vooruitgang in computing is echt—snellere hardware, betere algoritmen, sterkere beveiligingstools. De grenzen zijn ook echt, en ze begrijpen is een praktisch voordeel: het helpt je het juiste gereedschap kiezen, realistische verwachtingen stellen en je niet laten misleiden door beloften die wiskunde negeren.
Een Turingmachine is een minimaal, abstract rekenschema: een tape (geheugen), een lees-/schrijfkop en een eindige set regels (toestanden). Het is belangrijk omdat het een precieze manier geeft om te praten over wat “een programma” in principe kan doen—ongeacht specifieke hardware of programmeertaal.
De Church–Turing-stelling is de bewering dat alles wat berekend kan worden door een effectieve, stapsgewijze procedure ook door een Turingmachine berekend kan worden. Het is geen formeel bewezen stelling in de wiskundige zin; het is een goed onderbouwd uitgangspunt dat helpt verschillende rekenmodellen (CPU's, talen, schakelingen) onder één begrip van “berekenbaar” te vergelijken.
“Berekenbaar” betekent dat er een algoritme bestaat dat het juiste antwoord zal produceren (uiteindelijk). “Efficiënt berekenbaar” betekent dat het dit doet met praktische tijd en geheugen wanneer de invoer groter wordt. Veel echte problemen ontstaan doordat mensen deze twee door elkaar halen: iets kan wel berekenbaar zijn, maar onbruikbaar omdat de kosten exploderen.
Het haltingprobleem vraagt of er een universeel algoritme bestaat dat voor elk programma en elke invoer kan bepalen of dat programma uiteindelijk stopt of oneindig blijft draaien. Turing bewees dat zo’n universele beslisser niet kan bestaan. In de praktijk is dit de reden dat veel “perfecte” analysers voor willekeurige code onmogelijk zijn.
Omdat veel eigenschappen van bugs herformuleerbaar zijn als “bereikt het programma ooit deze staat?”, kun je daarmee het haltingprobleem coderen. Praktische tools moeten dus compromissen sluiten: ze kunnen
Daarom is goede statische analyse waardevol, maar nooit magisch.
Complexiteit gaat over hoe de benodigde middelen groeien met de invoergrootte—voornamelijk tijd en ruimte. Een kleine verandering in groeisnelheid kan op schaal alles domineren (bijv. verdubbelen versus kwadrateren van werk). Daarom kan een methode die op een klein voorbeeld werkt, onbruikbaar worden met echte data.
Moderne cryptografie steunt vaak op problemen die makkelijk zijn met een sleutel maar extreem kostbaar om zonder sleutel om te keren. Die ‘kostengap’ is meestal een complexiteitsaanname: aanvallers kunnen het in principe berekenen, maar niet binnen realistische tijd/prijs op schaal. Met andere woorden: grenzen zijn niet alleen obstakels—ze vormen onderdeel van het veiligheidsontwerp.
Turing’s codekraken toonde een blijvende aanpak: combineer structuur, statistiek en automatisering.
Moderne beveiliging volgt nog steeds dit patroon, alleen dan op internetschaal.
De Turingtest meet of een machine in een beperkte gespreksomgeving menselijk-achtige conversatiegedragingen kan vertonen. Het is bruikbaar als gedragsbenchmark, maar het meet niet direct begrip, bewustzijn of waarheidsgetrouwheid. Het kan overtuiging en stijl belonen boven betrouwbaarheid.
AI-systemen draaien op programma's en erven dus dezelfde berekenbaarheids- en complexiteitsbeperkingen die Turing beschreef. Je kunt meestal geen absolute, universele garanties krijgen zoals “dit systeem faalt nooit in elke situatie”; sommige verificatiedoelen stuiten op onbeslisbaarheid voor brede klassen systemen. In de praktijk leidt dit tot risicomanagement: testen, monitoren, gelaagde verdedigingen en duidelijke aannames.