KI-Automatisierung in der IT: Servicedesk und Dokumente

Jede IT-Abteilung im Unternehmen hat inzwischen „irgendwas mit KI“ auf der Roadmap. Die meisten dieser Initiativen bleiben an derselben Stelle stecken: eine Demo, die das Steuerungsgremium beeindruckt — und danach sechs Monate Funkstille. Das Problem ist fast nie das Modell. Es ist, dass etwas automatisiert wurde, das beeindruckend aussah, statt etwas, das tatsächlich teuer war — und dann an einer Wand aus Integration, Datenschutz und Vertrauen scheitert, die kein Prompt-Tuning einreißt.

Zwei Bereiche lohnen den Aufwand zuverlässig: der IT-Servicedesk und das dokumentenlastige Back Office— Ausschreibungen, RFP-Antworten und die technische Dokumentation, um die sich alle drücken. Beide sind hochvolumig, textförmig und voller wiederkehrender Einschätzungen. Bei beiden ist es auch am leichtesten, die Architektur falsch zu wählen. Dieser Leitfaden behandelt, wie man es richtig macht — und die Entscheidung, die alles andere rahmt: Azure AI, selbst gehostete Modelle oder ein Hybrid aus beidem.

Warum der Servicedesk das offensichtliche erste Ziel ist

Ein Servicedesk ist eine Warteschlange natürlichsprachlicher Probleme, abgebildet auf eine endliche Menge bekannter Lösungen — nahezu die Definition eines guten LLM-Anwendungsfalls. Aber „den Servicedesk automatisieren“ ist zu vage. Zerlege es in Schritte und automatisiere die mit klarem Wert:

• Triage und Klassifizierung — kategorisieren, priorisieren, routen. Risikoarm und ab Woche eins messbar gegen historische Fehlleitungen.
• Wissensabruf — die meisten Tickets sind Wiederholungen gelöster Probleme; die wahrscheinliche Lösung erscheint, bevor jemand antwortet.
• Antwortentwürfe — kein Auto-Versand. Ein Entwurf, den der Agent prüft und freigibt. Hier liegt die meiste Zeitersparnis, und Human-in-the-Loop ist Pflicht.
• Deflection — ein Self-Service-Assistent, der die wirklich einfachen Tickets löst, gegroundet in Ihrer Dokumentation, nicht im offenen Internet.

Die Dokumentenseite: Ausschreibungen, RFPs und die Schreib-Steuer

IT-Ausschreibungen und RFP-Arbeit sind der Back-Office-Zwilling des Servicedesks: aufwendig, repetitiv und größtenteils eine Neukombination dessen, was die Organisation bereits geschrieben hat.

• Anforderungsextraktion — Pflichten, Bewertungskriterien und Fristen aus einer langen Ausschreibung in eine strukturierte Checkliste ziehen, damit nichts aus Klausel 14.3 bei der Abgabe untergeht.
• Entwurfserstellung aus früheren Arbeiten — der Großteil einer starken Antwort existiert bereits in vergangenen Angeboten; Retrieval verwandelt das leere Blatt in einen prüfbaren Erstentwurf.
• Dokumentation, die aktuell bleibt — erzeugt aus den Systemen und Konfigurationen, die sie beschreibt, nicht aus der Erinnerung von vor drei Monaten.

Nichts davon ersetzt die Fachkraft. Es entfernt das Abtippen, Nachschlagen und Umformatieren — und gibt dem Urteilsvermögen die Zeit zurück, die es verdient. Die Mechanik baut auf KI-Dokumentenverarbeitung auf.

Die Architekturentscheidung: Azure AI, selbst gehostet oder hybrid

Diese Wahl bestimmt Kosten, Compliance und wie weit das Projekt kommt. Es gibt keine universelle Antwort — sondern eine Entscheidung nach Datensensibilität, Latenz, Volumen und dem bestehenden Stack.

Azure AI / Azure OpenAI

Der Weg des geringsten Widerstands, wenn Sie bereits eine Microsoft-Landschaft betreiben: verwaltete Modelle, Identität über Entra und native Anbindung an Copilot Studio und Power Automate als Workflow-Kitt. Der Kompromiss: Kosten pro Token bei hohem Volumen und ein Datenschutz-Gespräch, das man ehrlich führen muss.

Selbst gehostete Modelle

Llama oder Mistral via Ollama, in Docker oder Kubernetes, verändern Wirtschaftlichkeit und Compliance: sensible Ticketinhalte und vertrauliche Ausschreibungen verlassen nie die von Ihnen kontrollierte Infrastruktur, und Inferenz wird zu festen, planbaren Kosten. Der Preis: Sie betreiben es selbst. Die volle Abwägung steht in selbst gehostete KI vs. Cloud-APIs.

Hybrid — die ehrliche Antwort

Leiten Sie das Gros der hochvolumigen, weniger sensiblen Arbeit an ein selbst gehostetes Modell; greifen Sie für das schwierigere Reasoning zu einem Azure-Frontier-Modell, wo die Qualität die Kosten rechtfertigt und die Datenklassifizierung es erlaubt. Die beste Architektur setzt jede Anfrage auf den günstigsten Endpunkt, der die Aufgabe noch korrekt löst.

RAG ist das Rückgrat, kein Feature

Jeder Anwendungsfall oben teilt einen Mechanismus: das relevante Organisationswissen abrufen, dem Modell zuführen und eine Antwort erzeugen, die in Ihren Daten gegroundet ist — mit nachvollziehbaren Quellen. Ein Servicedesk-Assistent ohne Retrieval erfindet plausible Lösungen; ein Ausschreibungs-Entwerfer ohne Retrieval schreibt selbstbewusste Fiktion. Produktions-RAG über Unternehmensinhalte ist ein eigenes Engineering-Problem. Siehe Produktions-RAG-Pipeline aufbauen.

Sicherheit und Datenschutz entscheiden, was überhaupt geht

Im deutschen und EU-Unternehmenskontext ist Datenschutz keine späte Checkbox — er prägt die Architektur ab dem ersten Diagramm. Ticketinhalte enthalten personenbezogene Daten; Ausschreibungen sind geschäftlich vertraulich. Beides fällt unter die DSGVO und zunehmend unter die EU-KI-VO und Datensouveränität. Deshalb laufen Sicherheitsmaßnahmen parallel zum Bau:

• Guardrails und Output-Validierung, damit der Assistent beim Thema bleibt.
• Prompt-Injection-Abwehr — abgerufene Dokumente und eingereichte Tickets sind nicht vertrauenswürdige Eingaben. Siehe RAG-Pipelines absichern.
• Dokumentenbezogene Zugriffskontrolle im Retrieval, damit die Generierung nie preisgibt, was der Nutzer nicht ohnehin sehen darf.
• Audit-Logging und Monitoring des Modellverhaltens — für Compliance und um Drift zu erkennen.

Integration ist die 20 %, die 80 % der Arbeit sind

Modell und Prompts sind der einfache Teil. Diese Projekte stehen und fallen mit der unspektakulären Integration in die Systeme, in denen die Menschen ohnehin arbeiten — ServiceNow, Jira Service Management, die Microsoft-365-Landschaft. Ein Assistent in einem separaten Fenster wird nicht genutzt. Die Automatisierung muss im Ticket, im Workflow, im Dokument landen — über Copilot Studio, Power Automate oder ITSM-Webhooks. Dieselbe Lehre zieht sich durch LLM-Integration in Geschäftssysteme.

Warum diese Projekte scheitern — und wie man es vermeidet

• Keine Erfolgsmetrik vorab. „Es funktioniert“ nach drei Demo-Tickets ist keine Messung. Legen Sie vorher fest, was Sie bewegen.
• Den falschen Schritt automatisiert. Die beeindruckende End-to-End-Demo ist selten der wertvolle, risikoarme Schritt.
• Human-in-the-Loop übersprungen, wo es zählt. Auto-Versand oder ungeprüfte Abgaben machen aus einem Fehler hundert.
• Zu wenig in Daten investiert. Retrieval-Qualität ist ein Datenqualitäts-Problem.

Es sind dieselben Muster wie bei warum die meisten KI-Projekte vor der Produktion scheitern— keines davon eine Frage der Modellqualität.

Wo anfangen

Wählen Sie einen Workflow mit klarem, schmerzhaftem Volumen — Ticket-Triage oder RFP-Erstentwürfe — definieren Sie die Metrik, bauen Sie Retrieval- und Sicherheitsschicht sauber, und halten Sie einen Menschen in der Schleife für alles, was das Haus verlässt. Beweisen Sie es dort, dann skalieren Sie. Die Unternehmen mit echtem KI-Nutzen sind nicht die mit dem größten Modell, sondern die, die den richtigen Schritt wählten, ihn in eigenen Daten groundeten und sicher genug machten, um ihm zu vertrauen.