Alle cases / Productie
IT-serviceautomatisering voor de overheid, volledig on-premises.
Een nationaal agentschap dat AI-triage voor de servicedesk nodig had zonder dat er data naar de cloud gaat.
- Klant
- Een nationaal digitaliseringsagentschap
- Sector
- Publieke sector, IT-operatie
Groeidoel
Service-desktriage voor een nationale dienst automatiseren zonder dat data het eigen netwerk verlaat.
Operationele beperking
Standaard AI-tools leunen op cloud-API’s. Voor gevoelige data in de publieke sector was dat geen optie.
Gemeten resultaat
Tickets automatisch geclassificeerd en doorgestuurd, 100% on premises, zonder afhankelijkheid van een externe leverancier voor de modellen.
Het volledige verhaal
- Startpunt
- Elke ticket werd met de hand gelezen en doorgestuurd, terwijl cloud-AI door beleid was uitgesloten.
- Systeem
- Een volledig lokale triage-oplossing op on-premises modellen, gecontaineriseerd voor de bestaande infrastructuur van de dienst en geschikt voor air-gapped omgevingen.
- Borging
- Geen cloud-calls en geen data die het netwerk verlaat. Routeringsbeslissingen worden gelogd en de servicedesk kan ze altijd overrulen.
- Resultaat
- Automatische triage en routering waarbij gevoelige data het netwerk van de dienst nooit verlaat, en geen afhankelijkheid van een externe modelleverancier.
In detail
Groei betekende meer tickets met strikte dataregels
De nationale digitaliseringsorganisatie had een duidelijke opdracht om meer publieke diensten online te brengen. Elke nieuwe online dienst voegde volume toe aan een al drukke IT-servicedesk. Elk incident, elk toegangsverzoek en elke wijziging moest handmatig worden gelezen en doorgestuurd. Het werk was repetitief en tijdkritisch, maar betrof gevoelige publieke data die het netwerk niet mocht verlaten. Beleidsregels sloten cloud-AI vanaf het begin uit, terwijl de leiding juist zocht naar manieren om de vraag bij te benen zonder de uitrol van nieuwe diensten te vertragen.
Het team zag hoe AI-triage zou kunnen helpen. Ze hadden een systeem nodig dat vrije tekst kon lezen, begreep waar een ticket over ging en het naar het juiste team kon sturen. Tegelijk moesten ze volledige controle over hun data houden. Geen cloud-API’s, geen externe verwerking, geen verborgen opslag. Alleen een on-premises systeem, passend binnen de bestaande beveiligingskaders, zou acceptabel zijn voor interne risicohouders en toezichthouders. De keuze was scherp. Ofwel handmatige triage als permanente grens accepteren, of een andere manier vinden om AI naar de servicedesk te brengen.
Handmatige triage bepaalde hoeveel vraag ze aankonden
De servicedesk was het loket voor issues over meerdere organisaties en systemen heen. Analisten lazen elk ticket, interpreteerden de omschrijving, bekeken eventuele bijlagen en kozen een categorie en een ondersteunend team. Simpele tickets kostten tijd, complexe waren afhankelijk van ervaring en lokale kennis. Naarmate het online gebruik toenam, werden de wachtrijen langer en werden responstargets lastiger te halen. Triage trok kundige medewerkers weg van het oplossen van incidenten naar het sorteren ervan. De leiding had meer capaciteit nodig zonder de bescherming van gevoelige data te verzwakken.
Omdat cloud-AI uitgesloten was, bleven eerdere automatiseringspogingen beperkt tot regelgestuurde routering. Die regels konden trefwoorden of velden matchen, maar konden slecht overweg met de uiteenlopende taal die burgers en interne gebruikers gebruikten in hun tickets. Nieuwe of aangepaste regels onderhoud kostte meer tijd dan het opleverde. Het team wist dat het maar een fractie van de informatie in elk ticket gebruikte, beperkt door wat de regelengine kon lezen. Ze hadden een aanpak nodig die binnen de beleidskaders bleef én met echte taal kon omgaan.
SIEL ontwierp een volledig lokale AI-triageworkflow
SIEL werkte met de IT- en securityteams van de organisatie aan een triagesysteem dat volledig binnen de eigen infrastructuur draaide. De focus lag op het werk, pas daarna op de technologie. Samen brachten ze de bestaande routeringsbeslissingen, de wachtrijen en de goedkeuringsstappen in kaart waar menselijke review verplicht zou blijven. Dat leverde een concreet doel op. Het nieuwe systeem moest binnenkomende tickets uit de bestaande tools kunnen lezen, categorie en doelqueue bepalen, de onderbouwing loggen en het ticket teruggeven, zonder dat er één byte buiten het netwerk van de organisatie ging.
Technisch draaide het systeem op on-premises modellen binnen de eigen datacenters van de organisatie. SIEL verpakte de modellen en applicatielogica in containers die aansloten bij het bestaande platform van de organisatie. Daardoor kon het worden uitgerold in hun standaardomgevingen, inclusief afgeschermde segmenten. De organisatie kon inspecteren wat er werd uitgerold, de toegang beheren en de hosting laten aansluiten op de eigen monitoring. Modelupdates en configuratiewijzigingen liepen via dezelfde changeprocessen als andere interne systemen, wat de risicohouders vertrouwen gaf.
De triageservice draaide in het afgeschermde netwerk
Beveiligingseisen stuurden elke ontwerpkeuze. De triageservice accepteerde tickets alleen vanuit het vertrouwde netwerk. Er gingen geen uitgaande calls naar externe API’s. Logs, configuratie en modellen werden lokaal opgeslagen. Waar een airgap gold, werden updates aangeleverd via de bestaande procedures van de organisatie voor het verplaatsen van software naar die omgeving. De rol van SIEL was om een systeem te bouwen dat binnen die kaders kon functioneren zonder uitzonderingen of speciale verbindingen nodig te hebben.
Elk deployment-unit was zelfvoorzienend. De containers bevatten het model, de routeringslogica en de koppelingen met het bestaande ticketsysteem. Wilde de organisatie dezelfde triagecapaciteit in een andere netwerkomgeving draaien, dan konden ze een identieke unit uitrollen zonder de workflow opnieuw te ontwerpen. Daardoor kon de centrale IT-functie de triageservice behandelen als elke andere interne dienst, met heldere grenzen en voorspelbaar gedrag, in plaats van een uitzonderingsgeval dat door AI-eisen werd gedreven.
Mensen bleven beslissend bij de routering
Vanaf het begin maakte de organisatie duidelijk dat de servicedesk de regie moest houden. SIEL bouwde het systeem zo dat elke routeringsbeslissing met voldoende context werd gelogd om te kunnen controleren. Teamleiders konden zien hoe een ticket geclassificeerd was en naar welke queue het was gestuurd. Als de keuze niet passend was, konden ze die overrulen en het ticket elders neerleggen. Die correcties werden vastgelegd, wat het mogelijk maakte om de routering in de tijd te verbeteren via configuratie en modelupdates onder regie van de organisatie.
Het team kon ook drempels instellen voor wanneer automatische routering was toegestaan en wanneer een ticket in een reviewqueue moest blijven. Voor categorieën met hoger risico of complexere beleidsregels kon het systeem een route voorstellen, maar wachten op menselijke goedkeuring. Zo kon de organisatie automatisering inzetten waar de zekerheid hoog was, terwijl gevoelige stromen onder strakker toezicht bleven. Naarmate het vertrouwen in het gedrag van het systeem groeide, konden zij de scope van volledige automatisering stap voor stap verbreden, in lijn met hun eigen risicohouding.
Vaste prijs, afgesproken voordat we beginnen. Een senior engineer antwoordt binnen twee werkdagen.
