Service Level Agreement (SLA) – PrudAI B.V.

Versie: 1.2 — Augustus 2026

Onlosmakelijk verbonden met de NLdigital Voorwaarden 2025 (Hoofdstuk 1 & 2), het Data Pro Statement en de Fair Use Policy.

Dit document legt de prestatie-indicatoren, ondersteuningsniveaus en garanties vast met betrekking tot de SaaS-dienstverlening van PrudAI B.V. (hierna: "Leverancier"). Het is opgesteld ter aanvulling van de algemene voorwaarden om de continuïteit, betrouwbaarheid en transparantie van onze dienstverlening te borgen.

Artikel 1. Reikwijdte, Samenhang en Definities

1.1 Diensten. Deze SLA is van toepassing op de door de Klant afgenomen SaaS-diensten van Leverancier: LEO, ZIA, VERA, IRMA, BEVER en ORDO. Waar hierna "de Dienst" staat, wordt de door de Klant afgenomen dienst bedoeld. LEO, ZIA, VERA en BEVER worden geleverd vanaf één gedeeld platform en delen daardoor dezelfde Meetpunten; IRMA en ORDO hebben eigen Meetpunten.

1.2 Samenhang met andere documenten. Deze SLA vult de NLdigital Voorwaarden 2025 aan en treedt daarvoor niet in de plaats. Afspraken over de verwerking van persoonsgegevens, subverwerkers, datalekken, exit en audit staan in het Data Pro Statement; regels over toelaatbaar gebruik staan in de Fair Use Policy. Bij tegenstrijdigheid tussen deze SLA en de NLdigital Voorwaarden 2025 prevaleren de NLdigital Voorwaarden 2025, tenzij deze SLA de Klant een gunstiger serviceniveau biedt.

1.3 Definities.

• Beschikbaarheid: het percentage van de tijd per kalendermaand waarin de Dienst via het openbare internet toegankelijk is voor de Klant, gemeten op de in artikel 2.3 bedoelde Meetpunten.
• Ongeplande Downtime: de tijd waarin een of meer van de voor de Dienst geldende Meetpunten de Dienst als niet beschikbaar registreren, met uitzondering van de in artikel 2.4 genoemde gevallen.
• Kantoortijden: maandag tot en met vrijdag van 09:00 tot 17:00 uur (CET/CEST), met uitzondering van in Nederland officieel erkende feestdagen.
• Incident: een onvoorziene onderbreking of kwaliteitsvermindering van de Dienst waardoor deze niet functioneert conform de documentatie.
• Melding: een door de Klant bij Leverancier geregistreerd Incident of supportvraag.
• Reactietijd: de tijd tussen de ontvangst van een Melding en het moment waarop een medewerker van Leverancier inhoudelijk op die Melding reageert. Een geautomatiseerde ontvangstbevestiging geldt uitdrukkelijk niet als reactie.
• Hersteltijd: de tijd tussen de eerste inhoudelijke reactie op een Melding en het moment waarop het Incident is opgelost dan wel een Workaround beschikbaar is.
• Maximaal Gegevensverlies (Recovery Point Objective, RPO): de maximale periode waarover gegevens verloren kunnen gaan wanneer Leverancier gegevens uit een back-up terugzet, gerekend vanaf het laatste back-upmoment.
• Hersteltermijn Back-up (Recovery Time Objective, RTO): de tijd tussen het moment waarop Leverancier besluit gegevens uit een back-up terug te zetten en het moment waarop die gegevens weer beschikbaar zijn in de Dienst. Deze term staat los van de Hersteltijd: de Hersteltijd ziet op het oplossen van een Melding, de Hersteltermijn Back-up uitsluitend op het terugzetten van gegevens.
• Workaround: een tijdelijke oplossing waarmee de Klant de getroffen functionaliteit op een andere manier kan gebruiken, zonder dat de onderliggende oorzaak al is weggenomen.
• Gepland Onderhoud: onderhoudswerkzaamheden aan infrastructuur, netwerken of software die conform artikel 2.5 vooraf zijn aangekondigd, binnen het daar genoemde standaardvenster plaatsvinden, of daar als beveiligingsupdate zonder uitstel gelijk aan worden gesteld.
• Meetpunt: een door Leverancier op https://status.prudai.com gepubliceerde, geautomatiseerde controle op een onderdeel van de Dienst.

Artikel 2. Beschikbaarheid, Meting en Rapportage

2.1 Beschikbaarheidsnorm. Leverancier hanteert een beschikbaarheidsnorm van 99,5% per kalendermaand, berekend over 24 uur per dag, 7 dagen per week. Deze norm is een inspanningsverplichting: Leverancier spant zich naar beste vermogen in om haar te realiseren, maar verbindt er geen restitutie, servicecredits of andere financiële gevolgen aan. Artikel 2.6 beschrijft wat er gebeurt wanneer de norm structureel niet wordt gehaald.

2.2 Berekening. De daadwerkelijke Beschikbaarheid wordt per kalendermaand achteraf berekend volgens de formule:

Beschikbaarheid (%) = ((Totale tijd in maand − Ongeplande Downtime) / Totale tijd in maand) × 100

2.3 Meetpunten en meetmethode. De Beschikbaarheid wordt vastgesteld aan de hand van de Meetpunten die op https://status.prudai.com worden gepubliceerd. Per Dienst gelden de volgende Meetpunten:

LEO, ZIA, VERA en BEVER worden vanaf één gedeeld platform geleverd en delen daarom dezelfde Meetpunten. De Dienst geldt als niet beschikbaar zodra een of meer van de voor die Dienst geldende Meetpunten de Dienst als niet beschikbaar registreren. Elk Meetpunt wordt elke minuut gecontroleerd met een time-out van 10 seconden, vanaf een server die buiten de productieomgeving van de Dienst staat. De statuspagina toont de actuele en recente meting en geldt tussen partijen als uitgangspunt bij het vaststellen van Ongeplande Downtime. Meent de Klant dat de meting een storing niet of onjuist weergeeft, dan meldt hij dat conform artikel 3 en beoordelen partijen de betreffende periode gezamenlijk aan de hand van de beschikbare logging.

2.4 Uitzonderingen op Downtime. Niet als Ongeplande Downtime wordt gerekend de tijd waarin de Dienst niet beschikbaar is als gevolg van:

• Gepland Onderhoud conform artikel 2.5;
• overmacht in de zin van de NLdigital Voorwaarden 2025;
• opschorting wegens misbruik op grond van de Fair Use Policy;
• storingen in apparatuur, software, netwerken of internetverbindingen aan de zijde van de Klant, of het niet nakomen door de Klant van artikel 9;
• onbeschikbaarheid van externe bronnen of diensten van derden die buiten de invloedssfeer van Leverancier valt, voor zover de Dienst zelf blijft functioneren.

2.5 Gepland Onderhoud. Onderhoud dat de beschikbaarheid merkbaar raakt, kondigt Leverancier ten minste 48 uur vooraf aan op https://status.prudai.com. Daarnaast geldt een standaard onderhoudsvenster op zondag tussen 01:00 en 05:00 uur, waarbinnen onderhoud zonder nadere aankondiging kan plaatsvinden. Beveiligingsupdates die geen uitstel dulden voert Leverancier direct door; deze gelden als Gepland Onderhoud en de Klant wordt er zo spoedig mogelijk over geïnformeerd. Alle overige onderbrekingen, waaronder die door de reguliere, niet vooraf aangekondigde uitrol van updates, tellen mee als Ongeplande Downtime.

2.6 Rapportage en structureel niet halen. De actuele en recente Beschikbaarheid is doorlopend en publiekelijk in te zien op https://status.prudai.com. Op verzoek van de Klant stelt Leverancier de onderliggende meetgegevens over een specifieke kalendermaand beschikbaar, ook wanneer die maand niet meer op de statuspagina wordt getoond, voor zover het betreffende Meetpunt in die maand al in gebruik was. Wordt de norm uit artikel 2.1 in twee opeenvolgende kalendermaanden niet gehaald, dan stelt Leverancier op verzoek van de Klant een schriftelijke analyse met verbetermaatregelen op en bespreekt die met de Klant.

Artikel 3. Support en Incidentmanagement

3.1 Kanalen. De Klant kan Meldingen indienen via de supportomgeving op https://support.prudai.com, die vanuit de applicatie bereikbaar is, of per e-mail via support@prudai.com. Meldingen worden geregistreerd, voorzien van een prioriteit en tot afhandeling gevolgd.

3.2 Prioriteiten. Leverancier kent aan iedere Melding een prioriteit toe:

• P1 – Kritiek: volledige uitval van de Dienst. Geen enkele gebruiker kan inloggen of kritieke functionaliteit gebruiken en er is geen Workaround beschikbaar. Hieronder vallen ook beveiligingsincidenten.
• P2 – Hoog: ernstige functionele beperking. De Dienst is operationeel, maar belangrijke kernfunctionaliteit faalt voor meerdere gebruikers en er is geen of slechts een omslachtige Workaround.
• P3 – Medium: beperkte impact. De Dienst functioneert grotendeels naar behoren; er treedt een fout op in een niet-kritiek onderdeel of er is een eenvoudige Workaround.
• P4 – Laag: cosmetische fouten, algemene supportvragen, documentatieverzoeken of suggesties voor functionele verbeteringen.

3.3 Reactie-, herstel- en updatetijden. Reactietijden en updatefrequenties lopen binnen Kantoortijden en gaan in op het moment waarop de Melding is ontvangen. Hersteltijden lopen door in kalenderdagen en gaan in op het moment van de eerste inhoudelijke reactie, zodat de hersteltermijn nooit eerder verstrijkt dan de reactietermijn.

3.4 Werking van de hersteltijden. De hersteltijden zijn resultaatgerichte streefwaarden; de genoemde percentages worden bepaald over een kalenderkwartaal en op verzoek van de Klant gerapporteerd. Kan Leverancier een Workaround bieden, dan geldt het Incident als hersteld en wordt de resterende structurele oplossing als P2 of P3 verder opgepakt. Voor P3 en P4 spant Leverancier zich in de oplossing in een van de eerstvolgende reguliere releases mee te nemen; Leverancier is niet gehouden een Incident op te lossen dat geen wezenlijke verstoring van de Dienst veroorzaakt.

3.5 Medewerking. Leverancier is aan de reactie- en hersteltijden gehouden voor zover de Klant zijn volledige medewerking verleent, waaronder het verstrekken van de informatie die nodig is om het Incident te reproduceren en het beschikbaar zijn van de in artikel 9.1 bedoelde contactpersonen.

3.6 Escalatie. Is de Klant van mening dat een Melding onvoldoende voortgang kent, dan kan hij escaleren via support@prudai.com onder vermelding van het meldingsnummer. Een escalatie wordt binnen één werkdag opgepakt door een verantwoordelijke van Leverancier. Leidt dat niet tot een oplossing, dan staat de klachtenprocedure uit artikel 8 open.

Artikel 4. Back-up en Herstel

4.1 Reikwijdte en frequentie. Leverancier maakt ten minste eenmaal per uur een back-up van de databases waarin de gegevens van de Klant worden vastgelegd: onder meer de gebruikers, instellingen, gesprekken, dossierstructuur en documentmetadata. De documentbestanden in objectopslag worden eveneens ten minste eenmaal per uur naar een tweede opslagregio gekopieerd. Het Maximaal Gegevensverlies (RPO) bedraagt daarmee één uur.

Niet onder deze back-upregeling vallen zoekindexen, vectoropslag en andere afgeleide opslag: die bevatten geen brongegevens en worden na een herstel opnieuw opgebouwd. Voor die afgeleide opslag geldt geen Maximaal Gegevensverlies.

4.2 Retentie. Uurlijkse back-ups worden ten minste 24 uur bewaard; van elke dag wordt daarnaast een back-up ten minste 14 dagen bewaard. Back-ups worden versleuteld opgeslagen en zijn onderworpen aan dezelfde beveiligings- en geheimhoudingsverplichtingen als de productieomgeving.

4.3 Controle. Leverancier bewaakt geautomatiseerd en ten minste dagelijks of van de beschermde systemen een actuele back-up aanwezig is, en wordt intern gewaarschuwd wanneer dat niet zo is. Leverancier voert daarnaast ten minste eenmaal per jaar een herstelproef uit waarbij een back-up daadwerkelijk wordt teruggezet en op volledigheid wordt gecontroleerd, en legt de uitkomst daarvan vast.

4.4 Hersteltermijn (RTO). Besluit Leverancier gegevens uit een back-up terug te zetten, dan zijn die gegevens binnen vier uur na dat besluit weer beschikbaar in de Dienst. Voor het terugzetten zelf geldt deze Hersteltermijn Back-up (RTO); die treedt in de plaats van de Hersteltijd uit artikel 3.3, die op het oplossen van de Melding als geheel ziet.

Is de omgeving waarin de Dienst draait als geheel niet meer beschikbaar, dan geeft Leverancier geen Hersteltermijn af. Herstel omvat in dat geval stappen die losstaan van de back-ups, zoals het inrichten van nieuwe infrastructuur, het omzetten van naamgeving en het opnieuw in bedrijf stellen en verifiëren van alle onderdelen van de Dienst. Leverancier behandelt dat als P1-Incident conform artikel 3 en spant zich in tot herstel; een termijn wordt daarvoor niet toegezegd.

4.5 Herstel na een Incident. Is herstel uit een back-up nodig, dan behandelt Leverancier dat als een P1-Incident conform artikel 3.

4.6 Beperkingen. De Dienst wordt geleverd vanuit een omgeving die door meerdere klanten wordt gedeeld. In lijn met artikel 27.1 van de NLdigital Voorwaarden 2025 is Leverancier niet gehouden tot herstel van beschadigde of verloren gegane gegevens anders dan het — waar mogelijk — terugplaatsen van de laatst beschikbare back-up. Het afzonderlijk terugzetten van uitsluitend de gegevens van één Klant is niet in alle gevallen mogelijk; waar dat wel kan, kan Leverancier daarvoor zijn gebruikelijke tarieven in rekening brengen. Gegevens die de Klant zelf uit de Dienst verwijdert, worden niet uit een back-up teruggehaald tenzij dat uitdrukkelijk wordt afgesproken.

Artikel 5. Releases en Wijzigingen in de Dienst

5.1 Releaseritme. Leverancier werkt met doorlopende uitlevering: verbeteringen en correcties komen gedurende het jaar beschikbaar zodra zij gereed zijn. Voor functionele wijzigingen die voor gebruikers merkbaar zijn, publiceert Leverancier release notes.

5.2 Aankondiging. Wijzigingen die de bestaande werkwijze van gebruikers wezenlijk raken, kondigt Leverancier ten minste 14 dagen vooraf aan via de gebruikelijke kanalen. Voor het wijzigen van de inhoud of omvang van de SaaS-dienst geldt daarnaast artikel 38.3 van de NLdigital Voorwaarden 2025.

5.3 Spoedcorrecties. Correcties van fouten en beveiligingsproblemen die geen uitstel dulden brengt Leverancier direct in productie. Leverancier streeft ernaar dat zoveel mogelijk buiten Kantoortijden te doen.

Artikel 6. Continuïteit van de Keten en AI-specifieke Afspraken

6.1 Fallback-mechanisme. Om de continuïteit van de Dienst te borgen maakt de architectuur gebruik van automatische loadbalancing en een fallback-keten over meerdere AI-leveranciers. Valt een onderliggend datacenter of endpoint uit of raakt het overbelast, dan schakelt de software zonder handmatige interventie over naar het volgende geconfigureerde endpoint in de keten.

6.2 Samenstelling van de keten. De ingeschakelde subverwerkers, hun dienstverlening en hun regio-instellingen zijn vastgelegd in artikel 5 van het Data Pro Statement; wijzigingen daarin verlopen volgens de daar beschreven procedure, inclusief de aankondigingstermijn en het bezwaarrecht van de Klant. Deze SLA noemt individuele leveranciers en hun regio's bewust niet, zodat die gegevens op één plaats worden onderhouden en niet uiteen kunnen lopen.

6.3 Uitkomst en snelheid bij fallback. De Klant erkent dat de fallback-keten is ingericht op beschikbaarheid: wanneer wordt teruggevallen op een ander endpoint of model kunnen de snelheid en de formulering van de uitkomst afwijken van de gebruikelijke situatie. Leverancier borgt dat elk endpoint in de keten geschikt is voor het beoogde gebruik van de Dienst, maar garandeert geen woordelijk gelijke uitkomsten.

6.4 Wijziging of uitfasering van modellen. Onderliggende AI-modellen worden door hun leveranciers periodiek vervangen of uitgefaseerd. Leverancier informeert de Klant ten minste 30 dagen vooraf over een modelwijziging waarvan Leverancier verwacht dat die de uitkomsten van de Dienst merkbaar beïnvloedt, tenzij de onderliggende leverancier een kortere termijn hanteert of een acuut beveiligingsbelang zich daartegen verzet; in dat geval informeert Leverancier de Klant zo spoedig mogelijk. Leverancier draagt zorg voor een ten minste gelijkwaardig alternatief en brengt daarvoor gedurende de lopende contractperiode geen aanvullende kosten in rekening.

6.5 Responsiviteit. Leverancier bewaakt doorlopend de reactiesnelheid van de Dienst. Een structurele verslechtering daarvan die het normale gebruik merkbaar belemmert, behandelt Leverancier als Incident conform artikel 3, ook wanneer de Dienst formeel beschikbaar blijft.

Artikel 7. Informatiebeveiliging

7.1 Beheersysteem. Leverancier hanteert een informatiebeveiligingsmanagementsysteem (ISMS) gericht op de beschikbaarheid, integriteit en vertrouwelijkheid van de informatie van klanten, ingericht naar het model van ISO 27001. De algemene beveiligingsdocumentatie is beschikbaar via https://trust.prudai.com. Het Statement of Applicability en — zodra beschikbaar — de certificerings- en auditrapporten worden op aanvraag verstrekt, via security@prudai.com of conform artikel 8 van het Data Pro Statement.

7.2 Penetratietesten. Leverancier voert een readiness review uit om voorbereid te zijn op een externe penetratietest. Wenst de Klant een penetratietest te laten uitvoeren, dan verleent Leverancier daaraan zijn medewerking; de uitvoering en de kosten daarvan komen voor rekening van de Klant, tenzij schriftelijk anders overeengekomen.

7.3 Datalekken. De melding van een inbreuk in verband met persoonsgegevens, de termijn waarbinnen dat gebeurt en de inhoud van die melding zijn geregeld in artikel 6 van het Data Pro Statement.

Artikel 8. Klachten

8.1 Klacht. Een klacht is een uiting waarin de Klant expliciet aangeeft niet tevreden te zijn over de dienstverlening van Leverancier. Klachten worden ingediend via support@prudai.com onder vermelding van "klacht", met een omschrijving van de ontevredenheid, de gevolgen daarvan en de indiener.

8.2 Behandeling. Leverancier bevestigt de ontvangst binnen twee werkdagen, onderzoekt de oorzaak en plant een overleg met de Klant waarin de klacht wordt besproken en afspraken worden vastgelegd om deze te verhelpen. Een inhoudelijke reactie volgt nooit later dan drie weken na ontvangst. Leverancier bewaakt de uitvoering van de gemaakte afspraken.

Artikel 9. Verplichtingen van de Klant

9.1 Contactpersonen. De Klant wijst één of twee vaste contactpersonen aan voor de afhandeling van Meldingen en houdt hun contactgegevens actueel. De operationele communicatie over Meldingen verloopt via deze contactpersonen.

9.2 Gebruiksomgeving. De Klant draagt er zorg voor dat de werkplekken van zijn gebruikers correct zijn geconfigureerd en aan gangbare beveiligingsnormen voldoen, dat een actueel ondersteunde internetbrowser wordt gebruikt, dat beveiligingsupdates van het besturingssysteem zijn geïnstalleerd en dat de internetverbinding voldoende capaciteit biedt. Het beheer en de bewaking van het lokale netwerk en de internetverbindingen zijn de verantwoordelijkheid van de Klant.

9.3 Toegang. Toegang tot de gegevens in de Dienst verloopt uitsluitend via de daarvoor bedoelde functionaliteit en de officiële API's. Directe toegang tot de onderliggende databases is niet toegestaan.

9.4 Geen beroep op deze SLA. De Klant kan zich niet op de service levels uit deze SLA beroepen wanneer de storing of prestatievermindering:

• betrekking heeft op producten of diensten die niet in deze SLA of in de overeenkomst zijn genoemd;
• voortkomt uit het niet nakomen door de Klant van dit artikel, de overeenkomst, de NLdigital Voorwaarden 2025 of de Fair Use Policy;
• het gevolg is van een poging tot het opzettelijk beschadigen van gegevens of systemen;
• het gevolg is van overmacht.

Artikel 10. Exit en Dataportabiliteit

De export van gegevens tijdens de looptijd, de overgangsperiode na beëindiging, de migratiebijstand, de termijnen voor definitieve verwijdering en de aankondigingstermijn wanneer Leverancier de Dienst staakt, zijn geregeld in artikel 7 van het Data Pro Statement. Die bepalingen gelden onverkort als onderdeel van het serviceniveau dat Leverancier aan de Klant biedt.

Artikel 11. Wijziging, Versiebeheer en Evaluatie

11.1 Wijziging. De wereld van AI en cloudinfrastructuur ontwikkelt zich snel. Leverancier kan deze SLA aanpassen wanneer technologische ontwikkelingen, wijzigingen in netwerkarchitecturen of afspraken met onderliggende leveranciers daartoe aanleiding geven. Wijzigingen worden via de gebruikelijke kanalen of de website bekendgemaakt en treden 30 dagen na bekendmaking in werking.

11.2 Nadelige wijziging. Verlaagt een wijziging het serviceniveau op een voor de Klant nadelige en niet ondergeschikte wijze, dan kan de Klant de betreffende dienst binnen 30 dagen na bekendmaking schriftelijk opzeggen tegen de datum waarop de wijziging ingaat, zonder dat daarvoor kosten of een vergoeding verschuldigd zijn.

11.3 Versiebeheer. Deze SLA is voorzien van een versienummer en een versiehistorie. De versie die gold op het moment van de gebeurtenis waarop een beroep wordt gedaan is tussen partijen bepalend. Leverancier houdt eerdere versies beschikbaar.

11.4 Evaluatie. Leverancier evalueert deze SLA ten minste eenmaal per jaar en actualiseert haar waar nodig.

Versiehistorie

Eerdere versies blijven beschikbaar, zoals vastgelegd in artikel 11.3: versie 1.1 — Augustus 2026 · versie 1.0 — Augustus 2026 · Mei 2026 · Februari 2026.

Aldus opgesteld ter goeder trouw en onlosmakelijk verbonden met de SaaS-overeenkomst van PrudAI B.V.