KI und IT-Support: Wenn Maschinen beheben und Menschen entscheiden

Der IT-Support hat im Vergleich zu den meisten KI-Projekten einen besonderen Vorteil: ein großer Teil der Arbeit ist wiederholbar. Dieselben Passwort-Resets, derselbe Drucker, derselbe Laptop, der nicht aufwacht. Das macht den Support zu einem guten Automatisierungskandidaten, bündelt aber auch das Risiko, denn viele dieser Aktionen berühren Produktionssysteme, Konten und Daten. Die praktische Aufteilung ist einfach: Maschinen beheben, Menschen entscheiden.

Wo KI wirklich hilft

Drei Bereiche funktionieren zuverlässig und ohne großes Risiko. Erstens die Sortierung: ein Ticket lesen, einordnen und an die richtige Person oder Warteschlange weiterleiten, was die Wartezeit verkürzt, ohne etwas zu verändern. Zweitens bekannte Ursachen mit bekannten Behebungen, etwa ein entsperrtes Konto, ein geleerter Cache, ein Neustart eines Dienstes im Testsystem oder eine Schritt-für-Schritt-Anleitung zum Zurücksetzen. Drittens die Vorbereitung: Diagnosedaten sammeln, einen Vorfall zusammenfassen, einen Wissensbasisartikel entwerfen oder ein Skript schreiben, das später ein Mensch ausführt.

Alle drei sparen die knappe Ressource im Support: Aufmerksamkeit. Keiner davon muss eigenständig handeln, um sich zu lohnen.

Die Linie, an der Menschen freigeben

Eine nützliche Regel schaut auf zwei Eigenschaften jeder Aktion: wie weit die Wirkung reicht und ob sie umkehrbar ist. Aktionen mit kleiner Wirkung, die sich rückgängig machen lassen, können mit Protokollierung automatisch laufen. Aktionen, die viele Personen betreffen oder nicht rückgängig zu machen sind, warten auf einen Menschen.

Zugriffsrechte, Berechtigungen und Entscheidungen zum Kontoabschluss.
Änderungen an Produktionskonfiguration, Netzwerk und Sicherheitseinstellungen.
Löschung von Daten, Postfächern oder Sicherungen.
Vage oder instabile Symptome, bei denen die Ursache noch nicht klar ist.
Alles, was ein Nutzer auf ungewöhnlichem oder dringlichem Weg anfragt.

Wenn ein Techniker unsicher ist, führt der Weg ebenfalls zur Freigabe. Unsicherheit ist ein Grund, langsamer zu werden, nicht ein Grund, die Maschine raten zu lassen.

Freigaben, die Menschen wirklich nutzen

Ein Freigabeschritt schützt nur, wenn er nutzbar ist. Zeigen Sie den exakten Befehl oder die Änderung vor dem Ausführen, sowohl in klarer Sprache als auch in der Originalform. Bieten Sie, wo das System es zulässt, einen Trockenlauf oder eine Vorschau, und wo nicht, einen Rücksetzplan. Begrenzen Sie die Gültigkeit der Freigabe zeitlich, damit ein alter Auftrag nicht versehentlich Tage später ausgeführt wird, und protokollieren Sie jede Entscheidung mit Person und Grund.

Planen Sie auch die Ablehnung ein. Wer nicht mit einem Klick und einem kurzen Grund ablehnen kann, stimmt innerhalb von zwei Wochen nur noch zu.

Reihenfolge beim Ausrollen

Erheben Sie die Tickets des letzten Quartals und zählen Sie die wiederkehrenden Ursachen.
Beginnen Sie mit rein lesenden Aktionen: Einordnung, Diagnose, Zusammenfassungen.
Fügen Sie als Nächstes umkehrbare Schreibvorgänge außerhalb der Produktion hinzu.
Erst danach enge Produktionsaktionen hinter eine Freigabe stellen.
Prüfen Sie abgelehnte Aktionen wöchentlich, denn sie zeigen genau, wo die Grenze liegt.

Die richtigen Zahlen messen

Erstlösungsquote, Eskalationsrate, Rücksetzrate und vom System verursachte Vorfälle sind die vier relevanten Zahlen. Die gesparte Zeit der Techniker zählt ebenfalls, aber nur zusammen mit der Rücksetzrate; eine schnelle Behebung, die zweimal rückgängig gemacht werden muss, ist keine Ersparnis. Rechnen Sie in den ersten Wochen mit Meinungsverschiedenheiten darüber, wo die Linie liegt. Schreiben Sie die Regel auf, statt sie nächsten Monat erneut zu diskutieren, und ändern Sie sie bewusst statt ungewollt.

Das Ziel ist kein Support-Team ohne Menschen. Es ist ein Support-Team, bei dem Routineaufgaben schnell und gleichmäßig erledigt werden und ein Mensch die Entscheidungen trifft, die Folgen haben. Das ist ein kleineres Versprechen als volle Autonomie und deutlich zuverlässiger.

IT support has an unusual advantage compared to most AI projects: a large part of the work is repeatable. The same password resets, the same printer, the same laptop that will not wake up. That makes support a good candidate for automation, but it also concentrates risk, because many of these actions touch production systems, accounts, and data. The practical split is simple: machines fix, humans decide.

Where AI genuinely helps

Three areas reliably work without much risk. The first is triage: reading a ticket, classifying it, and routing it to the right person or queue, which shortens waiting time without changing anything. The second is known fixes for known causes, such as unlocking an account, clearing a cache, restarting a service on a test system, or walking a user through a reset step by step. The third is preparation: collecting diagnostics, summarising an incident, drafting a knowledge base article, or writing a script that a human later runs.

All three save the scarce resource in support, which is attention. None of them needs to act on its own to be worth the effort.

The line that needs human approval

A useful rule is to look at two properties of every action: how wide the effect reaches, and whether it can be reversed. Actions that are narrow and reversible can run automatically with logging. Actions that affect many people or cannot be undone should wait for a person.

Access rights, permissions, and offboarding decisions.
Changes in production configuration, networks, and security settings.
Deletion of data, mailboxes, or backups.
Vague or unstable symptoms where the cause is not yet clear.
Anything that a user asked for in an unusual or urgent way.

When a technician is not sure either, the answer is also approval. Uncertainty is a reason to slow down, not a reason to let the machine guess.

Approval that people will actually use

An approval step only protects you if it is usable. Show the exact command or change before it runs, in plain language as well as in its original form. Provide a dry run or a preview where the system allows it, and a rollback plan where it does not. Keep the approval time-limited so that an old request cannot be executed days later by accident, and log every decision with the person and the reason.

Design for refusal as well. If a reviewer cannot reject with one click and a short note, approvals become a rubber stamp within two weeks.

Roll out in order

Inventory the tickets from the last quarter and count the repeat causes.
Start with read-only actions: classification, diagnostics, summaries.
Add reversible writes on non-production systems next.
Only then allow narrow production actions behind approval.
Review declined actions weekly, because they show exactly where the boundary sits.

Measure the right things

First-time fix rate, escalation rate, rollback rate, and incidents caused by the system are the four numbers that matter. Time saved by technicians matters too, but only together with the rollback rate; a fast fix that has to be undone twice is not a saving. Expect disagreements in the first weeks about where the line belongs. Write the rule down instead of arguing about it again next month, and change it deliberately rather than by accident.

The goal is not a support desk that runs without people. It is a support desk where the routine work is handled quickly and consistently, and where a human makes the calls that carry consequences. That is a smaller promise than full autonomy, and a much more reliable one.

BT desteği, çoğu YZ projesine kıyasla sıra dışı bir avantaja sahiptir: işin büyük bölümü tekrar eder. Aynı şifre sıfırlamalar, aynı yazıcı, açılmayan aynı dizüstü. Bu durumu otomasyon için iyi bir aday yapar, ama riski de toplar; çünkü bu eylemlerin çoğu üretim sistemlerine, hesaplara ve verilere dokunur. Pratik ayrım basittir: makineler onarır, insanlar karar verir.

YZ'nin gerçekten yardımcı olduğu yerler

Çok risk olmadan güvenle çalışan üç alan vardır. Birincisi yönlendirme: talebi okumak, sınıflandırmak ve doğru kişiye ya da kuyruğa göndermek; hiçbir şeyi değiştirmeden bekleme süresini kısaltır. İkincisi bilinen nedenler için bilinen çözümler: hesabı açmak, önbelleği temizlemek, test sisteminde bir servisi yeniden başlatmak veya kullanıcıya adımları sırayla anlatmak. Üçüncüsü hazırlık: tanılama verisi toplamak, olayı özetlemek, bilgi tabanı yazısı taslağı çıkarmak ya da daha sonra bir insanın çalıştıracağı betiği yazmak.

Üçü de destekteki nadir kaynağı, dikkati, kazandırır. Hiçbiri kendiliğinden karar vermek zorunda değildir.

İnsan onayı gereken çizgi

Yararlı bir kural, her eylemin iki özelliğine bakmaktır: etkisi ne kadar geniş ve geri alınabilir mi? Dar ve geri alınabilir eylemler kayıt altında otomatik çalışabilir. Birçok kişiyi etkileyen ya da geri alınamayan eylemler bir insanı bekler.

Erişim hakları, yetkiler ve hesap kapatma kararları.
Üretim yapılandırması, ağ ve güvenlik ayarlarında değişiklikler.
Veri, posta kutusu veya yedek silme.
Nedeni henüz netleşmemiş belirsiz ya da kararsız belirtiler.
Kullanıcının olağandışı ya da acil yolla istediği her şey.

Teknisyen de emin değilse yol yine onaya çıkar. Belirsizlik, makineye tahmin ettirmek için değil, yavaşlamak için bir nedendir.

İnsanların gerçekten kullanacağı onay

Bir onay adımı ancak kullanışlıysa korur. Çalıştırmadan önce tam komutu veya değişikliği, hem düz dilde hem orijinal hâlinde gösterin. Sistem izin veriyorsa kuru çalıştırma ya da önizleme, izin vermiyorsa geri alma planı sunun. Onayın geçerlilik süresini sınırlayın ki eski bir istek günlerce sonra yanlışlıkla çalışmasın; her kararı kişi ve gerekçesiyle kaydedin.

Reddetmeyi de tasarlayın. Bir tıkla ve kısa bir gerekçeyle reddedemeyen kişi, iki hafta içinde yalnızca onaylar.

Yayılım sırası

Son çeyreğin taleplerini çıkarın ve tekrar eden nedenleri sayın.
Salt okunur eylemlerle başlayın: sınıflandırma, tanılama, özetleme.
Sırasında üretim dışı sistemlerde geri alınabilir yazma işlemlerini ekleyin.
Ancak ondan sonra dar üretim eylemlerini onay arkasına alın.
Reddedilen eylemleri haftalık gözden geçirin; sınırın tam nerede olduğunu onlar gösterir.

Doğru ölçüleri izleyin

İlk seferde çözüm oranı, aktarım oranı, geri alma oranı ve sistem kaynaklı olaylar dört önemli sayıdır. Teknisyenin kazandığı zaman da önemlidir; ama yalnızca geri alma oranıyla birlikte. İki kez geri alınan hızlı bir onarım tasarruf değildir. İlk haftalar sınırın nerede olacağı konusunda görüş ayrılıkları bekleyin. Kuralı yazın, gelecek ay yeniden tartışmayın ve onu kazara değil, bilerek değiştirin.

Hedef, insanların olmadığı bir destek masası değildir. Hedef, rutin işin hızlı ve tutarlı yürüdüğü, sonuç doğuran kararları ise bir insanın verdiği bir destek masasıdır. Bu, tam otonomiden daha küçük bir vaat ve çok daha güvenilir bir vaattir.

← Blog