Hoppa till huvudinnehållet
FromNine
Meny

AI och data

Data som AI och beslut kan lita på.

Vi bygger dataplattformar där varje datamängd har en ägare, ett kontrakt och en känd kvalitet, så att analys, drift och AI hämtar samma tillförlitliga siffror.

För koncerner, myndigheter och kommunala bolag som behöver en tillförlitlig bild av data som är spridd över bolag, förvaltningar och äldre system.

Data och analys: förmågor i lagerFyra lager staplade på djupet. Uppifrån och ned: analys och AI som använder data, dataprodukter med ägare och kontrakt, lakehouse-lagren som tvättar och harmoniserar och datastyrning som omfattar allt.01Analys och AI02Dataprodukter och kontrakt03Lakehouse-lager04Datastyrning och härkomst
  1. 01Dataprodukter med namngivna ägare, kontrakt och kvalitetskontroller
  2. 02Datastyrning som omsätter ändamålsbegränsning och lagringstider i praktiken, inte bara en katalog
  3. 03En uppsättning nyckeltals­definitioner som både verksamheten och it skriver under på

01 Problem

Välbekanta problem med data

De flesta AI-projekt som inte motsvarar förväntningarna visar sig vara dataprojekt i förklädnad.

  1. 01

    Tre rapporter, tre olika siffror

    Ekonomi, verksamhet och ledning räknar omsättning eller ärendevolym på var sitt sätt. Mötena börjar med avstämning i stället för beslut.

  2. 02

    Ingen äger datan, så ingen rättar den

    Felen upptäcks längre ned i kedjan, rättas i ett kalkylark och kommer tillbaka nästa månad.

  3. 03

    AI-teamet ägnar mest tid åt att leta data

    Varje användningsfall börjar med veckor av behörighetsansökningar, uttag och tvätt som nästa team kommer att göra om.

  4. 04

    Arkiven går inte att använda för AI

    Skannade dokument med dålig textigenkänning, dubbletter och ingen metadata. Sökningar i dem ger mest brus.

02 Leveranser

Det här levererar vi

  1. 01 Datagrund för AI och analys

    Lakehouse-arkitekturer med modellering i lager, från rådata via harmoniserade data till data som är redo att användas, och dataprodukter som redovisar vad de innehåller, hur färska de är och vem som ansvarar för dem.

    Det här gör vi

    • Plattformsarkitektur och val av lagringsformat
    • Konventioner för modellering i lager
    • Utformning av dataprodukter med kontrakt
    • Inläsning i batch och med ändringsdatafångst (CDC)

    Det här får du

    • Lakehouse-plattform definierad som kod
    • De första dataprodukterna i drift
    • Mall för datakontrakt och granskningsrutin
  2. 02 Kvalitet, härkomst och grunddata

    Automatiska kvalitetskontroller i varje lager, härkomst från källa till rapport och grunddata och referensdata för de enheter som spelar roll: invånare, kunder, produkter och anläggningar.

    Det här gör vi

    • Kvalitetsregler med tröskelvärden och larm
    • Härkomst på kolumnnivå
    • Regler för matchning och sammanslagning av grunddata
    • Förvaltning av referensdata

    Det här får du

    • Kvalitetsöversikt per dataprodukt
    • Härkomst som går att söka i
    • Gemensamma grundposter för prioriterade enheter
  3. 03 Datastyrning som upprätthålls

    En katalog, klassning och åtkomstregler som plattformen tillämpar automatiskt. Ändamålsbegränsning och lagringstider enligt GDPR är inbyggda, och datadelning följer dataförvaltningsakten där den gäller.

    Det här gör vi

    • Klassningsschema och märkning
    • Attributbaserade åtkomstregler
    • Automatiserad gallring och radering
    • Avtal och tekniska kontroller för datadelning

    Det här får du

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

    Bättre textigenkänning, berikad metadata, borttagna dubbletter och städade arkiv, så att system för dokumenttolkning och sökning utgår från innehåll som är värt att hitta.

    Det här gör vi

    • Inventering av innehåll och stickprov på kvalitet
    • Förbättrad textigenkänning och layouttolkning
    • Upptäckt av nästan identiska dokument
    • Berikning av metadata och klassning

    Det här får du

    • Städat 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 lager med nyckeltalsdefinitioner som verksamheten och it är överens om, styrd självservice och inbäddad analys i SaaS-produkter och portaler.

    Det här gör vi

    • Workshoppar om nyckeltalsdefinitioner
    • Semantisk modell och lager för mått
    • Ramar för självservice 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
    • Översikter som ersätter kalkylark
  6. 06 Strömmande data för driften

    Ändringsdatafångst och händelseströmmar där beslut inte kan vänta på nattens körning: lagersaldon, ärendestatus, signaler om bedrägeri.

    Det här gör vi

    • Krav på fördröjning per användningsfall
    • CDC från driftdatabaser
    • Strömbearbetning och materialiserade vyer
    • Utformning av omkörning och efterladdning

    Det här får du

    • Strömmande flöden i drift
    • Driftvyer med mål för aktualitet
    • Rutin för omkörning

03 Arkitektur

En illustrativ referens­arkitektur

Data går från verksamhetssystem och dokument via inläsning till ett lakehouse i lager: rådata som den kom in, sedan harmoniserad och kvalitetskontrollerad data och till sist dataprodukter med en ägare och ett kontrakt. Ingen konsument läser rådata.

Från dataprodukterna går ett flöde till det semantiska lagret och BI, andra till sökning och särdrag för AI och till data-API:er för andra system. Datastyrningen ligger under allt och tillämpas 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ålager
    • Harmoniserat lager
    • Kvalitets­kontroller och härkomst
    • Grunddata och referensdata
    • Dataprodukter med kontrakt
  3. Användning

    • Semantiskt lager och BI
    • Sökning och särdrag för AI
    • Data-API:er och delning
  4. Datastyrning

    • Datastyrning: katalog, klassning, åtkomstregler, gallring
Lakehouse-lager som blir ägda dataprodukter

Illustrativ arkitektur, inte en kunds system.

Läs diagrammet som text

Huvudflödet går från verksamhetssystem via inläsning i batch och med ändringsdatafångst, ett rålager, ett harmoniserat lager och dataprodukter till ett semantiskt lager med styrd BI.

Ostrukturerade dokument kommer också in via inläsningen efter textigenkänning och berikning. Kvalitetskontroller och härkomst omfattar rålagret och det harmoniserade lagret. Grunddata och referensdata matar dataprodukterna. Dataprodukterna försörjer även sökning och särdrag för AI samt data-API:er för delning.

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

04 Överväganden och begränsningar

Tekniska överväganden och begränsningar

  • Ägarskap före verktyg

    Så hanterar vi det

    Varje dataprodukt får en verksamhetsägare som bestämmer vad den betyder och en teknisk ägare som håller den i drift. Vi hjälper till att definiera båda rollerna och kontraktet mellan producenter och konsumenter.

    Begränsningar och beroenden

    En plattform kan inte skapa ägarskap. Om organisationen inte utser ägare kommer kvalitetsproblemen tillbaka, oavsett verktyg.

  • Ändamåls­begränsning i praktiken

    Så hanterar vi det

    Personuppgifter märks med de ändamål de får användas för, och åtkomstregler och gallring följer märkningen automatiskt.

    Begränsningar och beroenden

    Vilka ändamål som är lagliga avgör ditt dataskyddsombud och dina jurister. Vi genomför beslutet; vi fattar det inte.

  • Data för AI har en egen kvalitetsnivå

    Så hanterar vi det

    För användningsfall med AI mäter vi det som sökning och modeller behöver: täckning, aktualitet, dubbletter och kvaliteten på textutvinningen.

    Begränsningar och beroenden

    Vissa arkiv är inte värda att laga. En bedömning baserad på stickprov visar det, och ibland är rätt svar att lämna dem utanför.

05 Så arbetar vi

Så arbetar vi

Vi bygger plattformen kring de första dataprodukterna som spelar roll, inte tvärtom.

  1. 01

    Välj beslut, inte datamängder

    Börja med två eller tre beslut eller användningsfall för AI och de data de behöver, med namngivna ägare.

    ResultatLista över dataprodukter med ägare

  2. 02

    Bygg grunden runt dem

    Plattform, inläsning, kvalitetskontroller och datastyrning, precis så mycket som behövs för att leverera produkterna ordentligt.

    ResultatDe första dataprodukterna i drift

  3. 03

    Väx produkt för produkt

    Varje ny produkt återanvänder grunden; katalogen och ordlistan över nyckeltal växer med den.

    ResultatFärdplan för produkter och mått på användning

06 Mänsklig kontroll

Där människor behåller kontrollen

Dataplattformar automatiserar förflyttningar och kontroller. Människor bestämmer betydelse, åtkomst och ändamål.

  • Ägarna godkänner definitionerna

    Ett nyckeltal eller en dataprodukt byter betydelse bara när verksamhetsägaren godkänner det, och ändringen versionshanteras.

  • Åtkomst beviljas av dem som äger reglerna

    Dataägarna bestämmer vem som får använda vilka data och för vilket ändamål; plattformen upprätthåller det och loggar varje beviljande.

  • Kvalitetsbrister stoppar flödet

    När en kontraktskontroll fallerar får konsumenterna besked och ägaren beslutar om data ska publiceras, hållas inne eller rättas.

07 Tekniker

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
  • Molnbaserad orkestrering
Datastyrning
  • Unity Catalog och Purview
  • Kataloger med öppen källkod
  • Ramverk för datakvalitet
  • Policybaserad åtkomstkontroll
Analys
  • Power BI
  • Semantiska lager och mått
  • Inbäddad analys
  • SAP-analys (befintliga miljöer)

Att vi listar en teknik beskriver vår tekniska erfarenhet. Det innebär inte ett partnerskap med leverantören eller att leverantören står bakom oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

Gemensamma nyckeltal för en familjeägd industrikoncern

01Utgångsläge
En familjeägd industrikoncern med huvudkontor i Sverige och dotterbolag i fyra länder rapporterar orderingång, leveransprecision och lager ur varje bolags eget affärssystem, med egna definitioner. Koncernledningen jämför siffror som inte betyder samma sak.
02Det här skulle vi bygga
Harmoniserade dataprodukter per bolag som matar ett gemensamt semantiskt lager med nyckeltal som definieras på koncernnivå, medan de lokala detaljerna bevaras.
03Här beslutar människor
Controllern i varje bolag godkänner hur bolagets data mappas; ägaren av koncernens nyckeltal godkänner definitioner och ändringar.
04Det här skulle vi mäta
Tid för att ta fram månadsrapporten, antal rättelser vid avstämning och användning av certifierade översikter.

09 Branscher

I din bransch

  • Forsknings- och verksamhetsdata hos regioner och life science-företag, med strikt ändamålsbegränsning, pseudonymisering och loggning av åtkomst.

  • Grunddata för produkter och anläggningar samt kvalitets- och produktionsdata som kopplas ihop för planering, spårbarhet och AI.

  • Grunddata från ansvariga källor, uppgifter som återanvänds i stället för att begäras in igen och rapportering som beslutsfattare och revisorer kan spåra tillbaka till posten.

Sverige

Dataskydd och gemensamma grunddata

Dataskyddsförordningen (GDPR) gäller i hela EU och kompletteras i Sverige av dataskyddslagen (2018:218), med Integritetsskyddsmyndigheten (IMY) som tillsynsmyndighet. Dataförordningen ger användare rättigheter till data från uppkopplade produkter och tjänster. För koncerner med bolag i flera länder skiljer sig de nationella reglerna om lagringstider och ändamål fortfarande åt.

Offentliga aktörer bygger dessutom på gemensamma grunddata inom Ena, Sveriges digitala infrastruktur, som samordnas av Digg och från den 1 januari 2027 av Digitaliseringsmyndigheten. Vi utformar dataprodukter vars kontrakt anger var data får behandlas, för vilka ändamål och hur länge, så att plattformen kan tillämpa rätt regel per land och verksamhet utan separata kopior av datan.

Frågor om data och analys

Behöver vi ett datanät (data mesh)?

Du behöver de användbara delarna av det: dataprodukter med ägare och kontrakt. Full decentralisering lönar sig i stora organisationer med mogna verksamhetsteam. Många organisationer klarar sig bättre med ett centralt plattformsteam och verksamheter som äger sina dataprodukter.

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

En kort bedömning baserad på stickprov av de källor som ett användningsfall behöver ger svaret: täckning, kvalitet, behörigheter och rättslig grund. Svaret blir oftast ”delvis”, med en tydlig lista över vad som ska åtgärdas först. Teamen inom AI-utveckling och generativ AI använder samma bedömning.

Vi har redan ett datalager. Måste vi börja om?

Sällan. Ett datalager som levererar rapporter som verksamheten litar på är en tillgång. Oftast bygger vi ut det med lakehouse-förmågor för ostrukturerad data och stora volymer och migrerar bara där kostnad eller begränsningar motiverar det.

Hur hanterar ni datadelning med partner eller andra myndigheter?

Genom dataprodukter som exponeras via styrda API:er, med avtal, ändamålsbegränsning och loggning på plats. Där dataförvaltningsakten eller dataförordningen gäller utformar vi de tekniska kontrollerna därefter.

Berätta vilket beslut du inte kan fatta med dagens data

Vi följer vad beslutet behöver tillbaka till källorna och visar vad en första dataprodukt skulle kräva.