Så byggde jag ett AI-stött utbildningssystem för medborgarskapsprovet
Det började inte som ett AI-projekt. Problemet var betydligt mer jordnära: hur bygger man ett seriöst sätt att träna inför ett nytt svenskt medborgarskapsprov när materialet är faktatungt, regler kan ändras och användarna kan ha väldigt olika språkliga förutsättningar?
Det började inte som ett AI-projekt. Problemet var betydligt mer jordnära: hur bygger man ett seriöst sätt att träna inför ett nytt svenskt medborgarskapsprov när materialet är faktatungt, regler kan ändras och användarna kan ha väldigt olika språkliga förutsättningar? Det var först när jag började bryta ned arbetet som AI blev relevant. Medborgarskapskollen blev därför mindre av en “quiz-app med AI” och mer av ett innehålls- och kvalitetssystem. Frågor skulle vara pedagogiska utan att bli barnsliga. Förklaringar skulle vara tydliga utan att ändra innebörden. Översättningar skulle vara begripliga utan att juridiska eller samhällsspecifika begrepp gled iväg. Artiklar skulle kunna produceras i skala utan att regler, belopp och datum började leva sitt eget liv.
Det är den arkitekturen jag beskriver här: hur jag delade upp innehåll, frågebank, översättning, faktakontroll och publicering i separata lager, och varför det blev viktigare än själva språkmodellen.
När innehållet är produkten blir fakta en systemfråga
UHR ansvarar för medborgarskapsprovet och beskriver att provet införs stegvis. Den första delen, om grundläggande kunskaper om det svenska samhället, genomfördes i augusti 2026. Migrationsverket ansvarar samtidigt för själva medborgarskapsprövningen och avgör vem som ska anvisas till provet. Det innebär att den som bygger ett fristående utbildningsverktyg arbetar nära ett regelområde som faktiskt förändras. Det går inte att behandla innehållet som statisk copy.
Det var den viktigaste designinsikten. En vanlig innehållssajt kan ibland leva med att en gammal artikel uppdateras några veckor sent. I ett verktyg som hjälper människor att förstå krav för medborgarskap kan ett gammalt datum eller ett uteblivet undantag ändra vad läsaren tror gäller för henne. Därför började jag tänka på varje faktapåstående som data med proveniens, inte bara som text.
I praktiken ledde det till tre separata nivåer:
- Källnivå – vad säger UHR, Migrationsverket, lagtext eller annan primärkälla?
- Kunskapsnivå – vilken regel, definition, tidsgräns eller samhällsfakta kan vi faktiskt stödja?
- Presentationsnivå – hur ska samma kunskap uttryckas som artikel, fråga, svarsförklaring eller översättning?
Det låter enkelt, men separationen gör stor skillnad. Om presentationslagret får ändra kunskapslagret för att texten “låter bättre” har man inget robust utbildningssystem längre.
Jag ville testa kunskap, inte formuleringen i facit
En av de första problemen med frågebanken var hur lätt det är att skriva frågor som i praktiken testar minnet av en formulering. En språkmodell är väldigt bra på att generera hundratals varianter, men just därför kan den också skapa ett falskt intryck av bredd. Om fem frågor egentligen kräver samma exakta detalj har jag inte byggt fem kunskapskontroller. Jag har byggt fem ytliga varianter av samma sak.
Jag började därför behandla varje fråga som en liten specifikation:
Det gjorde det möjligt att granska frågor på ett annat sätt. Jag kunde fråga: testar frågan faktiskt den avsedda kunskapen? Är svaret onödigt smalt? Är ett felalternativ egentligen också korrekt under ett undantag? Kräver frågan en detalj som källmaterialet inte motiverar? Den sista frågan visade sig särskilt viktig. AI har en tendens att fylla ut luckor med något som låter pedagogiskt. I ett utbildningssystem måste luckan i stället bli synlig.
Frågebanken blev ett eget datalager
När frågorna blir många vill jag inte att facit ska ligga gömt i fri text. Jag vill kunna fråga systemet vilka frågor som bygger på en viss källa, vilka som berör samma kunskapsmål och vilka som behöver granskas när materialet ändras. En förenklad modell kan se ut så här:
Detta gör två saker. För det första blir det möjligt att uppdatera selektivt. Om UHR ändrar en del av sitt material behöver jag inte gissa vilka frågor som påverkas. För det andra blir AI:n en processor av strukturerad kunskap i stället för en improviserande frågemaskin. Jag använder fortfarande modellen för sådant den är bra på: föreslå alternativa formuleringar, hitta tvetydigheter, skapa rimliga distraktorer och föreslå enklare förklaringar. Men den får inte själv skapa den auktoritativa sanningen.
Det stora contentproblemet dök upp efter genereringen
När jag skalade innehållsplanen till hundratals artiklar blev nästa svaghet tydlig. Att generera text var billigt. Att verifiera den var dyrt. I en inventering landade jag på 2 051 faktapåståenden som behövde kontrolleras. Det ändrade hur jag såg på hela plattformen. Jag hade först tänkt “content engine”. I praktiken behövde jag ett evidence-system. För varje materiellt påstående vill jag kunna lagra åtminstone:
Verdict behöver dessutom vara mer nyanserat än sant/falskt. Ett påstående kan vara korrekt men ofullständigt. Ett annat kan ha varit korrekt när artikeln skrevs men blivit inaktuellt. Ett tredje kan bygga på två källor som använder olika definitioner. Det är därför jag använder states som VERIFIED, QUALIFIED, UNRESOLVED, CONFLICT och REMOVED. En writer får inte göra UNRESOLVED mer övertygande. Den måste antingen kvalificera, ta bort eller blockera texten.
Översättning blev ett separat kvalitetssystem
Medborgarskapskollen ska kunna vara användbar även för personer som redan kan svenska på en basal nivå men inte alltid behärskar myndighets- och samhällstermer. Där uppstod ett annat problem: en “korrekt” översättning kan ändå vara pedagogiskt dålig. Jag byggde därför inte en enda global prompt av typen “översätt tydligt”. Jag separerade en gemensam översättningspolicy från språkfiler för bland annat arabiska, bengali, hindi, urdu, somaliska, dari, persiska, tigrinja, BKS, polska, turkiska och spanska.
Den globala policyn låser sådant som:
- fakta och säkerhetsgrad,
- namn på myndigheter och institutioner,
- neutralitet,
- nummer, datum och belopp,
- frågans svårighetsgrad,
- vad som får förklaras men inte förändras.
Språkfilen hanterar sedan det som faktiskt varierar: translitterering, etablerade motsvarigheter, grammatiska fallgropar, när ett svenskt begrepp bör stå kvar tillsammans med en förklaring och vilken register-nivå som är naturlig. Det här blev ett bra exempel på varför “multilingual AI” inte bara handlar om att modellen kan språket. Produktkvalitet ligger i reglerna runt modellen.
Pedagogik före gamification
Jag gjorde också ett medvetet produktval att inte bygga Medborgarskapskollen som ett barnsligt spel. Målgruppen är vuxna människor som förbereder sig inför något som kan vara viktigt för deras framtid. Därför undviker jag språk som Battle, Boss, XP, liv och dueller. Det betyder inte att produkten ska vara torr. Progression, återkoppling, återkommande repetition och tydliga mål är fortfarande användbara. Skillnaden är hur de ramas in.
Jag vill att användaren ska känna:
- vad hon kan,
- vad hon behöver repetera,
- varför ett svar var fel,
- vilket område frågan tillhör,
- hur hon kan läsa vidare.
Det är ett pedagogiskt feedback-loop, inte ett belöningssystem som försöker hålla kvar användaren för sin egen skull.
AI:n får olika roller i olika steg
När arkitekturen mognade blev det tydligt att “AI” egentligen var flera olika jobb.
Researcher hämtar och strukturerar underlag. Question Architect föreslår kunskapsmål och frågetyper. Writer formulerar fråga och förklaring från godkänt underlag. Translation Reviewer kontrollerar språkspecifika problem. Fact Checker kontrollerar materiella claims. Publisher Gate avgör om något är redo.
Detta är inte agentteater. Jag behöver inte nio modeller som chattar med varandra. Poängen är ansvarsfördelning. Samma modell kan användas i flera steg, men den får olika input och olika behörighet. Det ger också bättre felsökning. Om en fråga är faktamässigt fel vet jag om felet uppstod i researchen eller senare. Om den är korrekt men språkligt otydlig vet jag att problemet ligger i presentationen. När allt sker i en enda prompt försvinner den spårbarheten.
Ett konkret exempel på hur en fråga ska passera systemet
Anta att källmaterialet innehåller en samhällsfakta som ska testas. Jag vill inte börja med “skriv en quizfråga”. Flödet blir i stället:
Den ordningen är långsammare än ren generering. Men den kan skala, eftersom varje steg går att automatisera, mäta och förbättra separat.
Vad jag inte automatiserar fullt ut
Det finns några gränser där jag fortfarande vill ha hårdare kontroll. Förändrade medborgarskapsregler är en sådan. Migrationsverket införde nya regler den 6 juni 2026, och ytterligare information om undantag från krav på permanent uppehållstillstånd publicerades i juli. Det är ett bra exempel på varför “vi faktagranskade sajten vid lansering” inte räcker. Tidskänsliga regler behöver återkommande revalidation. Jag vill också vara försiktig med frågor där flera svar kan vara rimliga beroende på kontext. Där är det bättre att göra frågan tydligare än att försöka vinna en argumentation om facit.
Och jag vill inte låta ett språkpass skriva över den juridiska eller sakliga säkerhetsgraden. Om originalet säger “kan” får översättningen inte bli “kommer”.
Det jag hade byggt annorlunda från dag ett
Om jag började om skulle jag lägga ännu mer kraft på content schema innan första artikel eller fråga producerades. Det är lockande att börja i frontend eftersom progression, quiz och resultat är synliga. Men den verkliga tillgången är kunskapsmodellen bakom. Jag skulle definiera:
- vilka källor som får vara auktoritativa,
- hur claims identifieras,
- hur freshness-risk lagras,
- hur frågor länkas till knowledge targets,
- hur språkversioner ärver från originalet,
- hur förändrade regler propagerar,
- vilka QA-states som är blockerande.
När detta finns blir UI och AI-funktioner mycket lättare att byta ut. Utan det blir varje ny funktion ännu ett ställe där sanningen kan divergera.
Innehåll och produkt delar kunskapsmodell, inte publiceringsgate
Contentplanen växte fram ur samma kunskapsmodell som frågebanken, men jag lät den aldrig ärva samma publiceringsgate. En claim kan vara godkänd för en kort förklaring i en övningsfråga utan att vara redo att bära en hel artikel — en guide kräver mer kontext och ofta fler källor än en förklaringsruta gör. Jag lät också produktens faktiska frågor styra vilka ämnen som fick bli artiklar, i stället för att utgå från en lista med sökord. Vad användarna svarar fel på, vilka begrepp som återkommer och vad som händer efter ett svagt provresultat säger mer om vad som behöver förklaras än en generisk SEO-brief gör. Det gjorde sökmotortrafiken till en naturligare del av flödet: en artikel som fångar en fråga innan personen känner till verktyget kan sedan hänvisa vidare till träningsmaterialet, i stället för att avsluta med en generisk uppmaning.
Resultatet jag är mest intresserad av är inte antal frågor
Det är lätt att mäta fel sak. Antal artiklar, antal frågor och antal språk är imponerande siffror, men de säger lite om systemets kvalitet. Jag skulle hellre följa:
- andel claims med verifierad primärkälla,
- andel frågor med explicit knowledge target,
- antal blockerade tvetydigheter före publicering,
- hur ofta en regeländring kan spåras till berörda sidor,
- användarens felmönster per kunskapsområde,
- hur ofta en översättning behöver saklig korrigering efter språkgranskning.
Det är metrics som berättar om systemet faktiskt blir mer tillförlitligt och pedagogiskt.
Min viktigaste lärdom
Det mest värdefulla med AI i Medborgarskapskollen är inte att den kan skriva många frågor. Det är att den kan hjälpa till att strukturera, jämföra, granska och omforma samma godkända kunskap för olika pedagogiska behov. Men det fungerar bara om sanningen ligger utanför språkmodellen. Jag ser därför systemet som en kedja:
AI:n kan vara mycket aktiv i mitten. Den ska däremot inte få flytta startpunkten. För en produkt som lär ut samhällskunskap nära ett verkligt myndighetskrav är det skillnaden mellan en snabb contentgenerator och ett utbildningssystem jag faktiskt vill stå bakom.
Hur jag skulle modellera kunskapskartan bakom frågorna
En sak jag skulle göra ännu mer explicit i nästa iteration är en riktig knowledge graph-light, utan att göra projektet akademiskt. Varje fråga behöver inte bara ett knowledge_target, utan relationer till närliggande kunskap. Om ett område handlar om svenska institutioner kan en fråga exempelvis höra till “demokrati”, “riksdag”, “regering” och “myndigheter” samtidigt. Då kan systemet bygga repetition utifrån vad användaren missar, inte bara vilken kategori administratören råkade lägga frågan i.
Jag behöver inte Neo4j för det. En enkel relationsmodell räcker:
Det öppnar för mycket bättre återkoppling. Om en användare missar tre frågor som ser olika ut men alla kräver förståelse för samma institution kan systemet säga “repetera det här området” i stället för att bara visa 7/10. Det gör också contentproduktionen bättre. När en artikel om ett ämne skapas kan jag se vilka kunskapsnoder den ska täcka och vilka frågor som kan länka tillbaka till artikeln. SEO-innehåll och utbildningsinnehåll blir då två presentationer av samma kunskapsmodell i stället för separata silos.
Hur jag vill hantera versionsändringar i källmaterialet
En praktisk risk är att en primärkälla ändras utan att URL:en gör det. Därför räcker inte en source URL. Jag vill kunna lagra en snapshot-identitet eller hash tillsammans med hämtningstid.
När källan hämtas igen kan systemet jämföra hash. En förändring betyder inte automatiskt att alla claims är fel, men det skapar en review-trigger. Det är här checksum-tänket jag tidigare använt för stora faktagranskade material blir praktiskt. SHA-256 är inte en sanningsmaskin. Det bevisar inte att innehållet är korrekt. Men det kan bevisa att det material jag granskar i dag är exakt samma byteinnehåll som det jag godkände tidigare. Den distinktionen är användbar när hundratals artiklar och språkversioner bygger på samma underlag.
Jag vill alltså kunna svara på två olika frågor:
- Var den här källversionen granskad?
- Är den här källversionen fortfarande den aktuella?
De kräver olika kontroller.
Frågekvalitet behöver egna evals
Det är också lätt att göra QA för subjektiv. “Den här frågan känns bra” skalar dåligt. Jag vill ha ett litet evalset med kända felmoder. Exempel:
- två svarsalternativ är tekniskt korrekta,
- rätt svar kräver ett undantag som inte nämns,
- frågan testar en siffra som inte är pedagogiskt central,
- distraktorn är uppenbart absurd,
- språket är svårare än kunskapen som ska testas,
- en översättning gör rätt svar lättare att gissa,
- förklaringen introducerar en ny claim som inte fanns i frågan,
- frågan kan besvaras genom grammatisk form snarare än kunskap.
Sedan kan en reviewer-agent få bedöma just dessa dimensioner, men jag vill fortfarande ha deterministiska checks där det går. Om två svaralternativ normaliseras till samma betydelse kan det flaggas. Om ett årtal saknar source mapping kan det flaggas. Om en fråga saknar knowledge_target ska den inte ens gå till språkgranskning.
Översättningar ska ärva status från originalet
En annan systemregel är att översättningar aldrig får ha högre QA-status än originalet. Om den svenska originalfrågan går från VERIFIED till NEEDS_REVIEW för att en källa ändrats ska de tolv språkversionerna automatiskt bli stale.
Det hindrar ett vanligt contentproblem där originalet rättas men gamla översättningar lever vidare. Jag vill också separera tre typer av ändringar:
Sakändring. Alla språk måste omverifieras. Språkändring i svenska originalet utan sakändring. Översättning behöver bara uppdateras om ändringen påverkar betydelse eller pedagogik. Lokal språkförbättring. Endast den språkversionen behöver ny review.
Det är sådan versionslogik som gör flerspråkighet hanterbar när materialet växer.
Jag vill mäta användarens kunskap utan att lura mig själv
När systemet får riktiga användarsvar kommer nästa lager: adaptiv repetition. Men även där finns risk att överkomplicera med AI. Jag behöver först några enkla signaler:
Om användaren svarar fel på samma kunskapsnode flera gånger kan systemet prioritera den. Om en fråga har extremt låg rättfrekvens för nästan alla användare kan det vara kunskapen som är svår – eller frågan som är dåligt skriven. Där blir analytics ett QA-instrument för innehållet, inte bara personalisering. AI kan sedan hjälpa till att förklara ett fel på flera sätt, men den måste använda samma verifierade kunskapsunderlag. Jag vill inte att en adaptiv tutor blir ett nytt fakta-lager vid sidan av frågebanken.
Adminytan är en del av kvalitetssystemet
En annan lärdom är att content governance behöver synas i admin. Om administratören bara ser “Edit article” blir all backend-proveniens osynlig. Jag vill kunna öppna en fråga eller artikel och se:
- aktuella källor,
- senaste source check,
- vilka claims som är qualified,
- vilka språkversioner som är stale,
- vilken agent/reviewer som senast godkände,
- vilka relaterade frågor som påverkas av samma regel,
- om användardata antyder att frågan är problematisk.
Då kan AI göra mycket av förarbetet men en människa kan fatta ett faktiskt informerat beslut.
Var jag skulle lägga mänsklig granskning
Jag skulle inte kräva manuell review av varje kommatecken. Människan behövs där värdet är högst:
- nya eller ändrade regler,
- claims med juridisk eller myndighetsnära konsekvens,
- source conflicts,
- frågor med hög tvetydighetsrisk,
- språk där AI-reviewers är oense,
- användarrapporterade fel,
- material som ska få status som definitivt facit.
Resten kan gå genom automatiserad QA med sampling. Det är samma princip som i resten av mina AI-system: human-in-the-loop ska sitta där felet kostar, inte där det är lätt att lägga en knapp.
Vad jag skulle testa innan nästa större innehållssläpp
Innan nästa stora batch skulle jag frysa ett representativt testpaket med frågor på olika svårighetsnivåer och språk. Det ska innehålla kända tvetydigheter, regler med undantag, frågor där ett lockande distraktoralternativ nästan är rätt och exempel där språkversionen riskerar att avslöja facit. Samma paket körs efter varje större ändring i prompt, modell eller språkregelverk. Jag skulle dessutom göra en release-check som inte tittar på enskilda frågor utan på helheten: överrepresenterar banken vissa kapitel? Finns kunskapsområden som nästan aldrig testas? Har samma typ av detalj blivit en genväg till höga poäng? Finns frågor som är tekniskt korrekta men pedagogiskt irrelevanta?
Det är där ett AI-stött system kan bli bättre än en statisk frågebank. Inte genom att generera mer, utan genom att kontinuerligt hitta obalans och föreslå vad som behöver granskas. Beslutet om vad som faktiskt ska räknas som rätt kunskap måste fortfarande bottna i källmaterialet.