AI voor ICT-bedrijven: 3 praktische toepassingen voor support, documentatie en offertes

Je developers zitten allang met Claude Code of Copilot te programmeren. Wat nog grotendeels met de hand gaat, is de bedrijfskant eromheen: de supportinbox, de documentatie die achter de laatste release aanloopt, en de offerte die iemand 's avonds nog moet schrijven. Nederland telde in 2025 ruim 106.000 ICT-bedrijven, het grootste deel daarvan dienstverlening: support, implementatie, maatwerk. Elk uur dat daar naar herhaalwerk gaat, gaat niet naar een nieuw project. Een AI-agent kan dat herhaalwerk voor een groot deel overnemen, met één harde grens: bij een technisch detail dat een klant letterlijk gaat uitvoeren, mag AI nooit zonder controle het laatste woord hebben. Hieronder drie toepassingen van AI voor ICT-bedrijven om deze week mee te starten, een uitgewerkt voorbeeld per toepassing met de fout erin, en de plek waar een vage offerte je later geld kost.

Waarom AI voor ICT-bedrijven nu relevant is

De meeste ICT-dienstverleners draaien op een schaars goed: factureerbare uren van mensen die ook de techniek snappen. Support, documentatie en offertes concurreren allemaal met projectwerk om diezelfde uren, en verliezen meestal, want een klant die wacht voelt urgenter dan een documentatiepagina die "morgen ook nog wel bij te werken is". Het resultaat: documentatie die achterloopt en een supportteam dat dezelfde vraag voor de twintigste keer beantwoordt. Precies die herhaling maakt AI hier sterk (een nieuwe supportvraag lijkt op tien eerdere, een documentatiewijziging volgt uit een changelog-regel), en diezelfde herhaling is de zwakte: bij twijfel vult een taalmodel het patroon in dat het vaker zag, niet het detail dat voor jouw systeem klopt.

De 3 praktische toepassingen van AI voor ICT-bedrijven deze week

Kies er één om mee te starten. Neem de taak die deze week de meeste avonduren kost.

1. Supporttickets: van vraag naar conceptantwoord

De taak: een binnenkomende technische supportvraag beantwoorden, met de juiste feiten uit je eigen documentatie en changelog, niet uit het gemiddelde van wat een taalmodel over vergelijkbare systemen heeft gezien.

Hoe AI helpt: je geeft de vraag, de relevante documentatie en de recente changelog mee, en AI stelt een conceptantwoord op. Dat werkt omdat een supportinbox grotendeels uit variaties op bekende vragen bestaat. Verwacht een concept binnen een minuut, tegen tien tot twintig minuten uitzoeken en typen. Niet doen zonder de exacte documentatie erbij: zonder bron valt AI terug op wat vergelijkbare systemen doorgaans doen, en dat hoeft niet te kloppen voor het jouwe.

Een voorbeeld. Een klant van een boekingssysteem voor klinieken meldt:

Van: dev@voorbeeldkliniek.nl
Onderwerp: 429 Too Many Requests op /v2/bookings sinds gisteren

Sinds gisteren 14:00 krijgen we structureel 429's op onze nachtelijke
sync naar /v2/bookings. Dit liep een maand geleden op hetzelfde volume
al zonder problemen. Is de rate limit aan jullie kant veranderd? We
draaien nu een retry-loop maar die vult onze logs.

De prompt:

#CONTEXT: Je bent supportengineer bij een softwareleverancier van
boekingssoftware. De klant is zelf developer en leest dit antwoord
tussen twee debug-sessies door. Hij wil weten: is dit aan onze kant
veranderd, en wat moet hij nu doen.

#WERKWIJZE:
1. Vat het probleem samen in eigen woorden.
2. Zoek in de meegegeven changelog naar wijzigingen rond de genoemde
   datum en tijd.
3. Vind je niets, zeg dat expliciet. Verzin geen wijziging.

#BELANGRIJKE REGELS:
- Noem geen limietwaarde, headernaam of foutcode die niet letterlijk
  in de meegegeven documentatie of changelog staat. Zet
  [CONTROLEREN BIJ ENGINEERING] neer als iets ontbreekt.
- Beloof geen tijdlijn voor een fix zonder die van engineering.

#BEPERKINGEN: Zet het concept klaar. Verstuur niets.

Wat er realistisch terugkomt:

Bedankt voor je melding! De rate limit op /v2/bookings staat op 60
requests per minuut per API-key. Jullie nachtelijke sync overschrijdt
dat waarschijnlijk. Voeg een X-RateLimit-Retry header toe en verhoog
het interval tussen calls naar 2 seconden, dan zou het probleem
opgelost moeten zijn.

Klinkt overtuigend, klopt niet. Het getal "60 requests per minuut" en de header "X-RateLimit-Retry" staan nergens in de meegegeven documentatie: het model heeft ze niet gevonden, maar wel geleverd, omdat een limiet van rond de zestig per minuut een gangbaar patroon is bij vergelijkbare API's. Erger nog: de AI concludeert "waarschijnlijk" zonder te bevestigen of er echt iets veranderd is, terwijl de klant precies dát vroeg.

Wat je repareert voor je verstuurt: de engineer checkt de changelog en vindt dat er gisteren om 14:00 wél een wijziging was, alleen een andere dan de AI verzon: een load balancer-update die verkeer nu per IP-adres beperkt tot 40 requests per minuut, in plaats van per API-key. Het gerepareerde antwoord: "Bevestigd: we hebben gisteren om 14:00 een wijziging doorgevoerd in de load balancer die verkeer nu per IP-adres beperkt tot 40 requests per minuut. Jullie sync draait vanaf één server-IP, dat verklaart de 429's die eerder niet optraden. Twee opties: verspreid de calls met een interval van 2 seconden, of vraag een uitzondering aan voor jullie IP." Dat kost een paar minuten changelog checken, tegen een klant die een niet-bestaande header implementeert en daarna weer terugschrijft dat het nog steeds niet werkt.

2. Documentatie en runbooks actueel houden

De taak: je documentatie laten meebewegen met elke release, zodat de tekst beschrijft wat het systeem nu doet, niet wat het twee releases geleden deed.

Hoe AI helpt: je geeft de wijziging (een changelog-regel of een git diff) en de bestaande documentatiepagina mee, en AI stelt de aangepaste sectie voor. Dat werkt omdat het een vergelijkingstaak is: oude tekst naast nieuwe informatie leggen, precies waar taalmodellen goed in zijn. Verwacht een conceptwijziging in een paar minuten tegen twintig tot dertig minuten zelf herschrijven. Niet doen voor tekst die uitlegt waarom een keuze is gemaakt (architectuur, trade-offs): AI was niet bij dat gesprek en verzint een plausibele reden als je erom vraagt.

Een voorbeeld. Changelog-regel: "Release 4.12.3 (19 september 2026): endpoint /v2/bookings/ geeft nu cancelled_by_customer of cancelled_by_provider terug in plaats van cancelled." Bestaande documentatietekst: "status: kan zijn 'confirmed', 'pending' of 'cancelled'." Prompt: werk deze sectie bij op basis van de changelog, in dezelfde toon en structuur, en benoem het als breaking change als dat van toepassing is.

Wat er realistisch terugkomt: "status: kan zijn 'confirmed', 'pending', 'cancelled_by_customer' of 'cancelled_by_provider'." Dat klopt, maar twee dingen ontbreken. De AI markeert het niet als breaking change, terwijl elke klant die nu op 'cancelled' filtert vanaf deze release niets meer terugkrijgt. En drie codevoorbeelden verderop op dezelfde pagina, die nog los 'cancelled' gebruiken, blijven ongewijzigd: die stonden niet in de changelog-regel, dus het model ziet geen aanleiding ze aan te passen. Het werkt de plek bij waar je expliciet om vroeg, niet de hele pagina.

Wat je repareert: een waarschuwing voor breaking change bovenaan de sectie, de drie codevoorbeelden verderop bijwerken, en een migratiezin voor klanten die nog op de oude waarde filteren. Dat kost vijf minuten controleren van de hele pagina, tegen een supportticket per klant die de wijziging mist.

3. Offerte-scope voor een IT-project

De taak: een intakegesprek omzetten in de scope-tekst van een offerte, zonder dat de tekst zo vaag wordt dat je later niet meer kunt bijfactureren.

Hoe AI helpt: je geeft de intakenotities mee en laat AI er een gestructureerde scope-tekst van maken. Dat werkt voor de vaste onderdelen: adres, leveringsvoorwaarden, standaardtekst uit je sjabloon. Verwacht daar een compleet concept in een paar minuten, tegen een half uur zelf structureren. Het wordt lastig bij de functionele omschrijving, om een reden die in de ICT-contractenpraktijk breed bekend is en niets met AI te maken heeft: bij een vaste prijs mag je iets wat je "vergat" in de offerte niet meer als meerwerk factureren, want je had het als leverancier moeten voorzien. Een taalmodel schrijft van nature brede, geruststellende taal ("een modern, gebruiksvriendelijk portaal, klaar voor toekomstige uitbreidingen"), en dat is precies de vaagheid die je later geld kost. Reken voor het scherper maken van die functionele omschrijving op vijftien tot dertig minuten technische controle, niet op een kant-en-klare tekst.

Een voorbeeld. Intakenotitie: "Klant wil een klantportaal waarin klanten hun facturen kunnen inzien en downloaden." AI-concept: "Een modern, gebruiksvriendelijk klantportaal met facturenoverzicht, downloadfunctie en een intuïtieve zoekfunctie, volledig responsive en klaar voor toekomstige uitbreidingen." Leest goed, belooft te veel: geen woord over hoeveel gebruikersrollen, of facturen ouder dan twee jaar ook zichtbaar zijn, of inloggen via e-mail of ook via een Microsoft-account moet, en welk exportformaat. Vraagt de klant er drie maanden later één van bij, dan staat er niets in de offerte dat het uitsluit, dus geldt het als impliciet toegezegd.

Wat je repareert: een technisch verantwoordelijke herschrijft de scope met expliciete grenzen: "Facturenoverzicht toont facturen vanaf invoering van het huidige systeem. Login via e-mail en wachtwoord; inloggen met een Microsoft- of Google-account valt buiten deze offerte en wordt op aanvraag als meerwerk aangeboden. Download als PDF; andere exportformaten vallen buiten scope." Dat kost een kwartier scherper formuleren, tegen een discussie over meerwerk die je facturatie vertraagt. Voor de rest van het offerteproces (invulwerk, geldigheidsduur) geldt dezelfde aanpak als in offerte maken met AI.

Support, documentatie of offerte: prompt, workflow of agent?

Neem het lichtste gereedschap dat de klus betrouwbaar klaart. De drempels volgen uit wat handmatig kost, tegenover wat bouwen kost.

Waar AI voor ICT-bedrijven misgaat: een verzonnen technisch detail

Je zag het hierboven twee keer: een niet-bestaand limietgetal, een niet-bestaande header. Het mechanisme is hetzelfde bij elk taalmodel: zonder een hard antwoord in de meegegeven bron valt het terug op het patroon dat het bij vergelijkbare systemen vaker zag, en dat patroon klinkt net zo overtuigend als een feit. GitHub zegt het zelf treffend over Copilot: het product heet Copilot, geen Autopilot, je blijft zelf verantwoordelijk. Ook in agentmodus is het advies expliciet: gebruik het samen met "rigorous functionality testing, code scanning, security testing" en je eigen oordeel, niet als vervanging daarvan. Bij een supportantwoord of documentatie is dat duurder dan bij marketingtekst: een klant voert het detail letterlijk uit, en een verzonnen configuratiewaarde die in productie belandt kan iets breken of een deur openzetten die dicht hoort te zijn.

Waar dit naartoe gaat: de scheiding tussen "AI schrijft een concept" en "een engineer controleert en verstuurt" wordt dunner. GitHub's hoogste Copilot-niveau is al bedoeld voor "sustained, high-volume agent workflows", waarin een agent zelfstandig een pull request opent op basis van een toegewezen taak, precies het patroon dat dit artikel voor support, documentatie en offertes beschrijft. De controlelaag verdwijnt daarbij niet, hij verschuift van elke regel typen naar elk concept beoordelen.

Uit de Stack Overflow Developer Survey 2025: 66% van de ondervraagde developers noemt "AI-antwoorden die bijna goed zijn, maar net niet" hun grootste frustratie, en het vertrouwen in AI-nauwkeurigheid zakte naar 29%, terwijl 84% de tools al gebruikt. Het probleem is dus zelden dat AI evident onzin schrijft; het zit net naast de waarheid, op een manier die je niet in één oogopslag ziet.

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

Wat na een week beter wordt: je prompts kennen de vaste structuur van je documentatie en worden scherper na elke gecorrigeerde fout. Wat niet beter wordt: inschatten of een klant een mens nodig heeft in plaats van een mail, en het navertellen van een architectuurkeuze die niet is opgeschreven. Uit onze trainingen: zes tot zeven van de tien supportconcepten kloppen zonder wijziging.

Drie meetpunten voor een streepjeslijst, zonder tooling:

• Hoeveel supportconcepten verstuurde je ongewijzigd? Onder de helft betekent dat je te weinig documentatie meegeeft in de prompt, niet dat de tool niet werkt.
• Hoe vaak trof je een verzonnen getal, header of foutcode aan? Eén keer op tien is normaal. Vaker: geef AI expliciet minder bronmateriaal tegelijk, dan wordt het patroon dat het invult kleiner.
• Hoelang liep je documentatie achter na een release? Klok het verschil tussen releasedatum en het moment dat de pagina klopt, voor en na. Geen verbetering van minstens een paar dagen? Dan hangt de workflow niet echt aan je releaseproces vast.

Privacy, broncode en geheimhouding: wat plak je niet in een AI-tool?

Broncode, API-sleutels en systeemconfiguratie van een klant zijn meestal geen persoonsgegevens, maar vaak wel een bedrijfsgeheim met een geheimhoudingsclausule erop. Een publieke AI-tool is in dat opzicht een derde partij: wat je erin plakt, staat buiten de kring waarvoor de geheimhouding gold, ongeacht of het onder de AVG valt. Neem daarom een zakelijk abonnement met verwerkersovereenkomst zodra klantdata of klantsystemen in het spel zijn, en zet training op je data uit. Klantgegevens die wél persoonsgegevens zijn (namen, e-mailadressen, IP-adressen) vallen bovendien onder de AVG, met dezelfde basisregels als in onze gids over veilig omgaan met bedrijfsdata in ChatGPT. Bij een ISO 27001-eis in je klantcontract laat je vooraf je informatiebeveiligingsverantwoordelijke beoordelen welke AI-tools daarbinnen passen.

Wat AI hier niet goed kan

Inschatten hoe boos of gestrest een klant is, lukt AI matig: een ticket met drie uitroeptekens krijgt een standaard beleefd antwoord terug, terwijl die klant een telefoontje nodig had. Een architectuurkeuze navertellen die nooit is opgeschreven, kan AI ook niet: het verzint een plausibele reden in plaats van toe te geven dat het niet weet waarom iets ooit zo gebouwd is.

Doe dit deze week

1. Kies één taak: support, documentatie of offerte

   Neem de taak die deze week de meeste avonduren kost. Verzamel tien recente supporttickets, één changelog-regel met bijbehorende documentatiepagina, of één intakegesprek voor een offerte.

2. Draai de supportprompt hierboven op tien echte tickets

   Geef steeds de bijbehorende documentatie of changelog mee. Streep elk getal, elke headernaam en elke foutcode aan die niet letterlijk in die bron staat. Kom je aan meer dan twee van de tien met zo'n verzonnen detail: geef AI kleinere, gerichtere brokken documentatie mee in plaats van de hele pagina.

3. Leg de check-regel schriftelijk vast

   Eén A4: welk type concept altijd langs een engineer gaat (elk concept met een getal, header of foutcode erin), wie dat controleert, en welke informatie nooit in een publieke AI-tool komt.

Het agent-recept dat vandaag werkt: bij elke nieuwe supportticket zoekt een AI-stap eerst de relevante documentatie en changelog op, schrijft een concept met expliciete markering bij elk technisch detail, en legt dat in de wachtrij voor een engineer. Niets gaat de deur uit zonder die klik. Meer van deze promptopbouw staat in de promptbibliotheek; voor AI structureel inbedden in je ontwikkelproces lees je AI integreren in softwareontwikkeling.

Wil je dit met je team goed neerzetten, op jullie eigen documentatie en offertesjabloon? Bouw het in de Agent Sprint, of begin breder met een AI-werksessie. Twijfel je waar te starten, plan een vrijblijvend gesprek.

Bronnen

• GitHub: Copilot-productpagina. "The product is called 'Copilot' not 'Autopilot'" en het advies om AI-suggesties te testen zoals elke externe code, zelf geopend.
• GitHub: Copilot-abonnementen. Citaten over agentwerkstromen ("sustained, high-volume agent workflows", een agent die zelf een pull request opent) en het advies om Copilot te combineren met "rigorous functionality testing, code scanning, security testing" en eigen oordeel, zelf geopend.
• CBS: Digitalisering en kenniseconomie 2025, hoofdstuk ICT en economie. Aantal ICT-bedrijven in Nederland in 2025. Cbs.nl was deze run niet direct te openen door de egress-proxy; het cijfer is kruisverwijsd via WebSearch, niet zelf op de bron geopend.
• Stack Overflow Developer Survey 2025, AI-sectie. Cijfers over AI-gebruik, vertrouwen en de "bijna goed"-frustratie onder developers. Survey.stackoverflow.co was deze run niet direct te openen door de egress-proxy; de cijfers zijn kruisverwijsd via WebSearch, niet zelf op de bron geopend.
• Het meerwerk-mechanisme bij een vaste-prijsofferte (wat je "vergeet" in de scope, mag je later niet bijfactureren) is staande praktijk in de Nederlandse ICT-contractenwereld. De specifieke toelichting daarover op ictrecht.nl was deze run niet bereikbaar door de egress-proxy, dus deze claim staat hier zonder zelf geopende bron-URL en is bewust niet als losse link in de tekst opgenomen.

Veelgestelde vragen

• Waar kun je AI voor ICT-bedrijven het beste voor gebruiken?

  De drie taken met genoeg herhaling voor een goed eerste concept: supporttickets beantwoorden met je eigen documentatie erbij, documentatie bijwerken na een release, en de scope-tekst van een offerte structureren. Bij alle drie geldt dezelfde grens: een concept met een technisch detail (een getal, een header, een foutcode) gaat eerst langs een engineer voor het de deur uitgaat.

• Waarom geeft AI soms een verkeerde technische limiet of instelling terug in een supportantwoord?

  Omdat het model zonder een hard antwoord in je eigen documentatie terugvalt op het patroon dat het bij vergelijkbare systemen vaker zag. Een rate limit van rond de zestig per minuut is bij veel API's gangbaar, dus die waarde komt eruit, ook als jouw systeem een andere limiet heeft. Geef daarom altijd de actuele documentatie of changelog mee in de prompt, en laat AI expliciet zeggen als het antwoord er niet in staat.

• Is het veilig om broncode of klantconfiguratie in ChatGPT of Claude te plakken?

  Alleen op een zakelijk abonnement met verwerkersovereenkomst en met training op je data uitgezet. Broncode en systeemconfiguratie van een klant zijn vaak geen persoonsgegevens, maar wel een bedrijfsgeheim waar een geheimhoudingsclausule op zit: een publieke AI-tool is daarin een derde partij. Bij een ISO 27001-eis in je klantcontract laat je vooraf je informatiebeveiligingsverantwoordelijke beoordelen welke tools daarbinnen passen.

• Mag je een AI-gegenereerde offerte-scope voor een IT-project zomaar versturen?

  Niet zonder technische controle. AI schrijft van nature brede, geruststellende scope-taal, en bij een vaste prijs mag je wat je daarin vergeet niet later als meerwerk factureren: je had het als leverancier moeten voorzien. Laat daarom bij een offerte met maatwerk-scope altijd een technisch verantwoordelijke de tekst controleren op vage bewoordingen voor je hem verstuurt.

• Welke AI-tools gebruiken IT-bedrijven voor support en documentatie?

  De meeste ticketsystemen zoals Zendesk, Freshdesk, HubSpot Service Hub en Intercom hebben inmiddels ingebouwde AI-conceptfuncties, en GitHub Copilot en Claude bieden allebei documentatie- en codeondersteuning. Welke functie op welk abonnement zit, wisselt per leverancier en per kwartaal: check dat in je eigen beheerconsole voor je een aparte tool aanschaft naast wat je al hebt.