Service Level Agreement

Het doel van deze SLA is het vastleggen van prestatieafspraken, zoals geldende prestatieniveaus, reactietijden, service windows, rapportages en beschikbaarheid van de door de opdrachtnemer ontwikkelde AI Tools en AI Agents en bijbehorende software.

Deze Service Level Agreement (SLA) is onlosmakelijk verbonden met de tussen opdrachtgever en opdrachtnemer gesloten raamovereenkomst, waarvan de algemene voorwaarden van de opdrachtnemer integraal onderdeel uitmaken.

Opdrachtgever en opdrachtnemer evalueren de SLA jaarlijks. Gewenste wijzigingen worden schriftelijk gecommuniceerd door middel van een RfC (Request for Change). Heeft een gewenste wijziging financiële gevolgen, dan brengt de opdrachtnemer hiervoor een begroting uit. Na het bespreken van een RfC en na wederzijdse goedkeuring passen partijen deze SLA in een nadere schriftelijke overeenkomst aan. Wijzigingen zijn pas van kracht na ondertekening van een nadere overeenkomst door beide partijen.

De in de SLA overeengekomen servicelevels kunnen alleen worden nagekomen indien de afspraken en procedures tussen opdrachtnemer en opdrachtgever eveneens worden nageleefd.

Of de kosten voor het oplossen van prio 1, 2 en 3 incidenten zijn inbegrepen in deze SLA, hangt af van het gekozen pakket. Zie hiervoor het onderdeel "Incidenten oplossen inbegrepen" in de SLA-overzichtstabel.

1.1 Infrastructuur en hosting

Afspraken zoals beschreven in deze SLA gelden voor de door de opdrachtnemer geleverde ICT-infrastructuur. Indien de opdrachtnemer zijn diensten levert op de infrastructuur van de opdrachtgever, valt deze infrastructuur niet onder deze SLA en is de opdrachtnemer vanuit een adviserende rol betrokken.

1.2 AI Tools, AI Agents en software

Afspraken zoals beschreven in deze SLA gelden voor de door de opdrachtnemer ontwikkelde AI Tools en AI Agents en bijbehorende software. Software van de opdrachtgever of derden valt niet onder deze SLA.

1.3 Modellen van derden

AI Tools en AI Agents maken gebruik van AI-modellen van derde partijen. De beschikbaarheid en de uitvoer van deze modelleveranciers vallen buiten deze SLA. Bij een storing bij een modelleverancier spant de opdrachtnemer zich in om, waar technisch mogelijk, uit te wijken naar een alternatief model zodat de dienstverlening doorloopt.

1.4 Scope

De onderstaande AI Tool(s) en AI Agent(s) vallen onder deze SLA.

3.1 Contactpersonen

Beide partijen, de opdrachtnemer en de opdrachtgever, wijzen elk een contractbeheerder en een vaste contactpersoon aan. De contactgegevens van de contractbeheerder en de contactpersoon worden schriftelijk vastgelegd. Wijzigingen in de contactgegevens worden eveneens schriftelijk vastgelegd. De contractbeheerder bij de opdrachtnemer vervult de rol van Service Manager.

3.2 Algemene beschrijving van onze diensten

De opdrachtnemer garandeert dat de diensten beschikbaar zijn binnen de grenzen van deze SLA. In het geval dat een storing de beschikbaarheid vermindert, verplicht de opdrachtnemer zich tot het oplossen van de storing binnen de in deze SLA overeengekomen termijnen. De opdrachtnemer verplicht zich tot regelmatige controle en gedegen onderhoud van de door haar ontwikkelde AI Tools en AI Agents en waarborgt dat de capaciteit van deze diensten zodanig is dat dit bij normaal gebruik niet leidt tot storingen.

3.3 Duur van de SLA

De SLA gaat in op het moment van eerste levering van de dienst en wordt aangegaan voor dezelfde periode als de raamovereenkomst waaronder de dienst wordt geleverd. De SLA wordt automatisch beëindigd op de datum waarop de raamovereenkomst eindigt. Een opzegging van de raamovereenkomst geldt tevens als een opzegging van deze SLA. Na de initiële periode van de raamovereenkomst wordt de SLA jaarlijks verlengd met een opzegtermijn van 1 maand.

3.4 Service window

Een service window beschrijft het tijdsframe waarbinnen de serviceafspraken gelden over responstijden en oplostijden. Voor incidenten, wijzigingen en problemen gelden verschillende service windows.

3.5 Prioriteitentabel

Aanduiding van prioriteiten zoals gedefinieerd binnen deze SLA.

3.6 Maintenance window

Het onderhoudswindow is het met de opdrachtgever afgesproken tijdsbestek waarin geen of beperkt gebruik gemaakt kan worden van een dienst van de opdrachtnemer zoals vastgelegd in de raamovereenkomst, als gevolg van onderhoudswerkzaamheden.

3.7 Reactietijden

Voor incidenten, problemen en wijzigingen gelden verschillende reactietijden. Deze worden beschreven in de desbetreffende hoofdstukken van deze SLA.

3.8 Oplostijden

Opdrachtnemer heeft een inspanningsverplichting conform het SLA-niveau wat betreft het oplossen van incidenten en/of verzoeken van opdrachtgever. De complexiteit van elk incident of verzoek maakt het onmogelijk een 100% garantie af te geven om het incident of verzoek tijdig op te lossen. Opdrachtnemer hanteert daarom een garantie van 95% op de oplostijden. Opdrachtnemer grijpt direct in indien er sprake is van een probleem binnen de infrastructuur van opdrachtgever en draagt zorg (inspanningsverplichting) dat de dienstverlening van opdrachtgever zo spoedig mogelijk weer in gebruik kan worden genomen.

3.9 Onderhoud, gepland onderhoud en noodonderhoud

Gepland onderhoud kan op elk moment plaatsvinden. De opdrachtgever wordt voorafgaand hieraan geïnformeerd via de projectmanagementsoftware. Het is mogelijk dat tijdens deze onderhoudsperiode de dienst tijdelijk geheel of gedeeltelijk buiten gebruik is en daardoor niet beschikbaar is voor de opdrachtgever (prioriteitsniveau 1: uitval van de dienst).

Gepland onderhoud vindt plaats in overleg met de opdrachtgever en omvat:

• het onderhoudswindow waarin het gepland onderhoud zal plaatsvinden;
• de verwachte duur van het gepland onderhoud;
• de diensten waarop het geplande onderhoud van invloed zal zijn.

Gepland onderhoud wordt niet meegenomen in de beschikbaarheidsberekeningen.

Noodonderhoud kan nodig zijn wanneer omstandigheden onmiddellijk ingrijpen vereisen. In een dergelijke situatie wordt de opdrachtgever zo spoedig mogelijk geïnformeerd. Onbeschikbaarheid tijdens noodonderhoud telt mee in de beschikbaarheidsberekening.

3.10 Back-up en recovery procedure

Indien de software draait op de infrastructuur van de opdrachtnemer, is de back-up en recovery van de gegevens als volgt geregeld:

• Frequentie: eenmaal per dag wordt een back-up gemaakt.
• Medium: back-ups worden weggeschreven op een andere omgeving. Dit kunnen fysieke servers zijn of een cloudomgeving.
• Bewaartermijn: de back-up wordt gedurende 7 kalenderdagen bewaard.
• Recovery procedure: de opdrachtgever kan aan de opdrachtnemer verzoeken om gegevens uit de back-up beschikbaar te maken. Uren gemaakt voor de recovery procedure door de opdrachtnemer worden verrekend op basis van nacalculatie.

Indien de software draait op de infrastructuur van de opdrachtgever of een overeengekomen derde partij, zijn de back-up en recovery procedure afspraken geen onderdeel van deze SLA.

3.11 Beschikbaarheid

Voor de beschikbaarheid van de software geldt een garantie zoals opgenomen in de SLA-overzichtstabel, op jaarbasis. De procedure voor het beschikbaar stellen van de software en de systeemomgeving is opgenomen in de overeenkomst tussen opdrachtgever en opdrachtnemer. De opdrachtnemer garandeert niet dat er altijd communicatie over het internet mogelijk is of dat er altijd een verbinding tot stand kan worden gebracht met een andere machine die is aangesloten op het internet. Er is sprake van onbeschikbaarheid als een dienst van de opdrachtnemer als gevolg van een niet geplande gebeurtenis voor geen enkele gebruiker bruikbaar is. Als een dienst slechts voor bepaalde gebruikers onbruikbaar is of niet correct functioneert, is er sprake van een incident, waarbij de dienst op zich als beschikbaar wordt aangemerkt.

De verantwoordelijkheid van de opdrachtnemer met betrekking tot beschikbaarheid is niet van toepassing op storingen indien:

• geplande werkzaamheden worden uitgevoerd;
• de storing optreedt als gevolg van een storing in de infrastructuur van de opdrachtgever;
• de storing optreedt als gevolg van een storing in de infrastructuur van derden, waaronder modelleveranciers en de hostingprovider;
• de storing elders in de keten optreedt door een aangevraagde wijziging van de opdrachtgever;
• een uitval wordt veroorzaakt door ongeautoriseerde wijzigingen door personeel van de opdrachtgever in de apparatuur van de opdrachtnemer;
• overmacht.

Voor diensten wordt de beschikbaarheid (A) als volgt berekend, bij een fictieve uptimegarantie van 99,5%. De daadwerkelijke uptimegarantie wordt bepaald door het gekozen SLA-pakket:

3.12 Veiligheid en betrouwbaarheid

De opdrachtnemer geeft geen garanties en aanvaardt geen aansprakelijkheid met betrekking tot de veiligheid van netwerkverbindingen.

3.13 Werkzaamheden buiten afgenomen service window

De opdrachtnemer heeft geen verplichting tot het uitvoeren van werkzaamheden die vallen buiten het gekozen service window. De opdrachtgever kan op basis van goodwill de opdrachtnemer vragen werkzaamheden toch te verrichten. Deze werkzaamheden worden uitgevoerd tegen het dubbele tarief van het op dat moment geldende uurtarief.

4.1 Doel

Incidentmanagement heeft tot doel (dreigende) verstoringen in de dienstverlening aan de opdrachtgever zo snel mogelijk te verhelpen. De opdrachtgever moet zo min mogelijk hinder van storingen ondervinden en zo snel mogelijk met de normale werkzaamheden door kunnen gaan. Dit wordt gedaan door het aannemen, beoordelen, oplossen en afmelden van meldingen van de opdrachtgever.

4.2 Invoer door opdrachtgever

De melding gaat via het contactpunt passend bij de prioriteit. Het contactpunt heeft de volgende gegevens nodig als invoer:

• naam van de melder;
• telefoonnummer en e-mailadres van de melder;
• de datum (eventueel tijdstip) waarop het incident voor het eerst gesignaleerd is;
• omschrijving van het incident;
• een geschatte prioriteit van de opdrachtgever.

4.3 Invoer door opdrachtnemer

Een incident kan ook door de opdrachtnemer geconstateerd worden. Ook in dat geval wordt het proces gevolgd zoals beschreven in artikel 4.2.

4.4 Uitvoer

Na het afhandelen van het incident wordt een terugkoppeling over het verholpen incident naar de incidentmelder gedaan. De frequentie van terugkoppeling over de status tijdens de uitvoering is afhankelijk van de prioriteit en wordt met de opdrachtgever naar redelijkheid afgestemd. Indien van toepassing is de status te volgen via de projectmanagementsoftware van de opdrachtnemer.

4.5 Proces en uitvoerende partijen

4.6 Formele afspraken tussen opdrachtnemer en opdrachtgever

4.7 Reactietijdentabel

Zie het SLA-overzicht.

4.8 Contact

Het type contact bij melding van een incident is vastgelegd in onderstaande tabel.

4.9 Voorwaarden en uitsluitingen

• De opdrachtnemer is niet bereikbaar op tijdstippen buiten het service window.
• Meldingen die buiten het toepasselijke service window worden ingediend, worden op de eerstvolgende werkdag in behandeling genomen.
• Alle meldingen veroorzaakt door herhaaldelijk of stelselmatig onkundig gebruik van apparatuur en/of programmatuur door medewerkers van de opdrachtgever worden door de opdrachtnemer direct aan de opdrachtgever geëscaleerd.
• Meldingen die, in overleg met de opdrachtgever, uitgesteld zijn, vallen buiten de overeengekomen servicelevels.
• Indien een incident leidt tot een wijziging in functionaliteit, geldt regulier projectmanagement.
• De opdrachtgever dient in haar contracten met derde partijen zorg te dragen dat de opdrachtnemer geïnformeerd wordt over de status en voortgang van de naar die partijen doorverwezen meldingen.
• Lopende capaciteitsreserveringen kunnen plaatsmaken voor eventuele herstelwerkzaamheden. De opdrachtnemer levert een inspanningsverplichting om de opgelopen verloren tijd zo spoedig mogelijk in te halen.

5.1 Doel

Het doel van probleemmanagement is het verhogen van de kwaliteit van de software door incidenten op hun oorzaak te onderzoeken en de oorzaken te laten wegnemen. Met andere woorden: het structureel oplossen van incidenten met de status "workaround" en hier lering uit trekken om daarmee verbetervoorstellen uit te brengen.

5.2 Invoer

• Incident met de status "workaround".

5.3 Uitvoer

• Een ticket/story in de projectmanagementsoftware van de opdrachtnemer zodat de status inzichtelijk is.
• Een opgelost probleem of een plan daartoe.
• Eventueel verdere voortgangsrapportages betreffende het probleem.

De frequentie van terugkoppeling over de status van het probleem richting de opdrachtgever tijdens de uitvoering is afhankelijk van de prioriteit en wordt met de opdrachtgever naar redelijkheid afgestemd.

5.4 Proces en uitvoerende partijen

5.5 Formele afspraken tussen opdrachtnemer en opdrachtgever

5.6 Start oplostijden

Zie de SLA-overzichtstabel.

6.1 Doel

Het doel van wijzigingsverzoeken is het planmatig doorvoeren van een wijziging in de systeemomgeving van de opdrachtgever of opdrachtnemer. Daarbij worden de risico's op verstoring van de diensten zo beperkt mogelijk gehouden. Wijzigingsverzoeken hebben geen betrekking op doorontwikkelingen van de AI Tools en AI Agents. Wijzigingen aan prompts en configuratie van AI Tools en AI Agents verlopen eveneens via dit proces.

6.2 Invoer

Wijzigingsverzoeken die zijn ingediend door geautoriseerde personen van de opdrachtgever of opdrachtnemer, vinden plaats via de projectmanagementsoftware van de opdrachtnemer.

6.3 Uitvoer

• Uitgevoerde wijziging.
• Voortgang inzichtelijk via de projectmanagementsoftware van de opdrachtnemer.

6.4 Proces en uitvoerende partijen

6.5 Definities standaard, beperkte en ingrijpende wijzigingen

6.6 Formele afspraken tussen opdrachtnemer en opdrachtgever

6.7 Voorwaarden en uitsluitingen

Alleen de opdrachtnemer is gerechtigd om wijzigingen aan te brengen in de onder haar verantwoordelijkheid vallende infrastructuur en software.

Opdrachtnemer erkent het belang van de beveiliging van de omgeving van de opdrachtgever en houdt zich regelmatig op de hoogte van de laatste informatie omtrent beveiliging. Om een optimale beveiliging te garanderen nemen opdrachtnemer en opdrachtgever de onderstaande maatregelen:

• Opdrachtnemer garandeert dat alleen haar medewerkers toegang hebben tot de systeemomgeving. Bij uitdiensttreding wordt deze toegang ontnomen.
• Indien een server is getroffen door een beveiligingsincident, beraadslaagt de opdrachtnemer over de te volgen stappen; indien nodig worden patches op korte termijn geïnstalleerd. Indien hierbij een onderbreking van de service plaatsvindt, wordt de opdrachtgever hier meteen van op de hoogte gesteld. Deze onderbrekingen tellen niet mee in de beschikbaarheidsberekening.
• Opdrachtnemer verleent haar medewerking aan security audits en penetration tests, mits deze de beschikbaarheid van de dienstverlening niet in gevaar brengen; dit ter beoordeling door de opdrachtnemer. De kosten van een security audit en penetration test zijn voor de opdrachtgever. Verzoeken moeten minstens één maand voorafgaand aan de geplande audit of penetration test schriftelijk worden ingediend via de contactpersonen.
• Gegevens die AI Tools en AI Agents verwerken, worden behandeld conform de verwerkersovereenkomst tussen opdrachtgever en opdrachtnemer. Bedrijfsgegevens van de opdrachtgever worden niet gebruikt voor het trainen van modellen van derden.

Beheer en onderhoud heeft als doel de beschikbaarheid, kwaliteit en veiligheid van de door de opdrachtnemer ontwikkelde AI Tools en AI Agents te waarborgen. De volgende onderdelen zijn daarvan een integraal onderdeel.

Platform health check

De software wordt voorzien van een op maat gemaakte module die de status van alle cruciale softwaresystemen test op beschikbaarheid. Voorbeelden hiervan zijn: database, model-API's of API's van systemen van derden. Bij uitval van een cruciaal onderdeel spant opdrachtnemer zich in om de gevolgen hiervan zoveel mogelijk te beperken. Indien mogelijk en noodzakelijk wordt via incidentmanagement gekeken of de uitval in de toekomst kan worden voorkomen, of de gevolgen ervan te beperken zijn.

Uptime monitoring

De beschikbaarheid van de AI Tools en AI Agents wordt gemonitord door middel van uptime monitoring. Deze software controleert elke minuut of de dienst nog beschikbaar is. Indien dit niet het geval is, wordt opdrachtnemer hiervan op de hoogte gebracht zodat hij actie kan ondernemen.

Certificaat-checks

Alle webapplicaties en koppelingen worden voorzien van een certificaat ten behoeve van beveiliging en privacy. Certificaten kunnen verlopen en moeten regelmatig vernieuwd worden. Om problemen met certificaten voor te zijn, nemen wij deze op in onze monitoring.

Integratie-monitoring

AI Tools en AI Agents zijn gekoppeld aan systemen van de opdrachtgever en derden. Deze koppelingen worden gemonitord op beschikbaarheid en op wijzigingen in de API's van derden. Bij een aangekondigde wijziging van een API beoordeelt de opdrachtnemer de impact en voert waar nodig aanpassingen door via het proces wijzigingsverzoeken.

Error monitoring

Indien er een fout optreedt in de software, wordt deze fout weggeschreven in een logbestand. Om deze taak beheersbaar te maken hanteert opdrachtnemer error tracking software waarbij alle mogelijke errors worden gelogd in één applicatie, inclusief de eigenschappen die speelden op het moment van de fout. Op deze manier kan er accuraat gekeken worden naar de oorsprong van de fout en een mogelijke oplossing.

Kwaliteitsbewaking AI-antwoorden

De kwaliteit van de uitvoer van AI Tools en AI Agents wordt periodiek steekproefsgewijs beoordeeld. Structurele afwijkingen worden via probleemmanagement onderzocht en waar nodig verholpen met prompt- of configuratiewijzigingen.

Updates en security patches

Wij onderscheiden updates en security patches in drie groepen:

A: De door opdrachtnemer ontwikkelde software. Software is voortdurend onderhevig aan updates, in drie categorieën. Minor updates voegen kleine verbeteringen toe en vereisen over het algemeen geen aanpassingen in de code van de opdrachtnemer (bijvoorbeeld versie 1.3.3 naar 1.3.4); de impact is laag. Major updates kenmerken zich door fundamentele wijzigingen waarbij over het algemeen de compatibiliteit met de voorgaande major versie wordt verbroken (bijvoorbeeld versie 1.3.3 naar 2.0); afhankelijk van het softwarepakket wordt een strategie bepaald voor de upgrade; de impact is hoog. Security patches dichten potentiële beveiligingslekken; patches met de status "Critical" worden zo snel mogelijk geïnstalleerd. Indien er problemen optreden tijdens de installatie, start de opdrachtnemer een incidentmanagementprocedure en communiceert dit met de opdrachtgever.

B: Hosting en infrastructuur. Het besturingssysteem waarop de software draait, is voortdurend onderhevig aan updates en security patches. Alle security patches worden zoveel mogelijk automatisch geïnstalleerd. Installatie van patches die niet automatisch geïnstalleerd kunnen worden of waarbij geplande downtime verwacht wordt, wordt uitgevoerd binnen de met de opdrachtgever afgesproken onderhoudsvensters.

C: Modellen en prompts. Modelleveranciers brengen regelmatig nieuwe modelversies uit en faseren oudere versies uit. De opdrachtnemer test nieuwe modelversies en voert de overstap door binnen de met de opdrachtgever afgesproken onderhoudsvensters. Indien een modelversie wordt uitgefaseerd door de leverancier, wordt de overstap tijdig gepland en waar nodig worden prompts en configuratie aangepast om de kwaliteit van de uitvoer te behouden.

Genoemde prijzen worden jaarlijks geïndexeerd op basis van de consumentenprijsindex (CPI) van het CBS.

Facturatie per kwartaal.

Deze Service Level Agreement is onlosmakelijk verbonden met de opdrachtbevestiging en/of raamovereenkomst tussen opdrachtnemer en opdrachtgever. Na ondertekening kan deze Service Level Agreement alleen aangepast worden door middel van een wijzigingsverzoek dat door beide partijen schriftelijk goedgekeurd moet worden.

De ondergetekenden verklaren bevoegd te zijn deze overeenkomst te ondertekenen.

* Niet nodig bij digitaal ondertekenen.

Deze bijlage beschrijft het additionele beheer en onderhoud van het AI-platform waarop de AI Tools en AI Agents draaien.

Platform upgrades en patches

• Tot maximaal 5 platform-upgrades per jaar (minor upgrades en patches).
• Alle "Critical" en "High" security patches volgens CVSS.
• Door opdrachtnemer ontwikkelde maatwerkmodules en integraties worden binnen de major release compatibel gehouden.
• Nieuwe modelversies worden getest en in overleg met de opdrachtgever doorgevoerd; uitgefaseerde modelversies worden tijdig vervangen.
• Prompt- en configuratiewijzigingen verlopen via het proces wijzigingsverzoeken (hoofdstuk 6).

Het gekozen SLA-pakket in combinatie met de onderstaande SLA-prioriteit bepaalt de oplostijden voor de installatie van uitgebrachte security patches.