Hoppa till huvudinnehållet
FromNine
Meny

AI och data

Data som både AI och beslutsfattare kan stå på.

På våra dataplattformar har varje datamängd en ägare, ett avtal och en kvalitet som är känd. Rapporterna, den dagliga styrningen och AI-tillämpningarna räknar därför med samma siffror.

För organisationer i Finland vars uppgifter är utspridda över bolag, enheter, äldre system och två språk.

Data och analys: skikten i tjänstenFyra skikt ovanpå varandra. Uppifrån och ned: analys och AI som använder uppgifterna, dataprodukter med ägare och avtal, lakehouse-skikten som tvättar och harmoniserar och styrningen som omfattar allt detta.01Analys och AI02Dataprodukter och avtal03Lakehouse-skikt04Styrning och härkomst
  1. 01Varje dataprodukt har en namngiven ägare, ett avtal och kvalitetskontroller
  2. 02Ändamål och lagringstider styrs av plattformen, inte bara av en katalog
  3. 03Nyckeltal med en definition som verksamheten och IT har skrivit under gemensamt

01 Utmaningar

Dataproblem som de flesta känner igen

Många AI-projekt som inte lever upp till förväntningarna är i själva verket dataprojekt.

  1. 01

    Samma fråga, tre olika svar

    Ekonomiavdelningen, verksamheten och styrelsen räknar fram omsättningen eller antalet ärenden på var sitt sätt. Varje möte börjar med att siffrorna stäms av i stället för att något beslutas.

  2. 02

    Felen rättas aldrig vid källan

    Ingen äger uppgifterna. Felen hittas långt senare, lagas i ett kalkylark och är tillbaka månaden därpå.

  3. 03

    AI-teamet letar mer än det bygger

    Varje nytt användningsfall inleds med veckor av behörighetsansökningar, uttag och tvätt, och nästa team börjar om från noll.

  4. 04

    Arkivet duger inte som underlag för AI

    Skannade dokument med svag textigenkänning, dubbletter och ingen metadata, och ofta finns en finsk och en svensk version av samma dokument utan att någon har kopplat ihop dem. Den som söker i dem får mest brus.

02 Leveranser

Det här levererar vi

  1. 01 En datagrund för AI och analys

    Ett lakehouse där uppgifterna förädlas i skikt, från rådata till harmoniserade data och vidare till det som används, och där varje dataprodukt redovisar vad den innehåller, hur aktuell den är och vem som ansvarar för den.

    Det här gör vi

    • Arkitektur för plattformen och val av lagringsformat
    • Konventioner för modellering i skikt
    • Utformning av dataprodukter med avtal
    • Inläsning i batch och med ändringsdatafångst

    Det här får du

    • Lakehouse-plattform definierad i kod
    • De första dataprodukterna i produktion
    • Mall för dataavtal och en granskningsprocess
  2. 02 Kvalitet, härkomst och grunddata

    Kvaliteten kontrolleras automatiskt i varje skikt, härkomsten kan följas från källan till rapporten och grund- och referensdata hålls i ordning för det som betyder mest: invånare, kunder, produkter och anläggningar.

    Det här gör vi

    • Kvalitetsregler med tröskelvärden och larm
    • Härkomst ned på kolumnnivå
    • Regler för matchning och sammanslagning av grunddata
    • Hantering av referensdata och kodlistor på finska och svenska

    Det här får du

    • Kvalitetsvy för varje dataprodukt
    • Härkomst som går att söka i
    • Gemensamma grundposter för de viktigaste objekten
  3. 03 Styrning som faktiskt tillämpas

    Katalogen, klassningen och åtkomstreglerna tillämpas av plattformen utan manuellt arbete. Dataskyddsförordningens krav på ändamålsbegränsning och lagringstider är inbyggda, och när uppgifter delas följs dataförvaltningsakten där den är tillämplig.

    Det här gör vi

    • Klassningsschema och märkning
    • Attributbaserade åtkomstregler
    • Automatisk gallring och radering
    • Avtal om datadelning och tekniska kontroller

    Det här får du

    • Katalog som fylls på från plattformen
    • Åtkomstregler som kod
    • Gallringsplan i drift
  4. 04 Ostrukturerat innehåll redo för AI

    Bättre textigenkänning, mer metadata, färre dubbletter och ett städat arkiv gör att dokumenttolkning och sökning arbetar med innehåll som är värt att hitta.

    Det här gör vi

    • Förteckning över innehållet och stickprov på kvaliteten
    • Förbättrad textigenkänning och layouttolkning
    • Upptäckt av nästan identiska dokument och språkversioner
    • Berikning av metadata och klassificering

    Det här får du

    • Rensat och berikat innehållslager
    • Rapport om innehållets kvalitet
    • Regler för innehåll som läggs till framöver
  5. 05 Analys och BI som används

    Ett semantiskt skikt med nyckeltal som verksamheten och IT har enats om, självbetjäning med tydliga ramar och analys som är inbyggd i SaaS-produkter och portaler.

    Det här gör vi

    • Workshoppar om definitionerna av nyckeltal
    • Semantisk modell och måttskikt
    • Ramar för självbetjäning och certifierade datamängder
    • Inbäddad analys i produkter för kunder

    Det här får du

    • Ordlista över nyckeltal med ägare
    • Certifierad semantisk modell
    • Rapportvyer som ersätter kalkylark
  6. 06 Strömmande data för den dagliga driften

    Ändringsdatafångst och händelseströmmar för beslut som inte kan vänta till nästa natts laddning, till exempel lagersaldon, var ett ärende befinner sig eller tecken på bedrägeri.

    Det här gör vi

    • Krav på fördröjning per användningsfall
    • Ändringsdatafångst från driftdatabaser
    • Strömbearbetning och materialiserade vyer
    • Utformning av uppspelning och efterladdning

    Det här får du

    • Strömmande flöden i produktion
    • Driftvyer med mål för aktualitet
    • Rutin för uppspelning

03 Arkitektur

En illustrativ referens­arkitektur

Uppgifterna kommer från verksamhetssystem och dokument och läses in i ett lakehouse med tre skikt. Det första håller rådata oförändrade, det andra harmoniserade och kontrollerade data och det tredje dataprodukter som har en ägare och ett avtal. Rådata läses aldrig direkt av användarna.

Ur dataprodukterna hämtar det semantiska skiktet och BI sina siffror, och andra vägar leder till sökning och egenskaper för AI och till data-API:er för andra system. Styrningen omfattar allt detta och verkställs av plattformen, inte av ett policydokument.

Illustrativt exempel
  1. Källor och inläsning

    • Verksamhets­system
    • Dokument efter textigenkänning och berikning
    • Batch och ändrings­datafångst
  2. Lakehouse

    • Råskikt
    • Harmoniserat skikt
    • Kvalitets­kontroller och härkomst
    • Grund- och referensdata
    • Dataprodukter med avtal
  3. Användning

    • Semantiskt skikt och BI
    • Sökning och egenskaper för AI
    • Data-API:er och delning
  4. Styrning

    • Styrning: katalog, klassning, åtkomstregler, lagringstider
Lakehouse-skikt som blir ägda dataprodukter

Illustrativ arkitektur, inte ett kundsystem.

Läs diagrammet som text

Bilden visar hur uppgifter från verksamhetssystemen läses in i batch och med ändringsdatafångst och passerar råskiktet, det harmoniserade skiktet och dataprodukterna innan de når ett semantiskt skikt med styrd BI.

Ostrukturerade dokument läses in efter textigenkänning och berikning. Råskiktet och det harmoniserade skiktet omfattas av kvalitetskontroller och härkomst, och grund- och referensdata går in i dataprodukterna. Från dataprodukterna går uppgifter också till sökning och egenskaper för AI och till data-API:er för delning.

Ett band för styrning med katalog, klassning, åtkomstregler och lagringstider sträcker sig över hela plattformen.

04 Överväganden och gränser

Tekniska avvägningar och gränser

  • Först ägare, sedan verktyg

    Så hanterar vi det

    Till varje dataprodukt utses en ägare i verksamheten som avgör vad den betyder och en teknisk ägare som ser till att den fungerar. Vi hjälper till att beskriva rollerna och avtalet mellan dem som levererar och dem som använder uppgifterna.

    Gränser och beroenden

    Ägarskap uppstår inte av en plattform. Utser organisationen inga ägare kommer kvalitetsproblemen tillbaka, hur bra verktygen än är.

  • Ändamåls­begränsning som fungerar

    Så hanterar vi det

    Personuppgifterna märks med de ändamål de får användas för, och åtkomst och lagringstid följer märkningen utan manuellt arbete.

    Gränser och beroenden

    Vilka ändamål som är tillåtna avgör organisationens dataskyddsombud och jurister utifrån dataskyddsförordningen och dataskyddslagen (1050/2018). Vi genomför beslutet, men vi fattar det inte.

  • AI ställer egna krav på data

    Så hanterar vi det

    I användningsfall med AI mäter vi det som sökningen och modellerna behöver: hur heltäckande och aktuella uppgifterna är, hur många dubbletter som finns, hur väl texten har tolkats och om båda språkversionerna finns.

    Gränser och beroenden

    En del arkiv lönar det sig inte att rätta. Ett stickprov visar om så är fallet, och ibland är det bästa att lämna dem utanför.

05 Arbetssätt

Så arbetar vi

Plattformen byggs kring de första dataprodukter som verkligen behövs, och inte tvärtom.

  1. 01

    Börja med besluten

    Två eller tre beslut eller användningsfall för AI, de uppgifter de behöver och namnen på dem som äger dem.

    ResultatPrioriterad lista över dataprodukter med ägare

  2. 02

    Bygg den grund de behöver

    Plattform, inläsning, kvalitetskontroller och styrning i den omfattning som krävs för att produkterna ska fungera väl.

    ResultatDe första dataprodukterna i drift

  3. 03

    Lägg till en produkt i taget

    Nya produkter använder samma grund, och katalogen och ordlistan över nyckeltal byggs ut efter hand.

    ResultatProduktfärdplan och mått på användningen

06 Mänsklig kontroll

Där människor behåller kontrollen

Plattformen flyttar och kontrollerar uppgifterna automatiskt. Vad de betyder, vem som får använda dem och för vad bestämmer människor.

  • Definitionerna ägs av verksamheten

    Ett nyckeltal eller en dataprodukt får en ny betydelse först när ägaren i verksamheten har godkänt det, och varje ändring versioneras.

  • Ägarna beviljar åtkomst

    Dataägarna bestämmer vem som får använda vilka uppgifter och i vilket syfte. Plattformen verkställer besluten och loggar varje beviljad åtkomst.

  • Kvalitetsbrister stoppar publiceringen

    Misslyckas en kontroll mot avtalet får användarna besked, och ägaren avgör om uppgifterna publiceras, hålls inne eller rättas.

07 Teknik

Tekniker vi arbetar med

Plattformar
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Öppet lakehouse på Apache Iceberg eller Delta Lake
Dataflöden
  • dbt
  • Apache Spark
  • Kafka och Debezium
  • Molnleverantörernas egen orkestrering
Styrning
  • Unity Catalog och Purview
  • Kataloger med öppen källkod
  • Ramverk för datakvalitet
  • Regelbaserad åtkomstkontroll
Analys
  • Power BI
  • Semantiska skikt och måttskikt
  • Inbäddad analys
  • SAP-analys i befintliga miljöer

Teknikerna nämns för att visa vilken erfarenhet vi har. Det betyder inte att vi är partner till tillverkarna eller att de har gått i god för oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

Gemensamma nyckeltal för äldreomsorgen i ett välfärdsområde

01Utgångsläge
Välfärdsområdets enheter för boendeservice rapporterar beläggning och bemanning ur system som de har ärvt från tidigare organisationer, var och en med egna definitioner och med enhetsnamn på finska eller svenska. Ledningen jämför siffror som inte betyder samma sak.
02System
Harmoniserade dataprodukter per källsystem som matar ett gemensamt semantiskt skikt, med definitioner som välfärdsområdet har fastställt, enhetsnamn på båda språken och de lokala detaljerna bevarade.
03Mänsklig kontroll
Enheternas controller godkänner hur deras uppgifter mappas; ägaren av nyckeltalen på välfärdsområdesnivå godkänner definitionerna och alla ändringar. Uppgifter om enskilda klienter når aldrig rapporterna.
04Det här skulle vi mäta
Tiden det tar att ta fram månadsrapporten, antalet rättelser vid avstämningen och användningen av de certifierade rapportvyerna.

09 Branscher

I din bransch

  • Forsknings- och verksamhetsdata inom social- och hälsovården med strikt ändamålsbegränsning, pseudonymisering och loggning av varje åtkomst.

  • Grunddata om produkter och anläggningar, kvalitets- och produktionsdata sammankopplade för planering, spårbarhet och AI.

  • Uppgifter som hämtas ur den källa där de förs, öppna data som kan publiceras i Suomi.fi-avoindata och rapporter som beslutsfattare och revisorer kan spåra tillbaka till posten.

Finland

Data under finländska regler och på två språk

Dataskyddsförordningen ger den gemensamma ramen för personuppgifter, och i Finland kompletteras den av dataskyddslagen (1050/2018); dataombudsmannen övervakar efterlevnaden. Dataförordningen ger användarna rättigheter till data från uppkopplade produkter och tjänster. För dataprodukterna betyder det att avtalet ska ange var uppgifterna får behandlas, för vilka ändamål och hur länge.

Finländska organisationer har dessutom sina uppgifter på två språk: enhetsnamn, kodlistor, dokument och fritext på finska och svenska. Vi modellerar språkversionerna så att de hänger ihop och rapporterna ger samma siffror oavsett språk.

För offentliga aktörer finns de nationella tjänsterna. Myndigheten för digitalisering och befolkningsdata (MDB) upprätthåller Suomi.fi-avoindata, den nationella tjänsten för öppna data, och Suomi.fi-informationsleden är ett standardiserat sätt att överföra uppgifter mellan offentliga och privata organisationers system. Vi bygger dataprodukterna så att de kan anslutas till dem utan separata kopior av uppgifterna.

Frågor om data och analys

Behöver vi ett datanät, en så kallad data mesh?

Du behöver det som är användbart i tanken: dataprodukter med ägare och avtal. Fullständig decentralisering passar stora organisationer med erfarna domänteam. För många fungerar ett centralt plattformsteam bättre, med verksamheterna som ägare av sina dataprodukter.

Är våra data redo för AI?

En kort bedömning av stickprov ur de källor som användningsfallet behöver visar hur täckningen, kvaliteten, åtkomsträttigheterna och den rättsliga grunden ser ut. För det mesta blir svaret ”delvis”, med en tydlig lista över vad som behöver rättas först. Teamen inom AI-utveckling gör samma bedömning.

Vi har redan ett datalager. Ska vi börja om?

Sällan. Ett datalager som ger tillförlitliga rapporter är värt att behålla. Oftast kompletterar vi det med lakehouse-funktioner för ostrukturerade data och stora volymer, och vi flyttar bara när kostnaden eller begränsningarna kräver det.

Hur sköter ni delning av data med partner eller andra myndigheter?

Genom dataprodukter som exponeras via styrda API:er, med avtal, ändamålsbegränsning och loggning på plats. Mellan offentliga och privata organisationers system kan Suomi.fi-informationsleden användas, och dess användning är frivillig. Där dataförvaltningsakten eller dataförordningen gäller utformar vi de tekniska kontrollerna efter dem.

Vilket beslut kan du inte fatta med dagens data?

Vi spårar vad beslutet kräver ända till källorna och visar vad en första dataprodukt skulle innebära.