Jag genererade 220 artiklar med AI — här är problemet jag underskattade

Att ta fram 220 artikelutkast med AI var inte den svåra delen. Den svåra delen började när jag ställde en mycket enklare fråga: Vilka av alla påståenden i de här texterna vet jag faktiskt är korrekta? När jag inventerade materialet landade jag på 2 051 faktapåståenden som behövde verifieras. Där förändrades problemet helt. Jag hade inte längre ett content-generation-problem. Jag hade ett evidence management-problem. Det här är den största missuppfattningen jag ser kring AI-content i skala: kostnaden för att skriva går mot noll långt innan kostnaden för att veta att texten är riktig gör det.

En artikel är för stor som enhet för faktakontroll

Den första frestelsen är att göra en andra AI-pass:

"Faktagranska den här artikeln."

Det kan hitta uppenbara fel, men det ger dålig spårbarhet. Om modellen säger att "artikeln ser korrekt ut" vet jag fortfarande inte vilket underlag som stödjer ett visst datum, belopp, undantag eller myndighetsregel. Jag började därför behandla texten som en samling atomära claims. En mening som:

"Du måste ha bott i Sverige i fem år och ha permanent uppehållstillstånd för att kunna bli svensk medborgare."

är inte ett påstående. Den kan innehålla flera verifierbara delar och dessutom vara fel genom att sakna undantag. I en claim-ledger vill jag hellre se något i stil med:

Varje claim får en källa, en status och vid behov en kvalificering. Det ligger nära hur aktuell forskning angriper långtext-faktakontroll. Ett vanligt upplägg är att först extrahera mindre, självständigt verifierbara claims och sedan kontrollera dem mot evidens. Forskningen pekar också på att själva claim-extraktionen är kritisk: en dåligt avgränsad eller dekontextualiserad claim kan ge ett falskt intryck av att verifieringen är robust.

Den verkliga datamodellen

Efter det här slutade jag tänka på källor som fotnoter och började se dem som produktdata. Min minsta användbara struktur ser ungefär ut så här:

Verdict är inte bara TRUE/FALSE. Jag vill åtminstone kunna skilja på:

• VERIFIED – stöds direkt av källa,
• QUALIFIED – i huvudsak korrekt men kräver villkor/undantag,
• UNRESOLVED – evidensen räcker inte,
• CONFLICT – trovärdiga källor säger olika saker,
• REMOVED – påståendet ska ut ur texten.

Det här är mindre elegant än att säga "AI fact checked". Det är betydligt mer användbart.

Primärkälla först

För mitt material kring medborgarskap och myndighetsnära information fungerar en enkel prioriteringsregel bra:

1. lag/förordning när juridisk precision krävs,
2. ansvarig myndighets primärinformation,
3. officiell statistik eller dokumentation,
4. sekundärkällor för kontext – inte som enda stöd för ett materiellt regelpåstående.

Samma princip går att översätta till andra ämnen. Skriver jag om Claude Code bör aktuell Anthropic-dokumentation slå en bloggpost. Skriver jag om Google Search bör Search Central slå en SEO-tråd. Skriver jag om ett forskningsresultat bör originalpaper slå en sammanfattning av paperet.

Färskhet är en egen dimension

Ett påstående kan ha varit korrekt när källan publicerades och ändå vara fel när artikeln går live. Därför räcker inte source_url. Jag behöver även veta när källan uppdaterades, när vi hämtade den och om claimen är tidskänslig. Belopp, krav, modellfunktioner, API-beteenden, myndighetsprocesser och produktpriser får till exempel en högre freshness-risk än historiska fakta.

Det här förändrar även underhållet. Om 15 artiklar bygger på samma myndighetsregel vill jag kunna hitta alla berörda claims när regeln ändras. Annars har jag byggt en publiceringsmaskin men inget uppdateringssystem.

Konflikter ska inte "lösas" av språkmodellen. En viktig lärdom är att en modell gärna producerar en syntes även när källorna faktiskt är oense. Jag vill i stället att konflikt blir ett explicit state:

Sedan kan en människa eller en särskild evidensgranskare avgöra om skillnaden handlar om datum, jurisdiktion, definition, en ändrad regel eller en verklig motsägelse. Det är samma anledning till att jag inte låter en downstream-writer "fixa" saknad evidens. Om researchlagret inte kan stödja påståendet ska textlagret inte få göra det mer övertygande.

Det här är också ett SEO-problem. Den här kvalitetsarkitekturen ligger ganska nära vad Google uttryckligen efterfrågar (länken kan omstruktureras av Google över tid – kolla att guidningen fortfarande gäller). Google säger inte att AI-genererat innehåll i sig är förbjudet. De betonar accuracy, quality och relevance. De varnar samtidigt för att skapa stora mängder sidor utan mervärde och lyfter originalinformation, tydlig sourcing och first-hand experience som tecken på people-first content. Det betyder att "220 artiklar" inte är en prestation i sig. Om 180 av dem bara återberättar det som redan finns på internet har jag byggt commodity content snabbare. Det är inte samma sak som att bygga topical authority.

Så ser min pipeline ut nu

Jag skulle i dag aldrig gå direkt från brief till publicering i den här typen av material.

Den viktiga förändringen är att writern inte får hitta på kunskapen. Den skriver från ett redan godkänt evidenslager.

Varför 2 051 claims var bra nyheter

Först såg jag siffran som ett problem. I efterhand var den en signal om att systemet började bli seriöst. När man inte vet hur många materiella claims man har är faktakontroll lätt att beskriva som en checkbox. När de blir identifierbara objekt kan man mäta dem:

• hur många är verifierade?
• hur många saknar primärkälla?
• vilka har hög freshness-risk?
• vilka artiklar är blockerade av samma claim?
• vilka källor används oproportionerligt mycket?
• vilka regler måste re-checkas om tre månader?

Det är där AI-content går från "massproduktion" till ett faktiskt redaktionellt system. Min viktigaste lärdom från de 220 artiklarna är därför paradoxal: ju billigare det blir att generera text, desto viktigare blir infrastrukturen runt det som textgeneratorn inte kan garantera — evidens, proveniens, uppdatering och beslutet att ibland inte publicera alls.

Claim extraction är svårare än den ser ut

När jag började bryta ned artiklarna märkte jag snabbt att "en mening = ett claim" inte fungerar. En mening kan innehålla flera delar med olika källor. Ett påstående kan också vara grammatiskt enkelt men semantiskt beroende av en definition som finns tidigare i texten. Forskningen kring claim extraction pekar just på problem som coverage, decontextualization och ambiguity. En claim som rycks loss från sitt sammanhang kan bli verifierbar men ändå missrepresentera vad artikeln faktiskt säger. Jag försöker därför göra varje claim:

• atomär nog att verifiera,
• komplett nog att förstå utan att gissa,
• kopplad till rätt tid/jurisdiktion när det är relevant,
• fri från värdeomdömen som egentligen inte är faktapåståenden.

Exempel:

Bättre claim inventory:

Nu kan en av delarna vara bekräftad medan en annan fortfarande är ett förslag eller omfattas av undantag.

Jag skiljer mellan source support och article wording. En källa kan stödja en claim utan att stödja exakt hur jag har formulerat den. Det är ett viktigt mellanlager. Säg att en myndighet skriver "I de flesta fall behöver du…". Om artikeln i stället skriver "Du måste alltid…" har källan inte räddat oss – vi har tappat modaliteten. Därför behöver fact-checkern kontrollera minst tre saker:

1. entailment: följer claimen av källan?
2. scope: gäller den samma grupp, tid och situation?
3. certainty: har texten blivit säkrare än källan?

Det är här ett rent URL-system är otillräckligt. "Vi har en källa" säger väldigt lite om relationen mellan källan och texten.

Evidence Auditor är separat från Researcher av en anledning

Jag separerar research och evidensgranskning eftersom samma agent annars lätt börjar försvara sitt eget arbete. Researcher har incitament att hitta något användbart. Evidence Auditor ska i stället försöka underkänna claims som inte håller. Ett förenklat handoff-kontrakt kan se ut så här:

Writer får bara claims från APPROVED/QUALIFIED-lagret. Det är en liten arkitekturförändring men stor kvalitetsskillnad. En writer som får fem webblänkar börjar annars gärna syntetisera saker som ingen källa uttryckligen säger.

Ett kontrakt som går att testa

Handoffen mellan Researcher, Evidence Auditor och writer blir mer robust om den går att köra som ett testfall, inte bara läsa som en beskrivning. Jag använder ett format i stil med:

Det skiljer själva uppgiften från den tillfälliga modell som utför den. Ett system kan då byta modell eller implementation utan att samtidigt byta definitionen av vad som räknas som ett godkänt resultat – samma logik som gör claim-ledgern granskningsbar i stället för en engångsbedömning.

Hur jag tänker kring automatiserad faktakontroll

Jag tror inte att lösningen är att automatisera bort människan helt. Jag vill automatisera förarbetet så hårt att den mänskliga kontrollen kan fokusera på svåra claims. Ett bra system kan automatiskt:

• hitta kandidater till factual claims,
• klassificera freshness-risk,
• söka primärkällor,
• matcha claims till evidens,
• upptäcka saknad källa,
• flagga konflikter,
• föreslå minimal korrigering,
• skapa en review-kö.

Människan kan sedan prioritera:

• juridiska/regelstyrda claims,
• claims med ekonomisk eller annan hög påverkan,
• källkonflikter,
• svårtolkade undantag,
• claims där wording och source certainty inte matchar.

Det skalar betydligt bättre än att en redaktör ska läsa 220 artiklar från början och försöka hålla alla fakta i huvudet.

Dubbletter är också en kvalitetssignal. När samma faktapåstående återkommer i många artiklar vill jag inte verifiera det 15 gånger som 15 isolerade texter. Jag vill identifiera en canonical claim eller åtminstone en gemensam source-of-truth. Exempel:

När regeln ändras kan systemet skapa en impact list. Det här är i praktiken samma tanke som normalisering i data: duplicera inte en kritisk sanning i hundratals ostrukturerade dokument om du kan modellera den som en återanvändbar enhet.

Freshness queue i stället för årlig storstädning

Jag skulle också hellre re-checka claims baserat på risk än göra en stor årlig content audit. Exempel på enkla freshness-klasser:

Hög. Priser, lagar/regler, myndighetskrav, API-funktioner, produktlimits, modellnamn och capabilities.

Medel. Organisationsprocesser, marknadsstatistik, rekommenderade workflows, verktygsjämförelser.

Låg. Historiska händelser, etablerade definitioner, metodprinciper som inte är leverantörsspecifika.

Sedan kan systemet sätta next_review_at på claim- eller artikelnivå. Det gör content maintenance till en queue i stället för en panikinsats när någon upptäcker att 40 sidor är gamla.

Det finns några frestelser jag aktivt undviker i faktakontrollen. "Confidence: 97 %" utan kalibrering – ett LLM-genererat konfidenstal ser vetenskapligt ut men är inte automatiskt en sannolikhet; jag använder hellre diskreta statuses kopplade till verifierbara kriterier. Majoritetsröst mellan modeller – tre modeller kan upprepa samma fel, och konsensus är inte evidens. Sekundärkälla som räddar primärkällan – om primärkällan säger något annat än tio bloggar är det inte automatiskt bloggarna som vinner. Omskrivning före verdict – fact-checkern ska först avgöra vad som är fel och varför, annars kan en snygg omskrivning dölja att claimen aldrig verifierades.

Ett exempel på ett publisher gate-beslut

Säg att artikeln har 34 materiella claims:

En vanlig språkmodell skulle lätt kunna producera en "nästan färdig" artikel. Min gate säger i stället:

Efter research kanske den unresolved claimen tas bort och konflikten löses genom att artikeln förklarar att två regler gällde vid olika datum. Först då får artikeln gå vidare. Det är mer konservativt, och för faktatungt material är det exakt vad jag vill ha.

Paradoxalt nog har den här arkitekturen gjort mig mer positiv till AI-content, inte mindre. När modellen inte behöver bära ansvaret för sanningen kan den göra det den är bra på: förenkla komplex information, hitta pedagogiska exempel, strukturera en lång text, anpassa språk till olika läsare, översätta med terminologikontroll, skapa alternativa förklaringar, föreslå FAQ utifrån redan verifierat material. Det är en mycket bättre roll än att samtidigt vara researcher, källa, writer och domare över sin egen factuality.

Min nya definition av skalbar contentproduktion

Skalbarhet betyder därför inte hur många drafts jag kan generera per timme. Jag tittar hellre på:

• kostnad per verifierad artikel,
• antal unresolved claims per 1 000 claims,
• andel claims med primärkälla,
• medianålder på high-risk claims,
• hur snabbt en source change kan propageras,
• hur många artiklar som stoppas innan ett fel publiceras.

Det är mindre imponerande i en demo än "220 artiklar på en dag". Men det är den typ av mått som avgör om 220 artiklar fortfarande är användbara sex månader senare.

Hur jag skulle bygga ett claim-system tekniskt

Jag skulle hålla claim-lagret enkelt i början. En relationsdatabas räcker långt: articles, claims, sources, claim_source_links och reviews. Det viktiga är inte tekniken utan att relationerna går att fråga på. Jag vill exempelvis kunna köra frågor som:

eller:

eller:

Det är först när sådana frågor går att ställa som source provenance blir operativ och inte bara dokumentation.

Quality gates jag skulle mäta över tid

Utöver artikelstatus skulle jag följa några enkla kvalitetsmått:

• primary-source coverage: andel high-risk claims med primärkälla,
• unresolved rate: unresolved claims / total claims,
• conflict rate: hur ofta trovärdiga källor kräver manuell bedömning,
• freshness compliance: andel claims re-checkade inom sin SLA,
• escape rate: faktiska fel som passerade publisher gate,
• rework rate: hur ofta writer måste göras om efter fact check.

Ett högt rework rate kan exempelvis betyda att Writer får för dåligt evidensunderlag. Då ska man inte "träna writern att vara försiktigare"; man ska förbättra handoffen från evidence-lagret.

Source longevity är ett praktiskt problem för sig: webbsidor ändras, PDF:er byts ut och länkar dör. För viktiga källor vill jag därför lagra mer än URL:en – titel, utgivare, publicerings-/uppdateringsdatum, retrieval timestamp och en kort evidenssammanfattning eller tillåtet excerpt. Där juridik och copyright tillåter kan man även arkivera en intern snapshot eller identifierare till den version som faktiskt granskades. Målet är att kunna svara på frågan: vilken version av underlaget låg bakom det här publiceringsbeslutet?

Det mänskliga review-gränssnittet spelar också roll. Om en människa måste öppna 15 flikar per claim blir systemet aldrig konsekvent använt. Jag skulle därför bygga review-UI runt claimen:

Det gör att människan granskar ett beslut i taget i stället för att "läsa hela internet".

Den stora förändringen efter 220 artiklar var att jag slutade se faktakontroll som ett redaktionellt slutsteg. Det blev ett datasystem mellan research och writing. När varje viktig claim har identitet, källa, status och freshness kan AI hjälpa till på riktigt: hitta, strukturera, föreslå och prioritera. Men sanningen behöver ett eget lager. Annars skalar vi bara förmågan att producera trovärdig text snabbare än vi kan kontrollera den.

Claim-level QA behöver dessutom sampling även när allt ser grönt ut. Automatiska verdicts kan själva ha systematiska fel. Därför skulle jag manuellt sampla även VERIFIED-claims, inte bara de som flaggas – tittar audit bara på problem som modellen själv upptäckt mäter vi främst modellens förmåga att känna igen sina egna problem. En enkel sampling kan stratifieras efter claim type och risk: myndighetsregler, datum, belopp, tekniska funktioner och låg-risk bakgrundsfakta. När en viss typ visar hög felprocent höjs reviewnivån för den kategorin. Det gör QA:n adaptiv i stället för att alla 2 051 claims behandlas exakt likadant.

Om jag bara skulle behålla en regel från hela projektet är det denna: publicera inte en claim bara för att den låter rimlig och modellen hittar en relaterad källa. Kräv att källan faktiskt stödjer samma påstående, för samma situation och med samma säkerhetsgrad. Det är där mycket av skillnaden mellan "AI-assisted research" och verklig verifiering ligger.

Källor och vidare läsning

• Google Search Central: Guidance on generative AI content
• Google Search Central: Helpful, reliable, people-first content
• Metropolitansky & Larson: Effective Extraction and Evaluation of Factual Claims
• Sahitaj et al.: Automated Fact-Checking of Real-World Claims
• Claim Extraction for Fact-Checking
• Decomposition Dilemmas
• NIST AI Risk Management Framework

Relaterade artiklar

• Så bygger jag claim-level fact checking
• Att generera 220 artiklar är enkelt. Att verifiera dem är det svåra.
• Hur jag hanterar regler, belopp och datum i AI-genererade artiklar
• Så använder jag confidence levels i AI-content
• Content generation vs content production — en viktig skillnad
• Så promptar jag AI för konsekventa varumärkesbilder