Bygg inte samma grund 290 gånger · Fullständig rapport

Avsnitt 1

Sammanfattning

Sveriges kommuner vill samverka kring AI i bygglov men saknar ett gemensamt sätt att göra det. Av 17 analyserade kommunala svar var 65 % positiva eller öppna för samverkan, medan 41 % saknar aktiv satsning eller är i ett tidigt skede.

Slutsatsen är enkel: bygg inte samma grund 290 gånger. Bygg en gemensam kärna som kan konfigureras lokalt och förvaltas gemensamt.

Underlaget har två delar. Avsnitt 2–3 redovisar vad kommunerna säger. Avsnitt 4 formulerar en föreslagen målbild. Avsnitt 5–12 beskriver Intertween som ett möjligt svar, och vad som hittills är prövat. Undersökningen står på egna ben, och förslaget är ett av flera tänkbara.

Avsnitt 2

Problemet: samma grund byggs om och om igen

Det som saknas är förmågan, inte viljan.

Kategorierna överlappar, så andelarna summerar inte till 100.

Alla 290 kommuner hanterar bygglov. Alla som vill använda AI möter samma frågor: vilka data som finns, vilka regler som gäller, hur handlingar ska klassas och vilken leverantör som ska bygga stödet. I dag tar de flesta dessa frågor var för sig.

”Det är inte ens rimligt att 290 kommuner ska göra detta var och en för sig.”samverkansorgan i undersökningen

För en stor kommun blir det dyrt och långsamt. För en liten kommun blir det ofta omöjligt. Resultatet är att samma grundarbete görs på många håll, eller inte alls, och att erfarenheterna stannar där de uppstod.

Avsnitt 3

Vad kommunerna säger: fyra mönster

Samverkan är det tema som oftast framgår, men tidigt skede och leverantörernas roll kommer tydligt därefter.

Mönster 1: Samverkan är rationell men svår att mobilisera

”AI inom bygglovsprocessen är inget vi jobbar aktivt med just nu. Men jag skulle gärna önska att kommuner samarbetar mer kring den frågan.”kommun i undersökningen

Intresset finns. Ett gemensamt initiativ behöver sänka tröskeln för att delta och erbjuda olika roller utifrån kommunernas kapacitet.

”Vi är en klassisk sno och glo kommun.”kommun i undersökningen

Alla kommuner vill inte bygga själva. Många vill kunna ta det som andra redan har prövat, och det behöver vara en självklar roll i en gemensam modell.

Mönster 2: AI-förmågan begränsas av informationsgrunden

”Det bygger på att det finns bra grunddata i form av exakt kartunderlag, säkra fastighetsgränser och digitaliserade detaljplaner.”kommun i undersökningen

Kedjan går från digitalisering via datakvalitet och spårbar källa till säkert AI-stöd. För många användningsfall är datastandardisering ett tidigare steg än modellutveckling.

Mönster 3: Leverantörerna är en väg in och en låsningsrisk

Leverantörerna har integrationen, distributionen och driften. Kommunerna har behoven, myndighetsansvaret och kraven. En gemensam kärna kan bära standarder, kunskap och validering mellan dem.

Rekommendationen är att ta med leverantörerna, men låta kommunerna gemensamt formulera kraven på interoperabilitet, spårbarhet och återanvändning.

Mönster 4: Nätverk finns, men produktägarskap saknas

”[Nätverket] är ingen organisation så vi har ingen central information.”kommun i undersökningen

Forum, allianser och gemensamma nämnder ger erfarenhetsutbyte. Det som saknas är gemensam operativ kapacitet: prioritering, finansiering, ägande, uppdatering och juridisk kvalitet.

Avsnitt 4

Vad som behövs: tre lager

Målbilden är modulär. En gemensam kärna delas av alla, varje kommun konfigurerar sin egen del, och den professionella bedömningen stannar alltid hos människor.

Gränsen mellan lagren är den viktigaste designfrågan. Det som läggs i kärnan måste gälla för alla. Det som är myndighetsutövning får aldrig hamna där.

Avsnitt 5

Hur det kan fungera: Intertween i klartext

Intertween är en infrastruktur för att dela kunskap mellan organisationer utan att dela deras data. Den är byggd för flera områden; bygglov är det första.

Varje kommun behåller sina system och sitt ansvar. Det som delas är godkänd kunskap, och det som kommer tillbaka är en ny version som kommunen själv väljer om den vill införa.

Fem byggstenar

• Kunskapsobjekt (Knowledge Object): varje kunskapsbit i ett märkt kuvert. Det säger vad det är, var det kommer ifrån, vilken version det är och vem som får använda det.
• Lokal nod: kommunens egen installation. Originalfiler, ärendehändelser och personuppgifter stannar här.
• Grind (Gateway): den enda vägen ut. Den prövar syfte, minimering och behörighet för varje paket och loggar beslutet.
• Gemensam kärna: en versionerad samling begrepp, checklistor, komponenter och regelreferenser som växer av kommunernas bidrag.
• Publicering och införande: i det uppdaterade pilotförslaget valideras kandidater och godkänns före release; avvikelser går till en människa. Varje kommun väljer själv om den inför dem, och pågående ärenden påverkas inte.

Leverantörer kopplas in via anslutningar, i dag som fil och senare som API, utan att kunskapens identitet ändras. AI är valfritt: varje steg fungerar också med människor och vanlig mjukvara.

Självständig inom en godkänd policy

Människor godkänner inte varje förändring. De godkänner reglerna för vad den gemensamma logiken får göra på egen hand, äger dem och följer upp avvikelserna. Varje automatisk förändring pekar på den policyversion som tillät den.

En avvikelserapport säger vad som ändrades och mellan vilka versioner, varför, vilken regel som tillät det eller vilken gräns som bröts, vilka kommuner som påverkas, vem som ska agera och hur förändringen rullas tillbaka. Policyn är versionerad, har en namngiven ägare, löper ut och kan pausas.

Självständigheten gäller kunskapen och modellen, aldrig besluten i enskilda ärenden. Myndighetsbeslut om enskilda fattas av människor, i linje med förvaltningslagen och GDPR artikel 22. Avvikelserapporter och möjligheten att pausa är den mänskliga tillsyn som AI-förordningen kräver, utformad som undantagsstyrning.

Avsnitt 6

Belägg hittills

Labbet har gett tidiga insikter om hur verkliga bygglovshandlingar kan bli spårbar kunskap. Tillsammans med kommunernas uttryckta behov ger de signaler om var det kan finnas värde att pröva. De belägger ännu inte någon uppmätt nytta i kommunal drift.

Bygglovslabbet: verkliga ärenden från en kommun

Bygglovslabbet utforskar vad som går att lära av handlingar från verkliga ärenden. I ett urval från 2019 i en kommun har händelser, krav och samband gjorts spårbara till sina källor. Arbetet har gett insikter om var ett gemensamt kunskapsstöd skulle kunna skapa värde, snarare än visat att nyttan redan är uppnådd.

• Handlingarna kan göra arbetets förlopp synligt. När daterade händelser kopplas samman går det att undersöka hur ärenden har rört sig genom processen, utan att först lägga en generell processkarta över dem. Det ger en tidig signal om möjligheten att bygga uppföljning närmare det faktiska underlaget.
• Kompletteringar ger konkreta frågor att börja med. Fyra begärda kompletteringar, bland annat fasadritning med marklinjer och bullerutredning, pekar ut situationer att undersöka vidare. De ger ett avgränsat underlag för att pröva om tydligare krav och stöd för saknade handlingar kan hjälpa handläggare och sökande.
• Luckor kan bli frågor i stället för slutsatser. När ett led saknar belägg markeras det som en lucka med möjliga förklaringar. Lärdomen är att stödet behöver skilja mellan det som inte syns i materialet och det som inte har hänt. Det skulle kunna göra granskningen mer nyanserad och minska risken för felaktiga tolkningar.
• Gemensamt lärande behöver förenas med lokala val. Ett separat, simulerat experiment med tre kommuner illustrerar hur bidrag skulle kunna samlas i en gemensam modell och hur varje kommun själv kan välja vad den inför. Det ger en utgångspunkt för att pröva återanvändning mellan kommuner, men visar ännu inte att den fungerar i verklig samverkan.

Insikterna är tidiga signaler om möjlig framtida nytta: bättre överblick, mer spårbara underlag och en grund för att återanvända kunskap. Om de leder till färre kompletteringar, kortare ledtider eller högre kvalitet behöver undersökas i en avgränsad pilot tillsammans med kommunerna. Sådana effekter har inte mätts i labbet.

Underlag och avgränsning: 9 ärenden, 18 skannade PDF-handlingar, 208 kunskapsobjekt och 578 relationer. Av 34 identifierade händelser var 32 daterade och användes för att utforska processen. Namn, adresser, signaturer och fastighetsbeteckningar ingår inte. Delningen mellan kommuner är simulerad.

Vad kommunerna vill börja med

Kommunerna i undersökningen rangordnar fyra användningsfall först. Alla är stödjande, och ingen av dem fattar beslut åt handläggaren.

Alla fyra förutsätter samma grund: handlingar sorterade i överenskomna typer, ärenden kopplade till fastigheter och detaljplaner, och regler knutna till den lagversion som gällde. Det är den grund som en gemensam kärna bygger, och den kan delas.

Tre källor pekar på samma första steg

Avsnitt 7

Lärdomar från praktiken: gemensamma modeller och agenter

Två AI-projekt visar att den verkliga investeringen är informationshanteringen före modellen. När agenter tar över delar av arbetet blir den investeringen produktionskritisk.

Två kommuner, samma flöde

En kommun behövde klassificera bygglovsritningar av flera typer som kommer in som bilder och PDF utan metadata. En annan kommun behövde klassificera dokument i ansökningar om föreningsbidrag och hämta nyckeltal ur skannade årsredovisningar. Områdena skiljer sig åt, men stegen är desamma:

1. Ärende inkommer
2. Dokumenten öppnas
3. Innehållet identifieras och tolkas
4. Underlaget granskas mot regler
5. Beslut och återkoppling

I båda projekten kan en agent ta steg 1–4: hämta ärendet, tolka dokumenten med OCR och bildmodell eller språkmodell, köra regelkontroll med konfidensmarkering och lämna ett förslag som handläggaren godkänner. Samma agent och samma flöde kan då användas av alla kommuner som gör samma sak.

Fyra lärdomar från båda projekten

Människan har omdöme men räcker inte till för stora volymer. Agenten klarar volymerna men saknar omdöme. Lösningen är att kombinera dem.

När agenter pratar med agenter

Det är agenter, snarare än människor framför instrumentpaneler, som kommer att använda mest data. De ställer frågor på eget initiativ, i stor skala, och eskalerar bara det som behöver en människa. När en kommuns agent frågar en annan kommuns agent, eller den gemensamma kärnan, förstår de varandra bara om de delar samma betydelser.

290 kommuner riskerar att skapa 290 olika AI-språk.

Intertween har i dag inget färdigt protokoll för samtal mellan agenter. Ett kompletterande lösningsförslag är MCP för AI-klienter och ett API för andra system, med gemensam åtkomstkontroll bakom Studio. Läs tillägget om anslutningar och behörigheter. Kontrakten för identitet, syfte, behörighet och ursprung är dock de som ett sådant protokoll behöver.

Vad som ska vara gemensamt och vad som ska vara lokalt

Agenter och assistenter använder båda lagren. Gemensam träningsdata kräver särskild omsorg: bara granskade exempel utan personuppgifter, godkända i grinden, bör delas.

Varför det lönar sig

Varje kommun har cirka 20–30 lagstadgade bedömningsprocesser, och många bygger på samma grundlogik. Ett tidigare räkneexempel jämförde enbart upprepad utveckling av grundlogik. Det var ingen total kostnadskalkyl. Lokal integration, drift, säkerhet, support och förvaltning behöver ingå i pilotens kostnadsbedömning.

Värdet växer i tre steg: när lösningen delas, när metoden delas och störst när informationsstrukturen delas. Det sista steget gör att både människor och AI kan förstå, jämföra och återanvända information mellan kommuner.

Att dela lösningar är bra, men lärandet delas inte

Det finns redan värdefulla initiativ för att dela mellan kommuner, bland annat från SKR. De gör det lättare att återanvända kod, verktyg och arbetssätt. Det de inte delar är lärandet: vad kommunerna upptäcker när lösningarna används, vilka luckor som visar sig och hur kunskapen blir bättre över tid.

Hur lärandet ska delas mellan kommuner, spårbart och så att varje kommun behåller sitt ansvar, är fortfarande en öppen fråga. Det är den frågan Intertween försöker besvara.

Avsnitt 8

En modell med öppna vikter som gemensamt kunskapsobjekt

En AI-modell kan vara ett kunskapsobjekt i de gemensamma flödena, på samma villkor som en checklista eller ett begrepp. Skillnaden är att modellen lär sig av bidragen i stället för att bara samla dem. Med öppna vikter kan alla kommuner använda, granska och förbättra samma modell, i stället för att köpa var sin.

Tidigare designantaganden – bevarade för spårbarhet

Texten nedan är den tidigare målbilden, inte gällande pilotkrav eller verifierade funktioner. Antaganden om obligatoriska adaptrar, federerad träning som grund, automatisk publicering och förbättring för alla ersätts av förslaget ovan.

Modellen som kunskapsobjekt

Vikterna lagras som en fil med kontrollsumma, och kunskapsobjektet pekar på den. Objektet beskriver:

• Syfte och plats i flödet, till exempel att modellen klassar inkomna ritningar i steget där typ och handlingar identifieras.
• Version och härkomst: vilken tidigare version den bygger på och vilka bidrag som har tränat den.
• Träningsmanifest: vilka godkända dataset som använts, i vilka versioner och från hur många kommuner.
• Resultat: träffsäkerhet per dokumenttyp och per kommun, kända svagheter och när modellen ska svara ”ej bedömbart”.
• Licens och förvaltning: en öppen licens för vikterna och vem som äger och förvaltar modellen.

Kommunens lokala flöde pekar på en exakt modellversion, på samma sätt som det pekar på en version av en checklista.

Tre lager, även för modellen

Lager	Modellen
Gemensam kärna	En gemensam basmodell med öppna vikter
Lokal konfiguration	Ett litet lokalt tillägg per kommun, en så kallad adapter, som tränats på kommunens egna ärenden
Professionell bedömning	Det modellen är osäker på går till manuell kö och avgörs av en handläggare

Lärande utan att datan lämnar kommunen

• Federerad träning som grund. Varje kommun tränar lokalt på sina egna ärenden. Bara viktändringarna skickas genom grinden, och den gemensamma nivån väger samman dem till en ny kandidatversion.
• Delade exempel som komplement. Granskade, avidentifierade exempel som har passerat grinden används för gemensam träning och framför allt som gemensam testuppsättning.
• Den manuella kön blir träningsdata. När handläggaren avgör det som modellen var osäker på blir svaret ett nytt märkt exempel. Det som i dag går till manuell kö blir modellens viktigaste källa till lärande.

Konstant lärande, publicerat i versioner

Modellen ändras aldrig medan den används. Lärandet pågår hela tiden, men resultatet publiceras som versioner:

1. En ny kandidatversion tränas på de senaste bidragen.
2. Den testas automatiskt mot den gemensamma testuppsättningen och mot varje kommuns egna testfall.
3. Blir den bättre totalt utan att bli sämre för någon kommun eller dokumenttyp, publiceras den automatiskt inom autonomipolicyn.
4. Blir den sämre för någon, ändras fördelningen kraftigt eller verkar ett bidrag vara felmärkt, pausas den och en avvikelserapport skickas.
5. Varje kommun väljer själv om den inför versionen och kan alltid gå tillbaka till en tidigare.

Självorganisering

Modellen kan föreslå struktur, inte bara klassa:

• Nya kategorier. Handlingar som inte passar någon befintlig typ grupperas och blir förslag på nya dokumenttyper.
• Luckor. Handlingar som inte stämmer med det förväntade flödet flaggas som intertweens.
• Gemensamma betydelser. När två kommuners lokala etiketter visar samma mönster föreslås en gemensam betydelse.

Förslagen blir kandidater i den gemensamma kärnan. Att slå ihop begrepp eller ändra en kategori som andra redan använder räknas alltid som en avvikelse och går till en människa.

Risker att designa för

Risk	Varför	Motåtgärd
Läckage via vikterna	Öppna vikter kan granskas av vem som helst, och en modell kan minnas delar av sin träningsdata	Ingen träning på personuppgifter. Avidentifiering före träning, differentiell integritet och säker sammanvägning vid federerad träning, och test för läckage före publicering.
Förgiftade bidrag	En kommun med felmärkta exempel kan försämra modellen för alla	Spårbarhet per bidrag, kontroll av avvikande bidrag och krav på flera oberoende kommuner
Bidrag som dras tillbaka	En modell kan inte enkelt ”glömma” det den har lärt sig	Träningsmanifestet sparas så att en version kan tränas om utan bidraget. Under tiden rullas den tillbaka till föregående version.
Glömska och drift	Ny träning kan försämra det modellen redan kunde	Varje version testas mot alla kommuners testfall, inte bara mot ett genomsnitt
Juridik	AI-förordningen och GDPR ställer krav på dokumentation och tillsyn	Modellen stödjer handläggaren och fattar aldrig beslut. Dokumentation, loggning och mänsklig tillsyn genom avvikelserapporterna.
Ägande och kostnad	Träning kräver beräkningskraft och någon som förvaltar modellen	Del av de öppna frågorna om ägarskap och finansiering, se avsnitt 12

Exempel: klassning av ritningar

En öppen bildmodell klassar ritningar som fasad, plan och sektion. Varje kommun tränar ett lokalt tillägg på sina egna ärenden och skickar viktändringarna genom grinden. En ny gemensam version publiceras när den blir bättre för alla, utan att någon ritning har lämnat någon kommun. Fullständighetskontrollen använder sedan klassningen för att se vilka handlingar som saknas.

Skiftet

Modellen blir inte en produkt som varje kommun köper för sig. Den blir ett gemensamt kunskapsobjekt som blir bättre för varje kommun som bidrar, med samma spårbarhet, versioner och ansvar som allt annat i Intertween.

Avsnitt 9

Designprinciper

Börja nära vardagsarbetet, men på avstånd från besluten. Stödjande användningsfall kommer före automatiserade myndighetsbedömningar.

”Väldigt lätt att missa följdfrågor som avgör om bygglov krävs eller inte.”kommun i undersökningen

• Rätt frågor före svar. Identifiera saknad kontext, ställ de följdfrågor som är obligatoriska, visa auktoritativa källor och eskalera när underlaget är osäkert.
• Varje påstående har en källa och en version. Ett svar ska gå att följa tillbaka till handling, sida och lagversion.
• Mönster är inte juridik. Att de flesta ärenden hanteras på ett visst sätt bevisar inte att det krävs eller att det gjordes rätt.
• Luckor markeras, de gissas inte bort. Det som saknas beskrivs som saknat underlag, med möjliga förklaringar.
• Data stannar lokalt. Bara godkänd kunskap passerar grinden, och varje beslut loggas.
• Självständigt inom en policy, och kommunen väljer själv. Den gemensamma logiken lär och organiserar sig själv inom godkända ramar och rapporterar avvikelser. En ny gemensam version införs bara efter ett lokalt beslut, och pågående ärenden påverkas inte.
• Leverantörer integrerar, kommunerna äger kraven. Interoperabilitet, spårbarhet och återanvändning formuleras gemensamt.
• AI är valfritt. Varje steg ska fungera även med människor och vanlig mjukvara.

Avsnitt 10

Sätt att delta

Fyra nivåer gör det möjligt att vara med även med begränsad kapacitet. Varje nivå har en tydlig motsvarighet i hur Intertween fungerar.

Eftersom 41 % av kommunerna i urvalet är i ett tidigt skede bör nivå 3 och 4 vara öppna från start. Det räcker inte att bara bjuda in dem som kan utveckla.

Avsnitt 11

Vägen framåt

Nästa steg är test och validering tillsammans med ett kluster av kommuner, med saknade handlingar som första pilot. Efter steg 3 fattas ett uttryckligt beslut om användningsfallet är redo.

Första pilot: saknade handlingar

• Omfattning: klassning av inkomna handlingar och kontroll av att alla handlingar som krävs för ärendetypen finns med.
• Deltagare: ett par kommuner på nivå 1 (Utveckla), till exempel kommuner som redan har underlag från labbet eller de tidiga AI-projekten, och fler på nivå 3 och 4.
• Gemensamt: lista över dokumenttyper, krav på handlingar per ärendetyp och granskade träningsexempel.
• Lokalt: ärenden, handlingar och beslut.
• Mäts: andel ärenden som behöver kompletteras, tid från begäran till svar och andel underlag som går till manuell kö.
• Klar när: en kommuns bidrag har passerat grinden, en annan kommun har infört det, och en nekad export har stannat lokalt.

Piloten stödjer handläggaren och fattar inga beslut. Den mäter kalendertid mellan händelser, inte arbetstid.

Avsnitt 12

Öppna frågor

De svåraste frågorna gäller ägarskap, inte teknik. Mjukvara kan göra ansvar synligt och spårbart, men den kan inte utse den som bär det.

Samverkanstrappan visar avståndet: från att dela och nätverka, via att samordna och samverka, till att samskapa och samäga en gemensam förmåga. De flesta nätverk i dag står på de första stegen.

• Ägarskap: vem äger och prioriterar den gemensamma kärnan?
• Finansiering: hur betalas förvaltningen när piloten är klar?
• Juridisk kvalitet: vem granskar regeltolkningar, och mot vilken lagversion?
• Rättslig grund: vad får delas som härledd kunskap och som träningsexempel, och hur länge får det sparas?
• Agenternas mandat: vem får ge en agent uppdrag, med vilket ändamål, och vem svarar för det den gör? Vem äger autonomipolicyn, och vem tar emot avvikelserapporterna?
• Leverantörskrav: hur formuleras gemensamma krav på interoperabilitet, spårbarhet och återanvändning, och vem ställer dem?
• Teknisk drift: vem driver den gemensamma tjänsten och svarar för säkerhet och tillgänglighet?

Bilaga: metod, urval och begränsningar

Kommunundersökningen

• Underlaget är 17 identifierade mejltrådar eller kommunala svar.
• Svaren har kodats tematiskt och kvalitativt, med överlappande kategorier.
• Svaren representerar olika kommunstorlek, mognad och samverkansform.
• Siffrorna visar förekomst i urvalet, inte andel av Sveriges 290 kommuner. Resultaten är indikativa.
• Kommuner, organisationer och personer är anonymiserade. Kommun 1 är en pseudonym, och AI-projekten beskrivs utan uppgifter som kan peka ut kommunerna.

Bygglovslabbet och Intertween

Labbet är ett experiment som körs i en webbläsare. Det är inte kopplat till något kommunalt system. Delningen mellan kommuner är simulerad, och labbet gör inga juridiska bedömningar.

Källor

• Slutrapport från en intervjuundersökning med kommuner om gemensam AI inom bygglov, 2026.
• Presentation om informationshantering för AI för ett nätverk inom offentlig sektor, maj 2026.
• Underlag från tidiga kommunala AI-projekt inom bygglov och föreningsbidrag, 2026.
• Intertween 2.0 Technical Specification and Architecture, version 1.0, 22 oktober 2026.
• Building Permit Lab Technical Specification and Architecture, version 1.0, 22 oktober 2026.