KI-Ausfall im Recruiting: So läuft Ihr Prozess weiter

Ein Notfallplan für Ausfälle KI-gestützter Recruiting-Workflows sorgt dafür, dass Bewerbungen, Entscheidungen, Interviews und die von Menschen verfasste Kommunikation in Ihrem ATS erhalten bleiben, auch wenn die modellabhängige Anreicherung separat ausfällt. Speichern Sie zuerst den eigentlichen Recruiting-Vorgang. Stellen Sie KI-Aufgaben mit Quellversionen in eine Warteschlange, begrenzen Sie Wiederholungsversuche, bieten Sie einen manuellen Weg an und gleichen Sie veraltete Aufgaben vor der Wiederaufnahme des Betriebs ab.

Diese Trennung ist entscheidend, weil KI längst nicht mehr auf einen Schreibassistenten in einem anderen Tab beschränkt ist. Ein Modell kann einen Lebenslauf auslesen, ein Interview zusammenfassen, eine Antwort vorschlagen, Datensätze durchsuchen oder Werkzeuge aufrufen, die eine Recruiting-Pipeline verändern. Muss das Modell erfolgreich antworten, bevor der Recruiting-Datensatz gespeichert wird, trifft jede Störung des Anbieters auch Ihren eigenen Prozess.

Lückenlose Automatisierung lässt sich nicht versprechen. Der Einstellungsprozess kann trotzdem verständlich und nutzbar bleiben, wenn sie aussetzt.

Was hat die 93-minütige Überschneidung der KI-Ausfälle tatsächlich gezeigt?

Am 3. September 2026 überschnitten sich bestätigte Störungen bei Anthropic, xAI und OpenAI 93 Minuten lang, von 14:43 bis 16:16 Uhr UTC. Sie begannen nicht gleichzeitig, und die öffentlich verfügbaren Belege weisen keine gemeinsame Ursache nach.

Anthropic eröffnete seinen Hauptvorfall um 13:26 Uhr UTC wegen erhöhter Fehlerraten bei mehreren Claude-Modellen. Der Störungsbericht nennt Claude.ai, die Claude API, Claude Code und Claude Cowork als betroffene Dienste. Anthropic erklärte, die Ursache gefunden zu haben, bezeichnete sie öffentlich aber lediglich als Infrastrukturproblem. Die Beeinträchtigung endete um 16:16 Uhr UTC, zwei Stunden und 50 Minuten nach der ersten Meldung. Eine separate Störung von Sonnet 5 war bereits um 12:56 Uhr UTC beendet. Beide Ereignisse dürfen daher nicht zu einem durchgehenden Ausfall zusammengezogen werden.

Die Störung bei xAI begann um 13:30 Uhr UTC. Laut Statusbericht zur API in der Region US East war der Dienst um 17:07 Uhr UTC wiederhergestellt. Für die Weboberfläche, die mobilen Apps, die Einbindung in X und weitere API-Bereiche wurden ähnliche Zeiträume gemeldet. SpaceXAI verwies später auf einen Ausfall in seinem Rechenzentrum in Memphis. Ob Stromversorgung, Netzwerk, Hardware oder Software versagten, veröffentlichte das Unternehmen nicht.

OpenAI meldete den Beginn der Beeinträchtigung um 14:43 Uhr UTC. Die Störungsseite nennt Komponenten von ChatGPT und Codex, nicht aber die OpenAI API. Eine Sprecherin führte die Probleme, die manche Nutzer betrafen, auf einen Fehler bei der Datenverkehrsleitung zurück. Um 15:17 Uhr UTC wurde eine Lösung eingespielt. Die Überwachung lief jedoch weiter, bis der Vorfall um 16:55 Uhr UTC als behoben markiert wurde. Wer von einem 34-minütigen Ausfall spricht, verwechselt die Zeit bis zur Eindämmung mit der endgültigen Behebung.

Die Überschneidung widerlegt eine verbreitete Annahme: Ein namhafter KI-Anbieter beseitigt das Betriebsrisiko nicht. Aus der zeitlichen Nähe lässt sich jedoch nicht schließen, dass die Anbieter dieselbe Cloud, dasselbe Netzwerk oder dasselbe Rechenzentrum nutzten oder vom selben Angriff beziehungsweise derselben Lastspitze betroffen waren. Zeitnahe Berichte fanden keine Aussage der Anbieter, die einen solchen Zusammenhang belegt. Von einer gemeinsamen Ursache zu sprechen, bleibt Spekulation, solange keine Ursachenanalyse sie nachweist.

Für ein Recruiting-Team lautet die entscheidende Frage nicht, warum drei Statusseiten rot waren. Es muss wissen, was Kandidatinnen, Kandidaten und Recruiter währenddessen weiterhin tun konnten.

Welche Recruiting-Workflows müssen einen KI-Ausfall überstehen?

Die maßgeblichen Vorgänge in Ihrem Einstellungsprozess müssen ohne Modell funktionieren. Ein Anbieterausfall darf die Anreicherung verzögern, aber keine Bewerbung löschen, keine Entscheidung verbergen und Kandidatinnen und Kandidaten nicht daran hindern, eine Person im Team zu erreichen.

Trennen Sie zuerst Transaktionen von Unterstützung. Transaktionen verändern den dauerhaften Zustand des Einstellungsprozesses. Unterstützung leitet Informationen ab oder entwirft einen möglichen nächsten Schritt.

Bei dieser Grenze geht es um Entscheidungshoheit, nicht darum, wie wichtig eine Funktion erscheint. Ein Recruiter kann sich stark auf eine erzeugte Zusammenfassung stützen, doch die ursprünglichen Interviewnotizen müssen weiterhin vorhanden sein. Ein Schreibassistent spart womöglich Stunden, aber der Recruiter muss eine Nachricht auch selbst verfassen können. Ein Suchmodell kann passende Treffer hervorheben, dennoch braucht eine berechtigte Person einen anderen Weg zum Kandidatendatensatz.

Das Handbuch zum KI-Risikomanagement-Framework des NIST empfiehlt tragfähige Alternativen ohne KI, klar definierte menschliche Rollen, Möglichkeiten zum Eingreifen und Notfallverfahren für den Ausfall von Drittanbietern. Im Recruiting bedeutet das: Der eingeschränkte Betrieb darf nicht aus einem leeren Ladebildschirm bestehen. Die Oberfläche sollte benennen, was fehlgeschlagen ist, bestätigen, was gespeichert wurde, und den nächsten sicheren Schritt anbieten.

Das betrifft auch das Bewerbererlebnis. Wenn die Bewerbung eingeht, aber das Auslesen verzögert ist, bestätigen Sie ihren Eingang. Verlangen Sie keine erneute Einreichung, nur weil der Aufruf zur Anreicherung sein Zeitlimit überschritten hat. Hinter einem barrierefreien Kandidatenportal steht derselbe Gedanke: Der entscheidende Weg muss verfügbar bleiben, wenn eine optionale Schicht ausfällt.

Halten Sie diese Grenze vor einem Vorfall schriftlich fest. Fragen Sie bei jeder modellgestützten Funktion: Welcher Datensatz ist vorhanden, wenn dieser Aufruf nie zurückkehrt? Was kann ein Mensch als Nächstes tun? Wenn beide Antworten unklar sind, bestimmt das Modell wahrscheinlich einen zu großen Teil der Transaktion.

Wie trennen Sie den eigentlichen Recruiting-Vorgang von der KI-Anreicherung?

Speichern Sie zuerst den Kerndatensatz lokal und fordern Sie die KI-Anreicherung danach als separate, beobachtbare Aufgabe an. Eine Aktion, die Kandidaten betrifft, sollte nicht auf die Antwort eines Modells warten. Eine Ausnahme ist nur vertretbar, wenn die Funktion ausdrücklich optional ist und einen klaren Weg ohne sie anbietet.

Ein praktischer Ablauf sieht so aus:

candidate or recruiter action → ATS transaction → durable AI task → bounded worker → provider → versioned result → human review

Angenommen, eine Kandidatin oder ein Kandidat reicht eine Bewerbung ein. Speichern Sie die betreffende Person, ihre Bewerbung, ihre Einwilligung, den Verweis auf den Anhang und die erste Phase in einer Datenbanktransaktion. Erst nachdem diese Transaktion abgeschlossen ist, sollte das System die Auslesung oder Zusammenfassung des Lebenslaufs in die Warteschlange stellen. Ist der Anbieter nicht verfügbar, bleibt die Bewerbung bestehen. Der Recruiter sieht „Zusammenfassung ausstehend“ statt eines leeren Datensatzes. Die betreffende Person erhält eine Bestätigung auf Grundlage der gespeicherten Bewerbung und nicht auf Grundlage des Anreicherungsergebnisses.

Eine dauerhafte Warteschlange nimmt Aufgaben auf, solange eine Abhängigkeit nicht verfügbar ist. Allein macht sie das System jedoch noch nicht ausfallsicher. Microsofts Leitfaden zur Lastverteilung über Warteschlangen nennt dafür die Überwachung der Warteschlangentiefe, begrenzte Verarbeitung, idempotente Verbraucher, eine Auffangstelle für endgültig fehlgeschlagene Aufgaben und klare Regeln zur Reihenfolge. Ohne diese Vorkehrungen kann die Wiederaufnahme nach einem Anbieterausfall eine Lawine angestauter Aufgaben auslösen.

Jede Aufgabe sollte eine unveränderliche Quellversion tragen. Das kann die Version eines Lebenslaufs, der Interviewnotizen, der Stellenkriterien oder einer Nachrichtenvorlage sein. Bevor ein Hintergrundprozess ein Ergebnis speichert, sollte er diese Version mit dem aktuellen Stand vergleichen. Hat ein Kandidat den Lebenslauf ersetzt oder wurde die Bewerbung inzwischen in eine andere Phase verschoben, ist die alte Aufgabe nicht nur verspätet. Sie ist veraltet.

Oft ist es sicherer, veraltete Arbeit zu ersetzen, statt sie erneut auszuführen. Bewahren Sie die alte Aufgabe für die Nachweiskette auf, vermerken Sie den Grund für das Überspringen und stellen Sie nur dann eine aktuelle Aufgabe ein, wenn das Ergebnis noch gebraucht wird. So lesen Recruiter keine sauber formulierte Zusammenfassung von Daten, die für die Bewerbung nicht mehr maßgeblich sind.

Auch Ihre Oberfläche braucht diese Genauigkeit. Verwenden Sie eindeutige Zustände wie ausstehend, in Bearbeitung, erneuter Versuch, fehlgeschlagen, ersetzt, abgebrochen und abgeschlossen. „KI nicht verfügbar“ ist nützlicher als ein endloses Ladesymbol. Noch besser ist „Bewerbung gespeichert; Zusammenfassung des Lebenslaufs verzögert“, weil die Meldung sowohl die erfolgreiche Transaktion als auch die fehlgeschlagene Anreicherung benennt.

Wie machen Sie Wiederholungsversuche sicher, bevor Sie eine Ausweichroute zu einem anderen Anbieter einbauen?

Wiederholungsversuche sind nur dann sicher, wenn dieselbe Anfrage keine geschäftliche Wirkung doppelt auslösen kann. Lösen Sie dieses Problem, bevor Sie einen weiteren Modellanbieter hinzufügen. Die Ausweichroute schafft sonst einen zusätzlichen Weg, über den doppelte oder veraltete Aktionen ausgeführt werden können.

KI-Aufgaben fallen in zwei Risikoklassen. Eine interne Zusammenfassung zweimal zu erzeugen kostet Geld und kann widersprüchliche Ergebnisse schaffen. Wird dagegen eine Aktion gegenüber Kandidaten oder eine Zustandsänderung wiederholt, kann das unmittelbar schaden: zwei Absage-E-Mails, zwei Interviewbuchungen, zwei Phasenwechsel oder ein Angebot, das verschickt wird, nachdem die Bewerbung zurückgezogen wurde.

Vergeben Sie für jeden Vorgang einen Idempotenzschlüssel auf Geschäftsebene. Ein sinnvolles Schema lautet:

account + application + capability + source_version + workflow_step

Speichern Sie diesen Schlüssel zusammen mit der Aufgabe und jedem daraus entstehenden Artefakt oder Nebeneffekt. Prüfen Sie vor dem Senden, Buchen, Ablehnen oder Verschieben in eine andere Phase sowohl den Schlüssel als auch den aktuellen lokalen Zustand. Der AWS-Leitfaden zu sicheren Wiederholungsversuchen mit idempotenten APIs erklärt, warum eine vom aufrufenden System vergebene Kennung zuverlässiger ist als der Versuch, aus ähnlichen Anfragen auf dieselbe Absicht zu schließen.

Entscheiden Sie sich anschließend für eine einzige Ebene der Wiederholungsversuche. Ein SDK versucht einen Aufruf womöglich bereits erneut. Ihr Hintergrundprozess kann dasselbe tun. Eine Workflow-Engine fügt vielleicht eine dritte Schleife hinzu. Wenn jede Ebene drei Versuche startet, kann ein Fehler weit mehr Aufrufe auslösen, als Ihre Richtlinie vermuten lässt. Verwenden Sie klar klassifizierte vorübergehende Fehler, exponentiell wachsende Wartezeiten, zufällige Streuung, eine Obergrenze und eine Frist. Fehler bei der Anmeldung, ungültige Eingaben und aus Sicherheitsgründen abgelehnte Anfragen sind kein Anlass für weitere Versuche.

Die Ausweichroute zu einem anderen Anbieter ist nicht die erste Schutzmaßnahme. Verschiedene Modellnamen können denselben Identitätsdienst, dieselbe Netzwerkinfrastruktur, dieselbe regionale Kapazität oder eine andere Abhängigkeit in der Steuerungsebene nutzen. OpenAI beschrieb in seiner Ursachenanalyse vom Juli 2026 ein regionales Kapazitätsproblem des Identitätsdienstes, bei dem die automatische Umschaltung zu wenig Datenverkehr umleitete. Ob Systeme wirklich unabhängig sind, muss sich am konkreten Ausfallpfad zeigen.

Wenn Sie einen Ausweichanbieter ergänzen, legen Sie fest, was er tun darf. Ein zweiter Anbieter kann für eine interne Zusammenfassung mit geringem Risiko vertretbar sein. Für einen vertraulichen Lebenslauf gilt das möglicherweise nicht, wenn Verträge, Speicherort und Aufbewahrung der Daten oder das Modellverhalten abweichen. Auch die Ergebnisse können sich so stark unterscheiden, dass die Annahmen nachgelagerter Systeme nicht mehr gelten. Halten Sie Anbieter und Modell im Prüfprotokoll fest, validieren Sie das Ausweichergebnis und bewahren Sie den Weg ohne KI.

Wie testen Sie einen fünfstufigen Notfallplan für den eingeschränkten Betrieb?

Ein brauchbarer Notfallplan ist kurz genug, um unter Druck befolgt zu werden, und genau genug, um Improvisation zu verhindern. Testen Sie diese fünf Schritte bei deaktivierter Verbindung zum Modell und nicht anhand einer Präsentation.

1. Eingeschränkten Betrieb ausrufen und den Kernweg schützen

Bestätigen Sie das Fehlerbild beim Anbieter. Deaktivieren oder umgehen Sie anschließend unkritische synchrone Aufrufe. Halten Sie die Annahme von Bewerbungen, den Zugriff auf Datensätze, manuelle Phasenwechsel, die Interviewverwaltung und die Möglichkeit verfügbar, Nachrichten selbst zu verfassen. Platzieren Sie eine klare Statusmeldung dort, wo Recruiter sie sehen. Halten Sie den Beginn des Vorfalls fest und benennen Sie die Person, die die Wiederherstellung koordiniert.

2. Wiederholungsversuche eindämmen und die Absicht bewahren

Setzen Sie den Schutzschalter für die betroffene Funktion auf offen oder pausieren Sie die Prozesse, die ihre Aufgaben verarbeiten. Löschen Sie keine Aufgaben aus der Warteschlange. Stoppen Sie Wiederholungsversuche auf mehreren Ebenen, bevor sie die Last verstärken oder Anfragelimits ausschöpfen. Bewahren Sie zu jeder Aufgabe den Idempotenzschlüssel, die Quellversion, die Frist, die Anfragekennung des Anbieters und den zuletzt aufgetretenen, klar klassifizierten Fehler auf.

Googles SRE-Leitfaden zu Kaskadenausfällen empfiehlt Ergebnisse mit eingeschränktem Umfang, Fristen, gezielte Lastreduktion und ein vorsichtiges Wiederholungsverhalten. Zusätzlicher Datenverkehr durch Wiederholungsversuche kann eine Überlastung verlängern. Ihr Ziel ist, den Druck zu verringern und zugleich die ursprüngliche Absicht der Aufgabe zu bewahren.

3. Menschen auf einen manuellen Weg führen

Geben Sie Recruitern konkrete Anweisungen für jede betroffene Funktion. Öffnen Sie den gespeicherten Lebenslauf, statt auf eine Zusammenfassung zu warten. Verwenden Sie eine Stichwort- oder Datenbanksuche statt Einbettungen. Schreiben Sie die Nachricht an den Kandidaten selbst. Halten Sie die Phasenentscheidung im ATS fest, statt einen Agenten damit zu beauftragen. Weisen Sie zeitkritische Bewerbungen und Interviews jeweils einer verantwortlichen Person zu. So wird aus „KI ausstehend“ nicht „Kandidat vergessen“.

Wenn Ihr Team einen Assistenten zur Bedienung von Recruiting-Werkzeugen einsetzt, prüfen Sie erneut die Grenzen für Berechtigungen und Freigaben beim Einsatz von KI-Recruiting-Agenten mit MCP. Die klar definierte Werkzeugschnittstelle kann verfügbar bleiben, obwohl das steuernde Modell ausgefallen ist.

4. Wiederherstellung mit begrenztem Budget prüfen

Arbeiten Sie nicht sofort den gesamten Rückstau ab, sobald eine Statusseite wieder grün ist. Leiten Sie zunächst eine kleine Gruppe aktueller Aufgaben mit geringem Risiko durch einen halboffenen Schutzschalter. Beobachten Sie Antwortzeit, Fehlerrate, Meldungen zu Anfragelimits, Wartezeit der Aufgaben und Ergebnisvalidierung. Nehmen Sie die Verarbeitung schrittweise wieder auf und halten Sie Kapazität für neue Bewerbungen frei.

5. Vor der erneuten Ausführung abgleichen

Wiederherstellung bedeutet Datenbankabgleich, nicht das Leeren der Warteschlange. Prüfen Sie für jede ausstehende oder fehlgeschlagene Aufgabe, ob ihre Quellversion aktuell ist, die Frist noch relevant ist, bereits ein gleichwertiges Ergebnis vorliegt oder ein Mensch die Handlung manuell erledigt hat. Prüfen Sie vor einem weiteren Versuch auch, ob externe Wirkungen wie E-Mails oder Kalenderbuchungen bereits eingetreten sind.

Priorisieren Sie aktuelle Nachrichten an Kandidaten und aktive Stellenausschreibungen. Markieren Sie veraltete Aufgaben als ersetzt. Brechen Sie Aufgaben ab, deren geschäftlicher Anlass nicht mehr besteht. Führen Sie nur aktuelle Aufgaben mit gültigem Idempotenzschlüssel erneut aus und vergleichen Sie anschließend die erwarteten mit den tatsächlichen Datensätzen. Halten Sie für den Vorfall fest, wie viele Aufgaben abgeschlossen, übersprungen, abgebrochen oder manuell gelöst wurden.

Führen Sie diese Übung vierteljährlich und nach wesentlichen Änderungen am Workflow durch. Messen Sie, ob eine Bewerbung weiterhin eingereicht werden kann, ob ein Recruiter fehlgeschlagene Anreicherungen erkennt und ob die Wiederherstellung ohne doppelte Handlungen gegenüber Kandidaten auskommt. Diese Ergebnisse zählen mehr als eine nominelle Verfügbarkeitsquote.

Was funktioniert in Kit weiter, und wo bleibt die Abhängigkeit von KI?

Kit trennt die zentralen Recruiting-Datensätze und viele manuelle Workflows von der KI-Anreicherung. Das Produkt verspricht jedoch weder ein vollständig offline nutzbares Recruiting-System noch eine automatische, vom Anbieterstatus gesteuerte Umschaltung. Die realistische Zusage ist enger: Der Recruiting-Datensatz bleibt bestehen, während modellgestützte Unterstützung sichtbar ausfallen kann.

Bei einer öffentlichen Bewerbung speichert Kit den Kandidatendatensatz, die Bewerbung, die Einwilligung, die Einreichung und die erste Phase in einer Datenbanktransaktion. Erst nach deren Abschluss beginnt die nachgelagerte Auslesung des Lebenslaufs. Scheitert die Auslesung, verschwindet die Bewerbung nicht mit ihr. Manuelle Phasenwechsel speichern den maßgeblichen Pipeline-Zustand unabhängig davon, ob sie in der Weboberfläche oder über ein MCP-Werkzeug ausgelöst werden. Ob ein Modell den Aufruf dieses Werkzeugs veranlasst, ist eine davon getrennte Abhängigkeit.

Recruiter können Intervieweinladungen erstellen, Kandidaten können direkt in Kit gebuchte Termine bestätigen und Teams können von Menschen verfasste Nachrichten sowie Liquid-Vorlagen ohne Modellaufruf speichern. Diese Wege hängen weiterhin von Systemen wie Kalenderverfügbarkeit, der Bereitstellung von Google Meet oder Calendly, Hintergrundaufgaben und dem Versand per SMTP ab. Es wäre falsch, sie als vollständig offline zu bezeichnen.

Kit bietet außerdem klar begrenzte Ausweichwege für bestimmte Funktionen. Beim Entwurf von KI-Antworten kann das System den Editor mit einem deterministischen Ersatztext vorbelegen, wenn Anbieter oder Übertragung ausfallen. Manche semantischen Suchen weichen von Gemini-Einbettungen auf die PostgreSQL-Textsuche aus. Werkzeuge für Bewerbungs- und Kandidatenzusammenfassungen serialisieren gespeicherte Datensätze; sie erzeugen nicht selbst neue Prosa. Ein angeschlossenes Modell kann diese Datensätze interpretieren, doch sie bleiben davon unabhängig bestehen. Unser Leitfaden zu MCP im Recruiting erklärt diese Trennung zwischen dem Modell und den Recruiting-Werkzeugen, deren Aufruf es anfordern kann.

Die Lücken sind ebenso wichtig. Kit überwacht nicht den Zustand der Anbieter, um automatisch zwischen Gemini, Anthropic und OpenRouter umzuschalten. Der Wechsel auf eine schwächere Modellvariante erfolgt nur innerhalb des konfigurierten Anbieters. Allgemeine Fehler im Chat werden angezeigt und lösen keinen automatischen, allgemeinen Wiederholungsablauf aus. Fehlgeschlagene Auslesungen von Lebensläufen und Metafeldern können eine manuelle Wiederherstellung erfordern. Einbettungen bleiben an Gemini gebunden, selbst wenn für den Chat ein anderer Anbieter eingestellt ist. Kit führt nicht jede fehlgeschlagene Anreicherung erneut aus und beseitigt auch keine Abhängigkeiten von Kalendern, SMTP oder Modellen.

Daran sollte sich jedes von Grund auf für KI entwickelte ATS messen lassen: Wenn die Statusseite des Modells rot wird, muss der Recruiting-Datensatz intakt bleiben. Sorgen Sie dafür, dass Bewerbungen und Entscheidungen maßgeblich, KI-Arbeit abgeleitet und wiederherstellbar und der menschliche Weg erkennbar bleiben, bevor Sie ihn brauchen.