BIO 12.02 ISO A.12.4.1

Performance Tracking Voor AI- En Dataworkloads In De Nederlandse Overheid

📅 2025-11-26
•
⏱️ 25 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Performance tracking vormt de ruggengraat van betrouwbare digitale dienstverlening: zonder structurele bewaking van prestaties is het onmogelijk om te garanderen dat AI- en cloudtoepassingen van de overheid snel, stabiel en voorspelbaar blijven functioneren voor burgers en ambtenaren.

Aanbeveling
IMPLEMENT
Risico zonder
High
Risk Score
8/10
Implementatie
140u (tech: 80u)
Van toepassing op:
✓ Azure
✓ M365
✓ AI Services
✓ Hybride omgevingen

Nederlandse overheidsorganisaties digitaliseren in hoog tempo en leunen daarbij steeds zwaarder op cloudgebaseerde applicaties, data-platformen en AI-diensten. Burgers verwachten 24/7 toegankelijke en vlot reagerende dienstverlening; vertragingen, storingen of onvoorspelbaar gedrag worden direct ervaren als kwaliteitsverlies en kunnen leiden tot gemiste termijnen, foutieve besluiten of verlies van vertrouwen. Tegelijkertijd leggen kaders als de BIO, NIS2 en de EU AI Act expliciete nadruk op continuïteit, monitoring en aantoonbare beheersing van risico’s. Zonder goed ingericht performance tracking ontbreekt inzicht in bottlenecks, verslechterende responstijden of sluipende capaciteitsproblemen, waardoor incidenten pas zichtbaar worden wanneer maatschappelijke impact al optreedt. Bovendien is prestatie-informatie essentieel voor onderbouwde beslissingen over schaalbaarheid, architectuurkeuzes en kostenoptimalisatie.

PowerShell Modules Vereist
Primary API: Azure Monitor, Application Insights, Log Analytics
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Monitor, Az.OperationalInsights

Implementatie

Dit artikel beschrijft hoe u performance tracking voor AI- en data-intensieve workloads structureel inricht binnen de Nederlandse overheid. We gaan in op het definiëren van heldere service level indicators (SLI’s) en service level objectives (SLO’s), het ontwerp van een meetstrategie met Azure Monitor, Application Insights en Log Analytics, en de inrichting van dashboards en alerts die aansluiten op de behoeften van zowel technische teams als bestuurders. Vervolgens laten we zien hoe performancegegevens kunnen worden gekoppeld aan risicobeheersing, capaciteitsplanning en compliance-eisen uit de BIO, NIS2 en EU AI Act. Tot slot geven we praktische richtlijnen voor operationele processen, zoals runbooks, periodieke reviews en samenwerking tussen beheer, security, data science en proceseigenaren.

Van ‘snel genoeg’ naar meetbare prestaties: kernbegrippen in performance tracking

Effectief performance tracking begint met een gedeeld begrippenkader. In veel organisaties wordt nog gesproken over ‘snel genoeg’ of ‘het voelt traag’, zonder dat duidelijk is welke objectieve maatstaven daarbij horen. Voor AI- en data-intensieve systemen in de publieke sector is dat onvoldoende. Hier gaat het om ketens waarin burgers via portalen gegevens aanleveren, ambtenaren besluiten voorbereiden in applicaties, en achterliggende AI- of analysetoepassingen in milliseconden tot minuten complexe berekeningen uitvoeren. In dat landschap zijn klassieke ICT-termen als responstijd, doorvoer en beschikbaarheid nog steeds relevant, maar worden ze aangevuld met AI-specifieke aspecten, zoals verwerkingstijd per modelaanroep, wachtrijen voor batch-scoringsjobs, tijd tot actualisatie van dashboards en de verhouding tussen computegebruik en gerealiseerde doorlooptijd. Door deze begrippen expliciet te definiëren, ontstaat een gemeenschappelijke taal waarmee techniek, beleid en bestuur over prestaties kunnen spreken.

Een tweede belangrijk kernbegrip is het onderscheid tussen service level indicators (SLI’s) en service level objectives (SLO’s). SLI’s zijn de concrete, meetbare grootheden, zoals de gemiddelde responstijd van een API, het 95e percentiel van de verwerkingstijd van een AI-model, het percentage geslaagde verzoeken of het aantal foutmeldingen per uur. SLO’s zijn de afgesproken streefwaarden voor die indicatoren, bijvoorbeeld: ‘95 procent van de aanvragen voor risicobeoordeling wordt binnen twee seconden beantwoord’ of ‘data in rapportages is maximaal één uur oud’. Voor Nederlandse overheidsorganisaties is het essentieel dat SLO’s worden afgeleid vanuit dienstverlening en wettelijke termijnen: hoe lang mag een burger moeten wachten op een bevestiging, binnen welke tijd moet een toezichthouder nieuwe signalen kunnen zien, en welke marges zijn acceptabel voordat de kwaliteit van besluitvorming of dienstverlening onder druk komt te staan? Door deze SLO’s expliciet vast te leggen, ontstaat een direct verband tussen technische prestaties en publieke waarden zoals betrouwbaarheid, voorspelbaarheid en gelijke behandeling.

Daarnaast speelt de context van AI een specifieke rol. Een AI-model kan inhoudelijk uitstekende prestaties leveren qua nauwkeurigheid en eerlijkheid, maar alsnog ongeschikt zijn voor operationele inzet omdat de responstijd te hoog is of de benodigde rekenkracht disproportioneel is. Zeker bij real-time scenario’s – zoals fraudedetectie bij transacties, risicobeoordeling in identiteitscontroles of automatische classificatie van binnenkomende meldingen – is een consistente, lage latency van cruciaal belang. Performance tracking helpt om deze balans inzichtelijk te maken: welke modellen of configuraties leveren binnen de gekozen infrastructuur een acceptabele combinatie van nauwkeurigheid, robuustheid en responstijd? In de praktijk leidt dit vaak tot architectuurkeuzes, zoals het scheiden van real-time en batch-scoringspaden, het gebruik van dedicated compute-resources voor kritieke modellen of het inzetten van caching-mechanismen voor veelvoorkomende vragen.

Tot slot is het belangrijk om performance niet uitsluitend als technische optimalisatie te zien, maar als integraal onderdeel van risicobeheersing en compliance. NIS2 en de BIO vragen expliciet om aantoonbare beheersing van beschikbaarheid en continuïteit van essentiële diensten. Langdurige vertragingen of periodieke uitval van AI-ondersteunde processen kunnen in dat licht worden gezien als incidenten die moeten worden voorkomen, gedetecteerd en gerapporteerd. De EU AI Act introduceert bovendien het concept van ‘operationele robuustheid en nauwkeurigheid’ voor high-risk AI-systemen: prestaties mogen niet onvoorspelbaar verslechteren onder normale gebruiksomstandigheden. Door performance tracking direct te koppelen aan deze eisen – bijvoorbeeld door in dashboards expliciet aan te geven hoe vaak SLO’s niet worden gehaald en welke maatregelen zijn genomen – wordt performance een stuurinstrument in plaats van een ad-hoc optimalisatie achteraf.

Technische implementatie met Azure Monitor, Application Insights en Log Analytics

In Microsoft-omgevingen vormt een combinatie van Azure Monitor, Application Insights en Log Analytics de basis voor een volwassen performance tracking-architectuur. De kern is dat elke relevante component – API’s, webportalen, back-endprocessen, data-pijplijnen en AI-modellen – systematisch telemetrie aanlevert. Voor web- en API-laag betekent dit het inschakelen van Application Insights met server- en client-side tracking, zodat zowel serverresponstijden als beleving aan de voorkant zichtbaar worden. Voor data- en AI-workloads worden pipeline-runs, modelaanroepen en batch-jobs verrijkt met metadata over start- en eindtijd, gebruikte resources, datasetgrootte en eventuele foutcodes. Deze gegevens worden centraal opgeslagen in één of meerdere Log Analytics workspaces, met een logisch scheidingsmodel dat aansluit op security- en privacy-eisen: bijvoorbeeld aparte workspaces per domein of gevoeligheid, met zorgvuldig ingestelde toegangsrechten.

Het ontwerp van de telemetriestructuur vraagt om bewuste keuzes. Voor performance tracking zijn vaak slechts enkele kernmetingen nodig, terwijl overmatige logging kosten en complexiteit kan vergroten. Een pragmische aanpak is om per keten ‘kritieke paden’ te definiëren: de stappen die de grootste impact hebben op de beleving van burgers of de efficiëntie van medewerkers. Voor deze paden worden minimaal de volgende gegevens vastgelegd: een correlatie-id die alle stappen in de keten verbindt, timestamps voor elke stap, responstijd per component, statuscodes en – waar mogelijk – context over de functionele handeling (bijvoorbeeld type aanvraag of betrokken proces). In AI-scenario’s kan hieraan worden toegevoegd: modelnaam en -versie, type scenario (real-time of batch), omvang van de input en indicaties voor wachtrijvorming. Door deze velden gestandaardiseerd te loggen, wordt het mogelijk om met Kusto Query Language (KQL) end-to-end doorlooptijden per keten te analyseren en bottlenecks snel te identificeren.

Bovenop de ruwe telemetrie worden in Log Analytics herbruikbare KQL-query’s gedefinieerd die de eerder geformuleerde SLI’s berekenen. Denk aan query’s die het 50e, 95e en 99e percentiel van responstijden per API en per tijdvenster tonen, het percentage geslaagde aanroepen inzichtelijk maken of wachttijden in message queues aggregeren. Voor AI-modellen kunnen query’s de gemiddelde en maximale verwerkingstijd per modelversie tonen en het aantal time-outs of resourcefouten rapporteren. Deze query’s worden vervolgens gevoed in Azure Monitor workbooks of dashboards in bijvoorbeeld Power BI of Microsoft Fabric, waarbij per doelgroep een passende weergave wordt gekozen: operationele teams willen vaak detailniveau en drill-down mogelijkheden, terwijl bestuurders vooral trends, incidenthistorie en SLO-conformiteit willen zien. Door dashboards te koppelen aan bestaande overlegstructuren – zoals stuurgroepen of change boards – wordt performance informatie structureel meegenomen in besluitvorming over architectuur, opschaling en prioritering van verbeteringen.

Alerting vormt de brug tussen monitoring en actie. In Azure Monitor kunnen voor elke SLI drempelwaarden worden ingesteld die bij overschrijding een waarschuwing genereren. Voor AI- en data-intensieve workloads is het verstandig om met meerdere niveaus te werken: ‘early warning’-alerts bij lichte afwijkingen, die vooral bedoeld zijn om trends tijdig te signaleren, en ‘kritieke’ alerts bij ernstige of langdurige overschrijdingen van SLO’s. Alerts worden idealiter geïntegreerd in bestaande processen en tooling, zoals ITSM-systemen, Microsoft Teams-kanalen voor beheer- en devops-teams of Microsoft Sentinel voor correlatie met beveiligingsincidenten. Belangrijk is dat alerts voldoende context bevatten om gericht te kunnen handelen: welke keten is geraakt, welke modelversie is betrokken, welke burgers of processen kunnen impact ervaren en welke eerstelijns-stappen adviseert het runbook? Door deze context in de alertdefinitie op te nemen, worden onnodige escalaties en zoekwerk beperkt en kunnen teams gericht reageren.

Operationele bewaking, capaciteitsplanning en continuïteitsbeheer

Gebruik PowerShell-script performance-tracking.ps1 (functie Invoke-PerformanceSummary) – Voert een lokale voorbeeldanalyse uit op performance-metingen en toont hoe SLI’s en SLO’s op basis van loggegevens beoordeeld kunnen worden voor AI- en dataworkloads..

Wanneer de technische basis voor performance tracking staat, verschuift de aandacht naar de dagelijkse operatie. Voor Nederlandse overheidsorganisaties betekent dit dat performancegegevens niet alleen beschikbaar moeten zijn, maar ook actief worden gebruikt in de aansturing van beheer, ontwikkelteams en leveranciers. Een goed ingericht operationsproces start met duidelijke rol- en taakverdeling: wie bewaakt de dashboards, wie beoordeelt alerts, wie voert eerste analyse uit, en wie neemt besluiten over tijdelijke mitigerende maatregelen of structurele verbeteringen? In veel organisaties ligt de eerste verantwoordelijkheid bij een centraal operations- of monitoringteam, terwijl gespecialiseerde devops- of datateams worden ingeschakeld voor diepere analyses. Proceseigenaren en businessrepresentanten moeten periodiek betrokken worden om te beoordelen of de gemeten prestaties nog aansluiten bij de verwachtingen in het werkveld. Zo wordt voorkomen dat technische optimalisaties worden doorgevoerd die weinig toegevoegde waarde hebben voor burgers of medewerkers, terwijl echt pijnlijke knelpunten onder de radar blijven.

Capaciteitsplanning is een direct vervolg op structureel performance inzicht. Door historische gebruikspatronen, seizoensinvloeden en projecties van nieuwe functionaliteit te combineren, kunnen organisaties anticiperen op piekbelastingen. Denk aan belastingcampagnes, verkiezingsperiodes, subsidieregelingen met korte aanvraagtermijnen of grote migraties naar nieuwe digitale kanalen. Door in dashboards expliciet te laten zien hoe resources als CPU, geheugen, I/O en netwerkbandbreedte correleren met responstijden en foutpercentages, kunnen architecten onderbouwde keuzes maken over opschaling, caching, herverdeling van workloads of zelfs verplaatsing van onderdelen naar andere regio’s of diensten. In een publieke context speelt daarnaast kostenbewustzijn een rol: performanceproblemen kunnen soms worden opgelost door ‘gewoon’ meer capaciteit in te zetten, maar dat is niet altijd efficiënt of verantwoord. Door performance tracking te koppelen aan kosteninformatie uit Azure Cost Management of FinOps-processen, ontstaat een integraal beeld waarin prestaties, kosten en risico’s in samenhang worden afgewogen.

Continuïteitsbeheer sluit aan op verplichtingen uit de BIO en NIS2 rond beschikbaarheid van essentiële diensten. Performance tracking levert de gegevens om te bepalen welke scenario’s de grootste dreiging vormen: langzame uitval door oplopende wachtrijen, plotseling verlies van capaciteit door storingen, of ketenproblemen waarbij externe leveranciers vertraging veroorzaken. Deze inzichten moeten worden vertaald in concrete runbooks waarin stap voor stap staat beschreven hoe teams reageren bij verschillende soorten performance-incidenten. Bijvoorbeeld: bij oplopende responstijden voor een AI-risicoclassificatiemodel kan worden besloten om tijdelijk een eenvoudiger, conservatiever model in te zetten, bepaalde functionaliteit uit te schakelen voor niet-kritieke gebruikers, of aanvragen in batch te verwerken buiten piekuren. Door deze scenario’s vooraf te oefenen in test- of oefenomgevingen, inclusief betrokkenheid van communicatie, juristen en proceseigenaren, wordt de organisatie beter voorbereid op echte incidenten en worden ad-hoc beslissingen met onbedoelde neveneffecten voorkomen.

Tot slot is rapportage richting bestuur en toezichthouders een essentieel onderdeel van operationele performance governance. Periodieke managementrapportages moeten op een begrijpelijke manier laten zien hoe vaak SLO’s zijn gehaald, waar structurele knelpunten zich voordoen, welke verbetermaatregelen zijn genomen en welke risico’s nog openstaan. Voor high-risk AI-systemen onder de EU AI Act kan performance-informatie worden opgenomen in bredere AI-rapportages, waarin naast nauwkeurigheid, fairness en uitlegbaarheid ook operationele robuustheid wordt behandeld. Door deze rapportages te koppelen aan besluiten in portefeuillevergaderingen, investeringscommissies of architectuurboards, wordt performance een volwaardige factor in strategische keuzes. Dit draagt er uiteindelijk aan bij dat digitale diensten van de overheid niet alleen veilig en rechtmatig zijn, maar ook betrouwbaar en voorspelbaar in het dagelijks gebruik door burgers en professionals.

Governance, compliance en audit rond performance tracking

Performance tracking raakt meerdere governance- en compliancekaders tegelijk. De BIO stelt eisen aan logging, monitoring, capaciteitsbeheer en continuïteitsplanning, terwijl NIS2 nadruk legt op het voorkomen en beperken van verstoringen in essentiële diensten. De EU AI Act introduceert daarbovenop eisen voor operationele robuustheid en monitoring van high-risk AI-systemen. Voor Nederlandse overheidsorganisaties is het daarom belangrijk om performance tracking niet als losstaand technisch project te benaderen, maar te verankeren in het bredere stelsel van beleid, risicomanagement en audit. Dat begint met formeel beleid waarin staat vastgelegd welke typen systemen aan performance tracking onderworpen zijn, welke SLI’s en SLO’s minimaal worden gehanteerd, hoe vaak prestaties worden geëvalueerd en welke escalatiepaden gelden bij structurele overschrijdingen. Dit beleid moet worden afgestemd tussen CIO, CISO, chief data/AI officers en de proceseigenaren van kritieke dienstverlening, zodat technologische keuzes in lijn zijn met bestuurlijke prioriteiten en wettelijke verplichtingen.

Voor auditors en toezichthouders is vooral de aantoonbaarheid van belang: kunnen organisaties laten zien dat performance tracking niet alleen op papier bestaat, maar daadwerkelijk wordt uitgevoerd en gebruikt in de dagelijkse sturing? Dit betekent dat dashboards, alertconfiguraties en runbooks moeten worden ondersteund door historische gegevens: welke alerts zijn in de afgelopen periode afgegaan, welke analyses zijn uitgevoerd, welke maatregelen zijn genomen en hoe snel zijn problemen opgelost? Door performance-incidenten vast te leggen in een centraal incident- en probleemregistratiesysteem, inclusief oorzaak-gevolg-analyses en verbeteracties, ontstaat een waardevolle bron voor audits en managementreviews. Bovendien maakt dit het mogelijk om trends te herkennen, zoals steeds terugkerende bottlenecks of structurele capaciteitsproblemen in bepaalde ketens. Deze inzichten kunnen vervolgens worden vertaald naar structurele verbeterprogramma’s, bijvoorbeeld herontwerp van architectuur, versimpeling van processen of investeringen in robuustere infrastructuur.

Transparantie richting burgers en ketenpartners vormt het sluitstuk van governance rond performance. Hoewel gedetailleerde technische informatie doorgaans intern blijft, kan het nuttig zijn om op hoofdlijnen te communiceren welke serviceniveaus de organisatie nastreeft en hoe wordt gehandeld bij verstoringen. Dit kan bijvoorbeeld via publieksvriendelijke servicepagina’s, jaarverslagen of specifieke toelichtingen in algoritmeregisters. In die communicatie kan worden uitgelegd dat AI- en datasystemen continu worden bewaakt op prestaties, dat er duidelijke procedures zijn voor het omgaan met vertragingen of storingen en dat lessen uit incidenten worden gebruikt om dienstverlening te verbeteren. Door performance tracking zo te positioneren als onderdeel van verantwoord en transparant digitaal overheidshandelen, wordt het niet alleen een intern stuurinstrument maar ook een bouwsteen voor maatschappelijk vertrouwen in de digitale overheid.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS Performance tracking voorbeeldscript voor AI-systemen. .DESCRIPTION Ondersteunt Nederlandse overheidsorganisaties bij het lokaal testen en demonstreren van performance tracking-concepten voor AI-diensten. Het script werkt uitsluitend met lokale voorbeeldbestanden, zodat het veilig is voor debugging en trainingen zonder verbinding te maken met productieomgevingen. .NOTES Filename: performance-tracking.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-11-26 Last Modified: 2025-11-26 Version: 1.0 Related JSON: content/ai/operations/performance-tracking.json .EXAMPLE .\performance-tracking.ps1 -Summary Voert een eenvoudige analyse uit op lokale performance-samenvattingen. .EXAMPLE .\performance-tracking.ps1 -Baseline -WhatIf Toont welke voorbeeldbestanden zouden worden aangemaakt voor lokale experimenten. #> #Requires -Version 5.1 [CmdletBinding()] param( [Parameter()] [switch]$WhatIf, [Parameter()] [switch]$Summary, [Parameter()] [switch]$Baseline ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' function Get-RepositoryRoot { <# .SYNOPSIS Bepaalt de rootmap van de repository op basis van de locatie van dit script. #> [CmdletBinding()] param() $root = Resolve-Path (Join-Path $PSScriptRoot "..\..\..") -ErrorAction SilentlyContinue if (-not $root) { throw "Kon de repository-root niet bepalen op basis van PSScriptRoot: $PSScriptRoot" } return $root.Path } function Get-PerformanceTrackingPaths { <# .SYNOPSIS Geeft standaardpaden terug voor performance tracking-voorbeelddata. .OUTPUTS PSCustomObject met padinformatie. #> [CmdletBinding()] param() $repoRoot = Get-RepositoryRoot $root = Join-Path $repoRoot "monitoring\ai-models\performance-tracking" $summaryPath = Join-Path $root "summaries" [PSCustomObject]@{ RepositoryRoot = $repoRoot Root = $root SummaryPath = $summaryPath } } function New-PerformanceSampleData { <# .SYNOPSIS Maakt voorbeeld-bestanden aan voor performance-samenvattingen. .DESCRIPTION Deze functie is bedoeld voor lokale debugging en workshops. In een productieomgeving worden deze statistieken doorgaans automatisch uit logging en metrics gegenereerd. #> [CmdletBinding()] param() $paths = Get-PerformanceTrackingPaths $folders = @( $paths.Root, $paths.SummaryPath ) foreach ($folder in $folders) { if (-not (Test-Path -Path $folder)) { if ($WhatIf) { Write-Host " [WhatIf] Zou map aanmaken: $folder" -ForegroundColor Yellow } else { New-Item -Path $folder -ItemType Directory -Force | Out-Null Write-Host " Map aangemaakt: $folder" -ForegroundColor Green } } } $exampleSummary = @( @{ endpoint = "ai-inference-eu" window = "Kantooruren (08:00-18:00)" requests = 12500 successRate = 0.995 p50LatencyMs = 210 p95LatencyMs = 430 p99LatencyMs = 750 maxLatencyMs = 1100 error5xxCount = 12 timeoutCount = 4 }, @{ endpoint = "ai-inference-nightly-batch" window = "Nachtbatch (23:00-05:00)" requests = 420000 successRate = 0.989 p50LatencyMs = 480 p95LatencyMs = 920 p99LatencyMs = 1600 maxLatencyMs = 2300 error5xxCount = 96 timeoutCount = 42 } ) $summaryFile = Join-Path $paths.SummaryPath "performance-summary.json" if ($WhatIf) { Write-Host " [WhatIf] Zou voorbeeld-performancebestand schrijven: $summaryFile" -ForegroundColor Yellow } else { $exampleSummary | ConvertTo-Json -Depth 5 | Out-File -FilePath $summaryFile -Encoding UTF8 Write-Host " Voorbeeld-performancebestand aangemaakt: $summaryFile" -ForegroundColor Green } } function Read-PerformanceSummaryFile { <# .SYNOPSIS Leest een JSON-bestand met performance-samenvattingen. .OUTPUTS Array van PSCustomObject met performancegegevens. #> [CmdletBinding()] param( [Parameter(Mandatory = $true)] [string]$Path ) if (-not (Test-Path -Path $Path)) { throw "Bestand niet gevonden: $Path" } $raw = Get-Content -Path $Path -Raw -ErrorAction Stop if (-not $raw.Trim()) { throw "Bestand is leeg: $Path" } return $raw | ConvertFrom-Json -ErrorAction Stop } function Invoke-PerformanceTrackingSummary { <# .SYNOPSIS Toont een overzicht van de belangrijkste performance-indicatoren. .OUTPUTS Array van PSCustomObject met samengevatte resultaten. #> [CmdletBinding()] param() $paths = Get-PerformanceTrackingPaths Write-Host "`nPerformance tracking – voorbeeldanalyse" -ForegroundColor Cyan Write-Host "Repository-root: $($paths.RepositoryRoot)" -ForegroundColor Cyan Write-Host "Samenvattingsmap: $($paths.SummaryPath)`n" -ForegroundColor Cyan if (-not (Test-Path -Path $paths.SummaryPath)) { Write-Host " Er zijn nog geen performance-samenvattingen aanwezig." -ForegroundColor Yellow Write-Host " Gebruik -Baseline om voorbeelddata voor lokale debugging te genereren." -ForegroundColor Yellow return @() } $summaryFile = Join-Path $paths.SummaryPath "performance-summary.json" if (-not (Test-Path -Path $summaryFile)) { Write-Host " Geen bestand 'performance-summary.json' gevonden in $($paths.SummaryPath)." -ForegroundColor Yellow Write-Host " Gebruik -Baseline om voorbeelddata aan te maken." -ForegroundColor Yellow return @() } try { $entries = Read-PerformanceSummaryFile -Path $summaryFile } catch { Write-Host " ❌ Fout bij het lezen van performance-samenvattingen: $_" -ForegroundColor Red return @() } if (-not $entries) { Write-Host " Geen performance-entries gevonden in $summaryFile." -ForegroundColor Yellow return @() } $results = @() foreach ($entry in $entries) { $status = "OK" $issues = New-Object System.Collections.Generic.List[string] if ($entry.p95LatencyMs -gt 1000) { $status = "High" $issues.Add("p95-latency ($($entry.p95LatencyMs) ms) is hoger dan richtwaarde 1000 ms.") } elseif ($entry.p95LatencyMs -gt 700) { if ($status -eq "OK") { $status = "Medium" } $issues.Add("p95-latency ($($entry.p95LatencyMs) ms) nadert de richtwaarde van 1000 ms.") } if ($entry.successRate -lt 0.99) { if ($status -eq "OK") { $status = "Medium" } $issues.Add("Success rate ($([math]::Round($entry.successRate * 100, 2))%) ligt onder 99%.") } if ($entry.timeoutCount -gt 0) { if ($status -eq "OK") { $status = "Medium" } $issues.Add("Er zijn $($entry.timeoutCount) time-outs geregistreerd.") } $result = [PSCustomObject]@{ Endpoint = $entry.endpoint Window = $entry.window Requests = $entry.requests SuccessRate = $entry.successRate P95LatencyMs = $entry.p95LatencyMs P99LatencyMs = $entry.p99LatencyMs MaxLatencyMs = $entry.maxLatencyMs Error5xxCount = $entry.error5xxCount TimeoutCount = $entry.timeoutCount Status = $status Notes = ($issues -join " ") } $results += $result switch ($status) { "OK" { Write-Host " ✅ $($entry.endpoint) [$($entry.window)]: p95=$($entry.p95LatencyMs) ms, success=$([math]::Round($entry.successRate * 100, 2))%" -ForegroundColor Green } "Medium" { Write-Host " ⚠️ $($entry.endpoint) [$($entry.window)]: aandacht vereist." -ForegroundColor Yellow if ($result.Notes) { Write-Host " $($result.Notes)" -ForegroundColor Yellow } } "High" { Write-Host " ❌ $($entry.endpoint) [$($entry.window)]: duidelijke performanceproblemen." -ForegroundColor Red if ($result.Notes) { Write-Host " $($result.Notes)" -ForegroundColor Red } } } } if (-not $results -or $results.Count -eq 0) { Write-Host "`nGeen performancegegevens beschikbaar om samen te vatten." -ForegroundColor Yellow } else { $high = $results | Where-Object { $_.Status -eq "High" } $medium = $results | Where-Object { $_.Status -eq "Medium" } if ($high -or $medium) { Write-Host "`nSamenvatting: één of meer endpoints vertonen performance-afwijkingen die nadere analyse vragen." -ForegroundColor Yellow } else { Write-Host "`n✅ Alle geanalyseerde endpoints liggen binnen de voorbeeldrichtwaarden." -ForegroundColor Green } } return $results } function Invoke-BaselineSetup { <# .SYNOPSIS Hoofdentrypoint voor het aanmaken van voorbeeld-performancebestanden. #> [CmdletBinding()] param() Write-Host "`nPerformance tracking – baseline-templates" -ForegroundColor Cyan New-PerformanceSampleData } try { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Performance tracking – AI operations" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan if ($Summary) { Invoke-PerformanceTrackingSummary | Out-Null } elseif ($Baseline) { Invoke-BaselineSetup } else { Write-Host "Geen modus opgegeven. Gebruik één van de volgende opties:" -ForegroundColor Yellow Write-Host " -Summary Toon een overzicht van performance-samenvattingen (indien aanwezig)." -ForegroundColor Yellow Write-Host " -Baseline Maak voorbeeld-bestanden aan voor lokale performance-analyses." -ForegroundColor Yellow Write-Host " Voeg -WhatIf toe om alleen te tonen wat er zou gebeuren zonder bestanden te wijzigen." -ForegroundColor Yellow } } catch { Write-Error "Fout in performance-tracking.ps1: $_" throw } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder gestructureerd performance tracking blijven prestatieproblemen vaak onopgemerkt totdat burgers, medewerkers of ketenpartners direct hinder ervaren. Dit vergroot de kans op overschrijding van wettelijke termijnen, verstoringen in essentiële diensten, non-compliance met BIO, NIS2 en EU AI Act, en aantasting van vertrouwen in digitale dienstverlening van de overheid.

Management Samenvatting

Richt een integraal performance tracking-raamwerk in voor AI- en data-intensieve workloads: definieer SLI’s en SLO’s vanuit publieke dienstverlening, verzamel consistente telemetrie met Azure Monitor en Application Insights, automatiseer dashboards en alerts, en veranker opvolging in governance, capaciteitsplanning en auditprocessen.