Innerhalb einer der ersten produktiven Einsätze von Lakebase: LangGuards agentisches Workflow-Governance-System

Das unsichtbare Problem mit Agenten-KI

Die meisten Unternehmen experimentieren mit autonomen KI-Agenten. Nur sehr wenige setzen sie sicher im großen Maßstab ein. Laut McKinseys Umfrage „The State of AI in 2025“ (November 2025) haben in keiner Geschäftsfunktion mehr als zehn Prozent der Unternehmen KI-Agenten in die Produktion skaliert. Das Scheitern liegt selten an mangelndem Ehrgeiz; es liegt an mangelnder Sichtbarkeit.

Im Gegensatz zu herkömmlicher Software generieren autonome Agenten ihre eigene Logik im Handumdrehen. Sie umgehen herkömmliche Sicherheitsüberwachungen, rufen Tools auf und greifen auf Daten zu, die im Nachhinein schwer zu überprüfen sind, und agieren in komplexen Multi-Agenten-Workflows, bei denen eine einzige falsch konfigurierte Berechtigung oder Richtlinienlücke zu einem erheblichen Sicherheitsvorfall eskalieren kann. Was Unternehmen benötigen, ist eine neue Kategorie von Kontrollinfrastruktur: eine, die in dem Moment operiert, in dem eine Entscheidung getroffen wird, nicht nachdem der Schaden bereits entstanden ist.

Das ist das Problem, das LangGuard lösen soll.

Laufzeiterzwingung trifft auf Plattform-Governance

LangGuard fungiert als Laufzeiterzwingungsschicht für Agenten-Workflows und überwacht und erzwingt Richtlinien über die End-to-End-Kette von Aktionen, Entscheidungen, Tools, Anmeldeinformationen und Absichten, die jedes System berühren, mit dem ein Agent interagiert. Databricks bietet vereinheitlichte Governance durch Unity Catalog und AI Gateway – das System of Record für Daten, Modelle und Zugriffsrichtlinien. Wenn Unternehmen Agenten in die Produktion einführen, benötigt der Workflow selbst auch eine Laufzeiterzwingungsschicht, die diese plattformweiten Kontrollen auf jeden Schritt der Agentenausführung erweitert. Dort kommt LangGuard ins Spiel. LangGuards Governance-Engine, das GRAIL™ (Governance AI Run-time Links) Daten-Fabric, erfasst jede Agentenaktion als multidimensionale Trace-Daten und konstruiert einen Live-Knowledge-Graphen des Workflow-Verhaltens und -Kontexts. Wenn ein Agent versucht, ein Tool aufzurufen, auf einen Datensatz zuzugreifen oder ein Modell aufzurufen, wertet LangGuard diese Aktion gegen die Richtlinie aus, bevor sie ausgeführt wird, über jedes System, das der Workflow berührt, unabhängig davon, wo er ausgeführt wird.

Die Skalierung einer Produktionsumgebung für Agenten-Deployments ist eine echte Herausforderung. Ein einzelner Workflow kann Dutzende koordinierter Agenten, Hunderte von Tool-Aufrufen, mehrere Foundation Models und Richtlinien umfassen, die über fünfzehn oder mehr Enterprise Systems of Record verwaltet werden, darunter IT-Ticketing-Systeme wie ServiceNow, IAM- und IDP-Plattformen, CRM-Systeme wie Salesforce, HR-Plattformen wie Workday, Cloud-Sicherheitsplattformen wie Wiz und CrowdStrike, Contact-Center-Plattformen wie TalkDesk, MCP Gateways und API Gateways. Dies in Echtzeit zu steuern, ohne die Agentenleistung zu beeinträchtigen, erfordert eine speziell für dieses Problem entwickelte Infrastruktur.

Warum wir Lakebase gewählt haben

Das LangGuard-Team hat jahrelang IBM QRadar entwickelt, einen mehrfachen Gartner Magic Quadrant Leader und eine der weltweit am weitesten verbreiteten SIEM-Plattformen für Unternehmen. QRadar verarbeitet und korreliert täglich Petabytes an Sicherheitstelemetrie unter strengen Latenz- und Zuverlässigkeitsanforderungen. Diese Erfahrung hat uns eine harte Lektion gelehrt: Die Datenbankarchitektur ist entscheidend. Als wir die Workflow-Governance-Engine von LangGuard entwarfen, standen wir vor der gleichen Herausforderung, die wir zuvor gelöst hatten: operative Sicherheitsdaten, die in unvorhersehbaren, hochintensiven Bursts eintreffen, bei denen jede Millisekunde Latenz bei der Entscheidungsfindung zählt und Leerlaufkosten für die Infrastruktur inakzeptabel sind. Herkömmliche Datenbanken, die Compute und Speicher koppeln, zwingen Sie, für die Spitzenlast zu provisionieren und diese Kapazität rund um die Uhr zu bezahlen. Das serverlose Modell von Lakebase, das Compute vollständig von Speicher entkoppelt und zwischen Bursts auf Null skaliert, war die Antwort, die wir uns immer gewünscht, aber beim Aufbau von QRadar nicht zur Verfügung hatten. Es passte genau zu unserem Problem.

Was Lakebase zur richtigen Wahl macht

Lakebase ist eine neue Kategorie von operativen Datenbankarchitekturen, die Compute von Speicher trennt, sodass sich Compute elastisch an die Workload-Nachfrage anpassen kann, während der dauerhafte Zustand unabhängig in einer replizierten Speicherschicht verbleibt. Aufbauend auf der offenen Grundlage von PostgreSQL bewahrt die Lakebase-Architektur alles, worauf sich Entwickler in einer bewährten relationalen Datenbank verlassen, und beseitigt gleichzeitig die Infrastruktureinschränkungen, die traditionelle, monolithische RDBMS für die Geschwindigkeit und Skalierbarkeit moderner Apps, Agenten und KI ungeeignet machen.

Serverloses Autoscaling und Scale-to-Zero

Das Verhalten von Agenten ist notorisch sprunghaft. Ein Agenten-Workflow kann stundenlang völlig ruhen und dann plötzlich innerhalb von Sekunden Hunderte von Trace-Schreibvorgängen und Enforcement-Lesevorgänge generieren. Lakebase stellt dynamisch Compute-Ressourcen bereit, sobald diese Traces unser System überfluten, und schaltet sich vollständig ab, wenn die Aktivität stoppt. Da der dauerhafte Zustand in der Speicherschicht und nicht im Compute-Knoten liegt, erfordert das Hochfahren einer neuen Compute-Instanz keine Datenbewegung. Sie verbindet sich einfach mit dem vorhandenen Datenbankverlauf und beginnt sofort mit der Abfragebearbeitung.

Für ein Startup, das im Enterprise-Maßstab tätig ist, ist dies der Unterschied zwischen einer Infrastruktur, die die tatsächliche Nutzung widerspiegelt, und einer Infrastruktur, die Sie für Ruhezeiten bestraft. Unsere Betriebskosten bleiben perfekt auf die Workloads abgestimmt, die wir tatsächlich bedienen.

Millisekunden-Leselatenz für operative Hot-Daten

Die natürliche Sorge bei jeder disaggregierten Datenbank ist die Leselatenz. Lakebase löst dies durch eine Caching-Schicht zwischen Compute und Speicher, die Hot-Daten nahe am Compute hält.

Für die Enforcement-Abfragen von LangGuard, bei denen es sich um eng indizierte Lookups gegen GRAIL™-Kontext- und Tabellen handelt, erwarten wir, dass der aktive Arbeitsdatensatz bequem in den lokalen Compute-Speicher passt. Diese Architektur gibt uns die Gewissheit, dass Governance-Entscheidungen mit Workflow-Geschwindigkeit erzwungen werden können, ohne die Agentenausführung merklich zu verzögern.

Sofortiges Datenbank-Branching für das Testen von Governance-Richtlinien

Das sofortige Datenbank-Branching von Lakebase ist eine seiner operativ wertvollsten Funktionen für ein Governance-Produkt. Wenn wir einen Branch erstellen, werden keine Daten physisch kopiert. Der Branch weicht vom aktuellen Datenbankzustand mithilfe von Copy-on-Write-Semantik ab und verbraucht Speicher nur für neue oder geänderte Daten. Unsere Entwickler können in Sekundenschnelle eine isolierte, exakte Kopie unserer Produktions-Trace-Daten erstellen, neue Governance-Richtlinien gegen reale Agentenverhaltensweisen testen und die Enforcement-Logik validieren, ohne die Stabilität der Live-Umgebung zu gefährden.

PostgreSQL: Eine bewährte Grundlage

Lakebase basiert auf PostgreSQL, der weltweit fortschrittlichsten Open-Source-Relationaldatenbank mit jahrzehntelanger Produktionshärtung in allen Branchen. Für LangGuard bedeutet dies volle Kompatibilität mit den Tools, Bibliotheken und Erweiterungen, die unser Team bereits kennt, ohne proprietäre Abfragesprachen oder Migrationsrisiken.

Wie LangGuard und Databricks zusammenarbeiten

Die gemeinsame Architektur von LangGuard und Databricks wurde entwickelt, um unternehmensweite Agenten-Workflows End-to-End zu steuern und gleichzeitig alle operativen Daten auf einer einzigen, vertrauenswürdigen Daten- und KI-Plattform zu halten. Auf der linken Seite der Architektur befinden sich die Enterprise Agentic Workflows selbst: KI-Agenten und ihre Orchestratoren, die mit Dutzenden von Systems of Record interagieren, wie z. B. IT-Service-Management, CRM, HR, Identitätsmanagement, Sicherheit, Contact Center sowie API/MCP-Gateways. Jede Agentenaktion, jeder Tool-Aufruf und jede Datenzugriffsanfrage generiert umfangreiche Trace-Ereignisse, die in Echtzeit an LangGuard fließen.

In der Mitte des Diagramms befindet sich die LangGuard Governance Workflow Engine, die von der zum Patent angemeldeten GRAIL™-Daten-Fabric angetrieben wird. GRAIL erfasst jede Agentenaktion als multidimensionale Trace-Daten und konstruiert einen Live-Knowledge-Graphen des Workflow-Verhaltens und -Kontexts. Wenn ein Agent versucht, ein Tool aufzurufen, auf einen Datensatz zuzugreifen oder ein Modell aufzurufen, führt LangGuard eine Richtlinienbewertung anhand dieses Live-Kontexts und der relevanten Governance-Regeln durch und gibt eine Zulassen/Ablehnen/Ändern-Entscheidung zurück, bevor die Aktion ausgeführt wird. Dies gibt Unternehmen einen einzigen Kontrollpunkt für die Durchsetzung von Richtlinien über jedes System, das der Workflow berührt, unabhängig davon, wo die zugrunde liegenden Agenten ausgeführt werden.

Auf der rechten Seite dient Databricks Lakebase als operativer System of Record für die Trace- und Richtliniendaten von LangGuard. Die serverlose PostgreSQL-Architektur von Lakebase trennt Compute von Speicher und ermöglicht elastisches Autoscaling und Scale-to-Zero zwischen Bursts von Agentenaktivitäten, während operative Hot-Daten in einem Low-Latency-Cache nahe am Compute gehalten werden. LangGuard schreibt kontinuierlich Trace-Ereignisse in Lakebase und führt Low-Latency-Lesevorgänge für Governance-Richtlinien-Lookups und kontextbezogene Abfragen durch, um sicherzustellen, dass Durchsetzungsentscheidungen mit Workflow-Geschwindigkeit getroffen werden können, ohne die Datenbankkapazität übermäßig zu provisionieren.

Da die operativen Daten von LangGuard nativ in Lakebase gespeichert sind, stehen sie der breiteren Databricks Data Intelligence Platform für Analysen und KI ohne zusätzlichen ETL-Aufwand sofort zur Verfügung. Databricks AI, Model Serving und MLflow können Anomalieerkennungsmodelle direkt auf GRAIL-Trace-Daten trainieren und bereitstellen, um Agenten zu identifizieren, die von ihrer etablierten Verhaltensbasis abweichen. Diese prädiktiven Signale fließen zurück in die LangGuard Governance Engine und schließen den Kreis zwischen Echtzeit-Durchsetzung und prädiktiver Überwachung, sodass Unternehmen von reaktiven Kontrollen zu proaktiver, verhaltensbasierter KI-Governance auf einer einzigen Plattform übergehen können.

Was kommt als Nächstes: Prädiktive Governance für Agenten-Workflows

Die Engine von LangGuard erzwingt heute etablierte Richtlinien zur Laufzeit über den gesamten Workflow hinweg. Die nächste Evolutionsstufe ist prädiktiv: Training von Verhaltensmodellen auf historischen GRAIL-Trace-Daten, um anomales Agentenverhalten zu erkennen, bevor es sich als Richtlinienverstoß manifestiert.

Da unsere operativen Trace-Daten bereits im Databricks-Ökosystem leben, wie oben beschrieben, können wir direkt von der Durchsetzung zur Vorhersage übergehen, ohne separate ETL-Pipelines aufzubauen oder eine zweite Analyseplattform einzurichten.

Wenn ein Agent anfängt, sich unberechenbar zu verhalten oder von seiner etablierten Basislinie abzuweichen, werden diese Modelle es als Anomalie kennzeichnen, bevor Schaden entsteht. Diese Konvergenz von Echtzeit-Durchsetzung und prädiktivem maschinellem Lernen ist die Zukunft der unternehmensweiten KI-Governance, und es ist die Architektur, die wir heute aufbauen.

Sind Sie bereit, Ihre agentenbasierten Workflows End-to-End zu verwalten? Besuchen Sie langguard.ai, um zu erfahren, wie LangGuard unternehmensweite agentenbasierte Workflows mit vollständiger Richtlinienkonformität sichert, steuert und betreibt, oder erkunden Sie Databricks Lakebase, um zu sehen, wie serverlose OLTP-Infrastruktur KI-Governance in Echtzeit in großem Maßstab ermöglicht.

Mehr über LangGuard erfahren Databricks Lakebase erkunden

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag