OpenBot im Check: Was selbst gehostete KI-Kollegen wirklich brauchen

Ein KI-Kollege braucht mehr als einen Browser und eine Stellenbeschreibung

OpenBot ist eine MIT-lizenzierte Vorlage von CopilotKit für KI-Kollegen auf selbst betriebener Infrastruktur. Sie verbindet eine Agentenoberfläche, Browser, Dateien, Shell-Zugriff und MCP-Integrationen mit einer serverseitigen Prüfung von Regeln und einem Audit-Protokoll. Das Modell und den Betrieb stellst du selbst bereit.

Das ist für Teams interessant, die mehr Kontrolle benötigen, als eine fertige Assistenzsoftware bietet. Es macht OpenBot aber nicht zu einem schlüsselfertigen, vollständig offline nutzbaren oder automatisch sicheren Ersatz für Grok Bot. Die aktuelle OpenBot-README bezeichnet das Projekt ausdrücklich als Alpha-Vorlage, nicht als fertiges Produkt, dessen Betrieb jemand anderes übernimmt.

Unsere Empfehlung: Prüfe OpenBot für einen klar begrenzten, beaufsichtigten Geschäftsprozess, wenn anpassbare Berechtigungen und eigener Betrieb tatsächlich erforderlich sind. Kostenloser Quellcode allein ist kein ausreichender Beschaffungsgrund.

Prüfmethode: dokumentenbasierte Bewertung von OpenBot-Commit 1c7bd923fd1ec14ef15f7d6ab6e33ad73c72f2a4, geprüft am 10. September 2026. Wir haben OpenBot weder installiert noch einem Penetrationstest unterzogen. Beispiele und Pilotkriterien sind unser vorgeschlagener Prüfrahmen, keine gemessenen Produktergebnisse.

Was bietet OpenBot?

Das Beispielpaket enthält General Assistant für Alltagsaufgaben, Knowledge für Unternehmensfragen und Risk Analyst für risikobezogene Aufgaben. Das sind konfigurierbare Rollen, keine drei unabhängig geprüften Spezialisten. Der Name Risk Analyst belegt weder Compliance-Kompetenz noch Entscheidungsbefugnis.

Ein KI-Kollege kann einen Browser mit gespeicherten Anmeldungen nutzen, Dateien bearbeiten und freigegebene Werkzeuge aufrufen. Google Drive und Notion stehen im aktuellen MCP-Katalog. Die Plattform akzeptiert Agenten, die AG-UI sprechen. Du kannst daher ein unterstütztes Framework oder einen eigenen kompatiblen Endpunkt anbinden. OpenBot selbst ist kein Sprachmodell.

Name, Rolle und Anweisungen über die Oberfläche anzulegen, ist der einfache Teil. Modellzugriff, Endpunkte, Berechtigungen, Datenquellen und Abnahmetests brauchen weiterhin Verantwortliche. Die aktuelle Deployment-Dokumentation unterscheidet außerdem, welche Beispielagenten ohne einen konfigurierten Standard-Agentenendpunkt verfügbar sind.

Der entscheidende Aufbau: erst Regeln, dann Protokoll, dann Ausführung

Die OpenBot-Architekturdokumentation verortet die Aktionskontrolle auf dem Server, nicht in den Modellanweisungen. Bei darüber geleiteten Computeraktionen löst das Gateway das Ziel auf, prüft die Richtlinie, schreibt die Entscheidung ins Audit-Protokoll und leitet nur erlaubte Aktionen weiter. Ausführungsfehler erhalten einen zusätzlichen Eintrag.

Agentenanfrage → Ziel auflösen → Richtlinie prüfen → Entscheidung protokollieren → ausführen oder ablehnen

Das ist belastbarer als die Aufforderung an ein Modell, vorsichtig zu sein. Prüfer können nachvollziehen, welche Regel eine Aktion erlaubt oder abgelehnt hat, statt nachträglich die Erklärung des Assistenten zu interpretieren.

Eine protokollierte Freigabe beweist allerdings nicht, dass das Geschäftsergebnis richtig war. Ein Gateway-Eintrag macht einen externen Schreibzugriff auch nicht atomar, rückgängig machbar oder beliebig wiederholbar. Ein doppelt angelegter Lieferant bleibt ein Fehler, selbst wenn beide Anfragen sauber dokumentiert sind. Diese Eigenschaften benötigen eine eigene technische Lösung.

Die Kontrolle gilt zudem für Aktionen, die durch die Plattform laufen. Sie ist keine Garantie dafür, dass beliebiger Code oder ein separat betriebener Agentenendpunkt niemals außerhalb dieses Weges handeln kann.

Verweigert OpenBot standardmäßig alle Aktionen?

Die Regelprüfung verweigert bei fehlender Erlaubnis den Zugriff. Die mitgelieferte Startkonfiguration erlaubt jedoch ausdrücklich alle Aktionen. Beides ist auseinanderzuhalten.

Laut Architekturdokumentation erlaubt eine fehlende oder leere Richtlinie nichts. Verbote haben Vorrang vor Erlaubnissen; ein fehlerhafter Verbotsausdruck führt zur Ablehnung, ein fehlerhafter Erlaubnisausdruck gewährt keinen Zugriff. Beim Start wird allerdings eine ausdrückliche Richtlinie mit deny: [] und allow: ["true"] gesetzt, solange keine Umgebungsvariable oder gespeicherte Administratorrichtlinie sie ersetzt.

„Ohne Richtlinie ist nichts erlaubt“ bedeutet deshalb nicht, dass eine frische Installation bereits eine restriktive Unternehmensrichtlinie besitzt. Ersetze die großzügige Startkonfiguration vor der Anbindung von Unternehmenskonten durch geprüfte Freigaben. Teste erlaubte und verbotene Aktionen.

Dafür nutzt OpenBot Common Expression Language (CEL). CEL ist eine eingebettete Ausdruckssprache, kein Prompt an ein zweites Modell. Regeln lassen sich damit gegen den Aktionskontext prüfen und gezielt testen. Ihre Qualität hängt weiterhin von den bereitgestellten Datenfeldern und deinen formulierten Bedingungen ab.

Die grundsätzliche Abgrenzung zwischen Werkzeuganbindung und Berechtigung erklärt unser Beitrag warum MCP nicht die Sicherheitsgrenze ist.

Ist jeder KI-Kollege isoliert?

Die Isolation hängt von der tatsächlich eingesetzten Betriebsarchitektur ab. Mit konfiguriertem Supervisor bekommt jeder Bot einen eigenen Computer-Container, ein eigenes Arbeitsverzeichnis-Volume und ein eigenes Chromium-Profil. Ohne Supervisor können sich Bots den konfigurierten Computer teilen.

Das ist wichtig, weil der aktuelle OpenBot-Deployment-Guide auch ein Ein-Container-Image ohne Supervisor anbietet. In diesem Betriebsmodell teilen Bots Browser, Dateien und Anmeldungen. Die Dokumentation warnt ausdrücklich davor, diese gemeinsame Umgebung als Trennung zwischen Mandanten zu behandeln.

Frage vor einer Freigabe deshalb nach der tatsächlich laufenden Architektur. Der Hinweis auf Container in der README reicht nicht. Ein anderer Bot-Name ist keine Sicherheitsgrenze. Ein separater Container beschränkt auch nicht automatisch die erreichbaren Netzwerkziele oder die darin angemeldeten Konten.

Das unterscheidet sich von Ramp Inspects kurzlebiger Umgebung pro Programmiersitzung. OpenBots dauerhafte Mitarbeiterprofile und Arbeitsverzeichnisse benötigen eigene Regeln für Aufbewahrung, Zurücksetzen und Entzug von Kontozugriffen. Wer nur eine isolierte Ausführungsplattform sucht, statt einer vollständigen KI-Kollegen-Anwendung, kann die OpenSandbox-Plattform vergleichen.

Was passiert bei Anmeldung oder Zwei-Faktor-Authentifizierung?

OpenBot dokumentiert eine menschliche Übernahme im selben Browserbereich. Eine Person übernimmt die Steuerung für eine Anmeldung oder einen anderen betreuungsbedürftigen Schritt und gibt sie anschließend zurück. Währenddessen werden Browseraktionen des Bots abgelehnt, nicht für später aufgestaut.

Das ist eine sinnvolle Interaktionsregel. Der Bot sammelt keine Aktionen an, während ein Mensch die Seite verändert oder Zugangsdaten eingibt. Daraus entsteht jedoch keine pauschale Erlaubnis für die nächsten Schritte nach der Rückgabe.

Der vorgesehene Eingabeweg für Geheimnisse ist vom Chat getrennt; entsprechende Audit-Ereignisse speichern Metadaten statt des Geheimnisses. Behandle Browserprofile, aktive Anmeldungen, Screenshots und Werkzeugausgaben trotzdem als sensible Informationen. Ein geschützter Passworteingabeschritt macht spätere Beobachtungen nicht automatisch unkritisch.

Nutze im Pilot ein auf die Aufgabe begrenztes Konto. Prüfe, ob Abmelden oder Rechteentzug tatsächlich wirken. Eine abgeschlossene Zwei-Faktor-Anmeldung belegt die Authentifizierung einer Person. Sie berechtigt den KI-Kollegen nicht automatisch dazu, Nachrichten zu senden, Vertragsbedingungen anzunehmen oder Einkäufe freizugeben.

Ist OpenBot vollständig selbst gehostet oder vollständig lokal?

Du kannst OpenBot selbst betreiben, musst aber den gesamten Datenweg betrachten. Die aktuelle Konfigurationsreferenz verlangt Verbindungsdaten für CopilotKit Intelligence. Sie unterstützt außerdem kompatible Modellendpunkte: eine Anbieter-API, ein Gateway oder eigene Infrastruktur.

Ein lokales Modell verändert die Inferenzebene. Es verschiebt Gesprächsspeicherung oder angebundene Unternehmensdienste nicht automatisch auf deinen Rechner.

Beim aktuellen verwalteten Intelligence-Angebot reicht der Projektschlüssel ohne zusätzliches Lizenz-Token. Eine selbst betriebene Intelligence-Installation kann eine eigene Berechtigungskonfiguration benötigen. Folge der versionsgebundenen Dokumentation statt den Startbefehlen eines älteren Tutorials.

Was kostet OpenBot außer Modell-Tokens?

Die MIT-Lizenz gilt für OpenBots Code. Zusätzlich fallen je nach Aufbau Rechenleistung, PostgreSQL, Speicher, Sicherungen, Modellnutzung, das gewählte Intelligence-Angebot, Integrationspflege und Betriebsaufwand an.

Am 10. September 2026 nennt CopilotKits Preisseite für den kostenlosen Developer-Tarif einen Entwickler, 200 Gesprächsverläufe und drei Tage Aufbewahrung. Eigenbetrieb umfasst dort nur die Laufzeitumgebung. Kläre Speicher- und Betriebsbedingungen: kostenlos bedeutet weder unbegrenzt noch vollständig lokal.

Für die Planung eignet sich:

Kosten pro abgenommener Aufgabe = (Modell + Hosting + Speicherung + Betrieb + Prüfung + Nacharbeit) ÷ abgenommene Aufgaben

Definiere im Nenner ein konkretes akzeptiertes Ergebnis. Eine niedrige Token-Rechnung spart nichts, wenn Beschäftigte die Arbeit wiederholen oder fehlende Nachweise rekonstruieren müssen. Die geprüften öffentlichen Quellen belegen keinen Kostenvorteil für deinen konkreten Prozess.

OpenBot oder Grok Bot: Betriebsverantwortung statt angenommener Funktionsgleichheit

OpenBot als Grok-Bot-Alternative zu bezeichnen, beschreibt eine Beschaffungsentscheidung, keine bewiesene Gleichwertigkeit. Die offizielle Grok-Bot-Teamdokumentation nennt verwaltete Cloud-Computer, Firecracker-Isolation pro Nutzer, einen gemeinsamen Computer für dessen Bots und Freigabekontrollen. Verwaltungsfunktionen hängen vom Tarif ab.

Kein Ansatz ist automatisch sicherer oder günstiger. Für einen üblichen Geschäftsprozess kann eine gepflegte Standardlösung die bessere Wahl sein. Unser Vergleich von Individualsoftware und Standardsoftware erläutert, wann sich eigener Betrieb und Anpassbarkeit lohnen.

Ein sinnvoller OpenBot-Pilot für ein Unternehmen

Beginne mit Dokumentenvorbereitung, nicht mit Zahlungen oder Produktionsadministration. Ein mögliches Beispiel ist eine Lieferantenaufnahme: freigegebene Dokumente abrufen, fehlende Nachweise identifizieren und einen Entwurf zur menschlichen Freigabe erstellen. Der KI-Kollege darf dabei weder einen Lieferanten aktivieren noch den Entwurf extern versenden oder eine Rechnung genehmigen.

Das Kontrollmodell sollte OWASPs Empfehlungen gegen übermäßige Handlungsbefugnis folgen: Funktionen, Rechte und Autonomie begrenzen, Berechtigungen in den Zielsystemen durchsetzen und folgenschwere Aktionen freigeben lassen.

Tage 1–3: Grenzen festlegen. Bestimme Verantwortliche, einen Prozess, einen festen Aufgabensatz und erwartete Ergebnisse. Verwende synthetische oder freigegebene Testdokumente. Halte OpenBot-Revision, Modell und Betriebsarchitektur fest. Ersetze die großzügige Startrichtlinie und richte Anmeldung ein, bevor andere Nutzer den Dienst erreichen können.

Tage 4–7: Kontrollen prüfen. Erlaubte Lesezugriffe müssen funktionieren, untersagte Schreibzugriffe müssen scheitern. Prüfe, dass ohne erforderlichen Audit-Eintrag keine Aktion ausgeführt wird. Teste menschliche Browserübernahme und Rückgabe sowie die Trennung von Arbeitsverzeichnissen und Konten im gewählten Betriebsmodell.

Tage 8–10: Betrieb prüfen. Starte das System neu, stelle die Audit-Datenbank wieder her, prüfe die tatsächliche Gesprächsaufbewahrung und entziehe einem verbundenen Konto den Zugriff. Teste fehlgeschlagene und wiederholte Werkzeugaufrufe, ohne doppelte Geschäftsänderungen zuzulassen. Dokumentiere die Wiederherstellung statt dich auf einen grünen Container-Status zu verlassen.

Tage 11–14: Ergebnisse vergleichen. Miss Abschlussquote, Prüfzeit, Korrekturen, Modellkosten und Betrieb gegen den bestehenden Ablauf. Erweitere den Einsatz nur, wenn Qualität, Berechtigungen und Gesamtaufwand überzeugen. Andernfalls grenze die Aufgabe enger ein, baue eine deterministische Integration oder kaufe eine verwaltete Lösung.

Wann solltest du OpenBot wählen?

Ein kontrollierter Pilot passt, wenn ein technischer Verantwortlicher, ein konkreter Prozess und ein nachvollziehbarer Anpassungsbedarf vorhanden sind. Verschiebe ihn, wenn du vor allem einen betreuten Assistenten mit wenig Wartung suchst oder niemand Anmeldung, Berechtigungen und Wiederherstellung verantwortet.

Wavects KI-Beratung hilft, diese Entscheidung vor einem Plattformprojekt zu klären. Ein sinnvoller erster Liefergegenstand ist eine Datenflussübersicht, eine Berechtigungsmatrix, ein repräsentativer Aufgabensatz und eine begründete Start-oder-Stopp-Empfehlung. Die Twinsoft-AI-Fallstudie zeigt unseren Hintergrund bei wartbaren, für echte Nutzung vorbereiteten KI-Anwendungen. Sie ist kein Nachweis eines OpenBot-Projekts.

Besprich einen OpenBot-Machbarkeitspilot für einen Prozess mit klaren Abnahmekriterien, statt mit einer unternehmensweiten Einführung zu starten.

Der Nutzen liegt nicht darin, KI-Kollegen möglichst viele Zugriffe zu geben. Er liegt darin, gewährten Zugriff ausdrücklich zu regeln, nachvollziehbar zu machen und wirtschaftlich zu rechtfertigen. OpenBot ist ein Ausgangspunkt für diese Arbeit, kein Ersatz dafür.