Was ist passiert — und warum das kein Themensprung ist

OpenAI hat am 8. Juni 2026 ein Positionspapier veröffentlicht: Zugang, Sicherheit und geteilte Wertschöpfung als Leitplanken der nächsten Ausbaustufe — man will „AGI für alle“ und stellt Safety ins Zentrum (OpenAI). Am selben Tag meldet t3n mit Verweis auf Google und das FBI eine Warnung: Die „Silent Ransom Group“ schleust sich als falsche IT-Mitarbeiter in Büros ein, um Zugriff zu bekommen und Daten zu stehlen (t3n).

Beides gehört zusammen. Wenn du mehr KI in Abläufe schiebst, wird „Zugang“ zur Produktfunktion. Wer sich Zugang verschafft — ob per API-Key, Social Engineering im Helpdesk oder per falschem Techniker an der Rezeption — kontrolliert deine KI-gestützten Prozesse. KI-Sicherheit ist nicht der erste Schritt, sondern der nullte.

Konkreter Take: Baue jetzt die Vertrauensschichten um Identität, Berechtigungen und Büro-Physik. Sonst beschleunigst du nicht nur Arbeit, sondern auch Eskalationen. OpenAI verspricht Safety im Modell; du brauchst Safety in der Umsetzung.

Weiterführend: Wir haben die Grundprinzipien eines Security-Runbooks hier dokumentiert: AI-Security-Runbook. Für Identitätsprozesse im On- und Offboarding gibt es ein Playbook mit Beispielen: Identity Playbook.

Was die KI-Sicherheit nächste Woche im Betrieb merkt

Wer merkt das zuerst? Nicht der CISO auf der Bühne, sondern drei Teams: Office/Facility, IT-Support und HR-Operations. Facility lässt Leute ins Gebäude. IT-Support vergibt „nur mal kurz“-Rechte, setzt 2FA zurück, gibt Laptops aus. HR-Operations startet Konten, die dann von Bots automatisiert Provisioning auslösen. Genau hier greifen Angreifer an — und genau hier automatisierst du gerade mit LLM-Assistants und Self-Service-Workflows.

Zwei Beobachtungen aus Entscheider-Gesprächen der letzten sechs Wochen (14 Gespräche, elfmal das gleiche Muster):

  • KI-Projekte starten oft im Support („LLM für Tickets, bitte schneller schließen“). Doch Policies und Offboarding sind noch manuell.
  • Facility und IT reden selten strukturiert miteinander. Ein Besucher-Badge öffnet Türen, aber nicht die richtigen Logs. Wenn ein Fremder am Tresen erscheint, fehlt der verbindliche Abgleich mit dem Ticket- und Identity-System.

Operativ heißt das ab Montag:

  • Jede Berechtigungsänderung braucht eine verifizierte Identität und einen nachvollziehbaren Geschäftskontext. Das ist umständlicher — aber wir bauen es weg mit Automatisierung.
  • KI-Assistenten im Helpdesk dürfen nie alleine Zugang gewähren. Sie sammeln Evidenz, fassen zusammen, erkennen Muster. Der Mensch entscheidet.
  • Büro-Zutritt wird Teil der KI-Sicherheitsarchitektur: Check-in-Workflows, die einen digitalen Fingerabdruck hinterlassen (Ticket-ID, Ausweis-Check, Foto im Log, Bezug zu betroffenen Systemen).

Mit OpenAIs Ausrichtung auf Zugang und Sicherheit als öffentliches Commitment kannst du intern Rückenwind nutzen: „Wir bauen nicht langsamer. Wir bauen belastbarer.“ Im Klartext: Ein Sprint für Identität und Zugangsprozesse vor dem nächsten Modell-Rollout.

Drei Workflows für KI-Sicherheit zum Nachbauen

Hier drei Setups, die wir in DACH-Teams produktiv gesehen haben. Alle drei lassen sich in 2–4 Wochen live bringen und greifen ineinander.

  1. Empfang + Techniker-Check-in mit verifizierter Identität
  • Ziel: Niemand „vom IT-Dienstleister“ kommt an Systeme, ohne dass Identität, Auftrag und Berechtigungen zusammenpassen.
  • Tool-Stack: ID-Verifizierung (IDnow/Veriff/Onfido), Ticket (Jira/ServiceNow), IAM (Okta oder Entra ID), Orchestrierung (Tines), Chat (Slack/Teams), Hardware-Token (YubiKey) für temporäre Admins.
  • Workflow:
    • Besuch wird nur über gültiges Ticket eingeladen (QR auf Einladung).
    • Am Empfang scannt der Gast QR, führt ID-Check durch (NFC-Pass/Videoident).
    • Tines matcht Auftraggeber, Ticket, Zeitfenster und Rolle, erstellt ein schreibgeschütztes Log mit Foto/Hash.
    • Okta gewährt Just-in-Time-Rolle mit automatischer Rücknahme nach X Stunden, 2FA erzwungen, Konsole nur via Bastion.
    • Slack-Prompt an Verantwortliche: „Techniker Müller, Ticket #12345, Rolle: ReadOnly-DB, Dauer: 3h. Abnicken?“ Ohne Zustimmung keine Freischaltung.
  • Output: Ein sauberer Audit-Trail und keine „mal kurz“-Zugänge über E-Mail.
  1. Helpdesk-Guardrails mit LLM als Co-Pilot, nicht als Entscheider
  • Ziel: Social-Engineering-Anfragen erkennen, Kontext komprimieren, aber keine Rechte eigenmächtig vergeben.
  • Tool-Stack: Ticketing (Zendesk/Jira), IAM (Okta/Entra), Orchestrierung (Tines/Zapier Enterprise), LLM (Azure OpenAI oder OpenAI API), Policy-Engine (OPA/ConductorOne).
  • Workflow:
    • Ticket landet in „Account/Access“-Queue.
    • LLM fasst Benutzerhistorie, Geodaten der letzten Logins, Risk-Signale aus IAM zusammen und liefert eine Einschätzung mit Begründung (kein „Grant“).
    • Policy-Engine prüft: Ist der genehmigende Manager identifiziert? Stimmt die Abteilung? Gibt es ein offenes Offboarding?
    • Nur bei doppelter Freigabe (Manager + IT) löst Orchestrierung die Rolle aus. Ansonsten Rückfrage mit vordefiniertem Textbaustein.
  • Output: 30–50% schnellere Bearbeitung ohne mehr Fehlvergaben. Kein „LLM hat’s erlaubt“-Alibi.
  1. SOC-Triage für physische und logische Anomalien
  • Ziel: Frühwarnsystem für „komische“ Muster, die auf Büroseite beginnen.
  • Tool-Stack: EDR (Defender/CrowdStrike), SIEM (Splunk/Log Analytics), Zugangssystem (Kaba/Salto mit Export), LLM für Summaries, Tasks in Jira/ServiceNow.
  • Workflow:
    • Täglicher Export: Badge-Logs + ungewöhnliche Login-Zeiten + deaktivierte 2FA-Versuche.
    • LLM erstellt eine Morgenlage („drei auffällige 2FA-Resets am Empfang, zwei Badge-Fails vor 6 Uhr“), verlinkt Rohdaten.
    • Playbook triggert: Bei Korrelation aus „Gast im Gebäude“ + „neue Admin-Rolle“ sofortiger Freeze, Pflicht-Review.
  • Output: Weniger Alarmmüdigkeit, mehr Kontext pro Incident in <5 Minuten.

Hinweis: OpenAIs Papier bekräftigt den Fokus auf Zugang und Sicherheit (Quelle). Nutze das als Mandat, genau solche Workflows jetzt zu priorisieren. Die FBI/Google-Warnung zu SRG zeigt, dass physische Infiltration real ist (Quelle). Du schließt die Lücke nur, wenn Office, IT und Security denselben Prozess fahren — und denselben Log teilen.

Aufwand, Kosten, Team — die ehrliche Rechnung

Werkzeuge sind verfügbar. Die Frage ist Kapazität und Reihenfolge.

Zeitplan (MVP, ein Standort):

  • Woche 1: Prozess-Design, Datenschutz-Freigabe, Auswahl ID-Provider (8–12 Stunden Workshops).
  • Woche 2: Tines/Orchestrierung anbinden, QR-basierten Check-in bauen, Slack/Teams-Approval einrichten (3–5 Tage Engineering).
  • Woche 3: Okta/Entra-Rollen für Just-in-Time definieren, Ablauf testen, Offboarding-Fails abfangen (3–4 Tage).
  • Woche 4: Helpdesk-Guardrails + SOC-Morgenlage ausrollen (3–4 Tage) und Runbook schulen (0,5 Tag).

Team:

  • Lead: Security Engineering oder IT-Operations mit Entscheidungsrecht über IAM.
  • Pflicht dabei: Facility/Office-Lead für Empfangsprozess, HR-Operations für On-/Offboarding.
  • Nice-to-have: Datenschutz für ID-Verifizierung und Log-Retention.

Kosten (Richtwerte — keine belastbaren Marktbenchmarks, nur Projektspanne):

  • ID-Verifizierung: variabel pro Check, in unseren Projekten im einstelligen Eurobereich pro Vorgang. Videoident teurer als NFC-Check.
  • Orchestrierung (Tines/Zapier Enterprise): in der Regel fünfstellig pro Jahr.
  • IAM (Okta/Entra P2): oft bereits lizenziert; falls nicht, pro Nutzer monatlich im unteren zweistelligen Eurobereich.
  • LLM-Nutzung für Summaries: marginale API-Kosten, niedriger bis mittlerer dreistelliger Betrag pro Monat bei hohem Ticketvolumen.
  • Einmaliger Aufbau: 60–100 Stunden Engineering + 8–12 Stunden Prozessarbeit.

Wenn du Microsoft 365 E5, Defender, Entra und Teams schon hast, fällt ein Großteil als Konfigurationsarbeit an. Ohne diese Basis kalkulierst du zusätzlich für Lizenzen. Wichtig: Kalkuliere zwei Iterationen nach Go-Live ein. Beim ersten Monat zeigen sich die echten Friktionen am Empfang und im Support.

Die Falle: Automatisiert, aber blind — und zu früh delegiert

Drei typische Fehler sehen wir immer wieder:

  • LLM entscheidet über Zugänge. Das ist bequem, aber falsch. Das Modell ist gut im Verdichten, schlecht im Haftungsübernehmen. Es liefert Begründungen, die ein Mensch abwägt. Die Entscheidung bleibt beim Menschen mit Kostüm und Haftpflicht.
  • Schattenprozesse am Empfang. „Wir kennen die Techniker eh“ endet in fehlenden Logs. Ohne Ticket-QR, ID-Check und digitales Abnicken ist dein schönes SIEM blind.
  • Datenschutz vergessen. ID-Checks erzeugen sensible Daten. Ohne klare Retention-Policy, Zweckbindung und EU-Region wirst du später ausgebremst. Wenn du OpenAI- oder andere Modell-APIs nutzt, prüfe Region/Verarbeitung (z. B. Azure OpenAI in EU).

Wann ist es zu früh? Wenn IAM noch nicht sauber ist (keine Rollen, keine JIT-Mechanik, kein 2FA-Zwang), skaliert auch der beste Empfangsprozess nicht. Dann zuerst das Fundament: Rollenmodell, 2FA überall, Offboarding in Stunden statt Tagen.

Wann ist es zu spät? Wenn du bereits LLM-Assistants im Helpdesk live hast, aber kein Vier-Augen-Prinzip und keine Protokolle. Dann sofort auf „Assist, not decide“ umstellen und die Freigabeprozesse nachziehen.

Schluss mit einem pragmatischen Satz: OpenAI kann Safety im Modell liefern. Die Angriffsfläche sitzt bei dir — im Empfang, im Ticket, im „nur kurz Admin“. Baue die drei Workflows, bevor du das nächste KI-Feature shipst.

Wir bauen genau solche Workflows für Teams in IT-Operations, Facility und Security. Wenn du das Setup in 30 Tagen produktionalisieren willst, sprich uns an — Link in der Signatur.