Monitoring na het in de handel brengen: praktische gids voor SaaS-teams

Monitoring na het in de handel brengen betekent controleren hoe een AI-systeem zich na de release gedraagt en de bevindingen gebruiken om het veilig en conform te houden. Voor SaaS-teams begint dit met een benoemde verantwoordelijke, een vastgelegd monitoringplan, betrouwbare feedback uit werkelijk gebruik en een route van elke belangrijke bevinding naar een besluit. Een dashboard levert pas bruikbaar bewijs wanneer iemand het beoordeelt en handelt naar de uitkomst.

Deze gids gaat over AI-systemen met een hoog risico onder de Europese AI-verordening. De operationele aanbevelingen kunnen ook andere AI-functies helpen, maar daarmee valt niet elk SaaS-product onder artikel 72. De checklists, beoordelingsintervallen en voorbeelden zijn uitvoeringsadviezen, geen verplicht regelgevend sjabloon.

Bepaal toepassingsgebied en actuele planning

Artikel 72 verplicht aanbieders van AI-systemen met een hoog risico om evenredige monitoring na het in de handel brengen in te richten en vast te leggen. Het omvat systematische verzameling en analyse van relevante prestatiegegevens gedurende de hele levensduur, inclusief relevante interacties met andere AI-systemen. Het doel is de voortdurende naleving van de eisen voor systemen met een hoog risico te beoordelen. AI-verordening, artikel 72.

Begin bij het beoogde doel, de risicoclassificatie en de rol van uw onderneming. Een applicatie onder eigen naam aanbieden, een gekocht systeem gebruiken en een AI-model voor algemene doeleinden leveren zijn verschillende situaties. Laat de juridisch verantwoordelijke rol en toepasselijke bepalingen bevestigen, inclusief overgangsregels voor bestaande systemen, voordat u het programma als wettelijke verplichting presenteert.

Op 13 september 2026 noemt de Commissie 2 december 2027 als toepassingsdatum voor de hoogrisicoregels van bijlage III en 2 augustus 2028 voor AI met een hoog risico in producten uit bijlage I. Deze aangepaste mijlpalen volgen op de inwerkingtreding van de AI-omnibus op 27 juli 2026. Ze stellen niet alle AI-verplichtingen in algemene zin uit. Actualisering van de Commissie.

Het gewijzigde artikel 72, lid 3, verlangt een monitoringplan en stelt 2 september 2027 als deadline voor richtsnoeren van de Commissie, inclusief een sjabloon. Presenteer de oorspronkelijke deadline van februari 2026 voor een uitvoeringshandeling niet als de huidige situatie. Verordening (EU) 2026/1744, artikel 1, punt 30.

Bewaar bij het plan een gedateerde toepasselijkheidsnotitie. Noteer systeemversie, onderbouwing, relevante data, beoordelaar en aanleiding voor herbeoordeling. Heropen de notitie als doel, markt of productverantwoordelijkheden wijzigen. Een duidelijke afbakening voorkomt dat het team een ongefundeerde belofte van volledige naleving voor elke functie overneemt.

Verbind monitoring door de aanbieder met klantfeedback

Een aanbieder ziet mogelijk servicetelemetrie, terwijl klanten de gevolgen van individuele uitkomsten zien. Ontwerp een feedbackroute die beide perspectieven verbindt. Vraag klantgerichte teams om voldoende context om productfouten, ongeschikte invoer, configuratieproblemen en gebruik buiten het vastgelegde doel te onderscheiden.

Gebruiksverantwoordelijken hebben volgens artikel 26, lid 5, een afzonderlijke operationele monitoringplicht, waaronder relevante communicatie aan aanbieders en escalatie van bepaalde risico’s en ernstige incidenten. Het plan van de aanbieder vervangt die verantwoordelijkheid niet. AI-verordening, artikel 26.

Spreek af wie klachten ontvangt, hoe klanten de betrokken versie identificeren en wie aanvullende informatie kan opvragen. Zorg voor een urgente route buiten reguliere klantbesprekingen. Als de klant het systeem host en u geen productiegegevens kunt bekijken, leg die beperking vast en spreek alternatief bewijs af, zoals geaggregeerde bevindingen, gecontroleerde reproducties of evaluaties door de klant.

Zie voor de organisatorische context de Engelstalige gidsen over verwachtingen rond AI-governance voor SaaS-aanbieders en het toewijzen van complianceverantwoordelijkheden.

Maak een uitvoerbaar plan

Begin met een kort plan voor één duidelijk afgebakend systeem. Verwijs naar bestaande ontwikkel-, support-, beveiligings- en risicodossiers in plaats van bewijs te dupliceren. Deze velden vormen een praktisch begin:

• Systeemgrens: beoogd doel, betrokken gebruikers, ondersteunde configuraties, releases en verbonden AI-componenten.
• Verantwoordelijkheid: planeigenaar, technisch beoordelaar, juridisch escalatiecontact en vervanger.
• Signalen: evaluaties, klachten, menselijke correcties, servicestoringen, leveranciersmeldingen en bekende blinde vlekken.
• Methoden: steekproeven, vergelijkingsbasis, beoordelingsfrequentie en beperkingen van elke meting.
• Besluiten: drempels voor onderzoek, beperkingen, terugdraaien van releases, klantcommunicatie en escalatie naar de directie.
• Bewijs: opslagplaatsen voor bevindingen, goedkeuringen, corrigerende maatregelen en nacontroles.
• Wijzigingsaanleidingen: nieuwe modellen, prompts, gegevensbronnen, integraties, klantgroepen en gebruiksdoelen.

Wijs elk signaal aan iemand toe. Een gedeelde inbox zonder verantwoordelijke beoordelaar kan meldingen verzamelen terwijl iedereen denkt dat een ander ze behandelt. In kleine bedrijven kan één persoon meerdere rollen vervullen. Het plan moet toch onderscheiden wie onderzoekt, wie restrisico accepteert en wie voortzetting goedkeurt.

Test het plan met een recente supportklacht. Kan de beoordelaar de release identificeren, de vergelijkingsbasis vinden, de juiste ontwikkelaar bereiken en een besluit vastleggen zonder privéberichten door te zoeken? Zo niet, verbeter eerst de overdracht voordat u meer meetwaarden toevoegt.

Kies signalen die een besluit kunnen veranderen

Begin met de faalscenario’s uit de risicobeoordeling. Vraag per scenario welk waarneembaar bewijs op een verzwakkende beheersmaatregel zou wijzen. Beschikbaarheid en reactietijd kunnen relevant zijn, maar tonen niet aan dat uitkomsten geschikt blijven voor het beoogde doel.

Bruikbare kandidaten zijn onjuiste uitkomsten in beoordeelde steekproeven, ontbrekende escalatie van onzekere gevallen, onverwachte veranderingen in menselijke correcties, klachten over terugkerende uitsluiting en fouten na een update bij een achterliggende leverancier. Vergelijk relevante gebruikscontexten waar dit zinvol en rechtmatig is. Een ontbrekende of zeer kleine steekproef is een beperking, geen bewijs van gelijkwaardige prestaties.

Leg vast hoe elke indicator wordt berekend en welke populatie hij dekt. Het wekelijkse foutpercentage kan dalen doordat het product verbetert, moeilijke gevallen uit de steekproef verdwijnen of de gegevensverzameling stukgaat. Voeg informatie over verkeer, configuratie en meetdekking toe aan numerieke veranderingen.

Onderbouw alarmdrempels schriftelijk. Een voorbeeldregel kan onderzoek openen als een release herhaaldelijk faalt in een kritisch evaluatiescenario. Dat is een interne beslisregel, geen wettelijke numerieke grens. Wijs iemand aan om valse alarmen en gemiste detecties te beoordelen, zodat ook de monitoring verbetert.

Verzamel niet standaard volledige klantgesprekken. Bepaal samen met privacy- en beveiligingsverantwoordelijken de minimaal benodigde informatie, toegangsbeperkingen en passende bewaartermijnen per bewijstype. Gebruik waar mogelijk een dossiernummer met afgeschermd ondersteunend materiaal in plaats van gevoelige inhoud naar meerdere tickets en dashboards te kopiëren.

Bepaal beoordelingsritmes en wijzigingstriggers

Scheid directe waarschuwingen, routineanalyse en periodieke managementbeoordeling. Een team kan urgente signalen bij binnenkomst beoordelen, trends wekelijks bekijken en het plan maandelijks herzien tijdens een eerste uitrol. Dit zijn voorgestelde startintervallen; kies een ritme op basis van risico’s en veranderingssnelheid.

Elke release moet aangeven welke aannames mogelijk zijn veranderd. Nieuwe zoekbronnen, modelroutering, rechten, talen en klantgroepen kunnen gedrag veranderen zonder de interface te wijzigen. Leg vooraf een uitgangsmeting vast, bepaal de observatieperiode en welk bewijs een uitrolpauze zou rechtvaardigen.

Neem leveranciersupdates hierin mee. Bepaal wie berichten ontvangt, hoe versies herkenbaar zijn en wat er gebeurt als een achterliggende dienst zonder vastgezette versie verandert. Leg bij beperkte waarneembaarheid aanvullende controles en resterende onzekerheid vast in plaats van volledige dekking te suggereren.

Zie ook het Engelstalige artikel over hoe AI compliancemonitoring en rapportage verandert. Houd het resultaat kort: wat veranderde, welk bewijs is onderzocht, welk besluit volgde en wie pakt de volgende actie op?

Zet bevindingen om in corrigerende maatregelen

Elke belangrijke bevinding heeft een dossier nodig. Noteer ontdekkingstijd, betrokken release en configuratie, beschikbaar bewijs, mogelijke impact, eerste beheersing, beslisverantwoordelijke en opvolgdeadline. Maak onzekerheid expliciet: een plausibel vermoeden kan snelle actie vereisen voordat de oorzaak bekend is.

Een praktische volgorde is het signaal beoordelen, betrokken gebruikers beschermen, noodzakelijk bewijs bewaren, onderzoeken, een correctie kiezen en het resultaat controleren. Mogelijke acties zijn instructies wijzigen, configuraties beperken, een release terugdraaien, menselijke beoordeling verbeteren of een functie opschorten. Kies op basis van de werkelijke fout en toepasselijke verplichtingen.

Sluit het dossier niet automatisch zodra ontwikkelaars een patch uitrollen. Herhaal het gefaalde scenario, controleer representatief gebruik en leg eventuele nieuwe problemen vast. Werk risicobeoordeling, instructies, monitoringcontroles en releasedocumentatie bij wanneer de bevinding hun aannames verandert.

Leg bij tijdelijk geaccepteerde problemen bereik, goedkeurder, vervaldatum, aanvullende controles en heropeningstrigger vast. Een onbeperkte uitzondering is moeilijk te onderscheiden van een vergeten taak. De volgende beoordelaar moet begrijpen waarom het gebruik doorging en wat dat besluit zou veranderen.

Geef ernstige incidenten een afzonderlijke route

Mogelijke ernstige incidenten vereisen onmiddellijke juridische beoordeling en incidentrespons. Ze mogen niet wachten op de volgende trendbespreking. Artikel 73 bevat meldplichten en verschillende termijnen: een algemene uiterste termijn van 15 dagen, kortere grenzen voor bepaalde gevallen en onmiddellijke meldvereisten afhankelijk van de omstandigheden. Het geeft geen toestemming om standaard 15 dagen te wachten. AI-verordening, artikel 73.

Laat de verantwoordelijke bepalen of de wettelijke definitie is vervuld, welke meldbepalingen gelden, wie bericht moet krijgen en wanneer de termijn begon. Beoordeel ook parallelle verplichtingen onder andere toepasselijke regels en klantcontracten. Houd die besluiten afzonderlijk om te voorkomen dat één melding ten onrechte als afdoende voor alle verplichtingen geldt.

Oefen vóór introductie een urgent scenario. Controleer of het team contacten vindt, bewijs bewaart, gebruik beperkt en een eerste verslag opstelt terwijl feiten nog onvolledig zijn. Leg vast wie tijdkritische besluiten mag nemen wanneer de gebruikelijke verantwoordelijke afwezig is.

Voorbeeld: wervingsapplicatie na een modelupdate

Stel dat een SaaS-aanbieder een applicatie voor kandidatenrangschikking heeft die als hoog risico is beoordeeld. Na een update van een achterliggend model wijzen klachten op inconsistente rangschikking van kandidaten met ongewone loopbanen. De totale beschikbaarheid blijft normaal.

De monitoringverantwoordelijke opent een dossier, identificeert betrokken versies en klanten en vraagt ontwikkelaars het probleem met gecontroleerde voorbeelden te reproduceren. Het team onderzoekt of de evaluatieset deze loopbaanpatronen dekte en of de rangschikking veranderde ten opzichte van de goedgekeurde basis. Juridische en productbeoordelaars onderzoeken mogelijke impact en meldingsimplicaties.

Afhankelijk van de uitkomst kan de aanbieder de uitrol pauzeren, de vorige versie herstellen, functies beperken of extra menselijke beoordeling invoeren. Klantcommunicatie beschrijft het bereik en de tijdelijke maatregelen zonder een nog niet vastgestelde oorzaak te claimen.

Het dossier sluit pas wanneer verificatie de gekozen correctie ondersteunt en de verantwoordelijke het resultaat vastlegt. Het team breidt evaluatiedekking en monitoringtriggers uit waar gerechtvaardigd. Dit voorbeeld toont een werkwijze; niet elke inconsistente rangschikking is daarmee een wettelijk meldingsplichtig ernstig incident.

Veelgemaakte fouten

Beschikbaarheid als het hele programma zien. Operationele gezondheid vertelt of de dienst draait. Voeg controles toe voor uitvoerkwaliteit, toezicht en risico’s van het feitelijke doel.

Alleen op klachten wachten. Stille klanten missen misschien een meldkanaal of herkennen een fout niet. Combineer feedback met geplande evaluaties en gerichte navraag.

Een verouderde versie monitoren. Koppel bevindingen aan wijzigingen in model, applicatie, configuratie en bronnen. Een rapport over vorig kwartaal zegt mogelijk weinig over de huidige release.

Bewijs bewaren zonder besluiten. Grafieken verklaren niet waarom het team doorging, beperkte of stopte. Bewaar de redenering en vervolgverificatie.

Volledige zichtbaarheid beloven. Benoem ontbrekende klantgegevens, ontoegankelijke leveranciersdetails en steekproefgrenzen. Leg uit wat dit betekent voor zekerheid en besluiten.

Vragen uit teams

Wat is het praktische doel van monitoring na het in de handel brengen?

Ontdekken wanneer werkelijk gebruik eerdere aannames uitdaagt en dat bewijs omzetten in beoordeelde actie. De operationele uitkomst is een verdedigbaar besluit met gecontroleerde opvolging, ondersteund door traceerbare bevindingen.

Heeft elk SaaS-bedrijf een plan volgens artikel 72 nodig?

Ga daar niet van uit. Bevestig hoogrisicoclassificatie, aanbiedersrol, bereik en toepassingsdatum. Andere systemen kunnen baat hebben bij evenredige monitoring; gebruiksverantwoordelijken moeten hun eigen verantwoordelijkheden afzonderlijk beoordelen.

Wat leggen we eerst vast?

Begin met de grenzen van één systeem, de verantwoordelijke, belangrijkste faalscenario’s, beschikbare signalen en urgente escalatieroute. Behandel een echte bevinding voordat u het proces over het productportfolio uitbreidt.

Welk bewijs hoort een beoordeling op te leveren?

Bewaar planversie, beoordeeld bewijs, dekkingsbeperkingen, besluit, actieverantwoordelijke en verificatieresultaat. Een beoordelaar moet de route van signaal tot afsluiting kunnen volgen zonder het teamgeheugen te reconstrueren.

Bronnen

De juridische bespreking gebruikt de geconsolideerde AI-verordening, de AI-omnibuswijziging en de Commissiebronnen bij de relevante beweringen. Juridische stand gecontroleerd op 13 september 2026. Operationele voorbeelden en voorgestelde ritmes zijn redactionele aanbevelingen.

Afbeelding: Team Meeting door woodleywonderworks, CC BY 2.0, via Wikimedia Commons; verkleind tot 1280 × 482 pixels.