Internal IT helpdesk assistant

IT service desks spend much of their time on repetitive requests: password resets, VPN problems, "how do I connect to the printer", software and access requests. An LLM assistant living in Microsoft Teams, Slack or the intranet portal answers from the knowledge base, performs routine actions through the ITSM and identity systems, and escalates the rest with a complete ticket. Employees get answers in seconds, and the service desk concentrates on incidents that need a human.

Problem & value

• Today: employees email or phone the service desk, or fill ticket forms with poor detail. Agents re-ask the same questions, search scattered documentation and handle many Level-1 tickets that follow a fixed recipe. Out-of-hours coverage is thin, especially in SMBs with one or two IT staff.
• AI value: instant 24/7 first response, deflection of repeat questions, better ticket quality (category, urgency, affected asset, diagnostics already collected), shorter handling time for the tickets that remain, and knowledge-base gaps found from unanswered questions.
• Evidence: vendors publish deflection and resolution figures (for example Freshworks for Freddy AI), but these are self-reported and depend on the baseline; measure your own before promising a number [1]. Treat any "X % of tickets automated" claim as a hypothesis for your ticket mix.

Variants

• Knowledge-only assistant: answers how-to questions with citations; no write access. Lowest risk.
• Action-taking assistant: triggers approved workflows (password reset after MFA, add to group, order software licence, unlock account, create a ticket) via ITSM/identity APIs.
• Agent copilot: the same models help service-desk staff (ticket summary, suggested reply, similar incidents) instead of facing employees; see CONV-007.
• Multi-domain employee assistant: IT, HR and facilities behind one front door, routed to separate knowledge bases (see KNOW-003 for HR).

How it works

1. employee message (Teams / Slack / web portal / email)
2. authentication & context (SSO identity, role, device, language)
3. intent routing (question | known action | incident | out of scope / sensitive)
4. retrieval (hybrid search + reranker over KB, runbooks, resolved tickets, status page)
5. answer generation with citations OR tool call (reset, request, group add) under policy
6. confirmation / approval step for risky actions (manager, IT, MFA step-up)
7. resolved? yes
8. close with feedback | no
9. ticket with summary, diagnostics, chat transcript
10. human agent takes over (warm handoff)
11. feedback loop: thumbs, reopen rate, KB-gap report

• Retrieval-augmented generation over internal documentation is the core; see KNOW-002. Permission-aware retrieval matters because IT docs contain admin credentials hints, network layouts and security procedures that not every employee should see.
• Tool use: the model calls narrowly scoped functions (via function calling or MCP servers) that wrap ITSM and identity APIs. Authorisation is enforced by the tool and the calling user's identity, never by the prompt.
• Human-in-the-loop: privileged actions (admin rights, mailbox access, MFA reset) require approval or out-of-band verification; low confidence or user dissatisfaction triggers handoff. A visible "talk to a person" option is mandatory in practice.
• Prompt injection: content from tickets, emails and web pages is untrusted input; keep tool permissions minimal and add guardrails.

Data preparation

The assistant draws on IT knowledge: runbooks and how-to articles in the wiki or SharePoint, past tickets from the helpdesk tool, asset and software inventories, onboarding checklists and vendor manuals. In SMBs much of it sits in the IT admin's notes, mailbox and personal file share, often undocumented.

Typical gaps: outdated or contradictory how-tos, tickets with vague titles and no resolution notes, passwords or personal data inside tickets, no categories, and access rights that let the assistant expose confidential documents.

Preparation steps: (1) collect the top 30 recurring problems from ticket history, (2) write one short, current solution article per problem, (3) clean ticket exports: remove credentials and personal data, add categories, (4) define which systems the assistant may read and which actions it may trigger (for example password reset only through the identity tool), (5) review permissions on the knowledge sources, (6) keep a test set of real questions. Tools: helpdesk export, Paperless-ngx or wiki tooling, n8n for ticket creation.

Share of effort: about 30 to 40 percent. See PREP-013, PREP-014, PREP-020, PREP-022, PREP-023 and DATA-007.

Implementation paths

Which path for whom

• SMB: Path A. Helpdesk and ITSM tools or Microsoft/Google assistants with built-in IT support features are available as EU-hostable products and the process is standard.
• Enterprise: Path B. IT service management is core infrastructure with ticket, identity and asset integration; a custom build on cloud APIs or a shared internal AI platform gives control.
• Developer: Path C. Open-source stack (open-weight model, vector database, existing helpdesk) is quick to assemble and reusable across clients.
• Public sector: Path C. Internal tickets contain employee and system data; sovereign cloud or on-premises open models fit procurement and security rules.

Path A — Buy (recommended for most SMBs)

• ITSM-native AI: ServiceNow (Now Assist / virtual agent), Jira Service Management with its Virtual Service Agent (Atlassian), Freshservice with Freddy AI, Zendesk, TOPdesk (NL, EU), Matrix42 (DE, EU), SysAid, HaloITSM, Ivanti, Zammad (DE, open source with hosted option) [1][2][3].
• Platform assistants: Microsoft Copilot Studio agents in Teams with connectors to ServiceNow/Jira and Entra ID; Slack-based assistants for engineering-heavy organisations [4].
• Choose A when: you already run an ITSM tool and want deflection and ticket quality quickly. Check EU data residency, which model providers process prompts, no training on your data, audit logs, and per-resolution versus per-seat pricing.

Path B — Build on cloud APIs

• Models: EU-hosted frontier APIs (Mistral, or Claude/GPT/Gemini via EU regions of Bedrock, Azure OpenAI, Vertex AI) with function calling and structured outputs; a small model for intent routing.
• Stack: embeddings plus a hybrid index (OpenSearch, pgvector, Qdrant), reranker, orchestration in n8n, Power Automate or a small service (LangGraph, Microsoft Agent Framework or plain code), MCP servers wrapping the ITSM, identity and MDM APIs [5].
• Channels: Bot Framework for Teams, Slack Bolt, or a web widget.
• Choose B when: the ITSM is niche, you need custom actions, or several departments share one front door.

Path C — Self-host (open source)

• Models: open-weight instruction models such as Mistral Small/Medium-class, Qwen3, Llama or gpt-oss, served by vLLM or Ollama; embeddings such as BGE-M3 or Qwen3-Embedding; rerankers such as bge-reranker [6].
• Stack: Open WebUI, Rasa or Botpress for dialogue, n8n for actions, Zammad or GLPI as ITSM, Qdrant or pgvector.
• Hardware: a 20-30B-class model for tool use serving a few hundred employees fits HW2-HW3; a CPU-only setup with an 8B model works for knowledge-only pilots. Operations effort is the main cost.
• Choose C when: IT documentation may not leave the premises (public sector, defence suppliers, KRITIS).

Path D — Custom training

Rarely justified. Fine-tune a small classifier for ticket routing/categorisation using thousands of historical labelled tickets, or tune a small model for a rare language or jargon. Prompting, retrieval and good KB articles deliver most of the quality.

State of the art (2026)

• Tool-calling LLMs are reliable enough for multi-step ITSM workflows with narrowly scoped tools, and MCP has become the common way to expose ITSM, identity and monitoring systems to assistants [5].
• Vendors have moved from FAQ bots to agentic ITSM: agents that diagnose (check device state, outages), act (provision, reset) and write the resolution notes [1][2].
• Limits: hallucinated procedures when the KB is stale or contradictory; wrong confidence on environment-specific issues; users pasting secrets or personal data into chat; injection through ticket text; multi-turn troubleshooting still fails when diagnostics need physical access. Answer quality is bounded by KB quality, so the biggest lever is cleaning and owning the articles.

Shared resources & combinations

• Same stack (llm-general + embedding + vector-db + reranker): KNOW-002 (RAG over documents), KNOW-003 (HR assistant), CONV-001 (customer chatbot); one retrieval platform can serve all three.
• CONV-007 agent assist for the service desk; CONV-026 in-product copilots reuse the same tool layer.
• AGENT-002 / AGENT-003 supply workflow automation and legacy-UI automation for systems without APIs; AGENT-001 handles the email channel of the service desk.
• Model serving (vLLM on HW2/HW3) can be shared across these use cases.

Effort, cost & KPIs

• Path A: days to weeks to enable; licence uplift per agent, per resolution or per conversation.
• Path B: roughly 1-3 months for a knowledge-plus-actions assistant with ITSM integration.
• Path C: 2-4 months plus ongoing operations; one GPU server.
• KPIs: deflection/self-resolution rate, containment without reopen, first-response and resolution time, escalation quality (agent re-asks), CSAT, KB coverage of unanswered questions, security incidents from assistant actions (target zero).

People & change

Management sets scope and the rule that the assistant never makes security-relevant decisions alone. The IT lead owns the process; IT staff are both users and content authors. IT security must review access rights, prompt-injection exposure and logging. The DPO covers employee data in tickets, AVV and DPIA. HR joins for onboarding and offboarding topics. All employees are end users.

Works council: yes, in practice. The assistant processes and logs employees' requests, and ticket analytics can show who asks what, so it is objectively suited to monitor behaviour (§87(1) no. 6 BetrVG; BAG: suitability is enough). Involve it from the start, inform it under §90(1) no. 3, consider an expert under §80(3) and agree a works agreement that limits evaluation to aggregated figures. Public sector: Personalrat.

Support AI literacy of all users and IT staff (Art. 4 AI Act) and link it to the company AI policy. Start with IT staff and a volunteer pilot department, name AI champions, and communicate openly what is logged. Typical concerns are surveillance and fear that IT staff are replaced; address them with transparent logging rules, no individual performance evaluation, and the message that the assistant frees time for projects. Humans stay in control: sensitive actions need confirmation, and an easy route to a person always exists. See GUIDE-004, GUIDE-007, GUIDE-013.

Risks, regulation & compliance

• EU AI Act: typically limited risk. Art. 50 requires that people are told they interact with an AI system, unless obvious; it applies from 2 Aug 2026 [7][8]. AI literacy (Art. 4) applies to staff operating it [8]. Not high-risk if confined to IT support. Caution: if conversations or logs are used to monitor, evaluate or rank employees' performance or behaviour, Annex III (employment) high-risk rules can apply, and emotion inference from employees' messages at work is prohibited under Art. 5(1)(f). Keep the assistant out of HR evaluation and do not analyse sentiment of individuals.
• GDPR: chats contain personal data (identities, device and usage data, sometimes health or private matters). Needs lawful basis, data-processing agreements, EU hosting or transfer safeguards, retention limits, transparency to employees, and a DPIA where logging is extensive. In Germany, works council co-determination (BetrVG sec. 87(1) no. 6) applies to technical systems capable of monitoring behaviour; involve it early.
• Security: least-privilege tool design, step-up authentication for sensitive actions, logging every AI-initiated change, secrets filtering in inputs, red-teaming for prompt injection. NIS2/ISO 27001 controls apply to the assistant as part of IT operations.
• Mitigations: read-only first, approval gates, citations, "I don't know" behaviour, human handoff, regular KB review.

Getting started

1. Export 3-6 months of tickets; rank categories by volume and by how scripted the resolution is.
2. Clean and assign owners to the top 30-50 KB articles; fill gaps from resolved tickets.
3. Pilot a knowledge-only assistant for one department in Teams or Slack with a visible AI notice and human-handoff button; inform the works council and data protection officer.
4. Add one or two safe actions (create ticket with diagnostics, unlock account with MFA) with logging.
5. Review failed conversations weekly; track deflection, reopen rate and CSAT before widening scope.

Sources

1. Freshworks — Freddy AI for ITSM — https://www.freshworks.com/freshservice/ai-itsm/
2. Atlassian — Jira Service Management — https://www.atlassian.com/software/jira/service-management
3. ServiceNow — Now Assist for ITSM — https://www.servicenow.com/products/it-service-management.html
4. Microsoft — Copilot Studio documentation — https://learn.microsoft.com/microsoft-copilot-studio/
5. Model Context Protocol specification — https://modelcontextprotocol.io/specification
6. vLLM project — https://github.com/vllm-project/vllm
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. AI Act Art. 4 (AI literacy), annotated text — https://artificialintelligenceact.eu/article/4/