AI voor telecomproviders: 3 praktische toepassingen bij storingen, support en meldplicht

Een storing bij een telecomprovider raakt in twee uur tijd soms meer klanten dan een gemiddeld bedrijf in een heel jaar aan support-tickets krijgt, en elke minuut vertraging in de communicatie vult je wachtrij verder. AI voor telecomproviders draait daarom niet om een chatbot die alles overneemt, maar om drie concrete taken: een storingsupdate opstellen zodra monitoring de feiten heeft, klantenservice- en supportvragen voorsorteren tijdens een piek, en het feitenrelaas voor een meldplichtig incident structureren. Bij SK Telecom draait dat al mee in de dagelijkse praktijk: de telecomprovider gebruikt Claude voor realtime ondersteuning van agents tijdens een gesprek en voor automatische gespreksverslagen na afloop, met menselijke controle als vast onderdeel van het ontwerp. Wil je met je eigen supportteam in kaart brengen welke van deze drie taken bij jullie het meeste tijd teruggeeft, dan is een AI-werksessie de eerste stap.

Wat AI voor telecomproviders vandaag al goed doet

Telecom heeft twee kenmerken die de inzet van AI anders maken dan bij de meeste sectoren: een storing kan in twintig minuten tijd honderden meldingen opleveren bij een vraagstroom die normaal tien per uur is, en de sector valt als digitale infrastructuur onder een eigen meldplicht naast de gewone AVG-regels. Gebruik AI daarom voor taken waar snelheid en volume de bottleneck zijn en feitelijke juistheid het enige is dat telt: een feitenstaat omzetten naar een leesbare update of een gestructureerd overzicht. Gebruik het niet voor de beoordeling van wat die feiten betekenen, zoals een oorzaak, een oplostijd of een significantie-classificatie: dat blijft mensenwerk, met als reden steeds dezelfde, zie de valkuil hieronder. Drie taken zijn rijp voor de eerste categorie.

Toepassing 1: een storingsupdate razendsnel en feitelijk opstellen

De taak: zodra monitoring een storing signaleert, moet er binnen enkele minuten een tekst staan op de statuspagina en in de pushmelding: wat is er aan de hand, wie heeft er last van, wanneer volgt de volgende update. Normaal loopt dat via overleg tussen netwerkbeheer, klantenservice en soms communicatie, en dat kost precies de tijd die je niet hebt als de wachtrij al volloopt.

Hoe AI helpt: je voert de monitoringgegevens in (welke regio, welke dienst, sinds wanneer, aantal gemelde storingen) en laat AI daar een klantvriendelijke update van maken, met een format dat je vooraf hebt vastgelegd. Dat werkt omdat het een vertaaltaak is: technische logregels omzetten naar een zin die een klant zonder technische achtergrond begrijpt. Het werkt niet voor de oorzaak: AI kent het monitoringdashboard niet verder dan wat je erin zet, en vult een ontbrekende oorzaak net zo makkelijk aan met een plausibel klinkende gok als met niets. Wat je mag verwachten: een eerste conceptupdate binnen een minuut in plaats van de tien tot vijftien minuten die een overleg tussen twee of drie afdelingen kost, maar altijd een menselijke check op het enige dat telt bij een storing, de feiten kloppen en de oorzaak wordt niet verzonnen.

Een voorbeeld: de storingsupdate, de prompt en waar het misgaat

Het volgende voorbeeld is een geconstrueerde, fictieve casus, opgebouwd op het mechanisme hierboven. ConnectNL (fictieve naam) ziet op een donderdagmiddag een piek in storingsmeldingen voor mobiel dataverkeer in de regio Utrecht: binnen twintig minuten komen er 340 meldingen binnen, tegenover een normale vijf tot tien per uur.

#CONTEXT: Je bent communicatiemedewerker bij een telecomprovider. Je
krijgt monitoringgegevens van een storing en moet daar een update van
maken voor de statuspagina en een pushmelding.

#DOEL: Een korte, feitelijke update die klanten geruststelt zonder iets
te beweren wat nog niet bevestigd is.

#WERKWIJZE:
1. Vraag mij om: regio, getroffen dienst, starttijd, aantal meldingen,
   en of de oorzaak al bevestigd is.
2. Schrijf een update van maximaal 60 woorden: wat is getroffen, sinds
   wanneer, wanneer volgt de volgende update.
3. Schrijf een losse, kortere pushmelding van maximaal 25 woorden.

#BELANGRIJKE REGELS:
- Noem nooit een oorzaak die ik niet expliciet als "bevestigd" heb
  aangemerkt.
- Noem nooit een oplostijd, alleen het moment van de volgende update.

Wat AI teruggeeft, een geconstrueerd maar geloofwaardig fragment:

Statuspagina-update, 15.42 uur:
We zien sinds 15.20 uur een storing in het mobiele dataverkeer in de
regio Utrecht. Vermoedelijk is dit het gevolg van de drukte door het
warme weer vandaag. We werken aan een oplossing en verwachten dit
rond 17.00 uur verholpen te hebben. Excuses voor het ongemak.

Pushmelding:
Storing mobiel internet regio Utrecht sinds 15.20 uur. Vermoedelijk
door de warmte. Update volgt om 16.30 uur.

De lengte en toon kloppen, en de structuur volgt het format precies. Het probleem staat in twee plekken: "vermoedelijk door de warmte" is een oorzaak die niemand heeft bevestigd (je gaf AI alleen het aantal meldingen, geen diagnose van een engineer), en "rond 17.00 uur verholpen" is een oplostijd die je prompt juist verbood. Het model kreeg de instructie om nooit een oplostijd te noemen en deed het toch, verstopt in de zin over wanneer het probleem verholpen is in plaats van wanneer de volgende update komt. Wat je repareert voordat dit de deur uit mag: schrap de oorzaak-zin volledig (vervang door "we onderzoeken de oorzaak"), en vervang "verholpen om 17.00 uur" door "volgende update om 16.30 uur". Dat kost een communicatiemedewerker vijftien tot dertig seconden lezen en corrigeren, tegenover de tien tot vijftien minuten die een telefonisch overleg tussen netwerkbeheer en klantenservice normaal kost.

Toepassing 2: AI klantenservice tijdens piekmomenten voorsorteren

De taak: tijdens een storing, een facturatieronde of een wijziging in abonnementsvoorwaarden stroomt de normale vraagstroom over. Een medewerker moet per vraag bepalen waar die over gaat, hoe urgent hij is, en wat het antwoord is, vaak terwijl de wachtrij al oploopt.

Hoe AI helpt: tijdens een telefoongesprek kan AI in realtime meezoeken in documentatie en relevante informatie aandragen, en na een gesprek automatisch een samenvatting, onderwerpclassificatie en actiepunten opstellen die een medewerker alleen nog controleert. SK Telecom (27 jaar op nummer 1 in de Koreaanse klanttevredenheidsindex) zet dit precies zo in: realtime ondersteuning tijdens het gesprek plus geautomatiseerde verwerking erna, met een menselijke controle op elk resultaat, meldt het klantverhaal van SKT. Dat werkt omdat meezoeken tijdens een gesprek en samenvatten na een gesprek beide ondersteunende taken zijn: het model levert aan, de agent beslist. Het werkt niet vanzelf: SKT's eigen cijfers laten zien dat de kwaliteit van automatische antwoorden met 34 procent steeg zodra agents realtime ondersteuning kregen, maar dat de kwaliteit van automatische samenvattingen op ongeveer 89 procent van het niveau van een menselijke agent ligt, dus net onder honderd. Verwacht dus winst bij elk gesprek, maar geen samenvatting die je ongezien doorstuurt naar een dossier met rechtsgevolg, zoals een klacht die tot een vergoeding kan leiden.

De grootste kwaliteitssprong kwam overigens niet van het taalmodel zelf. SKT's eigen Telco-model gaf na een koppeling met hun interne kennisbank (retrieval augmented generation, RAG) een beoordelingsscore die van 3,3 naar boven de 4,3 steeg, en het aandeel zwakke antwoorden daalde met 68 procent. Een AI-agent zonder koppeling aan je eigen klant- en abonnementsgegevens presteert dus merkbaar zwakker dan dezelfde technologie met die koppeling erbij. Hetzelfde onderscheid, een juist verstaan woord tegenover een juist besluit, is ook de kern van AI voice agent voor je telefoon.

Toepassing 3: het feitenrelaas voor een meldplichtig NIS2-incident voorbereiden

De taak: een storing of beveiligingsincident dat mogelijk "significant" is, moet in drie stappen gemeld worden: een vroegtijdige waarschuwing binnen 24 uur, een melding binnen 72 uur met een eerste inschatting van de ernst, en een eindverslag binnen 1 maand met de oorzaak en de genomen maatregelen, meldt de officiële meldplicht-pagina van het NCSC. Voor elke stap moet er een feitenrelaas liggen: wanneer gedetecteerd, welke diensten en hoeveel klanten getroffen, welke stappen al gezet zijn.

Hoe AI helpt: uit een stapel monitoringlogs, supporttickets en interne chatberichten kan AI per meldstap een chronologisch feitenoverzicht samenstellen, met tijdstip, betrokken systeem en bron per regel, in het format dat die stap nodig heeft (de vroegtijdige waarschuwing vraagt alleen of het incident vermoedelijk kwaadwillig is en of er grensoverschrijdende gevolgen zijn, het eindverslag vraagt de volledige oorzaak). Dat werkt omdat het een extractietaak is: veel losse regels samenvoegen tot één leesbare tijdlijn per stap, zonder dat er een inhoudelijk oordeel bij nodig is. Het werkt niet voor de beoordeling zelf: of een incident "significant" genoeg is om te melden, is een juridische inschatting met gevolgen voor de instelling, geen tekstualiseringstaak, en die inschatting hoort bij een compliance- of securityfunctionaris. Ondernemersplein (RVO) noemt "aanbieders van openbare elektronische communicatienetwerken" en "aanbieders van openbare elektronische communicatiediensten" expliciet bij de micro- en kleinbedrijven die automatisch onder de Cyberbeveiligingswet vallen, zonder de omzet- of personeelsdrempel die voor andere sectoren wel geldt. Voor de volledige uitleg van de zorgplicht en registratieplicht verwijzen we naar AI voor energiebedrijven, zodat we die hier niet dubbel opbouwen.

Wat je mag verwachten: een eerste feitenrelaas voor de vroegtijdige waarschuwing binnen een kwartier in plaats van de uren die het kost om losse logs uit drie systemen handmatig op een rij te zetten, maar nooit een conceptmelding die zelf al een woord als "significant" of "ernstig" gebruikt, of een oorzaak claimt voordat het eindverslag daar is. Dat label zet je er zelf op, met een naam en een datum erbij, niet het model.

Een voorbeeld: drie logregels en het feitenrelaas

Ook dit is een geconstrueerd, fictief voorbeeld, op hetzelfde mechanisme. Drie logregels van de ConnectNL-storing: "15.20 eerste melding mobiel dataverkeer regio Utrecht", "15.35 piek van 340 meldingen in twintig minuten" en "16.10 engineer bevestigt: overbelaste antennemast na onderhoudswerk, geen externe aanval". Gevraagd om daar een feitenrelaas voor de vroegtijdige waarschuwing van te maken, schrijft AI: "Incident gestart 15.20 uur, regio Utrecht, mobiel dataverkeer. 340 meldingen binnen twintig minuten, vermoedelijk kwaadwillig gezien de snelheid van de piek." Het probleem: "vermoedelijk kwaadwillig" is een eigen gevolgtrekking op basis van alleen het aantal meldingen, terwijl de derde logregel al een niet-kwaadwillige oorzaak bevestigt die het model niet heeft meegewogen. De reparatie: vervang de gevolgtrekking door "kwaadwillig: nee, bevestigd door engineer 16.10 uur". Dat kost een compliance-medewerker een halve minuut lezen tegenover de tien tot twintig minuten die het kost om dezelfde regels zelf uit het logsysteem te halen.

AI voor telecomproviders: een beslisregel voor storingen, support en meldingen

Waar AI voor telecomproviders misgaat: de ETA die nog niet vaststaat

De drie toepassingen hierboven delen één risico: een AI-tekst die een oorzaak, een oplostijd of een classificatie ("significant") claimt die nog niet bevestigd is, leest voor een klant of een toezichthouder als een feit, terwijl het een gok is die ergens in het proces is binnengeslopen. Bij storingscommunicatie is dat risico het grootst omdat de tekst direct naar duizenden klanten gaat: zoals in het voorbeeld hierboven, schrijft een model dat om een update van 60 woorden gevraagd wordt bijna automatisch ook een verklaring en een eindtijd erbij, ook als je dat met een regel verbiedt. Bij het feitenrelaas voor een meldplichtig incident ligt het risico net zo scherp, alleen is de schade daar niet een boze klant maar een voorbarige kwalificatie die een compliance-afdeling later moet terugdraaien. Dezelfde remedie werkt voor allebei: geef AI nooit de vrijheid om een conclusie, oorzaak of classificatie toe te voegen die niet letterlijk in de input stond, en controleer daar expliciet op voordat een tekst de deur uit mag.

Wat het oplevert, en hoe je dat na zeven dagen meet

Wat na een week beter wordt: de tijd tussen het eerste signaal van een storing en de eerste klantgerichte update, en het aandeel standaardvragen dat zonder wachttijd wordt beantwoord. Wat niet beter wordt: de kwaliteit van een gok over de oorzaak, en het vertrouwen dat een samenvatting zonder controle een dossier met rechtsgevolg mag voeden.

Meet het met drie getallen, zonder extra tooling:

• Hoeveel keer bevatte een AI-conceptupdate een oorzaak of oplostijd die nog niet bevestigd was? Dat moet nul zijn. Elke keer dat het wel gebeurt, zoals in het voorbeeld hierboven, is een signaal om de instructie in je prompt aan te scherpen.
• Welk deel van de supportvragen tijdens een piek werd correct doorgezet naar een mens? Anthropics eigen richtwaarde voor escalatie-nauwkeurigheid ligt op 95 procent of hoger. Kom je daar structureel onder, dan is je classificatie-instructie het probleem, niet de taak zelf.
• Hoeveel AI-samenvattingen van een supportgesprek zijn ongewijzigd in een dossier met rechtsgevolg terechtgekomen, zonder dat een medewerker ze heeft gecontroleerd? Dat moet nul zijn, precies om de reden die bij toepassing 2 staat: een samenvatting op 89 procent van menselijk niveau is geen honderd procent.

Privacy en regelgeving: AI, de AVG en de meldplicht voor telecomproviders

Een supportgesprek, een storingsmelding en een klantdossier bevatten persoonsgegevens: naam, adres, accountnummer, en soms locatiegegevens van een mobiel apparaat. Zet die nooit in een gratis consumentenversie van een AI-tool. Regel een zakelijk account met een verwerkersovereenkomst waarin modeltraining op je data is uitgesloten, zoals toegelicht in ChatGPT veilig en volgens de AVG gebruiken.

Daarnaast gelden voor telecomproviders twee lagen die niet voor elk bedrijf gelden. Ondernemersplein (RVO) noemt aanbieders van openbare elektronische communicatienetwerken en -diensten expliciet als sector die automatisch onder de Cyberbeveiligingswet valt, zonder omzet- of personeelsdrempel. Een melding van een significant incident doe je via het centrale meldpunt op MijnNCSC, waarmee je in één keer je sectorale CSIRT en de toezichthouder bereikt, meldt het NCSC. Los daarvan kende de sector via Agentschap Telecom, nu de Rijksinspectie Digitale Infrastructuur (RDI), al langer een eigen continuïteitsmeldplicht voor grote storingen. Voor de zorgplicht en registratieplicht zelf verwijzen we naar AI voor energiebedrijven, uitgewerkt voor een andere sector uit dezelfde bijlage.

Wat AI hier niet goed kan

AI kan een storing niet verhelpen en een incident niet zelf als significant classificeren. Beide blijven, net als bij een juridisch besluit, bij een functie binnen het bedrijf: de netwerkengineer bij de oorzaak, de compliance- of securityfunctionaris bij de meldplicht. AI mist ook per definitie wat er na je laatste instructie veranderd is, zoals een oorzaak die een engineer tien minuten na jouw eerste update wél bevestigt. De drempel uit de meetsectie hierboven (een oorzaak, oplostijd of classificatie die vaker dan incidenteel insluipt) is het signaal dat je promptinstructie het probleem is, niet de taak zelf.

Doe dit deze week

1. Pak je laatste storing of piekmoment erbij

   Zoek de laatste storingsupdate of klantmail die je team daadwerkelijk heeft verstuurd. Daarmee kun je een AI-concept direct naast de echte tekst leggen en zien waar het verschil zit.

2. Gebruik de prompt hierboven, met de guardrail tegen een oorzaak of ETA

   Laat AI alleen een update schrijven op basis van bevestigde feiten. Tel bij de eerste tien concepten hoe vaak er toch een oorzaak of oplostijd insloop, zoals in het voorbeeld hierboven.

3. Leg de beslisregel schriftelijk vast voor je supportteam

   Eén A4: jullie eigen meldingen-per-medewerker-drempel uit de beslisregel hierboven, en wie de melding via MijnNCSC uiteindelijk beoordeelt en ondertekent.

Het recept dat vandaag werkt: bij elke storing of piekmoment vult een medewerker de feiten in de prompt hierboven in, AI levert een conceptupdate zonder oorzaak of ETA, en een engineer of woordvoerder controleert voordat de tekst naar klanten gaat. Wil je dit met je support- of netwerkteam structureel opzetten, inclusief de guardrails voor jouw eigen systemen? In een AI-werksessie bouwt je team dat in één dagdeel voor de eigen processen. Twijfel je waar te beginnen, bekijk de trainingen of plan een kort gesprek.

Bronnen

• Claude (Anthropic), klantverhaal SK Telecom. Zelf geopend. Bron voor de cijfers over in-call assist (34 procent kwaliteitsverbetering), post-call verwerking (circa 89 procent van menselijk niveau), de 68 procent daling in zwakke antwoorden na finetuning, de stijging van 3,3 naar boven 4,3 na RAG-koppeling, en de 27 jaar nummer 1 in de Koreaanse klanttevredenheidsindex.
• Anthropic, implementatiegids voor een klantenservice-agent met Claude. Zelf geopend. Bron voor de richtwaarden van 70 tot 80 procent deflectie en 95 procent of hoger escalatie-nauwkeurigheid, en voor de guardrails tegen hallucinatie en out-of-scope-vragen.
• Rijksdienst voor Ondernemend Nederland (RVO), via Ondernemersplein, NIS2-richtlijn beschermt netwerk en informatiesystemen tegen cyberbeveiligingsrisico's. Zelf geopend via DataforSEO's on_page_content_parsing-tool nadat WebFetch door de blokkade van deze sessie werd geweigerd. Bron voor de ingangsdatum van 15 augustus 2026, voor de expliciete vermelding van aanbieders van openbare elektronische communicatienetwerken en -diensten als sector zonder omzet- of personeelsdrempel, en voor de nog lopende uitwerking van de toezichthouderverdeling per sector.
• Nationaal Cyber Security Centrum (NCSC), meldplicht onder de Cyberbeveiligingswet (NIS2). Zelf geopend via DataforSEO's on_page_content_parsing-tool nadat WebFetch door de blokkade van deze sessie werd geweigerd. Bron voor de drie meldstappen (vroegtijdige waarschuwing binnen 24 uur, melding binnen 72 uur, eindverslag binnen 1 maand) en voor het centrale meldpunt op MijnNCSC.
• Project Impact, AI voor energiebedrijven. Eigen, eerder gepubliceerde en apart gesourcte uitleg van de zorgplicht en registratieplicht onder NIS2, hier gebruikt om dubbele opbouw te voorkomen.

Veelgestelde vragen

• Mag een AI-chatbot zelf een oplostijd (ETA) voor een storing communiceren?

  Nee, niet totdat een engineer die oplostijd heeft bevestigd. AI mag een storingsupdate opstellen op basis van de feiten die je aanlevert, maar vult een ontbrekende oorzaak of oplostijd net zo makkelijk aan met een plausibel klinkende gok als met niets. Schrijf in je prompt expliciet dat AI nooit een oorzaak of oplostijd mag noemen die niet als bevestigd is aangemerkt, en controleer de eerste tien conceptupdates daar handmatig op.

• Valt een telecomprovider onder de meldplicht van NIS2?

  Ja. Ondernemersplein (RVO) noemt aanbieders van openbare elektronische communicatienetwerken en -diensten expliciet als sector die automatisch onder de Cyberbeveiligingswet valt, zonder de omzet- of personeelsdrempel die voor andere sectoren geldt. De meldplicht kent volgens het NCSC drie stappen: een vroegtijdige waarschuwing binnen 24 uur, een melding binnen 72 uur, en een eindverslag binnen 1 maand. Je meldt via het centrale meldpunt op MijnNCSC, dat automatisch je sectorale CSIRT en de toezichthouder bereikt.

• Wat is het verschil tussen een AI-chatbot en AI klantenservice met een agent erbij?

  Een AI-chatbot beantwoordt een vraag direct met wat het model al weet. AI klantenservice met een agent erbij zoekt eerst in je eigen documentatie of klantgegevens voordat hij antwoordt, en kan een supportgesprek samenvatten of classificeren na afloop. SK Telecom zag de grootste kwaliteitssprong pas nadat hun model aan een eigen kennisbank was gekoppeld (retrieval augmented generation), niet door het taalmodel alleen.

• Hoeveel klantvragen kan AI tijdens een storing afvangen?

  Reken op een richtwaarde van 70 tot 80 procent deflectie voor standaardvragen, zoals Anthropics eigen implementatiegids voor klantenservice-agents noemt. Bij een storing met een nog onbevestigde oorzaak ligt dat percentage lager, omdat de vraag "wat is er aan de hand" dan juist geen standaardvraag is. Combineer dit daarom altijd met een escalatie-nauwkeurigheid van 95 procent of hoger, zodat vragen die een mens nodig hebben ook echt bij een mens terechtkomen.

• Mag je klantgegevens van een storing of supportgesprek in een gratis AI-tool plakken?

  Nee. Een supportgesprek of storingsmelding bevat persoonsgegevens zoals naam, adres, accountnummer en soms locatiegegevens van een mobiel apparaat. Gebruik een zakelijk account met een verwerkersovereenkomst waarin modeltraining op je data is uitgesloten, net als bij elk ander gebruik van AI met klantgegevens.