Langdock Governance: Agenten prüfen, Compliance-Regeln aufsetzen, Risiken im Blick

Stand: 28.10.2026

Alle Beispiele haben wir im DECAID-Demo-Workspace mit der fiktiven Firma Quellberg gebaut und getestet. Firma, Personen und Zahlen sind erfunden.

Kurz gesagt: Governance ist der Bereich in Langdock, in dem Admins alle Agenten, Skills und Integrationen eines Workspace sehen, sie gegen eigene Compliance-Regeln prüfen lassen und Agenten genehmigen, markieren oder deaktivieren. Regeln formulierst du in normaler Sprache, ein Prüfmodell wendet sie bei jeder neuen Agent-Version automatisch an. In unserem Test fand eine selbst geschriebene Regel unter 69 Agenten drei archivierte, die Termine, Teams-Nachrichten oder Daten ohne Bestätigung ändern durften, und erkannte einen frisch gebauten Agenten mit demselben Problem sofort beim Veröffentlichen.

Was ist Governance in Langdock?

Governance ist ein eigener Bereich, den Admins über den Workspace-Namen oben links öffnen. Er gliedert sich in Ressourcen (Agenten, Skills, Integrationen, Apps, Workflows) und Governance (Compliance-Regeln, Freigabeanfragen). Laut Doku richtet er sich an IT- und Security-Teams, Compliance-Verantwortliche und Plattform-Verantwortliche (Quelle: Langdock-Doku »Governance: Übersicht«).

Vier Dinge kannst du dort tun:

• Agenten prüfen: Liste mit Inhaber, Sichtbarkeit, Prüfstatus, Compliance-Ergebnis, Integrationsrisiko, Budget, Modell und Version. Je Agent eine Detailansicht mit Anweisungen, Integrationen, Freigabe, Nutzung, Kosten und Verlauf.
• Skills und Integrationen einsehen: Anweisungen, Dateien und Freigabe jedes Skills, Nutzung und Verbindungen jeder Integration.
• Compliance-Regeln festlegen: eigene Prüfungen in Textform, die jede neue Agent-Version automatisch durchläuft.
• Aufräumen: Ungenutzte Agenten archivierst du in Governance von Hand oder per Richtlinie automatisch. Sie bleiben im Tab Archiviert und lassen sich wiederherstellen (Quelle: Langdock-Doku »Agenten«).

Governance ist ein kostenpflichtiges Add-on, bis zum 01.01.2027 aber für alle Workspaces kostenlos. Danach wird es je Nutzer abgerechnet, der Preis hängt von der Zahl der Seats ab (Quelle: Langdock-Doku »Governance: Übersicht«).

Governance, Workspace-Einstellungen oder Rollen?

Quelle: Langdock-Doku »Governance: Übersicht« und »Workspace-Einstellungen«. Wie du den Workspace einrichtest, steht in unserem Artikel zum Langdock-Workspace-Setup.

So aktivierst du Governance

1. In den Einstellungen unter Produkte › Governance den Schalter Governance aktivieren einschalten. Alle Workspace-Admins haben dann vollen Zugriff.
2. Entscheiden, ob Private Ressourcen in Governance ausblenden an sein soll. Dann erscheinen Agenten, Skills, eigene Integrationen und MCP-Server, die mit niemandem geteilt sind, nicht in den Listen.
3. Personen ohne Admin-Rolle bekommen Zugriff über die Berechtigung Governance ansehen: als Extra-Berechtigung oder in einer eigenen Rolle (beides workspaceweit) oder für den Admin einer Gruppe (dann nur für Ressourcen, deren Inhaber in dieser Gruppe sind).
4. Unter Compliance-Regeln die ersten Regeln anlegen und auf bestehende Agenten anwenden.

Quelle: Langdock-Doku »Governance: Übersicht« und »Rollen und Extra-Berechtigungen«, abgerufen am 28.10.2026. Regeln anlegen, ändern und abschalten dürfen nur Admins (Quelle: Langdock-Doku »Compliance-Regeln«).

Praxisfall: Schreibende Aktionen nur mit Bestätigung

Quellberg ist ein fiktiver Getränkehersteller aus München. Die IT hat eine einfache Regel: Ein Agent darf Mails, Teams-Nachrichten, Dateien oder Termine nur anlegen oder ändern, wenn die Person vorher bestätigt. Bisher hat das niemand systematisch geprüft.

Die Regel. Unter Compliance-Regeln › Neue Regel bietet Langdock 13 Vorlagen an, alle auf Englisch, etwa zu EU AI Act, DSGVO, personenbezogenen Daten, Prompt Injection oder zu weit gefassten Berechtigungen. Für unseren Fall passte keine, also haben wir Von Grund auf starten gewählt und auf Deutsch geschrieben:

Fehlgeschlagen, wenn der Agent mindestens eine Integrationsaktion hat, die Daten anlegt, ändert, sendet oder löscht (zum Beispiel E-Mail senden, Antwortentwurf anlegen, Nachricht in Teams posten, Datei hochladen, Termin anlegen), und diese Aktion keine Bestätigung durch die Person verlangt. Reine Lese- und Suchaktionen zählen nicht. Bestanden, wenn alle schreibenden Aktionen eine Bestätigung verlangen oder der Agent keine schreibenden Aktionen hat.

Dazu Name, Beschreibung, Schweregrad Hoch und der Haken bei Bestehende Ressourcen jetzt prüfen, laut Dialog 69 Agenten.

Der Bestand. Das Prüfmodell ging alle 69 Agenten durch, auch die archivierten. Drei fielen durch, alle archiviert, jeweils mit einer genauen Begründung, zum Beispiel: »›Add event‹ und ›Update event‹ sind schreibende Kalenderaktionen und jeweils mit ›requiresConfirmation: false‹ konfiguriert.« 25 Agenten bewertete die Regel im ersten Durchgang gar nicht, ihr Ergebnis lautete »Fehler« mit dem Hinweis »Keine Begründung zurückgegeben«. Darunter war einer unserer aktiven Agenten, der in der Agentenliste trotzdem »Kein hohes Risiko« zeigte. Nach Alle erneut ausführen bestand er mit Begründung. Unsere beiden anderen aktiven Quellberg-Agenten bestanden gleich. Das stimmt mit ihrer Konfiguration überein, die wir per API gegengeprüft haben: Bei beiden stehen Antwortentwurf und Teams-Meldung auf Bestätigung.

Ein neuer Agent mit Lücke. Dann haben wir den Agenten Schnellantwort (Quellberg) angelegt, der Händlermails direkt als Outlook-Entwurf beantwortet, mit Draft reply to message ohne Bestätigung. Beim Veröffentlichen lief die Regel von selbst und meldete »Nicht bestanden«: »Die Aktion ›Draft reply to message‹ legt einen Antwortentwurf an, obwohl sie ›requiresConfirmation: false‹ … ist.« In der Liste stand der Agent sofort mit Compliance Hohes Risiko.

Deaktivieren, korrigieren, genehmigen. Wir haben den Agenten mit Begründung deaktiviert. Wer ihn danach im Chat öffnete, sah: »Dieser Agent ist deaktiviert. Du kannst ihn momentan nicht verwenden.« Nach der Korrektur (Bestätigung an) und einer neuen Version bestand der Agent die Regel automatisch, blieb aber gesperrt, bis wir die neue Version genehmigt hatten. Jeder Schritt steht mit Person und Zeit im Verlauf, Deaktivierung und Genehmigung mit unserer Begründung.

Was wir beim Testen gelernt haben

Getestet am 28.10.2026 im Workspace Quellberg.

Regeln lesen auch die Konfiguration. Unsere Regel erkannte, welche Aktion auf Bestätigung steht, und nannte die betroffene Aktion beim Namen. Laut Release Notes v7.24 können Compliance-Regeln Bestätigungseinstellungen prüfen. Bei allen Agenten, deren Konfiguration wir per API gegengeprüft haben (Vertriebsassistenz, Lieferzusage und beide Versionen der Schnellantwort), traf sie die richtige Entscheidung.

Ein Fehler sieht in der Liste aus wie bestanden. Konnte das Prüfmodell einen Agenten nicht bewerten, steht in der Regel der Status »Fehler«, in der Agentenliste aber weiter »Kein hohes Risiko«. Filtere nach jedem Lauf im Tab Agenten der Regel nach Fehler und führe die Prüfung für diese Agenten erneut aus. Bei dem Agenten, den wir neu geprüft haben, lieferte der zweite Lauf ein sauberes Ergebnis. Als wir die Regel am 30.10.2026 wieder einschalteten und alle bestehenden Agenten prüfen ließen, bekamen alle 78 binnen rund einer Minute ein Ergebnis, keiner stand auf »Fehler«. Fehler kommen also nicht jedes Mal vor, der Blick in den Filter lohnt sich trotzdem.

Das Integrationsrisiko ignoriert Bestätigungen. Die Spalte Integrationsrisiko zeigte bei jedem Agenten mit einer Aktion unter »Ändern« Hohes Risiko, auch wenn diese Aktion eine Bestätigung verlangt. Die Spalte kennt drei Stufen: Sicher, Möglich und Hohes Risiko; hohes Risiko bedeutet laut Doku, dass der Agent etwas ändern oder löschen kann. Wie Agenten tatsächlich abgesichert sind, zeigt erst eine eigene Regel.

Deaktivieren ist in der Oberfläche ein Kreislauf. In Governance wird ein deaktivierter Agent erst wieder nutzbar, wenn der Bearbeiter eine neue Version veröffentlicht und jemand diese genehmigt, so steht es auch in der Doku. Im Test bestand die korrigierte Version die Regel von selbst, der Agent blieb trotzdem gesperrt, bis wir genehmigt hatten. Plane also eine Person ein, die solche Genehmigungen zeitnah erledigt. Über die Agents API ging es in unserem Test anders: Am 29.10.2026 machte ein einziger Aufruf mit disabled: false einen gesperrten Agenten sofort wieder nutzbar, ohne neue Version und ohne Genehmigung, und eine Sperre per API trägt keine Begründung. Am 30.10.2026 antwortete derselbe Aufruf mit unserem API-Key bei jedem Agenten, auch bei aktiven, mit »Agent not found«; wiederholen konnten wir den Befund deshalb nicht. Leg deshalb fest, wer API-Keys mit diesem Recht nutzen darf.

Markieren bleibt intern. Den Agenten Lieferzusage (Quellberg) haben wir mit einer Notiz markiert. Er lief im Chat ohne jeden Hinweis weiter. So entsteht eine Prüfliste für das Admin-Team, ohne die Nutzer zu beunruhigen. Eine Markierung überlebt allerdings keine neue Version: Nach der nächsten Veröffentlichung stand der Agent wieder auf Prüfung ausstehend, die Notiz nur noch im Verlauf.

Eine Regel kostet fast nichts. Die Analytik der Regel zeigte nach 71 Ausführungen für 70 Agenten Gesamtkosten von rund 1 US-Cent. Als wir die Regel am 30.10.2026 erneut 78 Agenten prüfen ließen, stiegen die Kosten um rund 1,6 US-Cent. Laut Doku werden Regelkosten derzeit nicht berechnet und zählen nicht zu den Nutzungslimits.

Regeln prüfen auch archivierte Agenten. Die Agentenliste zeigte drei aktive Agenten, die Regel prüfte 69. Die übrigen 66 lagen im Tab Archiviert, und dort lagen auch alle drei Treffer. Archivierte Agenten kann niemand für neue Chats nutzen, ein Treffer dort ist also kein akutes Risiko. Er zeigt aber, was passiert, wenn jemand den Agenten wiederherstellt. Starte neue Regeln deshalb mit Bestehende Ressourcen jetzt prüfen. Schaltest du eine Regel später wieder ein, fragt Langdock erneut, ob die bestehenden Agenten geprüft werden sollen oder die Regel nur für künftige Änderungen gilt.

Regeln greifen erst mit der ersten veröffentlichten Version. Einen zweiten Test-Agenten, den wir per API angelegt, aber nie veröffentlicht hatten, führte Governance als »Entwurf« mit »Nicht geprüft«, obwohl er eine schreibende Aktion ohne Bestätigung hatte.

Skills und Integrationen

• Skills: Die Liste zeigt Inhaber, Sichtbarkeit, Verifizierung, Compliance, aktive Nutzer, Agenten, Integrationen und Dateien. In der Detailansicht stehen Anweisungen und Dateien des Skills. Über das Menü Skill verifizieren bekommt ein Skill ein Häkchen, das seit Version 7.24 auch in der Bibliothek und an Agenten angezeigt wird (Quelle: Release Notes v7.24). Genehmigen, Markieren und Deaktivieren gibt es für Skills noch nicht. Compliance-Regeln können seit Version 7.24 auch Skills prüfen.
• Integrationen: Kennzahlen zu Tool-Aufrufen, Verbindungen und Agenten mit Integrationen. Je Integration siehst du Aufrufe, Verbindungen, Agenten und Workflows und unter Logs jeden einzelnen Aufruf der letzten 14 Tage mit Status und Fehlercode (Quelle: Release Notes v7.20). Eigene Integrationen und MCP-Server erscheinen mit Ersteller und Freigabe, API-Keys bleiben verborgen.

Team, Admin und Governance

• Wer sieht was: Alle Admins sehen alles, sobald Governance aktiv ist. Wer Governance nicht sehen soll, darf kein Admin sein (Quelle: Langdock-Doku »Governance: Übersicht«).
• Wer bemerkt Governance: Bearbeitende eines Agenten merken erst etwas, wenn ihr Agent deaktiviert wird. Dann bekommen Inhaber und Bearbeitende die Begründung in ihre Inbox, Nutzer sehen sie nicht (Quelle: Langdock-Doku »Agenten« in Governance). In unserem Test waren Admin und Inhaber dieselbe Person, eine Inbox-Nachricht kam dabei nicht an.
• Keine Chat-Inhalte: Regeln prüfen ausschließlich die Einrichtung eines Agenten (Quelle: Langdock-Doku »Governance: Übersicht«).
• Betriebsrat: Governance wertet keine Chat-Inhalte aus, zeigt aber Personenbezug: wer welchen Agenten besitzt und bearbeitet und, unter Integrationen › Logs, jeden Tool-Aufruf mit Zeit, Aktion, ausführender Person und verbundenem Konto, auch als Export. Regel in der Betriebsvereinbarung deshalb, wer Governance sehen darf und wofür die Logs genutzt werden. Nutzungszahlen je Person stehen außerdem in Analytics und Usage-Exporten.
• Ohne Inhaber: Der Tab Ohne Inhaber zeigt Agenten von Personen, die gegangen sind, damit du sie neu zuweist (Quelle: Langdock-Doku »Agenten« in Governance).
• Freigabeanfragen: Im Bereich Freigabeanfragen erscheinen Anfragen, Agenten für eingeschränkte Empfänger freizugeben. Für Skills steht dort »Bald verfügbar« (Stand 28.10.2026). Eine Anfrage haben wir im Test nicht ausgelöst.

Grenzen und Limits

Quellen: Langdock-Doku »Governance: Übersicht«, »Agenten«, »Skills«, »Compliance-Regeln«; Release Notes v7.16 bis v7.24, abgerufen am 28.10.2026; Vorlagen und Kosten aus eigenem Test vom 28.10.2026.

Häufige Fragen

Was kostet Langdock Governance?

Bis zum 01.01.2027 nichts. Danach ist Governance ein Add-on, das je Nutzer abgerechnet wird, der Preis sinkt mit der Größe des Workspace. Die aktuellen Preise stehen auf der Preisseite von Langdock.

Liest Governance unsere Chats mit?

Nein. Compliance-Regeln prüfen die Einrichtung und Anweisungen von Agenten. Die Analytik zeigt Nachrichten- und Nutzerzahlen je Agent, keine Inhalte. Die Logs der Integrationen zeigen allerdings, wer wann welche Aktion ausgelöst hat.

Wie schreibe ich eine gute Compliance-Regel?

Formulier eine klare Fehlerbedingung, sag ausdrücklich, was nicht zählt, und beschreib, wann ein Agent besteht. Starte sie mit Bestehende Ressourcen jetzt prüfen und lies die Begründungen der ersten Treffer, bevor du sie scharf nutzt. Unsere deutsch formulierte Regel funktionierte, obwohl alle Vorlagen englisch sind.

Was passiert, wenn ich einen Agenten deaktiviere?

Niemand kann ihn mehr nutzen. Inhaber und Bearbeitende bekommen deine Begründung. In Governance wird er erst mit einer neuen Version wieder nutzbar, die du genehmigst; ein Admin kann ihn außerdem direkt über die Agents API wieder freischalten.

Wer darf Governance sehen?

Alle Admins, sobald Governance aktiv ist. Andere Personen bekommen die Berechtigung Governance ansehen über eine Extra-Berechtigung, eine Rolle oder als Admin einer Gruppe. Regeln anlegen und ändern bleibt bei Admins.

Brauchen wir Governance bei wenigen Agenten?

Sobald Agenten mit Integrationen geteilt werden, lohnt sich mindestens eine Regel für schreibende Aktionen. In unserem Test fand sie Lücken in drei archivierten Agenten und in einem neuen Agenten gleich beim Veröffentlichen.

Ihr wollt wissen, welche Agenten in eurem Workspace was dürfen? Wir richten Governance mit euch ein, schreiben eure ersten Compliance-Regeln und bereiten die Abstimmung mit Datenschutz und Betriebsrat vor. Gespräch mit uns vereinbaren