Wenn der Copilot streikt

Bereits zum zweiten Mal in diesem Monat hatte Microsoft mit einem Ausfall des Copilot zu kämpfen. Mindestens ebenso schwer wie die Aussetzer selbst traf viele Partner und Kunden die damit einhergehende Erkenntnis, welche Risiken zu große Abhängigkeiten im KI-Bereich mit sich bringen können.

KI entwickelt sich zu einem festen Bestandteil der IT-Umgebungen in den Unternehmen, sowohl in Form von Agenten als auch hilfreicher Chatbots beschleunigen und automatisieren sie Prozesse und unterstützen Mitarbeiter und Teams dabei, ihre Arbeit effizienter zu erledigen. Doch was, wenn die unter anderem mit ihrer steten Verfügbarkeit beworbenen digitalen Kollegen plötzlich und unvermittelt ihre Arbeit einstellen? Die Antwort darauf hat einigen Unternehmen diesen Monat unfreiwillig Microsofts Copilot geliefert. Schon zweimal stellte der nicht zuletzt wegen seiner leichten Integrationen in vielen Unternehmen verbreitete KI-Helfer in einigen Regionen seine Arbeit ein.

Beim ersten Ausfall am 1. Juni konnten einige Kunden und Nutzer knapp viereinhalb Stunden weder auf Copilot für den Desktop noch auf die Webanwendung zugreifen. Letzte Woche folgte dann der zweite Aussetzer, der immerhin schneller wieder behoben werden konnte. Nachdem sich auf der Störungserkennungs-Website Downdetector bereits ab 13:47 Uhr Pazifikzeit, also mitten im US-Arbeitstag, Meldungen zu Störungen gehäuft hatten, bestätigte Microsoft um 14:07 Uhr auf X, man untersuche "ein mögliches Problem, das den Microsoft-365-Copilot-Chat beeinträchtigt". Immerhin blieben einigen Betroffenen dabei laut Microsoft Workarounds, indem etwa Administratoren über admin.cloud.microsoft auf das Microsoft-365-Admin-Center zugreifen und Nutzer teilweise über Teams weiter auf den Copiloten zugreifen konnten.

Etwa 20 Minuten später erläuterte der Konzern in einem Blogbeitrag, man habe "ein Problem bei einer jüngsten Bereitstellung für Microsoft Copilot identifiziert, das die Fähigkeit der Nutzer beeinträchtigt, auf den Copilot-Chat und portal.office.com zuzugreifen" und kündigte an: "Wir kehren zu einer vorherigen Build-Version zurück, um die Auswirkungen zu beheben." Etwas mehr als die dafür angepeilten 30 Minuten später vermeldete Microsoft dann auf X, man habe "die Änderung erfolgreich zurückgenommen und mit zuvor betroffenen Nutzern bestätigt, dass das Problem behoben ist".

CRN hat Microsoft um eine Stellungnahme gebeten.

Menschliches Sicherheitsnetz für die KI

Für viele Kunden und auch manchen Partner ist die Sache damit aber nicht ausgestanden, bei ihnen hat der Impetus der Ausfälle im Nachhinein auf höherer Ebene einen Denkprozess über Abhängigkeiten im KI-Zeitalter angestoßen. Sowohl im Sinne des Bedarfs der menschlichen Alternativen, Kontrolle und Absicherung als auch im Hinblick auf die möglichen Risiken durch einen Lock-In und die die damit einhergehenden Abhängigkeiten bei der Wahl ihrer Hersteller und Plattformen. Sie stellen sich etwa die Frage, wer übernimmt, wenn der Copilot und andere Tools und Agenten ausfallen, welche Alternativszenarien es gibt und wie sie damit ihre Souveränität und Resilienz technisch verbessern können.

Das bestätigte CRN auch Corey Kirkendoll. Für den CEO des texanischen Systemhauses 5K Technical Services, das Microsoft-Partner ist und es auf die CRN-Liste der wichtigsten 500 MSP geschafft hat, sind die Vorfälle ein Lehrbeispiel dafür, dass MSPs und Kunden den Menschen mit einplanen müssen, wenn sie überlegen, welche Workloads und Arbeitsabläufe sie auf moderne KI-Tools wie Copilot verlagern können. "Genau deshalb führen wir solche Gespräche", erklärte der CEO und empfahl: "Behandeln Sie KI-Tools wie jeden anderen kritischen SaaS-Dienst und lassen Sie niemals zu, dass ein einzelner Anbieter zum Single Point of Failure wird."

Für Teile dieses Artikels haben wir Material unserer geschätzten Kollegen von crn.com verwendet.

CRN-Newsletter beziehen und Archiv nutzen - kostenlos: Jetzt bei der CRN Community anmelden