Skip to content

Human-in-the-loop är ingen tillsyn. Det är en designdisciplin.

Varför passivt godkännande inte klarar den nya tillsynsribban – och hur du bygger om HITL till ett tröskelsystem med granskningsbara reservvägar och loggade överstyrningar.

Fasetterad scenografisk konsol för konfidenströsklar med revisionsspår och en deadline-markör för AUG 2026 – designdisciplin för HITL.
By easyAI Editorial

Godkännandet som aldrig var det

Hos Marrowfield Specialty Risk gav vårens granskning av skadetriage upphov till ett kort och pinsamt samtal. Mäklaren, omkring 150 anställda på en tillsynsövervakad marknad, hade kört ett AI-flaggningssystem i arton månader. Mariela Okafor, Claims Operations Lead, hade suttit på posten i tolv år. Handläggarna behandlade mer än 200 ärenden om dagen; modellen flaggade ungefär 8 %. Granskningen tog fram två siffror: 96 % godkännande på AI-flaggade ärenden, 23 sekunders genomsnittlig granskningstid. Compliance-ansvarig frågade: "Vilka trösklar har ni justerat mot?" Svaret: "Inga. Jag godkänner bara det AI:n skickar mig."

Marrowfield Specialty Risk är en sammansatt bild byggd av intervjuer med specialmäklare i mellansegmentet samt regelverkslitteraturen från BoE/FCA och EU:s AI-förordning. Namnen är anonymiserade; siffrorna illustrerar mönster i de undersökningar som citeras.

Hos tillsynsmyndigheter på tre kontinenter läses det samtalet i dag som bevis på bristande tillsyn. Att EU:s AI-förordning börjar tillämpas i augusti 2026 sätter ett datum på designmisstaget, men misstaget är äldre än kalendern.

§1 — Passivt godkännande är granskningsteater, inte tillsyn

Standardbilden i huvudet – "AI flaggar, människa godkänner" – går strukturellt inte att skilja från ingen tillsyn alls. Ett enknappsgränssnitt utan indata, utan modellresonemang och utan konfidenspoäng ger exakt de siffror Marrowfield fick fram. Driftsignaturen är densamma som för ett helt automatiserat arbetsflöde med en person i beredskap.

Tillsynsdata bekräftar detta i hela populationen. Undersökningen AI in UK Financial Services 2024 från BoE/FCA fann att "55 % av alla AI-användningsfall har någon grad av automatiserat beslutsfattande, varav 24 % är halvautonoma, dvs. de kan fatta en rad beslut på egen hand men är utformade för att involvera mänsklig tillsyn för kritiska eller tvetydiga beslut" [9]. Slutsatsen, i linje med hur NIST AI 600-1 ramar in risken i samspelet människa–AI: större delen av det automatiserade beslutsfattandet saknar någon meningsfull punkt att ingripa på.

Tillsynsmyndigheterna har agerat för att täppa till glappet. ICO:s ståndpunkt är tydlig: ett beslut faller inte utanför artikel 22 i Storbritanniens GDPR "bara för att en människa har 'gummistämplat' det" [2]. Samma vägledning är skarpare om driftbevisen: granskare som "rutinmässigt instämmer i AI-systemets utdata och inte kan visa att de verkligen har bedömt dem" kan klassas som helt automatiserade enligt Storbritanniens GDPR [3]. EU:s AI-förordning ställer ett parallellt krav i artikel 14 och kräver system som är "utformade och utvecklade på ett sådant sätt ... att de effektivt kan övervakas av fysiska personer" [1]. Ordet effektivt bär tyngden i båda rättstraditionerna. Designfrågan är inte längre "finns det en människa där?" utan "är designen sådan att en människa kan upptäcka, överstyra och avbryta – och skulle hon göra det?".

§2 — HITL är ett tröskelsystem, inte ett granskningssteg

Om du tar human-in-the-loop på allvar är det ett system: tydliga konfidenströsklar, tre beslutsvägar, ett riskviktat lager och en policy för köhantering. Modellen returnerar en konfidenspoäng på skalan 0,0–1,0, och tre gränser gäller – avslå automatiskt under den undre gränsen, mänsklig granskning i mittbandet, godkänn automatiskt över den övre. Försiktiga utgångspunkter för reglerade arbetsflöden ligger runt 0,3 / 0,95; måttlig drift nära 0,5 / 0,9; lågriskklassificering vid 0,7 / 0,95. Gränserna är medvetet asymmetriska: falska positiva och falska negativa kostar olika, och tröskelsystemet bygger in den asymmetrin i stället för att dölja den bakom en enda siffra. NIST AI RMF 1.0 landar på samma ställe – funktionen MANAGE "innebär att riskresurser regelbundet fördelas till kartlagda och uppmätta risker" [5], och trösklarna är fördelningsmekanismen, dimensionerad efter risk snarare än bekvämlighet.

Ovanpå ligger ett riskviktat lager. Konfidens multipliceras mot en allvarlighetspoäng för verksamhetsrisk – skadans storlek, hur oåterkalleligt beslutet är, regulatorisk exponering – och bildar en dirigeringsmatris på 3×3. Ett ärende med hög risk och låg konfidens eskaleras till chef; hög risk och hög konfidens går ändå till vanlig HITL-granskning i stället för automatiskt godkännande. Valet mellan två och tre nivåer spelar roll: ett tvånivåsystem tvingar in varje osäkert ärende i en enda kö, kön svämmar över, handläggarna faller tillbaka på massgodkännande – mönstret som gav Marrowfield 96 %. Ett trenivåsystem ger det automatiska avslaget en produktiv roll. Dirigeringen bygger på en central AI-strategiEN med en sanktionerad teknikstack som producerar konsekvent konfidenspoäng; en spretig flora av tillfälliga verktyg gör tröskeldisciplin omöjlig, eftersom poäng från olika modeller inte är jämförbara.

Human-in-the-loop som en dirigeringspunkt med konfidenströsklar: under den undre gränsen avslås åtgärden automatiskt, mittbandet går till mänsklig granskning och över den övre gränsen godkänns den automatiskt, med ett sunt överstyrningsband på 5 till 20 procent.
Human-in-the-loop som en dirigeringspunkt med konfidenströsklar, med ett sunt överstyrningsband på 5 till 20 procent.

§3 — Reservvägar är designade, inte underförstådda

"Reservväg" är inte felhantering. Det är den uttryckliga gren systemet tar när AI:n är osäker, och den behöver en väg, en person, en servicenivå. Tre upplägg täcker fältet.

Upplägg A – human-in-the-loop, synkront: AI:n pausar och skickar tillbaka ärendet till en kö med indatapost, resonemang och konfidens bifogade, mot en servicenivå på 2 till 4 timmar; passar beslut som ska ske mer eller mindre i realtid. Upplägg B – batchkö, asynkront: AI:n returnerar ett preliminärt svar och lyfter sedan fram det i en daglig eller veckovis batchkörning med ett retroaktivt fönster för överstyrning; passar arbete som inte är tidskritiskt. Upplägg C – eskalering till expert, hierarkiskt: styr efter AI:ns osäkerhet plus riskens allvar in i en flernivåpool av granskare (standard → expert → chef) med servicenivåer på 4 h / 24 h / 72 h; passar reglerat beslutsfattande – remisser inom försäkringsbedömning, medicinsk triage, compliance-flaggor.

Varje reservväg behöver en namngiven ägare och en dokumenterad servicenivå. Brittiska DSIT:s AI Playbook uttrycker det operativt – "tydligt dokumenterade gransknings- och eskaleringsprocesser ... och en AI-granskningsnämnd eller en nämnd på programnivå" [4] – och NIST AI RMF MANAGE bär samma instruktion från ett annat håll, med krav på övervakning efter driftsättning med namngivna återkopplingskanaler. Antimönstret vid granskning är genomgående: en samlingskö för "mänsklig granskning" utan servicenivå och utan ägare, där kön växer och AI:ns rekommendation blir det faktiska beslutet. Hos Marrowfield gav ombyggnaden varje reservväg en plats: småskador under en väsentlighetsgräns behandlas automatiskt; ärenden i mellanbandet körs enligt upplägg A på en servicenivå på 4 timmar; ärenden i det höga bandet och under tröskeln körs enligt upplägg C med namngivna försäkringsbedömare. Köerna slutade vara en enda överfull kanal och blev tre separata flöden med egna mätvärden och ägare.

§4 — Revisionsspåret för överstyrningar är compliance-artefakten

Det granskarna faktiskt synar är överstyrningsloggen. Ingen logg, eller en logg utan strukturerade skäl, underkänns redan innan några förmildrande förklaringar ens hinner väga in. Minimiartefakten per HITL-beslut är ett fast schema: case_id, AI-konfidens, AI-rekommendation, granskar-ID, granskningstid i sekunder, mänskligt beslut, skäl till överstyrning, tidsstämpel, policy_version. Utan policy_version går spåret inte att tyda ett år senare, eftersom trösklarna har flyttats. Artikel 14.4 i EU:s AI-förordning kräver att granskare kan "ingripa i ... driften eller avbryta systemet" [1] – och den operativa följden är att förmågan måste lämna ett avtryck, annars hände den inte. NIST AI 600-1 lägger det på åtgärdsnivå: "Övervaka och dokumentera tillfällen där mänskliga operatörer eller andra system överstyr den generativa AI:ns beslut" [6]. Loggen är det centrala beviset på meningsfull granskning.

Ansvaret sitter längre upp i kedjan än loggen. FCA:s AI Update sätter principen: "tydliga ansvarslinjer etablerade över hela AI-livscykeln" [10]. Brittiska SM&CR-företag lägger AI- och driftstacken under funktionen Chief Operations; amerikanska företag driver AI-kommittéer på styrelsenivå; europeiska företag följer EBA:s och ECB:s vägledning om ansvar på ledningsnivå. Principen är överförbar mellan de tre traditionerna, vilket gör det billigare att bygga AI-styrning från dag ett än att eftermontera den. ISO/IEC 42001:2023 ramar in den bredare kontrolluppsättningen som "ett integrerat sätt att hantera AI-projekt, från riskbedömning till verkningsfull hantering av dessa risker" [8].

Granskarna letar efter omvända signaler. Granskningstid under 10 sekunder läses som gummistämpling. Godkännandegrad över 98 % läses som ingen granskning. Ett tomt skälfält läses som odokumenterad meningsfullhet. Fler än 200 beslut om dagen per granskare läses som utmattning. Var och en är ett fynd i sig.

§5 — Hur håller kvartalsvis justering HITL ärligt?

Trösklar är inte något man ställer in och glömmer. Modeller driver, affärsregler ändras, gränsfall dyker upp. En kvartalscykel är den billigaste disciplinen som hindrar ett genomtänkt HITL-system från att falla tillbaka i teater, och den gäller med samma tyngd i alla jurisdiktioner: kravet på "effektiv" tillsyn i artikel 14 går inte att uppfylla utan den, och NIST AI RMF MANAGE förväntar sig "planer för att prioritera risk samt regelbunden övervakning och förbättring" på plats [5].

Månad ett – mät utgångsläget: HITL-volym per vecka, överstyrningsgrad per konfidensband, fördelning av tid till beslut, eskaleringsgrad per nivå. Månad två – identifiera driftsignaler: band där överstyrningen passerar 20 % betyder att modellen är opålitlig och att HITL-bandet behöver vidgas eller modellen tränas om; band under 2 % kan tryggt smalnas av; ärenden i upplägg B som inte granskats inom fönstret betyder att batchprocessen är trasig. Månad tre – justera och dokumentera: uppdatera tröskeldefinitionerna, höj policy_version med skälet till ändringen, informera driften, nollställ utgångsläget.

Cykeln förutsätter en granskarkultur som stöttar att man överstyr. ICO är uttryckligt: meningsfull granskning kräver att "granskarna har befogenhet att överstyra den utdata som AI-systemet genererar och är trygga med att de inte kommer att straffas för att göra det" [3]. Samma förväntan sitter i amerikansk upphandling under NIST AI RMF och i EU:s ansvarsregler under EBA och ECB – olika jurisdiktioner, identiskt drifttest. Där kulturen straffar avvikelse kollapsar överstyrningsgraderna av kulturella snarare än tekniska skäl, och de data cykeln bygger på blir omöjliga att tyda. Brittiska DSIT:s Playbook pekar ut ägarskapet: en AI-granskningsnämnd eller en nämnd på programnivå äger cykeln [4]. Det typiska svaret i mellansegmentet på "vem äger detta" är att befordra någon internt – se argumentet för att den bästa AI-ledaren att rekryteraEN redan finns i huset.

§6 — Vilka fem antimönster fäller en granskning enligt artikel 14?

Samma fem fellägen dyker upp i varje granskning.

Enknappsgränssnitt för godkänn/avslå. Granskaren ser bara beslutet. Symptom: godkännandegrader över 95 %, granskningar under 10 sekunder. Åtgärd: visa konfidens, indatapost och uttryckliga drivkrafter bakom osäkerheten. Artikel 14.4 b är uttrycklig om automationsbias – granskare måste "förbli medvetna om den möjliga tendensen att automatiskt eller överdrivet förlita sig på den utdata som ett AI-system med hög risk producerar" [1].

En enda granskare, ingen rotation. En operativ chef granskar varje HITL-ärende. Symptom: flaskhalsar på helger, utmattningsfel sent på dagen, en enskild felkälla. Åtgärd: en upplärd pool på 3–5 granskare på ett dokumenterat rotationsschema.

Tröskel satt en gång, aldrig justerad. Leverantörens standardvärden står orörda. Symptom: HITL-volymen ligger långt från bandet; överstyrningsgrader misstänkt låga eller kroniskt över 20 %. Åtgärd: kvartalscykeln i §5.

Inga skäl till överstyrning fångas. Granskarna kan överstyra, men skälfältet är frivilligt eller tomt. Symptom: meningsfullheten går inte att visa. Åtgärd: strukturerad infångning – rullgardin med de tre vanligaste skälen plus ett fritextfält, båda obligatoriska.

Reservkö utan servicenivå. Ärenden styrs till "mänsklig granskning" utan något ansvar för att betas av inom ett bestämt fönster. Symptom: kölängden växer månad för månad, granskarna hoppar över äldre poster. Åtgärd: uttrycklig servicenivå per reservväg plus en dashboard för köövervakning med en namngiven ägare. Att ansvaret är utspritt är den strukturella risken; BoE/FCA-undersökningen noterar att ansvaret "ofta är delat, där de flesta företag rapporterar tre eller fler ansvariga personer eller organ" [9], och artikel 14 i EU:s AI-förordning lägger tillsynen på en namngiven "fysisk person" [1].

§7 — Artikel 14 och kalendern fram till augusti 2026

Regelverksramen är ingen jurisdiktionsspecifik teater. Flera tillsynsmyndigheter konvergerar mot samma drifttest; EU:s AI-förordning bär den mest offentliga tidsfristen. Artikel 113 sätter tillämpningsdatumet för skyldigheterna för hög risk – inklusive artikel 14 – till den 2 augusti 2026 [1]. Från det datumet bär företag som driftsätter AI inom områden med hög risk enligt bilaga III (anställning, kreditbedömning, kritisk infrastruktur, data inom brottsbekämpning) skyldigheten.

Artikel 22 i Storbritanniens GDPR är redan bindande, och dess test är "meningsfull mänsklig medverkan" [3] – befogenhet, kompetens, beaktande av indata och alternativ, en stöttande kultur och ingen påföljd för att överstyra modellen. Där artikel 22 gäller – varhelst ett beslut har rättslig verkan eller på liknande sätt i betydande grad påverkar någon – underkänns "gummistämpling" i testet [2]. Den amerikanska hållningen saknas inte: delstatslagar (Colorado AI Act, NYC AEDT, Kaliforniens föreslagna ADMT-regler) och sektoriell tillämpning (FTC om automatiserat beslutsfattande, NIST AI RMF som upphandlingsreferens för federal användning) driver samma disciplin. ISO/IEC 23894:2023 standardiserar det underliggande riskhanteringssättet som "vägledning om hur organisationer ... kan hantera risk som specifikt rör AI" [7] – det renaste icke-regulatoriska ankaret för marknader vars AI-specifika lagar ännu inte trätt i kraft, och ryggraden i varje driftspolicy som omfattar flera jurisdiktioner.

Sektorstillsynen förstärker poängen: FCA är teknikneutral [10], EU:s motsvarigheter under EBA och ECB samordnar sig kring ansvar på ledningsnivå, och BoE/FCA:s undersökning från 2024 visar att ansvaret hos de flesta tillfrågade företag typiskt är fragmenterat över tre eller fler ansvariga parter [9].

Designfrågorna i §§2–5 är compliance-frågorna över tre rättstraditioner. Att bygga HITL på det här sättet betalas en gång; att eftermontera efter en underkänd granskning betalas varje kvartal.

§8 — Hur ser den fyra veckor långa HITL-designsprinten ut?

Ombyggnaden är avgränsad: en sprint på Operations Lead-nivå, inte ett program.

Vecka 1 – Mät nuläget. Inventera varje steg för "mänsklig granskning". Ta fram godkännandegrader, fördelningar av granskningstid, läget för infångning av överstyrningar, kölängder. Signaturen för passivt godkännande: hög godkännandegrad, låg granskningstid, inga strukturerade skäl till överstyrning.

Vecka 2 – Designa beslutsvägarna. Sätt konfidensgränser per arbetsflöde utifrån utgångspunkterna i §2. Designa reservvägar enligt §3. Definiera revisionsschemat för överstyrningar enligt §4. Dokumentera policy_version v1.0 med tröskelvärden, ägare och servicenivåer.

Vecka 3 – Inför, lär upp, samla in data. Koppla in gränssnittsändringarna – visa modellens resonemang och konfidens på granskarens skärm. Lär upp granskarpoolen på genomarbetade exempel. Inled skarp drift med full revisionsloggning från dag ett.

Vecka 4 – Första justeringsgranskningen och granskningsklar dokumentation. Kör cykeln i §5 mot data från vecka 3; uppenbara driftsignaler träder fram även på ett kort fönster. Sätt ihop artefaktpaketet: tröskeldefinitioner, dashboard för överstyrningsgrad, inventering av eskaleringsvägar, ansvarskarta. Resultatet är läget att pröva mot 50 frågor beslutsfattare ställer före en AI-implementeringEN, som täcker Q3.10, Q5.4, Q5.5 och Q5.7.

Kostnadsband: 20–40 timmar av Operations Lead-tid. Resultat: ett tillsynsprotokoll som är redo för artikel 14, en hållning för "meningsfull granskning" som står sig enligt artikel 22, och en MANAGE-funktion i linje med NIST RMF.

Från godkännande till disciplin

Fyra veckor efter ombyggnaden har driftbilden förskjutits. HITL-volymen i skadeflödet är ner 70 % eftersom det automatiska avslaget gör verkligt arbete på bandet under tröskeln. Den genomsnittliga granskningstiden på de ärenden som faktiskt når HITL har stigit till omkring fyra minuter – den tid den strukturerade granskningen verkligen tar. Överstyrningsgraden har stabiliserats på 14 %, inom det sunda bandet på 5–20 %, och varje överstyrt ärende bär strukturerade skäl. Compliance-ansvarigs fråga har nu ett svar med versionsnummer fäst vid sig.

Skillnaden mellan granskningsteater och granskningsbar tillsyn är inte hur seriöst ett företag pratar om mänsklig granskning. Den ligger i om granskningen är ett genomtänkt tröskelsystem eller ett godkännande med ett klick. Det ena klarar artikel 14. Det andra gör det inte.

För en bild av var HITL-designen står tvärs över en organisations reglerade arbetsflöden kartlägger easy-audit.ai den på två timmars strukturerade frågor.

Sammanfattning

HITL — designed oversight, not passive sign-off
│
├─ The failure · audit theatre
│   ├─ Passive sign-off — one-click approve, no reasoning shown
│   └─ Rubber-stamp test — >98% approve, <10s review fails it
│
├─ The system · thresholds & routes
│   ├─ Three routes — auto-reject / HITL review / auto-approve
│   ├─ Risk overlay — confidence × severity sets escalation
│   └─ Fallback paths — named owner, SLA, override audit log
│
└─ The discipline · stays honest
    ├─ Healthy band — 5–20% override; outside it, tune or retrain
    └─ Quarterly cycle — measure, spot drift, re-version, document

Frequently Asked Questions

Vilken konfidenströskel ska vi börja med för ett reglerat arbetsflöde?
För reglerade beslut: börja försiktigt – en undre gräns på 0,3 och en övre på 0,95, så att ett brett HITL-granskningsband ligger däremellan. Allmän drift kan köra måttligt (0,5 / 0,9); klassificering av lågriskinnehåll kan köra aggressivt (0,7 / 0,95). Det här är utgångspunkter, inte slutpunkter – den kvartalsvisa justeringscykeln flyttar dem utifrån faktiska överstyrningsdata från de tre första driftmånaderna. Godta aldrig leverantörens föreslagna standardvärden utan att mäta själv.
Hur skiljer sig HITL från ett granskningssteg som klistras på i slutet?
Ett granskningssteg i slutet är ett gränssnitt med ett klick för godkänn/avslå, utan indata, utan AI-resonemang och utan konfidenspoäng – strukturellt omöjligt att skilja från ingen tillsyn alls. HITL är ett genomtänkt tröskelsystem: tydliga konfidensgränser, tre beslutsvägar (automatiskt avslag, HITL-granskning, automatiskt godkännande), ett riskviktat lager ovanpå, namngivna reservvägar med servicenivåer och ett strukturerat revisionsspår för överstyrningar. Det som håller vid en granskning sitter i designen, inte i bemanningen. Bygg om gränssnittet så att det visar AI:ns resonemang och konfidens innan du utgår från att du har tillsyn.
Vad är en sund överstyrningsgrad, och varför spelar den roll?
5–20 % är det sunda bandet. Under 5 % tyder på gummistämpling – granskare godkänner utan någon verklig bedömning, exakt det mönster som tillsynsmyndigheter klassar som helt automatiserat beslutsfattande. Över 20 % tyder på att AI:n är opålitlig i det konfidensbandet – vidga HITL-granskningsfönstret eller träna om modellen. Överstyrningsgraden blir granskningsbevis: mät den per konfidensband, fånga skälen till varje överstyrning i ett strukturerat fält och granska fördelningen varje kvartal för att upptäcka drift.
Räcker HITL för att klara kravet på meningsfull mänsklig granskning vid automatiserade beslut?
Bara om granskningen uppfyller fem villkor: granskaren har befogenhet att överstyra, har kompetens inom beslutsområdet, väger in indata och alternativ (inte bara AI:ns utdata), arbetar i en organisationskultur som stöttar avvikelse och drabbas inte av påföljder för att gå emot AI:n. Gummistämpling lyfter inte ut ett beslut ur det automatiserade beslutsfattandet enligt artikel 22 i vare sig EU:s eller Storbritanniens GDPR. Mät granskningstid, skäl till överstyrning och rotation av granskare; behandla vart och ett som granskningsbart bevis.
När börjar tillsynskravet i artikel 14 i EU:s AI-förordning att gälla?
För AI-system med hög risk enligt bilaga III gäller skyldigheten från den 2 augusti 2026. Förbjudna metoder gällde redan från den 2 februari 2025; skyldigheter för AI för allmänna ändamål från den 2 augusti 2025. AI med hög risk som är inbäddad i reglerade produkter får en längre övergångsperiod till den 2 augusti 2027. Om du verkar inom ett område med hög risk – kreditbedömning, anställning, kritisk infrastruktur, data med koppling till brottsbekämpning – planera in den fyra veckor långa HITL-designsprinten så att den landar före augusti 2026, så att det finns utrymme för en första kvartalsvis justeringscykel innan tidsfristen.

Sources

  1. 1.EU AI Act Regulation 2024/1689, Article 14 — Human OversightOfficial Journal of the European Union · 2024
  2. 2.Guidance on AI and Data Protection — landingInformation Commissioner's Office (ICO) · 2024
  3. 3.Guidance on AI and Data Protection — fullInformation Commissioner's Office (ICO) · 2024
  4. 4.AI Playbook for the UK GovernmentUK Department for Science, Innovation and Technology (DSIT) · 2025
  5. 5.Artificial Intelligence Risk Management Framework 1.0National Institute of Standards and Technology (NIST) · 2023
  6. 6.NIST AI 600-1 — Generative AI ProfileNational Institute of Standards and Technology (NIST) · 2024
  7. 7.ISO/IEC 23894:2023 — Information Technology, AI, Guidance on Risk ManagementInternational Organization for Standardization (ISO) · 2023
  8. 8.ISO/IEC 42001:2023 — Information Technology, AI, Management SystemInternational Organization for Standardization (ISO) · 2023
  9. 9.Artificial Intelligence in UK Financial Services 2024Bank of England + Financial Conduct Authority · 2024
  10. 10.AI UpdateFinancial Conduct Authority (FCA) · 2024

Want this run on your business?

AI Foundation Audit — a structured assessment of your AI footprint: integration risks, governance gaps, ROI opportunities. Delivered as a comprehensive report you can act on.

Start your audit

You receive your Executive Report and Implementation Brief — tailored to your business and delivered immediately.