Naar de hoofdinhoud
FromNine
Menu

AI en data

Een data- en analyticsfundament waarop AI en beslissingen kunnen steunen

Wij bouwen dataplatformen waarin elke dataset een eigenaar, een contract en een bekende kwaliteit heeft, zodat analyse, bedrijfsvoering en AI allemaal uit dezelfde betrouwbare cijfers putten.

Voor Belgische organisaties die één betrouwbaar beeld willen van data die verspreid zit over afdelingen, vennootschappen en oudere systemen.

Data & analytics: de lagen van de dienstVier lagen, in de diepte gestapeld. Van boven naar beneden: analytics en AI die data gebruiken, dataproducten met eigenaars en contracten, de lakehouse-lagen die gegevens opschonen en harmoniseren, en governance over het geheel.01Gebruik in analytics en AI02Dataproducten en contracten03Lakehouse-lagen04Governance en herkomst
  1. 01Dataproducten met benoemde eigenaars, contracten en kwaliteitscontroles
  2. 02Governance die doelbinding en bewaartermijnen afdwingt, niet alleen een catalogus
  3. 03Eén set KPI-definities die zowel de business als IT onderschrijft

01 Knelpunten

Bekende dataproblemen

De meeste AI-projecten die tegenvallen, blijken vermomde dataprojecten te zijn.

  1. 01

    Drie rapporten, drie verschillende cijfers

    Financiën, de operationele teams en de directie berekenen omzet of dossiervolume elk op hun eigen manier. Vergaderingen beginnen met cijfers afstemmen in plaats van beslissen.

  2. 02

    Niemand is eigenaar van de data, dus niemand lost het op

    Fouten worden stroomafwaarts ontdekt, in een spreadsheet gecorrigeerd en komen de volgende maand terug.

  3. 03

    Het AI-team is vooral bezig met data zoeken

    Elke toepassing begint met weken aan toegangsaanvragen, extracties en opschoning, die het volgende team opnieuw doet.

  4. 04

    Archieven zijn onbruikbaar voor AI

    Gescande documenten met slechte tekstherkenning (OCR), duplicaten en geen metadata. Retrieval daarover levert ruis op.

02 Wat we leveren

Wat wij leveren

  1. 01 Datafundamenten voor AI en analytics

    Lakehouse-architecturen met gelaagde modellering, van ruw via geharmoniseerd naar klaar voor gebruik, en dataproducten die publiceren wat ze bevatten, hoe actueel ze zijn en wie ervoor verantwoordelijk is.

    Wat we doen

    • Platformarchitectuur en keuze van opslagformaten
    • Afspraken voor gelaagde modellering
    • Ontwerp van dataproducten met contracten
    • Inlezen in batches en via change data capture

    Wat u ontvangt

    • Lakehouse-platform vastgelegd in code
    • Eerste dataproducten in productie
    • Sjabloon voor datacontracten en een reviewproces
  2. 02 Kwaliteit, herkomst en stamgegevens

    Geautomatiseerde kwaliteitscontroles in elke laag, data lineage van bron tot rapport, en stam- en referentiegegevens voor de entiteiten die ertoe doen: burgers, klanten, producten en assets.

    Wat we doen

    • Kwaliteitsregels met drempels en alerts
    • Lineage tot op kolomniveau vastleggen
    • Matching van stamgegevens en regels voor het leidende record
    • Beheer van referentiegegevens

    Wat u ontvangt

    • Kwaliteitsdashboard per dataproduct
    • Lineage die u kunt bevragen
    • Golden records voor prioritaire entiteiten
  3. 03 Governance die wordt afgedwongen

    Een catalogus, classificatie en toegangsbeleid die het platform automatisch toepast. Doelbinding en bewaartermijnen uit de AVG (GDPR) zijn vastgelegd in regels, en het delen van gegevens volgt de Datagovernanceverordening (Data Governance Act) waar die van toepassing is.

    Wat we doen

    • Classificatieschema en tagging
    • Toegangsbeleid op basis van attributen
    • Automatisering van bewaren en verwijderen
    • Overeenkomsten en technische maatregelen voor het delen van gegevens

    Wat u ontvangt

    • Catalogus, gevuld vanuit het platform
    • Toegangsbeleid als code
    • Bewaarschema in werking
  4. 04 Ongestructureerde inhoud klaar voor AI

    Betere tekstherkenning, verrijking met metadata, ontdubbeling en het opschonen van archieven, zodat systemen voor intelligente documentverwerking en retrieval uitgaan van inhoud die het ophalen waard is.

    Wat we doen

    • Inventaris van inhoud en steekproeven op kwaliteit
    • Verbeteringen in OCR en lay-outextractie
    • Opsporen van bijna-duplicaten
    • Verrijking met metadata en classificatie

    Wat u ontvangt

    • Opgeschoonde, verrijkte inhoudsopslag
    • Rapport over de kwaliteit van de inhoud
    • Regels voor inhoud die vanaf nu wordt toegevoegd
  5. 05 Analytics en BI die mensen gebruiken

    Een semantische laag met KPI-definities waarover de business en IT het eens zijn, selfservice binnen duidelijke grenzen en ingebedde analytics in SaaS-producten en portalen.

    Wat we doen

    • Workshops om KPI’s te definiëren
    • Semantisch model en metriekenlaag
    • Vangrails voor selfservice en gecertificeerde datasets
    • Ingebedde analytics voor producten die klanten gebruiken

    Wat u ontvangt

    • KPI-woordenlijst met eigenaars
    • Gecertificeerd semantisch model
    • Dashboards die spreadsheets vervangen
  6. 06 Streaming voor operationeel gebruik

    Change data capture en eventstromen waar beslissingen niet kunnen wachten op de nachtelijke laadrun: voorraadniveaus, dossierstatus, signalen van fraude.

    Wat we doen

    • Eisen aan de vertraging per toepassing
    • CDC vanuit operationele databases
    • Streamverwerking en gematerialiseerde views
    • Ontwerp voor opnieuw afspelen en aanvullen

    Wat u ontvangt

    • Streamingpijplijnen in productie
    • Operationele views met doelen voor actualiteit
    • Procedure voor opnieuw afspelen

03 Architectuur

Een illustratieve referentiearchitectuur

Gegevens gaan van operationele systemen en documenten via het inlezen naar een lakehouse met lagen: ruw zoals ontvangen, dan geharmoniseerd en gecontroleerd op kwaliteit, dan dataproducten met een eigenaar en een contract. Afnemers lezen nooit ruwe data.

Vanuit de dataproducten voedt één route de semantische laag en BI; andere routes voeden AI-retrieval en features, en data-API’s voor andere systemen. Governance ligt onder het geheel en wordt door het platform toegepast, niet door een beleidsdocument.

Illustratief voorbeeld
  1. Bronnen en inlezen

    • Operationele systemen
    • Documenten na OCR en verrijking
    • Batch en change data capture
  2. Lakehouse

    • Ruwe laag
    • Geharmoniseerde laag
    • Kwaliteitscontroles en lineage
    • Stam- en referentiegegevens
    • Dataproducten met contracten
  3. Gebruik

    • Semantische laag en BI
    • AI-retrieval en features
    • Data-API’s en gegevensdeling
  4. Governance

    • Governance: catalogus, classificatie, toegangsbeleid, bewaartermijnen
Lakehouse-lagen naar dataproducten met een eigenaar

Illustratieve architectuur, geen systeem van een klant.

Lees het diagram als tekst

De hoofdroute loopt van operationele systemen via inlezen in batches en met change data capture, een ruwe laag, een geharmoniseerde laag en dataproducten, naar een semantische laag met BI onder governance.

Ongestructureerde documenten komen na OCR en verrijking ook binnen via het inlezen. Kwaliteitscontroles en lineage dekken de ruwe en de geharmoniseerde laag. Stam- en referentiegegevens voeden de dataproducten. Dataproducten bedienen ook AI-retrieval en features, en data-API’s om gegevens te delen.

Een governanceband met catalogus, classificatie, toegangsbeleid en bewaartermijnen omspant het platform.

04 Aandachtspunten en grenzen

Technische afwegingen en grenzen

  • Eigenaarschap vóór tooling

    Hoe we het aanpakken

    Elk dataproduct krijgt een business-eigenaar die bepaalt wat het betekent, en een technische eigenaar die het draaiende houdt. Wij helpen beide rollen te definiëren, net als het contract tussen leveranciers en afnemers van data.

    Grenzen en afhankelijkheden

    Een platform kan geen eigenaarschap creëren. Als de organisatie geen eigenaars aanwijst, komen de kwaliteitsproblemen terug, welke tooling u ook kiest.

  • Doelbinding in de praktijk

    Hoe we het aanpakken

    Persoonsgegevens krijgen een label met de doelen waarvoor ze gebruikt mogen worden, en toegangsbeleid en bewaartermijnen volgen die labels automatisch.

    Grenzen en afhankelijkheden

    Welke doelen rechtmatig zijn, beslissen uw functionaris voor gegevensbescherming en uw juristen. Wij voeren het uit; wij beslissen het niet.

  • Data voor AI heeft een eigen kwaliteitslat

    Hoe we het aanpakken

    Voor AI-toepassingen meten wij wat retrieval en modellen nodig hebben: dekking, actualiteit, duplicaten en de kwaliteit van de tekstextractie.

    Grenzen en afhankelijkheden

    Sommige archieven zijn het herstellen niet waard. Een beoordeling op basis van steekproeven maakt dat duidelijk, en soms is het juiste antwoord om ze buiten beschouwing te laten.

05 Hoe we werken

Zo werken wij

Wij bouwen het platform rond de eerste dataproducten die ertoe doen, niet omgekeerd.

  1. 01

    Kies beslissingen, geen datasets

    Begin bij twee of drie beslissingen of AI-toepassingen en de gegevens die ze nodig hebben, met benoemde eigenaars.

    ResultaatBacklog van dataproducten met eigenaars

  2. 02

    Bouw het fundament eromheen

    Platform, inlezen, kwaliteitscontroles en governance: precies genoeg om die producten goed te bedienen.

    ResultaatEerste dataproducten in productie

  3. 03

    Groei per product

    Elk nieuw product hergebruikt het fundament; de catalogus en de KPI-woordenlijst groeien mee.

    ResultaatProductroadmap en maatstaven voor gebruik

06 Menselijke controle

Waar mensen de controle houden

Dataplatformen automatiseren het verplaatsen en controleren van gegevens. Mensen beslissen over betekenis, toegang en doel.

  • Eigenaars keuren definities goed

    Een KPI of dataproduct krijgt alleen een andere betekenis als de business-eigenaar dat goedkeurt, en de wijziging krijgt een versie.

  • Toegang wordt verleend door beleidseigenaars

    Data-eigenaars bepalen wie welke gegevens voor welk doel mag gebruiken; het platform dwingt dat af en logt elke toekenning.

  • Een kwaliteitsbreuk legt de lijn stil

    Als een contractcontrole faalt, worden de afnemers op de hoogte gebracht en beslist de eigenaar of er wordt gepubliceerd, tegengehouden of gecorrigeerd.

07 Technologieën

Technologieën waarmee wij werken

Platformen
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Open lakehouse op Apache Iceberg of Delta Lake
Pijplijnen
  • dbt
  • Apache Spark
  • Kafka en Debezium
  • Cloud-native orkestratie
Governance
  • Unity Catalog en Purview
  • Opensourcecatalogi
  • Frameworks voor datakwaliteit
  • Toegangscontrole op basis van beleid
Analytics
  • Power BI
  • Semantische lagen en metriekenlagen
  • Ingebedde analytics
  • SAP-analytics (bestaande omgevingen)

Een technologie in deze lijst beschrijft onze engineeringervaring. Ze impliceert geen partnerschap met of aanbeveling door de leverancier.

08 Voorbeeld

Een illustratief voorbeeld

Illustratief voorbeeld

Eén set kerncijfers voor een intercommunale

01Situatie
Een intercommunale levert diensten aan tientallen gemeenten. Elke gemeente rapporteert over aanvragen en wachttijden uit haar eigen systeem, met eigen definities, en de raad van bestuur vergelijkt cijfers die niet hetzelfde betekenen.
02Wat we zouden bouwen
Dataproducten per bron die samenkomen in één semantische laag, met definities volgens OSLO waar die bestaan en het lokale detail bewaard.
03Waar mensen beslissen
Elke gemeente keurt de mapping van haar data goed; de eigenaar van de kerncijfers bij de intercommunale keurt definities en wijzigingen goed.
04Wat we zouden meten
Tijd om het maandrapport op te maken, aantal correcties bij de afstemming en gebruik van gecertificeerde dashboards.

09 Per sector

In uw sector

  • Onderzoeks- en operationele gegevens onder governance, met strikte doelbinding, pseudonimisering en logging van elke toegang.

  • Stamgegevens van producten en assets, kwaliteits- en productiedata samengebracht voor planning, traceerbaarheid en AI.

  • Authentieke bronnen, eenmalige gegevensopvraging en rapportage die beleidsmakers en auditors tot op het record kunnen herleiden.

België

Data volgens Belgische en Vlaamse standaarden

Wie in België data deelt met of tussen overheden, werkt met authentieke bronnen en vaste standaarden. In Vlaanderen beschrijven de OSLO-datastandaarden van Digitaal Vlaanderen hoe adressen, organisaties en dienstverlening gemodelleerd worden; federaal lopen sociale gegevens via de Kruispuntbank van de Sociale Zekerheid. De AVG (GDPR) en de Dataverordening bepalen wie welke gegevens mag gebruiken en voor welk doel.

Wij ontwerpen dataproducten waarvan het contract vastlegt waar data verwerkt mag worden, voor welk doel en hoe lang, en die waar mogelijk OSLO-begrippen hergebruiken in plaats van eigen definities.

Vragen over data en analytics

Hebben wij een data mesh nodig?

U hebt de nuttige onderdelen ervan nodig: dataproducten met eigenaars en contracten. Volledige decentralisatie loont in grote organisaties met volwassen domeinteams. Veel organisaties zijn beter af met een centraal platformteam en domeinen die eigenaar zijn van hun producten.

Zijn onze gegevens klaar voor AI?

Een korte beoordeling op basis van steekproeven van de bronnen die een toepassing nodig heeft, geeft u het antwoord: dekking, kwaliteit, toegangsrechten en rechtsgrond. Het antwoord is meestal ‘gedeeltelijk’, met een duidelijke lijst van wat eerst moet worden aangepakt. Onze teams voor AI-engineering gebruiken dezelfde beoordeling.

Wij hebben al een datawarehouse. Beginnen wij opnieuw?

Zelden. Een datawarehouse dat betrouwbare rapporten levert, is een troef. Meestal breiden wij het uit met lakehouse-mogelijkheden voor ongestructureerde en grote volumes data, en migreren we alleen waar kosten of beperkingen dat rechtvaardigen.

Hoe gaat u om met het delen van gegevens met partners of andere overheden?

Via dataproducten die worden ontsloten via API’s onder governance, met overeenkomsten, doelbinding en logging. Waar de Datagovernanceverordening of de Dataverordening van toepassing is, ontwerpen wij de technische maatregelen; de juridische beoordeling blijft bij uw juristen.

Noem de beslissing die u met de huidige data niet kunt nemen

Wij volgen wat ervoor nodig is terug tot in de bronnen en tonen wat een eerste dataproduct zou vragen, ook als die bronnen bij een andere overheid liggen.