All case studies / Production
Government IT service automation, fully on premises.
A national agency that needed AI-triaged service desk automation with zero tolerance for cloud data exposure.
- Client
- A national digitalisation agency
- Sector
- Public sector, IT operations
Growth goal
Automate service-desk triage for a national agency without any data leaving its network.
Operating constraint
Standard AI tooling depends on cloud APIs. For sensitive public-sector data that was not an option.
Measured result
Tickets triaged and routed automatically, 100% on premises, with no vendor dependency for the models.
The full story
- Baseline
- Every ticket read and routed by hand, with cloud AI ruled out by policy.
- System
- A fully local triage system on on-premises models, containerised for the agency's existing infrastructure and air-gap friendly.
- Controls
- No cloud calls and no data leaving the network. Routing decisions are logged and the desk can override any of them.
- Result
- Automatic triage and routing with sensitive data never leaving the agency, and no dependency on an external model provider.
In depth
Growth meant more tickets with strict data rules
The national digitalisation agency had a clear mandate to move more public services online. Each new online service added volume to an already busy IT service desk. Every incident, access request and change needed to be read and routed by hand. The work was repetitive and time sensitive, but it involved sensitive public sector data that could not leave the network. Policy ruled out cloud AI from the start, even as leaders looked for ways to keep up with demand without slowing delivery of new services.
The team could see how AI triage might help. They needed a system that could read free text, understand what each ticket was about and route it to the right team. They also needed to keep complete control of their data. No cloud APIs, no external processing, no hidden storage. Only an on premises system, aligned with existing security controls, would be acceptable to internal risk owners and oversight bodies. The choice was stark. Either accept manual triage as a permanent limit, or find a different way to bring AI into the service desk.
Manual triage capped how much demand they could absorb
The service desk was the intake for issues across multiple agencies and systems. Analysts read each ticket, interpreted the description, checked any attached context and chose a category and assignment group. Simple tickets took time. Complex ones depended on experience and local knowledge. As online usage increased, queues grew longer and response targets were harder to meet. Triage effort diverted skilled staff away from solving incidents and into sorting them. Leadership needed more capacity without weakening control of sensitive data.
Because cloud AI tools were ruled out, earlier automation attempts were limited to rule based routing. These rules could match keywords or fields, but they did not cope well with the varied language that citizens and internal users used when raising tickets. Creating and maintaining new rules added work instead of removing it. The team knew they were only using a fraction of the information in each ticket, constrained by what the rule engine could read. They needed an approach that respected policy but could handle real language.
SIEL designed a fully local AI triage workflow
SIEL worked with the agency’s IT and security teams to design a triage system that lived entirely within their own infrastructure. The focus was on work first, technology second. Together they mapped the existing routing decisions, the assignment queues and the approval steps where human review would remain mandatory. That gave a concrete target. The new system had to read incoming tickets from the existing tools, decide on category and target queue, log the reasoning and hand the ticket back, all without sending a single byte outside the agency network.
Technically, the system used on premises models that ran inside the agency’s own data centres. SIEL packaged the models and application logic into containers that matched the agency’s existing platform. That made it possible to deploy into their standard environments, including air gapped segments. The agency could inspect what was deployed, control access, and align hosting with their own monitoring. Model updates and configuration changes were handled through the same change processes that applied to other internal systems, which kept risk owners comfortable.
The triage system ran inside their air gapped network
Security requirements framed every decision in the design. The triage service accepted tickets only from inside the trusted network. It made no outbound calls to any external API. Logs, configuration and models were all stored locally. Where an air gap was enforced, updates were delivered through the agency’s established mechanisms for moving software into that environment. SIEL’s role was to build a system that could live inside those constraints without needing special exemptions or bespoke connectivity.
Each deployment unit was self contained. The containers included the model, the routing logic and the interfaces needed to talk to the existing ticketing platform. If the agency wanted to run the same triage capability in a different network segment, they could deploy another identical unit without re engineering the workflow. That helped the central IT function treat the triage system like any other internal service, with clear boundaries and predictable behaviour, instead of a special case driven by AI requirements.
People stayed in charge of routing decisions
From the start, the agency made it clear that the service desk needed to retain control. SIEL built the system so that every routing decision was logged with enough context to review and audit. Desk managers could see how a ticket had been classified and which queue it had been sent to. If the decision was not appropriate, they could override it and send the ticket elsewhere. Those corrections were recorded, which helped improve the routing over time through configuration changes and model updates under the agency’s control.
The team could also set thresholds for when automatic routing was allowed and when a ticket should stay in a review queue. For categories with higher risk or more complex policies, the system could suggest a route but wait for human approval. That meant the agency could adopt automation where confidence was high while keeping sensitive paths under closer supervision. Over time, as they gained trust in the behaviour of the system, they could widen the scope of full automation in a way that suited their own risk appetite.
Fixed fee, agreed before we start. A senior engineer replies within two business days.
