Formell verifiering: enda vägen att tillfredsställa AI-regulatorer
Samtalet som aldrig går bra
Föreställ dig den här scenen. Den utspelar sig varje vecka i styrelserum över hela Europa, på FDA:s granskningsmöten, på försäkringsbolagens riskbedömningsavdelningar. En AI-ingenjör presenterar sitt senaste system för regulatorer, jurister eller riskbedömare.
”Vår automatiska insulinkanyl uppnådde 99,97 procents träffsäkerhet i 50 miljoner testsituationer”, säger ingenjören stolt och klickar fram en bild full av imponerande siffror. ”Världsledande. Bättre än någon mänsklig endokrinolog.”
Det blir tyst i rummet. Regulatorn lutar sig framåt.
”Så du menar alltså”, säger hon långsamt, ”att av varje 10 000 insulindoser som den här enheten ger … så kan tre vara fel?”
Ingenjören skruvar på sig. ”Tja, statistiskt sett …”
”Bara i Tyskland har ungefär 7 miljoner människor diabetes som kräver insulinbehandling. Om varje person får fyra doser om dagen blir det 28 miljoner administreringar per dygn. Med din felprocent på 0,03 …” Hon räknar på sitt block. ”Det blir 8 400 potentiella dosfel. Varje enda dag.”
”Men de flesta av dem skulle inte vara kliniskt signifikanta …”
”Kan du berätta vilka som skulle vara det?”
Tystnad.
”Kan du berätta när nästa fel kommer att inträffa? Kan du berätta varför det kommer att inträffa?”
Ännu mer tystnad.
”Då är jag rädd att vi inte kan godkänna den här enheten.”
Den här konversationen, i olika former, utspelar sig ständigt när AI rör sig från forskningslaboratorier ut i den fysiska världen. Och den blottlägger en grundläggande epistemologisk klyfta mellan hur AI-ingenjörer tänker kring säkerhet och hur tillsynsmyndigheter, jurister och domstolar tänker kring den.
Språkbarriären som inte handlar om språk
När AI-ingenjören säger "99,97 % noggrannhet" tror de verkligen att de beskriver något imponerande och säkert. I maskininlärningssammanhang skulle den siffran hyllas. Artiklar skulle publiceras. Investerare skulle vara entusiastiska.
Men regulatorn hör något helt annat. De hör: "Det finns en liten men inte obefintlig sannolikhet att detta system kommer att misslyckas katastrofalt, och vi har ingen aning om när, var eller varför det kommer att hända."
Det här är inte ett kommunikationsproblem. Det handlar inte om att ingenjörer behöver bättre presentationsförmåga eller att regulatorer behöver teknisk utbildning. Det är en grundläggande kollision mellan två olika uppfattningar om vad "att veta att något fungerar" faktiskt innebär.
Inom konsumentmjukvara är probabilistiska metoder fullt acceptabla. Om Netflix rekommenderar en film du hatar dör ingen. Om Spotify föreslår en låt som inte matchar din smak är värsta fallet lätt irritation. Dessa system har råd att ha fel ibland eftersom kostnaden för misslyckande är trivial.
Men AI rör sig snabbt bortom konsumentrekommendationer till områden där misslyckande har fysiska, juridiska och moraliska konsekvenser: autonoma fordon som fattar beslut på bråkdelen av en sekund om fotgängare, medicintekniska produkter som beräknar läkemedelsdoser, industrirobotar som arbetar sida vid sida med mänskliga arbetare, finansiella system som godkänner eller nekar krediter som avgör om familjer kan köpa bostäder.
Inom dessa områden räcker inte "ganska säkert att det fungerar". Domstolar accepterar inte sannolikhetsfördelningar som bevis. Försäkringsaktuarie kan inte prissätta försäkringar för okända felscenarier. Regulatorer kan inte godkänna produkter som kanske dödar människor av skäl ingen kan förklara.
Varför testning, hur omfattande den än är, inte kan ge säkerhet
Det dominerande paradigmet inom AI-utvärdering idag är empirisk testning på separerade dataset. Du tränar din modell på Dataset A och utvärderar den sedan på Dataset B. Om den presterar bra på B antar du att den har "lärt sig" den underliggande uppgiften och kommer att generalisera till verklig driftsättning.
Denna metod har tre grundläggande problem som ingen mängd testning kan lösa.
Problem ett: Det oändliga indatautrymmet
Testning kan bara påvisa förekomsten av buggar, aldrig deras frånvaro. Oavsett hur många testfall du kör samplar du från ett oändligt indatautrymme. Ett system som styr en medicinteknisk produkt måste hantera inte bara de testscenarier du föreställt dig, utan varje tänkbar kombination av patientfysiologier, miljöförhållanden, sensoravläsningar och gränsfall som den verkliga världen så småningom kommer att producera.
Föreställ dig att försöka bevisa att det inte finns några nålar i en höstack genom att slumpmässigt plocka upp höstrån. Efter att ha undersökt en miljon strån utan att hitta några nålar kan du inte dra slutsatsen att höstacken är nålfri. Du kan bara säga att du ännu inte har hittat någon. Testning fungerar på samma sätt. Oavsett hur många scenarier som klarar sig kan nästa misslyckas.
Problem två: Sårbarheten för adversariella attacker
Djupa neurala nätverk är särskilt sårbara för adversariella indata. Det är omsorgsfullt konstruerade störningar som får modeller att misslyckas katastrofalt samtidigt som de ser normala ut för mänskliga observatörer.
En modell kan klassificera stoppskyltar korrekt i 99,99 % av fallen, men en liten dekal på rätt ställe kan få den att med hög säkerhet klassificera skylten som en hastighetsskylt. En modell kan identifiera medicinska tillstånd korrekt i tusentals röntgenbilder, men ett specifikt brusmönster, osynligt för mänskliga radiologer, kan få den att missa uppenbara tumörer.
Det här är inte teoretiska farhågor. Forskare har visat att adversarial attacker fungerar mot varje större typ av neurala nätverksarkitekturer. Och attackerna blir allt lättare att konstruera medan försvaren fortfarande är ofullständiga.
Testning kan inte skydda mot sårbarheter för adversarial attacker eftersom attackytan är oändlig. Du skulle behöva testa inte bara normala indata, utan varje tänkbar perturbation av varje normal indata. Det är matematiskt omöjligt.
Problem tre: Distributionsförskjutningen
Den verkliga världen står inte stilla. Den datadistribution som din modell tränades på kommer att förskjutas över tid. Patientpopulationer förändras. Körförhållanden utvecklas. Tillverkningsprocesser varierar. Sensordegradering uppstår.
En modell som presterar perfekt på dagens data kan misslyckas tyst när morgondagens data hamnar utanför dess träningsdistribution. Och till skillnad från explicita fel som får program att krascha, ger dessa misslyckanden ofta säkra, trovärdiga men felaktiga utdata.
Att testa på dagens data säger ingenting om morgondagens prestanda. När du väl observerar felet i produktion har skadan redan skett.
Formell verifiering: matematik som säkerhetens universella språk
Formell verifiering erbjuder ett helt annat angreppssätt. I stället för att fråga "fungerade systemet på dessa testfall?" frågar den "kan vi matematiskt bevisa att systemet uppfyller en egenskap för alla möjliga indata?"
Skillnaden är djupgående. Testning samplar indatautrymmet. Verifiering resonerar uttömmande om hela utrymmet.
Betrakta en robotarm som arbetar tillsammans med människor i en fabrik. Vi vill garantera en säkerhetsegenskap: "Armen får aldrig överstiga 2 meter per sekund när en människa detekteras inom 1 meter."
Testansatsen kör armen genom tusentals scenarier med simulerade människor på olika positioner och hastigheter och mäter om säkerhetsgränsen någonsin överträds. Om inga överträdelser observeras förklaras systemet "säkert". Men nästa scenario, det som inte testades, kan vara det som skadar en arbetare.
Verifieringsansatsen är fundamentalt annorlunda. Vi tar den matematiska modellen av styrsystemet, inklusive det neurala nätverk som bearbetar sensordata och styrenheten som genererar motorkommandon. Vi uttrycker säkerhetsegenskapen som en formell begränsning. Sedan använder vi specialiserade algoritmer som kallas SMT-lösare (Satisfiability Modulo Theories) för att besvara en precis fråga: "Finns det NÅGON indatakonfiguration, inom det giltiga operativa intervallet, för vilken utgångshastigheten överstiger 2 m/s när mänsklig närhet detekteras?"
Lösaren testar inte slumpmässiga punkter. Den analyserar hela systemets matematiska struktur. Den resonerar om funktionsutrymmets geometri. Om den returnerar "UNSAT" (ej uppfyllbar) har vi ett matematiskt bevis för att ingen sådan överträdande indata existerar. Säkerhetsegenskapen gäller inte bara för de fall vi testade, utan för varje möjligt fall som någonsin kan inträffa.
Detta är skillnaden mellan "jag kontrollerade många broar och ingen kollapsade" och "fysiken hos dessa material garanterar matematiskt att denna bro inte kan kollapsa under denna last." Det ena är en empirisk observation som kan revideras. Det andra är en logisk visshet.
Varför modern AI motstår verifiering
Om formell verifiering är så kraftfull, varför använder inte alla den? Varför förlitar sig företag som OpenAI och Google på "red teaming" (människor som försöker bryta modellen) i stället för matematiska bevis?
Svaret ligger i de arkitektoniska val som branschen har gjort. Moderna stora språkmodeller och djupa neurala nätverk är designade för uttrycksfullhet, inte verifierbarhet. De är optimerade för att generera kreativa utdata, inte för att vara matematiskt analyserbara.
En typisk transformatormodell har miljarder eller biljoner parametrar. Den använder komplexa, olinjära aktiveringsfunktioner som GeLU eller Swish. Den matematiska komplexiteten i att verifiera ett sådant system skalar exponentiellt med antalet neuroner och nätverkets djup.
Att bevisa en egenskap på en transformator med en miljard parametrar är beräkningsmässigt omöjligt. Universum skulle nå värmdöden innan lösaren hade utforskat alla matematiska grenar. Branschen har byggt system så komplexa att inte ens deras skapare fullt ut kan analysera dem.
Detta är ett designval, inte en oundviklighet. Branschen optimerade för imponerande demonstrationer och benchmarkresultat utan att överväga om de resulterande systemen någonsin skulle kunna användas säkert i reglerade miljöer.
Dweve-arkitekturen: verifierbar genom design
På Dweve gjorde vi andra arkitektoniska val. Vi designade våra system från grunden för att vara verifierbara, eftersom vi förstod att företags- och industrikunder så småningom skulle behöva tillfredsställa tillsynsmyndigheter, inte bara imponera på dem.
Vår metod kombinerar två viktiga innovationer som gör verifiering hanterbar.
Binär begränsningsupptäckt: enkel matematik
Istället för massiva flyttalsbaserade neurala nätverk med miljarder kontinuerliga parametrar använder Dweve-systemen binär begränsningsupptäckt. Kunskap representeras som diskreta logiska begränsningar snarare än inlärda kontinuerliga vikter.
Vårt Dweve Core-bibliotek innehåller 1 937 hårdvaruoptimerade algoritmer byggda på binära operationer: XNOR, AND, OR, POPCNT. Dessa operationer har enkla, väldefinierade matematiska egenskaper. En binär begränsning gäller antingen eller inte. Det finns ingen probabilistisk osäkerhet.
Genom att begränsa matematiken till enkla linjära samband och boolesk logik minskar vi dramatiskt verifieringens sökutrymme. Problem som skulle vara olösliga för kontinuerliga neurala nätverk blir lösbara för våra binära begränsningssystem. Verifieringsproblemet omvandlas från omöjlig icke-linjär optimering till lösbara Mixed Integer Linear Programming (MILP)- eller SAT-problem.
Dessa är fortfarande beräkningsmässigt svåra problem, men för storleken på de system vi använder i säkerhetskritiska tillämpningar kan moderna lösare hantera dem på sekunder eller minuter snarare än århundraden.
Sexlagersarkitekturen för begränsad autonomi
Vi försöker inte verifiera alla aspekter av AI-perception. Att inse att "ett pixelrutnät representerar en människa" är i sig en vag, probabilistisk bedömning. Man kan inte formellt bevisa att mönsterigenkänning alltid är korrekt, eftersom korrekthet beror på subjektiva definitioner.
Istället implementerar vi en skiktad säkerhetsarkitektur där probabilistiska AI-komponenter begränsas av formellt verifierade logiska begränsningar. AI:n kan föreslå åtgärder, men dessa förslag måste passera verifierade säkerhetsgrindar innan de utförs.
Dweve Nexus implementerar sex lager av säkerhetsåtgärder:
- Avsiktsverifiering: Validerar att AI-åtgärder överensstämmer med deklarerade mål
- Begränsad autonomi: Hårda gränser för vilka åtgärder som är tillåtna oavsett AI-förslag
- Innehållsmoderering: Filtrerar utdata för säkerhet och lämplighet
- Etiktillämpning: Säkerställer efterlevnad av definierade etiska begränsningar
- Avvikelsedetektering: Identifierar när AI-beteende avviker från förväntade mönster
- Körtidsövervakning: Kontinuerlig verifiering att säkerhetsinvariabler upprätthålls
Den kritiska insikten är att vi bara behöver formellt verifiera säkerhetslagren, inte hela AI-systemet. Även om den underliggande AI:n gör ett fel, garanterar lagret för begränsad autonomi matematiskt att farliga kommandon aldrig når ställdon.
Regulatorisk matematik: varför verifiering skapar affärsvärde
För våra kunder är formell verifiering ingen akademisk övning. Det är en konkurrensfördel som direkt översätts i affärsresultat.
Snabbare regulatoriskt godkännande
När en tillverkare av medicintekniska produkter kontaktar FDA eller EMA med ett AI-drivet system är regulatorerna med rätta försiktiga. De vet att AI kan vara oförutsägbar. Standardprocesser för godkännande kräver år av kliniska prövningar för att statistiskt visa säkerhet.
Men en tillverkare som använder formellt verifierade Dweve-komponenter kan förändra samtalet. I stället för att presentera testresultat som visar "vi har ännu inte observerat fel" kan de presentera matematiska bevis som visar "fel är omöjliga inom dessa gränser."
"Vi tror inte bara att den här insulinpumpen inte kommer att överdosera patienter. Här är det formella beviset för att den utgående dosen matematiskt begränsas av patientens vikt och glukosnivå. Överträdelse är inte bara osannolik. Den är logiskt omöjlig."
Detta möjliggör snabbare granskningsvägar. Regulatorer kan verifiera beviset oberoende. De behöver inte lita på testprocessen; de kan granska matematiken direkt.
Lägre försäkringspremier
Försäkringsaktuarieer står inför ett omöjligt problem med traditionella AI-system. Hur prissätter man risk för felscenarier man inte kan förutsäga eller förklara? Resultatet blir antingen extremt höga premier för att täcka okända risker, eller undantagsklausuler som gör försäkringen praktiskt taget värdelös.
Verifierade system förändrar den aktuariella beräkningen. Om ett matematiskt bevis garanterar att vissa typer av fel inte kan inträffa, kan dessa felscenarier uteslutas från riskmodellen. De återstående riskerna är kvantifierbara. Premierna minskar därefter.
En del av våra kunder har sett kostnaderna för ansvarsförsäkring sjunka med 40-60 procent efter att de infört verifierade säkerhetslager, helt enkelt för att försäkringsgivare nu kan beräkna avgränsade risker i stället för att prissätta för obegränsad osäkerhet.
Juridiskt försvar
När AI-system orsakar skada följer rättsprocesser. I traditionella AI-utrullningar är det nästan omöjligt att försvara systemet. "Hur fattade ert system detta beslut?" "Vi vet inte exakt, det är ett neuralt nätverk med miljarder parametrar..." Det svaret tillfredsställer varken domare eller jury.
Verifierade system erbjuder ett annat försvar: "Här är säkerhetsbegränsningen. Här är det matematiska beviset för att begränsningen inte kan överträdas. Skadan inträffade utanför den verifierade gränsen, vilket indikerar externa faktorer, inte systemfel."
Det handlar inte om att undvika ansvar. Det handlar om att kunna visa exakt vilka garantier som gavs och om de upprätthölls. Domstolar förstår formell logik. De förstår matematiska bevis. De förstår inte probabilistiska konfidensintervall.
The EU AI Act: Verification Becomes Mandatory
The theoretical advantages of formal verification are becoming practical requirements. The EU AI Act, which entered force in 2024 with phased implementation through 2027, fundamentally changes what's legally required for AI deployments in Europe.
For "high-risk" AI systems, which include medical devices, employment decisions, creditworthiness assessments, and many industrial applications, the Act requires:
- Risk management systems that identify and mitigate foreseeable risks
- High quality training data with documented provenance
- Logging capabilities that enable tracing of system behavior
- Transparency to users about AI-made decisions
- Human oversight mechanisms that allow intervention
- Accuracy, robustness, and cybersecurity appropriate to the application
Notice the language: "foreseeable risks," "traceable behavior," "accuracy appropriate to the application." These aren't vague aspirations. They're legal requirements with enforcement teeth including fines up to 35 million euros or 7% of global turnover.
How do you demonstrate that you've identified and mitigated "foreseeable risks" for a neural network with billions of parameters whose decision process is opaque even to its creators? How do you show that behavior is "traceable" when the system produces outputs through incomprehensible matrix multiplications?
Traditional AI architectures cannot satisfy these requirements through documentation and testing alone. But verified systems can. The proof is the documentation. The mathematical guarantee is the mitigation. The logical constraints are the traceability.
The 456 Domain specialists: Verifiable Scale
A common objection to verified AI is that verification doesn't scale. For simple systems with a few rules, yes, verification works. But real-world AI needs to handle complex perception and reasoning. How can verification work at scale?
Dweve Loom demonstrates that verification and capability are not mutually exclusive. Our foundation model uses 456 specialized constraint sets, each containing 64-128MB of binary constraints. But only 4-8 domain specialists activate for any given query.
This architecture, which we call ultra-sparse activation, means that verification effort scales with the active subset, not the full model. We don't need to verify all 456 domain specialist combinations simultaneously. We verify the routing logic that selects domain specialists, and we verify each domain specialist's constraint set independently.
The Permuted Agreement Popcount (PAP) routing system uses structural pattern detection to select relevant domain specialists. This routing layer is itself formally verifiable because it operates on discrete binary operations with well-defined mathematical properties.
The result is a system that can handle complex, real-world tasks while maintaining verification tractability. We get the capability benefits of mixture-of-experts architectures with the safety benefits of formal verification.
Implementation: What Verification Actually Looks Like
For organizations considering verified AI deployment, the practical process involves several stages.
Stage 1: Property Specification
Before verification begins, you must define what properties need to be verified. This is often the hardest step, requiring close collaboration between domain experts, engineers, and legal/compliance teams.
Properties must be precise and mathematically expressible. "The system should be safe" is not a verifiable property. "The motor velocity command shall not exceed V_max when proximity sensor indicates distance less than D_min" is verifiable.
På Dweve hjälper vi kunder genom denna specifikationsprocess med Spindle, vår plattform för styrning av företagskunskap. Hierarkin med 32 agenter inkluderar specialister på regelefterlevnad som hjälper till att översätta juridiska krav till formella begränsningar.
Steg 2: Arkitekturkartläggning
AI-systemets arkitektur måste kartläggas i en formell modell som verifieringsverktyg kan analysera. För Dweve-system är denna kartläggning enkel eftersom vår arkitektur med binära begränsningar är designad för verifierbarhet.
För organisationer med befintliga neurala nätverksinstallationer kan detta steg kräva arkitektoniska ändringar. Genom att lägga till lager med begränsad autonomi runt befintliga modeller, implementera säkerhetsbegränsningar som verifierade omslutningar, eller i vissa fall ersätta icke-verifierbara komponenter med Dweve-ekvivalenter.
Steg 3: Verifieringsutförande
Moderna SMT-lösare och formella verifieringsverktyg analyserar systemmodellen för att antingen bevisa de specificerade egenskaperna eller identifiera motexempel. Motexempel är ovärderliga eftersom de avslöjar exakt vilka indata som skulle kunna bryta mot säkerhetsbegränsningar, vilket möjliggör riktade åtgärder.
För Dweve-system slutförs verifiering vanligtvis inom minuter till timmar, beroende på begränsningarnas komplexitet. De 1 937 algoritmerna i Dweve Core har förverifierats för vanliga säkerhetsegenskaper, så verifiering handlar ofta om att komponera förverifierade komponenter snarare än att börja från grunden.
Steg 4: Certifiering och dokumentation
Verifierade egenskaper genererar bevisartefakter som fungerar som certifieringsunderlag. Dessa bevis är maskinkontrollerbara, vilket innebär att tillsynsmyndigheter självständigt kan verifiera dem med standardverktyg för beviskontroll utan att behöva lita på den ursprungliga verifieringsprocessen.
Dweve Fabric, vår enhetliga plattformsdashboard, genererar dokumentation för regelefterlevnad automatiskt från verifieringsresultaten. Samma bevis som tillfredsställer lösaren blir evidenspaketet för inlämning till tillsynsmyndigheter.
Framtiden: Verifierad AI som standardpraxis
Vi befinner oss vid en vändpunkt för AI-distribution. Erans "röra sig snabbt och sönder saker" är över för högriskapplikationer. Det regulatoriska landskapet skärps. Ansvarsrisken ökar. Försäkringsutmaningarna växer.
Organisationer som distribuerar AI i reglerade branscher står inför ett val. De kan fortsätta med traditionella arkitekturer och möta ökande friktion: längre godkännandeprocesser, högre försäkringskostnader, större juridisk exponering, potentiell marknadsuteslutning när regleringar träder i kraft.
Eller så kan de anta verifierade arkitekturer som tillfredsställer tillsynsmyndigheter med matematisk säkerhet snarare än statistiskt hopp.
Verifieringsrevolutionen handlar inte om att göra AI mindre kapabel. Den handlar om att göra AI pålitlig på sätt som betyder något för alla bortom forskningslaboratoriet: patienter, operatörer, försäkringsgivare, tillsynsmyndigheter och domstolar. Det handlar om att bygga AI som människor faktiskt kan distribuera med förtroende.
På Dweve tror vi att framtiden tillhör AI-system som kan bevisa sin säkerhet, inte bara lova den. Vår arkitektur, från de 1 937 verifierade algoritmerna i Core till sex lager av begränsad autonomi i Nexus till de 456 domänspecifika begränsningsuppsättningarna i Loom, är byggd från grunden för denna framtid.
Matematiken bakom visshet är inte en begränsning för AI-utvecklingen. Den är grunden för att kunna driftsätta AI i stor skala.
Redo att driftsätta AI som tillsynsmyndigheter kan godkänna? Dweves formellt verifierade arkitektur ger de matematiska garantier som förvandlar regulatoriska hinder till konkurrensfördelar. Kontakta oss för att diskutera hur verifiering kan påskynda din väg till marknaden samtidigt som den minskar din ansvarsexponering.