Kandidat för test · Verkligt underlag och simulerad delning
Kommunerna vill samverka men saknar en gemensam grund att stå på.
Bygg inte samma grund 290 gånger
En genomgång av 17 kommunala svar om AI inom bygglov visar ett tydligt glapp mellan vilja och förmåga. De flesta ser behovet av samverkan, men få har kapacitet att bygga själva. Fyra mönster återkommer: samverkan är rationell men svår att mobilisera, AI begränsas av informationsgrunden, leverantörerna är både en väg in och en låsningsrisk, och nätverk finns men ingen äger produkten.
Förstudien föreslår en modulär målbild: en gemensam kärna för regler, begrepp och dokumenthantering, lokal konfiguration för varje kommun, och professionell bedömning som alltid stannar hos människor. En föreslagen första pilot gäller saknade handlingar.
Läs förstudien: abstract och sammanfattning →”Bygg inte samma grund 290 gånger. Bygg en gemensam kärna som kan konfigureras lokalt och förvaltas gemensamt.”
Indikativa andelar i ett urval om 17 svar. Kategorierna överlappar.
Förstudien beskriver vad som behövs. Resten av fallet visar hur det kan fungera i praktiken, med Gemensamma flöden i Intertween och ett exempel som följer med genom alla steg.
Gemensamma flöden: en process, många lokala versioner.
Gemensamma flöden i Intertween kartlägger en process som många delar. Den gemensamma modellen lär sig av varje kommuns verkliga ärenden och delar med sig av det den har lärt sig. Varje kommun väljer själv vad den tar emot.
Varje kommun kan använda en godkänd gemensam version lokalt, lägga till egna regler eller också bidra till lärandet. Den gemensamma modellen samlar det som har godkänts. När flera lokala modeller jämförs syns en lucka som ingen kommun ensam kunde se.
Den gemensamma modellen lär sig
Varje kommun bidrar med det den har lärt sig: en checklista, en ordförklaring, ett mönster i processen. Bidraget går genom kommunens grind. Råa ärenden stannar hemma.
Kommunerna tar emot
Den gemensamma modellen ger tillbaka komponenter som andra redan har prövat. En liten kommun kan få en fullständighetskontroll som en stor kommun har byggt. Den lilla kommunen väljer själv om den vill införa kontrollen, vänta eller anpassa den.
Strukturella hål blir synliga
När många lokala processer läggs bredvid varandra syns luckorna: ett steg utan belägg, en överlämning som saknas, två ord för samma sak. Varje lucka blir en intertween, en markerad fråga som en människa tolkar.
Granskade bidrag från flera kommuner kan ge ett bredare underlag för dokumentigenkänning. Om stödet blir bättre behöver visas på undanhållna testärenden, även för små kommuner och svåra dokumenttyper.
Ärendespecifika kontroller föreslås köras i en nod som kommunen kontrollerar. Den håller godkända versioner av kunskap och regler, processstatistik och dokumentigenkänning. Lokal träning är valfri.
Kunskapsobjekt, statistik och klassificerarbidrag granskas i separata flöden. Kommunerna kan även bidra med förberedda handlingar som träningsdata genom en särskilt godkänd dokumentväg. Avidentifiering ensam ger inte rätt att dela eller träna. Läs om bidragsvägarna →
Modellen är också ett kunskapsobjekt
En AI-modell med öppna vikter kan ingå i de gemensamma flödena på samma villkor som en checklista eller ett begrepp. Den är versionerad, har ett träningsmanifest och redovisar sina resultat per kommun. Skillnaden är att den lär sig av bidragen i stället för att bara samla dem.
En versionerad dokumentklassificerare
Gemensamma komponenter kan återanvändas. Metod och utvärdering föreslås vara öppna; publicering av vikter prövas separat.
Ett lokalt tillägg per kommun
Kommunen använder en godkänd version och kan lägga till lokala regler och trösklar. Lokal träning är en ytterligare möjlighet som behöver prövas.
Granskade rättelser blir kandidater
Det modellen är osäker på avgörs av en handläggare. En granskad rättelse kan bli ett märkt träningsexempel, om användningsvillkoren tillåter det. Kvaliteten måste visas i nästa utvärdering.
Kandidatversioner jämförs på samma undanhållna ärenden med förutbestämda kvalitetskrav. Otillräckligt underlag ger begränsad prövning. Release och lokalt införande kräver separata godkännanden i piloten. Mer om risker och skydd finns i avsnitt 8 i förstudien.
Förhållandet är ömsesidigt. Den gemensamma modellen står inte över kommunerna. Den erbjuder, och varje kommun bestämmer.
Från en hög handlingar till en gemensam förbättring.
Samma sju steg gäller för all kunskap i Intertween. Här följer vi ett exempel genom alla steg.
Saknade handlingar. En ansökan kommer in utan alla ritningar. Handläggaren begär komplettering och ärendet står still. Kommun 1 i labbet har verkliga ärenden där handlingar begärdes. Tänk dig en andra kommun som har en lista över vilka handlingar varje ärendetyp kräver. Kan deras kunskap bli en gemensam kontroll?
-
1
Samla in
Lokal loopKällor läses in där de finns: filer, ärendehändelser, listor och processbeskrivningar. Vid varje inläsning registreras vad som lästes, vilken version av anslutningen som användes och en kontrollsumma, så att inläsningen kan upprepas med samma resultat.
I exempletKommun 1 läser in 18 skannade handlingar från 9 ärenden. Den andra kommunen läser in sin lista över krav på handlingar per ärendetyp.
WrapperConnector -
2
Paketera
Lokal loopVarje uppgift läggs i ett kunskapsobjekt: ett märkt kuvert med typ, källa, sida, version och vem som får använda det. Påståenden sorteras efter sin typ. En begäran är inte ett bevis på att något har gjorts.
I exempletEn begäran om fasadritning med marklinjer blir ett krav med okänd status, kopplat till den sida där det står.
{ "type": "InformationRequirement", "item": "fasadritning med marklinjer", "satisfied": "unknown", "source": { "page": 1 } }WrapperKnowledge Object -
3
Mappa
Lokal loopLokala ord kopplas till gemensamma betydelser. Kopplingarna är förslag tills en människa har granskat dem, och en mappning får aldrig ge fler personer åtkomst till uppgiften.
I exempletKommun 1 skriver ”Fasadritning”, den andra kommunen taggar ”Fasad”. Båda föreslås peka på samma dokumenttyp. ”Inkomstdatum” och ”Ankomstdatum” pekar på samma betydelse: datum mottaget.
MapperMappingProposal -
4
Upptäck
Lokal loopProcessen tas fram ur daterade händelser i stället för att ritas för hand. Händelser som inträffat samma dag får ingen påhittad ordningsföljd. Där ett led saknar belägg skapas en lucka med möjliga förklaringar.
I exempletÄrendena går ofta tillbaka till ”väntar på komplettering”. I ett ärende begärs en ritning som aldrig syns igen. Det blir en * intertween: skickades den men arkiverades inte, eller skickades den aldrig?
Gemensamma flödenintertween -
5
Observera
Lokal loopVarje mått redovisar täljare, nämnare och urval. Jämförelser görs bara när definitionerna är desamma. Tiden mellan två händelser redovisas som kalendertid, inte som arbetstid.
I exempletTre mått följs: andel ärenden som behöver kompletteras, kalendertid från begäran till svar och andel handlingar som går till manuell kö. I ett tidigt AI-projekt för klassning av bygglovsritningar gick 15 % till manuell kö.
ObserverTracker -
6
Väg samman
Gemensam loopGodkänd kunskap lämnar kommunen genom grinden. På den gemensamma nivån stäms lokala ord av mot varandra, och mönster och luckor jämförs mellan kommuner. Där syns också hur många oberoende kommuner som står bakom en komponent. Nio ärenden från en kommun räknas inte som nio bekräftelser.
I exempletDen andra kommunens fullständighetskontroll passerar grinden som ett bidrag. Den prövas mot kommun 1:s material: förklarar den de fyra begärda handlingarna? Tillåtna bidrag kan bilda en kandidat för dokumentigenkänning. Förberedda träningshandlingar kräver separat prövning; rutinmässiga lokala ärenden skickas inte till en central kontroll.
GatewayTrackerFederation -
7
Publicera och inför
Gemensam loopFörslagen samlas i en versionsrapport som beskriver vad som ändras och varför, med belägg och undantag. Automatiska kontroller prövar kandidaten mot fastställda kvalitetskrav. I piloten godkänner ansvariga releasen; avvikelser utreds före publicering. Sedan väljer varje kommun själv om den inför den.
I exempletVersion 2 av den gemensamma modellen publiceras inom policyn och innehåller kontrollen. Kommun 1 inför den för nya ärenden. En tredje kommun väntar. Pågående ärenden ligger kvar på den version de startade med. En klassificerarkandidat prövas separat på undanhållna ärenden. Release kräver dokumenterade kvalitetskrav och godkännande; otillräcklig evidens ger begränsad prövning.
Release serviceGemensamma flödenRegistry
Det som händer efter införandet, till exempel fler eller färre kompletteringar, observeras igen i steg 5. Så slutar varje varv där nästa börjar.
Tre loopar driver lärandet. Tio funktioner bär dem.
Lärandet sker på tre nivåer som hänger ihop: i varje kommun, mellan kommunerna och efter att en förändring har börjat användas.
Kommunen lär känna sin egen process ur sina egna ärenden. Den hittar luckor och mönster och bestämmer själv vad som kan delas. Allt sker inne i kommunens nod.
Godkända bidrag och mätvärden från många kommuner möts. Den gemensamma nivån stämmer av lokala ord mot varandra, jämför mönster när definitionerna stämmer och hittar luckor som ingen kommun ser ensam. Den arbetar självständigt inom en godkänd policy och rapporterar avvikelser.
Ett infört förslag är en hypotes tills utfallet har följts upp. Kommunen följer sina egna ärenden, och den gemensamma nivån följer hur versionen fungerade i alla kommuner som införde den. Observationerna kopplas till den version som faktiskt användes.
Självständig inom en godkänd policy
Avgränsade beräkningar och kandidatförslag kan köras inom en godkänd policy. I pilotförslaget granskas releaser uttryckligen, och ändrade dokumentkrav behöver ansvarig granskare. Varje körning pekar på policy och använda versioner.
| Typ av förändring | Exempel | Hur den styrs |
|---|---|---|
| Självständig | Omräknade mönster och vikter, nya kandidater till kategorier och kopplingar, uppdaterade jämförelser, analytiska versioner inom policyn | Ingen godkänner i förväg. Allt loggas och syns i rapporter. |
| Avvikelse | Oväntad förändring i en fördelning, bruten kvalitetsgräns, bidrag som krockar, förslag att slå ihop två begrepp | Just den förändringen pausas. En avvikelserapport går till policyns ägare. |
| Alltid människa | Juridisk tolkning, utökad åtkomst eller export, ändrad handläggning i en kommun, myndighetsbeslut | Kan aldrig delegeras till policyn |
- Vad som ändrades och mellan vilka versioner
- Varför: belägg, motbelägg och hur säker bedömningen är
- Vilken regel i policyn som tillät det, eller vilken gräns som bröts
- Vilka kommuner och sammanhang som påverkas
- Vem som äger policyn och vem som ska agera
- Hur förändringen rullas tillbaka
- Policyn är versionerad och godkänd av en namngiven ägare
- Den anger tillåtna förändringar, data, metoder, gränsvärden och övervakning
- Den löper ut och måste förnyas
- Insamling, delning och releaseflöde kan pausas var för sig
- Varje kommun beslutar själv om den inför en ny version
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, insyn och möjlighet att ingripa är föreslagna delar av tillsynen. Tillämpliga krav, roller och rättslig grund behöver prövas för piloten; arkitekturen visar inte i sig regelefterlevnad.
Se den gemensamma loopen steg för steg
Följ hur tre påhittade kommuner delar kunskap. Välj ett steg eller använd Nästa för att följa hela förloppet.
Lärsteg räknar illustrativa varv. V-numret visar godkänd release och lokalt införande.
Två kommuner, en enkel modell
Se innehållet i den gemensamma modellen
Intertweens funktioner i fallet
| Funktion | Vad den gör | I exemplet | Steg |
|---|---|---|---|
| Wrapper | Läser in källor och skapar kunskapsobjekt med källankare | 18 skannade handlingar blir objekt med sida och kontrollsumma | 1–2 |
| Mapper | Föreslår kopplingar mellan lokala ord och gemensamma betydelser. På gemensam nivå stäms förslagen av mellan kommuner | ”Fasadritning” och ”Fasad” blir samma dokumenttyp | 3, 6 |
| Gemensamma flöden | Håller isär upptäckta, avsedda och lokala modeller och binder kommunen till en version | Den upptäckta processen jämförs med den gemensamma | 4, 7 |
| Observer | Mätvärden, jämförelser och avvikelser med uttalade definitioner, lokalt och mellan kommuner | Lokalt: andel ärenden som behöver kompletteras. Gemensamt: samma mått jämfört mellan kommuner med samma definition | 5–6 |
| Observatory | Vyn där belägg, motbelägg, bidrag och utfall syns över tid | Hur många oberoende kommuner som står bakom kontrollen och vad som hände efter införandet | 6–7 |
| Tracker | Ursprung, relationer, bidrag och återanvändning | Vem som bidrog med kontrollen och var den används | 5–6 |
| Gateway | Prövar och loggar allt som lämnar noden | Kontrollen passerar, men råa ärenden stannar kvar | 6 |
| Federation | Tillit mellan noder, leverans och återkallelse | Bidraget tas emot, verifieras och kan dras tillbaka | 6 |
| Release service | Versionsrapport, avvikelserapport och aktivering inom autonomipolicyn | Version 2 publiceras inom policyn, och ett förslag som krockar pausas som avvikelse | 7 |
| Registry | Identitet, versioner och behörighetsstyrd sökning | Varje version av kontrollen har ett eget id | alla |
Kärnan som gör det möjligt
Allt delas i samma märkta kuvert: typ, ursprung, version och användningsvillkor.
En lucka eller oklar koppling som markeras och tolkas av en människa, i stället för att gissas bort.
Varje modell och komponent har versioner. Ett beslut kan alltid kopplas till exakt den version som användes.
Att publicera och att införa är två olika beslut. Publiceringen sker inom den gemensamma policyn, medan införandet beslutas lokalt.
Samma regler gäller för sökningar, grafen, exporter och agenter. Ingen kan ge sig själv mer åtkomst.
Hur ofta något sker säger inget om vad lagen kräver. Juridisk tolkning har en egen granskning.
Vad som hände och varför det är viktigt.
Vad som hände
- Två kommuners underlag blev märkt och spårbar kunskap utan att lämna kommunerna.
- Den verkliga processen togs fram ur händelserna, och en lucka blev synlig: en begärd ritning utan spår.
- Två lokala ord för samma sak fick en gemensam betydelse.
- En kommuns fullständighetskontroll blev en gemensam komponent och prövades mot en annan kommuns verkliga ärenden.
- En kandidat validerades och en release godkändes med spårbar policy och ägare. Avvikelser gick till en människa. Varje kommun valde själv om och när den skulle införa den.
- Utfallet följs upp och matar nästa varv.
Vad det kan ge
| För | Nytta |
|---|---|
| Sökande | Tydligare krav från början och färre kompletteringsrundor |
| Handläggare | En flygande start: underlag samlat och förslag med källor |
| Varje kommun | Behöver inte bygga grunden själv, och den egna datan stannar hemma |
| Små kommuner | AI-stöd tränat på många kommuners exempel, inte bara egna |
| Alla kommuner | Ett gemensamt språk för människa och AI, och jämförbar statistik |
Återanvändning kan minska dubbelarbete, men total kostnad behöver mätas. Lokal integration, säkerhet, support, drift och gemensam förvaltning ingår i pilotens kostnadsbedömning.
Läget i dag
- ✓Inläsning och paketering av verkliga handlingar
- ✓Processupptäckt med luckor och korrigerade läsningar
- ✓Simulerad delning, publicering och införande mellan tre kommuner
- ○Riktiga, separata noder för olika kommuner
- ○Juridiskt granskade regler och uppmätt effekt
Nästa steg
Test och validering tillsammans med ett kluster av kommuner, med saknade handlingar som första pilot. Efter kartläggning och databedömning fattas ett uttryckligt beslut om piloten är redo.
Piloten stödjer handläggaren och fattar inga beslut. Inget i fallet bedömer enskilda medarbetare.
Fyra sätt att vara med
- Nivå 1UtvecklaBidra med data, testmiljö och personal från verksamheten.
- Nivå 2ValideraGranska juridik, behov och resultat.
- Nivå 3RefereraDela processkartor och lokala variationer.
- Nivå 4AnslutaInför prövade komponenter när det passar.
Uppdaterat lösningsförslag · 27 oktober 2026
Tre delar som arbetar tillsammans
Den gemensamma modellen föreslås bestå av kunskap och regler, processstatistik och dokumentigenkänning. Delarna får egna versioner och prövas var för sig. Det här utvecklar lösningsförslaget; det är inte ett nytt resultat från kommunundersökningen.
- Kunskap och regler
- Godkända begrepp, dokumentkrav och lokala villkor med källor. Statistik kan föreslå en granskning, men avgör inte vad lagen kräver.
- Processstatistik
- Observationer om förlopp, kompletteringar och ledtider. Lokal statistik kan jämföras med gemensamma mönster utan att varje kommun måste träna en modell.
- Dokumentigenkänning
- Ett klassificeringsstöd för exempelvis plan- och fasadritningar. Osäker klassning går till manuell granskning; en okänd handling räknas inte automatiskt som saknad.
Ärendespecifika kontroller föreslås köras i en lokal nod som kommunen kontrollerar, med godkända komponentversioner och lokala regler. Kommunen kan ansluta, konfigurera eller också bidra till lärandet. Ett stort språkmodellstöd är valfritt.
Lärande skapar kandidater. Validering, godkänd publicering och kommunens lokala införande är separata steg. I piloten föreslås uttryckligt godkännande före en release. Faktisk nytta, kvalitet och driftkostnad behöver mätas.
Flödesprofil · Utkast 0.1 · 4 november 2026
Bygglov som ett normstyrt flöde
Bygglovsexemplet kan nu beskrivas med samma flödesmodell som andra verksamhetsflöden. Syftet är process: ärendet jämförs med tillämpliga normer, samtidigt som varje kommun behåller mandatet över bedömning och beslut.
- Syfte
processNormstyrd handläggning- Det som rör sig
- BygglovsärendetHändelser och tillstånd över tid
- Referens
- Tillämpliga kravLag, detaljplan och lokala beslut
- Observation
- ÄrendehistorikenHandlingar, kompletteringar och beslut
- Ansvar
- Kommunens mandatHandläggare och behöriga beslutsfattare
Tre läsningar av samma historik
- Discovery
- Visar hur ärenden faktiskt rör sig och vilka mönster som återkommer, även när de inte finns i den beslutade modellen.
- Efterlevnad
- Jämför ett ärende med den norm och den flödesmodellversion som gällde vid tidpunkten. En avvikelse är en signal för granskning, inte ett automatiskt rättsligt omdöme.
- Förbättring
- Observationer kan bli kandidater till en ändrad kravkatalog eller flödesmodell. Cultivator föreslår, människor granskar och kommunen beslutar om lokalt införande.
Varje ärende bör hänvisa till den flödesmodellversion som användes. En ny version ersätter inte historiken och ändrar inte äldre bedömningar i efterhand. Om en verifierad observation motsäger ett antagande kan berörda delar flaggas för översyn.
Läs hela utkastet till Flödesprofil → · Se pilotkrav och teknisk bilaga →
Möjlig vidareutveckling
En gemensam modell som fler kan ansluta till
Den gemensamma process- och kunskapsmodellen skulle kunna användas även från kommunernas verksamhetssystem, andra plattformar och AI-agenter. Studio föreslås bli arbetsytan där anslutningar, uppdrag och behörigheter kan hanteras.
Förslaget är ett versionerat API för system och en MCP-anslutning för AI-assistenter och agenter. Båda använder samma verksamhetstjänster och åtkomstregler som Studio. Ärendespecifika frågor föreslås gå till kommunens lokala nod, med dess godkända versioner och lokala regler. Gemensamma kunskapsfrågor kan gå till en gemensam tjänst. Externa anslutningar behöver alltså inte arbeta genom webbgränssnittet. AI kan hjälpa till att tolka frågor och använda verktyg; åtkomsten kontrolleras av tjänsten vid varje anrop.
Med rätt mandat skulle en anslutning kunna ställa källbundna frågor, hämta tillåten aggregerad statistik, bidra med handlingar som träningsdata för granskning och använda modellen som stöd för bedömningsutkast. Kommuner kan använda gemensamma komponenter utan lokal träning. Godkända handlingar och granskade exempel behövs som en separat bidragsväg för att utveckla och utvärdera dokumentigenkänningen. Originalen kan stanna lokalt; endast särskilt förberedda kopior eller utdrag med prövade användningsvillkor föreslås föras över. Bidrag ändrar inte modellen direkt. Lokala underlag behåller sina åtkomstgränser, och människor ansvarar för bedömningar och beslut.
Detta är en möjlig vidareutveckling, inte en driftsatt integration. Läs om anslutningar, behörigheter och ett möjligt första pilotsteg i Studio →