AI kan een supportvraag sneller inzichtelijk maken: het verzoek samenvatten, ontbrekende gegevens herkennen en passende goedgekeurde aanwijzingen voorbereiden. De waarde ontstaat wanneer dit een goed toetsbare werkstand oplevert. Of een antwoord wordt verzonden of een wijziging wordt uitgevoerd, is een afzonderlijke beslissing.
Voor een eerste inzet is een afgebakend takenpakket geschikt. De assistent maakt bijvoorbeeld interne ticketconcepten zonder zelf berichten te verzenden of systemen te wijzigen. Zo kunnen kwaliteit en correctiewerk in het echte werkproces worden beoordeeld.
Wat een bruikbaar voorstel moet bevatten
Een korte samenvatting noemt de waargenomen storing, de betrokken werkmiddelen en wat er tot nu toe is gebeurd. Aannames en open vragen staan apart. Als een tijdstip, foutmelding of de omvang van de verstoring ontbreekt, wordt dit zichtbaar gemaakt.
Een conceptantwoord moet uitleggen welke informatie nog nodig is of welke goedgekeurde stap passend lijkt. Een voorgestelde oplossing heeft een navolgbare onderbouwing nodig. Een vergelijkbaar klinkend oud ticket is onvoldoende bewijs als omgeving of oorzaak afwijkt.
Voorbeeld: ‘De applicatie is traag’
De assistent bereidt vragen voor over tijdstip, betrokken gebruikers, de concrete functie en foutmeldingen. Hij kan gegevens die al in het ticket staan samenbrengen en verwijzen naar een passend goedgekeurd documentatiegedeelte.
Daarbij beweert hij niet dat al een servercontrole is uitgevoerd of een oorzaak bevestigd. Een technische maatregel wordt pas voorgesteld als de beschikbare bevindingen die ondersteunen. Dit is een mogelijk procesvoorbeeld, geen klantreferentie.
Ticket- en documentrechten blijven leidend
Een supportassistent heeft niet automatisch toegang tot elk ticket en alle documentatie nodig. De zoekfunctie wordt beperkt tot de betreffende gebruiker, het afgesproken takenpakket en passende objecten. Dit geldt ook voor bijlagen, interne notities en informatie van andere klanten.
Bij kenniszoeken met RAG moeten deze rechten al bij de selectie van resultaten worden meegenomen. Onbevoegde inhoud mag evenmin terechtkomen in een modelcontext die later wordt weggegooid. De technische uitvoering van documenttoegang verschilt per bron; Microsoft beschrijft bijvoorbeeld verschillende benaderingen voor documentrechten in Azure AI Search (externe link). Een eenvoudig filter werkt alleen als identiteit en filterwaarden op een betrouwbare manier worden bepaald.
Als meerdere klantomgevingen worden ondersteund, maken hun scheiding en toegestane gegevensstromen deel uit van het integratieontwerp. Welke logs en inhoud worden bewaard, wordt bepaald door doel en operationele behoefte. Een zo groot mogelijke volledige promptgeschiedenis is geen doel op zich.
Binnenkomende inhoud is data, geen werkinstructie
Een ticket kan tekst bevatten die de assistent oproept tot een ongeoorloofde actie. Hetzelfde geldt voor documenten, e-mails en bijlagen. Zulke inhoud mag geen systeemregels wijzigen of aanvullende hulpmiddelen of toegang vrijgeven.
De toepassing begrenst daarom aan de serverzijde welke bronnen mogen worden gelezen en welke functies mogen worden aangeroepen. Een modelvoorstel alleen zet die grenzen niet buiten werking. Voor het integreren van gedefinieerde functies kunnen gecontroleerde MCP-hulpmiddelen en bestaande API’s worden gebruikt; de MCP-beveiligingsdocumentatie (externe link) beschrijft concrete aanvals- en beschermingsgebieden.
Goedkeuring en uitvoering als twee afzonderlijke stappen
De behandelaar ziet samenvatting, bronnen en conceptantwoord samen. Die kan gegevens corrigeren, aanvullende vragen stellen of het voorstel afwijzen. Een verzendknop moet duidelijk tonen welk bericht naar welke ontvanger gaat. Verzending verloopt via de daartoe bevoegde toepassing.
Voor technische wijzigingen is een extra scheiding zinvol: een diagnosevoorstel wordt geen beheeropdracht alleen doordat het aannemelijk klinkt. Doel, doelsysteem, toegestane reikwijdte en vereiste goedkeuringen worden apart gecontroleerd. Onduidelijke of riskante gevallen gaan naar de verantwoordelijke specialist.
Een pilot heeft meer nodig dan een goede demonstratie
- Normale gevallen: Worden het verzoek en de noodzakelijke vervolgvragen correct vastgelegd?
- Ontbrekende onderbouwing: Herkent de assistent dat een onderbouwd antwoord nog niet mogelijk is?
- Een verkeerde of oude bron: Worden de versie en de werkelijke relatie met het ticket gecontroleerd?
- Gewijzigde rechten: Verdwijnt inhoud na intrekking van toegang uit zoeken en context?
- Gemanipuleerde invoer: Blijven gereedschapsgrenzen en goedkeuringen behouden?
- Uitval van de dienst: Kan het ticket nog op de normale manier worden behandeld?
De beoordeling moet ook tijd voor lezen, corrigeren en controleren meenemen. Een lang concept kan extra werk veroorzaken. Een korte, goed onderbouwde werkstand kan juist ontlasten, ook als de definitieve beslissing bij een mens blijft.
Van één concept naar een beheerbare integratie
DAXS bepaalt samen met uw support en IT een geschikt begin, koppelt goedgekeurde gegevensbronnen en realiseert een afgebakende pilot. Het bestaande ticketsysteem, identiteiten en documentatie worden in samenhang bekeken. Omvang en uitbreiding volgen het aangetoonde nut.
AI-toepassingen in het kort · Invoering en gebruiksregels · IT in de dagelijkse operatie
