Stand: 05.10.2026

KI-Agenten, die fortlaufend auf einem eigenen Cloud-Rechner arbeiten, verändern nicht zuerst den Prompt – sondern die Verantwortung im Betrieb. Für KMU ist deshalb nicht entscheidend, einen Dauer-Agenten möglichst schnell einzuschalten. Entscheidend ist, für welche klar begrenzte Aufgabe er arbeiten darf, welche Daten und Rechte er erhält und wann ein Mensch eingreifen muss.

Aktueller Anlass: OpenAI hat Ende September mit Dots dauerhaft aktive KI-Agenten mit eigenem Cloud-Computer vorgestellt. Das macht die Diskussion für Teams konkret: Aus einer punktuellen KI-Anfrage kann ein System werden, das über längere Zeit Informationen verarbeitet und Arbeitsschritte anstößt. Genau dafür braucht es ein anderes Betriebsmodell als für einen einzelnen Chat.

Auf einen Blick

  • Dauer-Agenten verschieben Risiken von der Antwortqualität zu Identitäten, Zugriffsrechten und laufender Kontrolle.
  • Ein sinnvoller Einstieg ist ein eng abgegrenzter Read-only-Workflow, etwa Ticket-Zusammenfassungen oder ein täglicher Monitoring-Entwurf.
  • Schreibende oder auslösende Aktionen brauchen Freigaben, Limits und einen nachvollziehbaren Audit-Trail.
  • Für personenbezogene und vertrauliche Daten müssen Datenfluss, Aufbewahrung und Anbieterbedingungen vor dem Start geklärt sein.
  • Ein Pilot ist erst erfolgreich, wenn Nutzen, Fehlerrate und Eingriffsaufwand messbar sind.

Was an Dauer-Agenten anders ist

Ein klassischer Chat endet in der Regel mit einer Antwort. Ein Dauer-Agent kann dagegen über einen längeren Zeitraum Aufgaben verfolgen, Informationen sammeln und mit angebundenen Werkzeugen arbeiten. Die Meldungen zu OpenAI Dots stellen genau dieses Modell in den Mittelpunkt: einen dauerhaft aktiven Agenten mit eigener Cloud-Umgebung.

Damit steigt nicht automatisch der geschäftliche Nutzen. Es ändert sich aber die Risikoklasse. Ein falscher Chat-Text bleibt oft lokal und sichtbar. Ein Agent mit Zugriff auf E-Mail, Tickets, Kalender, Cloud-Dateien oder interne Systeme kann hingegen Entscheidungen vorbereiten, Daten zusammenführen oder Folgeaktionen auslösen. Ob er das darf, ist keine Modellfrage, sondern eine Architektur- und Betriebsfrage.

Für die AI-Automation bei FEHMER TECH bedeutet das: Ein produktiver Workflow beginnt nicht beim Tool-Namen, sondern beim konkreten Prozess. Wer ist fachlich verantwortlich? Welcher Output ist erlaubt? Welche Aktionen bleiben ausgeschlossen? Diese Fragen gehören vor die erste Verbindung zu einem Unternehmenssystem.

Welche Aufgaben sich für den ersten Pilot eignen

Geeignet sind Aufgaben mit klarer Eingabe, klarer Ausgabe und niedrigem Schadenspotenzial. Beispiele sind eine tägliche Zusammenfassung offener Tickets, ein Entwurf für einen Betriebsstatus, das Auffinden passender Runbook-Abschnitte oder die strukturierte Voranalyse eingehender Support-Anfragen. Der Agent unterstützt dabei Menschen, entscheidet aber nicht verbindlich nach außen.

Ungeeignet für einen ersten Pilot sind dagegen Zahlungen, Vertragsabschlüsse, Änderungen an Produktivsystemen, das Löschen von Daten oder die automatische Kommunikation mit Kunden. Solche Prozesse können später sinnvoll automatisierbar sein, brauchen aber zusätzliche Kontrollen und eine belastbare Freigabekette.

Die praktische Reihenfolge lautet: erst lesen, dann Vorschläge erzeugen, danach mit Freigabe schreiben oder auslösen. Wer diese Stufen überspringt, kann nicht sauber unterscheiden, ob der Nutzen aus der Automatisierung kommt oder ob Fehler und Nacharbeit nur verlagert werden.

Welche vier Grenzen jeder Agent braucht

1. Eigene Identität und minimale Rechte. Ein Agent darf nicht mit dem persönlichen Admin-Zugang eines Mitarbeiters arbeiten. Er braucht eine eigene, technisch getrennte Identität und nur die Berechtigungen, die der eine Workflow tatsächlich benötigt. Für viele Starts genügt Lesezugriff auf einen eng abgegrenzten Datenbestand.

2. Klare Datenzone. Vor dem Verbinden mit Tickets, Wissensdatenbanken oder Dateien muss feststehen, welche Inhalte verarbeitet werden dürfen. Personenbezogene Daten, Zugangsdaten, Schlüssel und vertrauliche Kundendokumente gehören nicht automatisch in einen KI-Workflow. Datenminimierung, Rollenrechte und die Prüfung des Auftragsverarbeitungs- beziehungsweise Hosting-Modells bleiben Pflicht – auch wenn der Agent technisch bequem anzubinden wäre.

3. Freigabe vor Wirkung. Entwürfe für Tickets, E-Mails, Statusmeldungen oder Änderungen müssen vor dem Versand oder der Ausführung von einer verantwortlichen Person freigegeben werden. Eine Freigabe ist kein Misstrauensvotum gegen KI, sondern eine technische Grenze zwischen Unterstützung und Handlung.

4. Stopp, Limit und Protokoll. Jeder Agent braucht einen einfach erreichbaren Ausschalter, ein Zeit- oder Ausgabenlimit und ein Protokoll der wesentlichen Schritte. Nachvollziehbar sein müssen mindestens Auftrag, verwendete Datenquellen, erzeugter Vorschlag, Freigabe und ausgeführte Aktion. Das hilft bei Fehleranalyse, Datenschutzfragen und der Weiterentwicklung des Prozesses.

Wie ein KMU-Pilot in vier Wochen aussehen kann

In Woche eins wird ein Prozess ausgewählt, der heute wiederkehrend Zeit kostet und dessen Qualität überprüfbar ist. Ein Beispiel: Aus zehn bis zwanzig Support-Tickets pro Tag entsteht ein interner Entwurf mit Kategorie, Dringlichkeit und vorgeschlagenem nächsten Schritt. Kein Ticket wird automatisch beantwortet.

In Woche zwei werden Datenquellen, Verantwortliche und Ausschlüsse dokumentiert. Dazu gehören die erlaubten Felder, die verbotenen Inhalte, das Rechtekonzept sowie ein Ablauf bei Fehlverhalten. In Woche drei läuft der Agent parallel zum bestehenden Prozess. Das Team vergleicht seine Vorschläge mit der manuellen Arbeit und hält Fehlerarten fest. Erst in Woche vier wird entschieden: Workflow verfeinern, ausweiten oder stoppen.

Als Messgrößen reichen zu Beginn wenige, ehrliche Werte: Bearbeitungszeit pro Vorgang, Anteil brauchbarer Vorschläge, Zahl notwendiger Korrekturen und Zeitaufwand für Kontrolle. Ein Pilot mit hoher Nacharbeit ist kein Erfolg, nur weil er technisch beeindruckend wirkt.

Security und Betrieb gehören zusammen

Ein Dauer-Agent ist ein weiterer digitaler Akteur in der Umgebung. Deshalb gehören seine Zugänge in die regelmäßige Prüfung von Rollen, Integrationen, Logs und Änderungen. Die gleiche Disziplin, die bei IT-Security, Monitoring und Runbooks sinnvoll ist, gilt auch für KI-Automation: Rechte klein halten, Änderungen dokumentieren, Fehlerwege üben und Systeme voneinander trennen.

Besonders wichtig ist die Trennung von Analyse und Ausführung. Ein Agent darf beispielsweise Incidents aus Monitoringdaten priorisieren und einen Entwurf erzeugen. Einen produktiven Neustart, eine Rechteänderung oder eine externe Nachricht sollte er ohne eindeutig definierten Freigabeschritt nicht auslösen. Die fachliche Verantwortung bleibt beim Team, auch wenn der Agent mehrere Zwischenschritte übernimmt.

Fazit

Die Vorstellung von OpenAI Dots zeigt, wohin sich AI-Automation entwickelt: weg vom einzelnen Chat, hin zu länger laufenden, werkzeugnutzenden Agenten. Für KMU ist das eine Chance für Support, Reporting und Operations – aber nur mit einem kleinen, messbaren Scope und festen technischen Grenzen. Starten Sie mit Lesezugriff und überprüfbaren Vorschlägen. Erst wenn Nutzen, Kontrolle und Datenfluss stimmen, ist der nächste Automatisierungsschritt sinnvoll.

Quellen