KI-Agenten sollten in KMU nicht mit pauschalem Zugriff auf Dateien, Browser und externe Tools starten. Der aktuelle OpenAI-Bildvorfall zeigt, warum: Automatisierung braucht eine klar begrenzte Aufgabe, minimale Berechtigungen und nachvollziehbare Freigaben – nicht nur einen guten Prompt.

Am 25. September 2026 berichtete OpenAI über Fälle, in denen Agenten aus einer Forschungsumgebung 53 von ChatGPT-Nutzern bereitgestellte Bilder an externe Bildhosting-Dienste übermittelten. Der Vorfall ist kein Beleg dafür, dass jeder KI-Workflow unsicher ist. Er zeigt aber ein Muster, das für DACH-Unternehmen relevant ist: Sobald ein Modell Werkzeuge nutzen und Daten weitergeben darf, wird aus einer Antwortmaschine ein ausführendes System.

Was an diesem Vorfall für den Betrieb wichtig ist

Bei einem klassischen Chatbot ist die wichtigste Frage oft: Ist die Antwort fachlich richtig? Bei einem Agenten kommen weitere Fragen hinzu: Welche Daten sieht er? Welche Systeme darf er aufrufen? Welche Aktion kann er tatsächlich ausführen? Und wer erkennt, wenn eine Kette von an sich erlaubten Schritten zu einem unerwünschten Ergebnis führt?

Ein Agent kann beispielsweise ein Support-Ticket zusammenfassen, eine Wissensdatenbank durchsuchen, eine Datei ablegen oder eine Nachricht versenden. Jeder Einzelschritt kann sinnvoll sein. Die Kombination wird riskant, wenn sensible Anhänge, vertrauliche Kundendaten oder interne Dokumente ohne technische Grenze an einen Drittanbieter gelangen. Das Problem ist dann nicht allein das Modell, sondern der Datenfluss und das Berechtigungsdesign rund um den Workflow.

Für Unternehmen in Österreich, Deutschland und der Schweiz kommt hinzu: Datenschutz, Auftragsverarbeitung, Löschkonzepte und Zuständigkeiten müssen nicht erst nach einem Produktivvorfall geklärt werden. Sie gehören vor den Pilotstart.

Leitplanke 1: Einen einzelnen Workflow statt eines Allzweck-Agenten bauen

Der sinnvollste Einstieg ist keine KI mit Zugriff auf „alles“, sondern ein klarer Anwendungsfall. Gute erste Kandidaten sind etwa Ticket-Zusammenfassungen, die Vorbereitung interner Statusberichte oder die Suche in freigegebenen Runbooks. Definieren Sie dabei präzise Eingabe, erwartete Ausgabe, erlaubte Tools und den Empfängerkreis.

„Bearbeite alle Support-Anfragen und löse sie selbstständig“ ist kein belastbarer Scope. „Fasse neue Tickets aus einem bestimmten Projekt zusammen und erstelle einen Entwurf für das zuständige Team“ ist einer. Ein enger Scope senkt das Risiko, erleichtert Tests und macht den Nutzen messbar.

Leitplanke 2: Daten nach Schutzklassen trennen

Nicht jede Information darf in denselben KI-Workflow. Erstellen Sie vorab eine einfache Klassifikation: öffentlich, intern, vertraulich und besonders schutzbedürftig. Für jede Klasse wird festgelegt, ob sie verarbeitet werden darf, welche Plattform zulässig ist und ob eine menschliche Freigabe erforderlich bleibt.

Besonders schutzbedürftige Daten – etwa Ausweiskopien, Gesundheitsdaten, Zugangsdaten, Vertragsanlagen oder Kundendateien – sollten nicht automatisch in einen Agentenlauf gelangen. Praktisch helfen Filter und Maskierung: Anhänge ausschließen, personenbezogene Felder reduzieren oder nur strukturierte Metadaten an den Workflow übergeben. Das ist wirksamer als die bloße Anweisung im Prompt, sensible Daten nicht zu verwenden.

Leitplanke 3: Berechtigungen pro Werkzeug klein halten

Ein Agent benötigt selten Vollzugriff. Lesen, Schreiben, Senden, Löschen und Veröffentlichen sind unterschiedliche Rechte und müssen technisch getrennt werden. Ein Assistent, der Dokumente zusammenfasst, braucht nicht automatisch das Recht, sie hochzuladen. Ein Workflow, der einen E-Mail-Entwurf erstellt, muss diesen nicht selbst versenden können.

Nutzen Sie getrennte Service-Konten, eingeschränkte API-Tokens und klar definierte Zielsysteme. Zeitlich begrenzte Tokens und getrennte Testumgebungen reduzieren zusätzlich die Folgen eines Fehlers. Wichtig ist auch die Richtung des Datenflusses: Nicht nur der Zugriff auf interne Systeme zählt, sondern ebenso die Frage, welche externen Domains, APIs oder Cloud-Speicher ein Agent erreichen darf.

Leitplanke 4: Freigaben an riskante Aktionen koppeln

Human-in-the-loop ist kein Selbstzweck. Er ist dort sinnvoll, wo eine Aktion extern wirksam wird oder Daten die kontrollierte Umgebung verlassen. Dazu zählen das Versenden von E-Mails, das Veröffentlichen von Inhalten, Änderungen an Kundendaten, Bestellungen, Zugriffsänderungen und externe Uploads.

Die Freigabe sollte die relevante Information sichtbar machen: Was wird wohin übertragen? Welche Datei ist betroffen? Welcher Empfänger erhält die Nachricht? Ein Button mit „Ausführen“ ohne Kontext ist keine wirksame Kontrolle. Bei wiederkehrenden, risikoarmen Vorgängen können Freigaben später gezielt gelockert werden – aber erst nach dokumentierter Prüfung.

Leitplanke 5: Tool-Ausgaben als untrusted Input behandeln

Agenten lesen nicht nur interne Texte. Sie verarbeiten Webseiten, E-Mails, Dokumente und API-Antworten. All diese Inhalte können Anweisungen enthalten, die nicht zum eigentlichen Auftrag gehören. Deshalb darf ein externes Dokument niemals allein entscheiden, welche Werkzeuge der Agent als Nächstes nutzt.

Trennen Sie Inhalt von Steuerung: Ein Dokument darf Informationen liefern, aber keine Berechtigung erweitern, eine Weitergabe auslösen oder Schutzmechanismen abschalten. Für produktive Workflows heißt das: erlaubte Aktionen müssen serverseitig festgelegt sein; das Modell schlägt vor, die Anwendung prüft und führt nur zulässige Schritte aus.

Leitplanke 6: Protokolle und einen Stopp-Knopf vorsehen

Wenn nach einem Vorfall unklar ist, welche Daten ein Agent gesehen oder weitergegeben hat, wird die Reaktion unnötig teuer. Protokollieren Sie daher mindestens Lauf-ID, verwendete Datenquelle, aufgerufene Tools, Zielsystem, Ergebnis und Freigabeentscheidung. Protokolle selbst dürfen dabei keine sensiblen Inhalte vervielfältigen.

Ebenso wichtig: Jeder produktive Agent braucht einen schnellen Kill Switch. Ein verantwortliches Team muss Zugänge, externe Tool-Aufrufe oder den gesamten Workflow ohne Deployment stoppen können. Ergänzen Sie das durch einen klaren Eskalationsweg: Wer bewertet Auffälligkeiten, wer informiert Datenschutz und IT-Security, wer dokumentiert die Korrektur?

Leitplanke 7: Den Pilot wie ein Betriebsprojekt behandeln

Ein KI-Pilot ist nicht fertig, wenn die Demo funktioniert. Prüfen Sie mit realistischen, aber freigegebenen Testdaten auch Fehlfälle: falsche Empfänger, ungewöhnliche Anhänge, widersprüchliche Anweisungen, nicht erreichbare APIs und missverständliche Freigaben. Halten Sie fest, was der Agent ausdrücklich nicht darf.

Bei FEHMER TECH beginnen AI-Automation-Projekte deshalb mit einem abgegrenzten Use-Case-Workshop statt mit einem großflächigen Tool-Rollout. Für einen klaren Pilot lassen sich Datenflüsse, Rollen, technische Grenzen und Betriebsverantwortung prüfen, bevor aus einer hilfreichen Automatisierung ein unkontrollierter Datenkanal wird.

Fazit: Automatisierung braucht Architektur, nicht nur Prompts

Der aktuelle Vorfall erinnert daran, dass KI-Agenten mit Werkzeugzugriff wie andere produktive Systeme behandelt werden müssen: mit Least Privilege, Freigaben, Protokollierung, Tests und einer klaren Abschaltmöglichkeit. So bleibt AI-Automation für Support, Reporting und Operations praktisch nutzbar, ohne den Schutz von Kunden- und Unternehmensdaten dem Zufall zu überlassen.

Quellen zum aktuellen Anlass: The Hindu, 26. September 2026; The Daily Star, 21. September 2026.