Das Unternehmensgehirn verliert Geheimnisse: Wie wir es bei Großbanken gestoppt haben — Tanmai Gopal, PromptQL

AAI Engineer
Computing/SoftwareManagement

Transcript

00:00:00Alles klar, alle können es sehen.
00:00:15Hallo zusammen.
00:00:17Danke, dass ihr da seid.
00:00:18Ich möchte über die Tatsache sprechen, dass wenn man
00:00:23einfach so ein Firmengehirn aufbaut, das wahrscheinlich
00:00:25Unternehmensgeheimnisse durchsickern lässt, was ohnehin
00:00:28die große Befürchtung ist, die wir beim Aufbau eines Firmengehirns haben,
00:00:32nämlich dieser Fall, in dem ein Praktikant ins Unternehmen kommt
00:00:34und plötzlich Gehaltsdetails erfährt und solche
00:00:36Situationen.
00:00:37Dagegen möchte man sich schützen.
00:00:40Das war so ziemlich das größte Hindernis,
00:00:43das uns bisher davon abgehalten hat, OpenClaw
00:00:47und Hermes überall einzusetzen.
00:00:49Das ist auch irgendwie der Grund –
00:00:50es ist wie diese große Chance, die ClaudeTag
00:00:52bei seiner kürzlichen Einführung vor ein paar Tagen hatte, wo
00:00:54es das Firmengehirn sein sollte,
00:00:56aber dann dachten alle, nun ja, es
00:00:57sieht nicht so aus, als würde es das Firmengehirn
00:01:00werden, oder?
00:01:01Deshalb werde ich darüber sprechen, was das so schwierig macht.
00:01:03Bevor wir dazu kommen, lasst uns dieses ganze Firmengehirn-Thema
00:01:07ein bisschen verstehen und auseinandernehmen, oder?
00:01:09Ich bin Tanmay.
00:01:10Ich bin der CEO und Mitgründer von PromptQL.
00:01:13Ihr könnt euch PromptQL später ansehen, aber unser Hintergrund als Team,
00:01:18das dies entwickelt hat, wir kommen vom Hustle Graph –
00:01:21wir sind die Entwickler der Hustle GraphQL-Engine.
00:01:23Das ist ein sehr beliebtes Open-Source-Projekt im GraphQL-Bereich,
00:01:26in dem wir viele Datenzugriffsprobleme lösen.
00:01:28Wir haben es überall eingesetzt, von Apple über Meta bis hin zu JPMorgan
00:01:32und so weiter.
00:01:33Und das hat uns eine Menge dieser Grundlage gegeben für –
00:01:39und so eine Hass-Liebe-Beziehung zu Daten
00:01:43und Datensicherheit.
00:01:44Ich werde euch also Dinge zeigen, an denen wir im letzten Jahr gearbeitet
00:01:51haben und was wir daraus gelernt haben, damit
00:01:53ihr das mitnehmen, anwenden und für euch selbst
00:01:56ausprobieren könnt.
00:01:58Und am Ende des Vortrags freue ich mich natürlich darauf, Notizen
00:02:01auszutauschen und zu sehen, was für euch funktioniert oder vielleicht auch nicht.
00:02:06Im letzten Jahr haben wir nur mit einer kleinen Gruppe von Leuten
00:02:08zusammengearbeitet, die eine gewisse Skalierungsspitze aufgewiesen haben.
00:02:12Bisher sind das etwa 15 bis 20 Personen.
00:02:15Und jetzt fangen wir gerade an, es für andere zu öffnen.
00:02:17Aber in dieser Zeit haben wir uns drei verschiedene
00:02:20Gruppen von Menschen mit sehr unterschiedlichen Bedürfnissen angesehen.
00:02:22Da gibt es KI-native Unternehmen, die bereit sind, einfach
00:02:25alles zu tun, solange es funktioniert.
00:02:27Dann gibt es technologieorientierte Unternehmen wie Instacart,
00:02:30die Best-of-Breed-Technologie mögen.
00:02:33Sie handeln also schnell.
00:02:34Sie tolerieren es auch, wenn mal etwas kaputtgeht.
00:02:36Aber es muss wirklich, wirklich gut sein, oder?
00:02:38Und dann gibt es Fortune-100-Banken, die ein wahnsinniges
00:02:41Maß an Sicherheit haben.
00:02:43Gott sei Dank tun sie das, denn das ist meine Bank.
00:02:45Ich möchte definitiv nicht, dass Vibe-codierte KI-Agenten
00:02:48in einer Bank laufen, denn dort ist mein Geld.
00:02:51Daher haben sie viele Sicherheitsregeln.
00:02:54Vielen Dank.
00:02:55Aber wir sind auch an solchen Orten im Einsatz,
00:02:59und zwar mit den Anfängen oder sozusagen dem Frontallappen
00:03:01einer Unternehmensmarke, oder?
00:03:02Wir können also über diese Art von Erkenntnissen sprechen.
00:03:05Unsere eigene persönliche Nutzung beim Aufbau unseres Firmengehirns
00:03:10umfasst etwa 5.000 Seiten.
00:03:13Wir bilden es als Wiki ab.
00:03:14Ihr könnt es abbilden, wie ihr wollt.
00:03:16Ihr könnt es als eine Reihe von Markdown-Dateien auf GitHub modellieren.
00:03:17Ihr könnt es in – erinnert ihr euch an Graph Frag? –
00:03:21ihr könnt es in Wissensgraphen modellieren.
00:03:23Ihr könnt tun und lassen, was ihr wollt.
00:03:25Ihr könnt es also platzieren, wo immer ihr wollt.
00:03:27Aber für uns sind es ungefähr 5.000 miteinander verknüpfte Seiten.
00:03:32Frage an euch.
00:03:33Angenommen, ihr hättet ein Firmengehirn, das funktionierte.
00:03:36Es funktionierte gut.
00:03:37Es war komplett eingerichtet, oder?
00:03:40Es gäbe eine gewisse tägliche Anzahl an Updates,
00:03:41die an diesem Firmengehirn vorgenommen würden, oder?
00:03:44Weil es Dinge von jedem im Unternehmen lernen würde, richtig?
00:03:47Oder?
00:03:47Von der Finanzabteilung über HR und eure Ingenieure bis hin zu allen.
00:03:52Wenn man also die tägliche Anzahl der Updates im Firmengehirn
00:03:55aufzeichnen würde, wie würde das wohl aussehen?
00:04:00Würde es eher wie ein Abwärtstrend aussehen?
00:04:04Das sind alles so zufällige Graphen.
00:04:05Aber würde es anfangen und dann nach unten gehen?
00:04:09Würde es eher stabil sein und bei Update-Spitzen auf und ab gehen?
00:04:12Oder würde es kontinuierlich nach oben steigen?
00:04:16Überlegt mal, wie die Commit-Historie
00:04:18eures Repositories für geteilte Fähigkeiten aussehen würde, oder?
00:04:21Wie viele Updates passieren bei einem gesunden Firmengehirn
00:04:26eigentlich jeden Tag?
00:04:27Wie sieht dieser Trend aus?
00:04:29Gibt es Stimmen für Option A?
00:04:31Glaubt jemand, es ist Option A?
00:04:33Okay, gut.
00:04:34Option B?
00:04:37Option C?
00:04:39Das ist nett.
00:04:41Als ich also unsere Daten aufgezeichnet habe, um zu sehen,
00:04:44wie ein gesundes Firmengehirn aussieht,
00:04:47besagt Nummer eins im Grunde Folgendes:
00:04:50Wir hatten eine Menge Enthusiasmus.
00:04:53Wir haben das Firmengehirn an Tag eins und Tag zwei aufgebaut.
00:04:56Wir haben jemandem die Aufgabe gegeben und gesagt:
00:04:57Erstelle das Repository für alle geteilten Fähigkeiten,
00:04:59durchsuche den ganzen Slack, durchsuche alle E-Mails, bau es auf
00:05:02und wir werden es alle nutzen.
00:05:03Und dann kümmert es niemanden, oder?
00:05:05Oder man hat ein System, das selbstlernend ist.
00:05:07Vielleicht habt ihr intern einen Hermes im Einsatz.
00:05:09Ich schaue mir also an, wie kontinuierlich mehr und mehr
00:05:11Kommentare hinzugefügt werden.
00:05:12Es geht je nach Begeisterung mal rauf und runter, richtig?
00:05:14Oder?
00:05:15Und als ich dann unsere Historie über die letzten zwei Monate aufgezeichnet
00:05:19habe – und das ist inzwischen schon ein bisschen veraltet –
00:05:22da haben wir das hier bekommen.
00:05:24Und ich war ziemlich schockiert.
00:05:26Ich dachte: Warum steigt das kontinuierlich an?
00:05:30Es ist eine sanfte Kurve, oder?
00:05:32Aber warum steigt es ganz sanft an?
00:05:34Warum nimmt die Zahl der Updates pro Tag zu?
00:05:38Das war faszinierend für mich zu sehen.
00:05:39Denn mir wurde klar: Wenn man ein System hat, das zu
00:05:42funktionieren beginnt, fangen die Leute an, ihm viel mehr beizubringen.
00:05:46Das ist so, als ob ich Ihnen die Fähigkeit zur Datenabfrage beibringe,
00:05:50und morgen bringe ich Ihnen bei, diese Daten zu interpretieren.
00:05:53Und übermorgen bringe ich
00:05:55Ihnen bei, darauf basierend eine Aktion auszuführen.
00:05:57Und danach überlege ich mir,
00:05:59wie man A/B-Tests macht – die Leute
00:06:00wie Sie fügen also kontinuierlich mehr hinzu.
00:06:03Aber weil alles ein Agent ist, bei dem kein Lernprozess
00:06:05perfekt ist, hat alles auch eine Art eigene konstante Rate, oder?
00:06:08Nicht wahr?
00:06:08Die Raten summieren sich also...
00:06:10sogar Ihre konstanten Raten summieren sich immer weiter.
00:06:12Und das ist mir auch bei unserem Ding aufgefallen.
00:06:15Das ist noch früh, wer weiß, ob es irgendwann abflaut.
00:06:18Vielleicht sieht es bald eher aus wie Option B.
00:06:20Aber bei einem gesunden Gehirn wächst natürlich die Gesamtgröße weiter.
00:06:24Sogar Ihre täglichen Updates steigen dabei ebenfalls an.
00:06:28Das ist also ein Zeichen für ein gutes Gehirn, das Sie gebaut haben, oder?
00:06:32Ein gesundes Gehirn, das Sie für Ihr Unternehmen geschaffen haben.
00:06:35Fantastisch.
00:06:36Anwendungsfälle für ein Unternehmensgehirn nutzen wir nun, um zu analysieren,
00:06:39wie wir ein System bauen, das keine Geheimnisse preisgibt, oder?
00:06:42Also zwei Anwendungsfälle.
00:06:44Der erste Anwendungsfall ist: Es gibt ein Unternehmensgehirn.
00:06:48Ich möchte es in meiner KI, meinem Agenten oder sonst wo nutzen, um Arbeit zu erledigen, richtig?
00:06:55Ich zeige Ihnen ein Beispiel dafür.
00:06:56Es ist so, als hätte ich eine E-Mail mit einem Sicherheitsfragebogen erhalten,
00:06:59den ich von einem Kunden beantworten muss.
00:07:00Und ich spreche mit meiner KI und sage: Schau im Unternehmensgehirn nach
00:07:03und hilf mir, den Sicherheitsfragebogen zu beantworten.
00:07:05Das ist also ein völlig gültiger Anwendungsfall für ein Unternehmensgehirn.
00:07:08Zweitens, ein sehr nützlicher Anwendungsfall, oder?
00:07:10Weil es das Wissen anderer Leute ist, das zu mir gelangt.
00:07:14Der zweite Anwendungsfall eines Unternehmensgehirns ähnelt etwas Cloud Tag,
00:07:18nämlich dieser Idee von Multiplayer.
00:07:21Wenn Sie Agenten in Slack an Orten platziert haben, an denen mehrere Personen
00:07:25damit interagieren können, wurde es sozusagen als geteilte KI genutzt, oder?
00:07:29Es ist nach dem Motto: Erledige die Arbeit.
00:07:32Ein Beispiel dafür könnte kollaboratives Vorfallmanagement sein, oder?
00:07:36Sie möchten zum Beispiel sagen: Hey, ich möchte Protokolle abrufen.
00:07:40Ich möchte den Vorfall untersuchen.
00:07:42Hole Protokolle, untersuche die Codebasis, öffne einen PR, deploye nach Staging,
00:07:46deploye nach Prod, richte eine Benachrichtigung ein.
00:07:48Mehrere Personen wollen Dinge mit dem Unternehmensgehirn tun.
00:07:51Das sind also quasi zwei Anwendungsfälle des Unternehmensgehirns.
00:07:53Einer ist dieser Fall von geteiltem, kollaborativem Wissen,
00:07:56und der andere ist der Anwendungsfall einer geteilten KI selbst, oder?
00:08:00Beide bergen ein riesiges Sicherheitsproblem, nicht wahr?
00:08:06Um das abzusichern, wollen wir das etwas genauer definieren, oder?
00:08:15Was genau ist ein Unternehmensgehirn?
00:08:18Das ist meine Definition davon, oder?
00:08:20Es ist ein geteilter Kontext, den man in Markdown ablegt,
00:08:23in eine Reihe von Markdown-Dateien, richtig?
00:08:26Und es sind Zugriffsregeln für die verschiedenen Daten und Werkzeuge,
00:08:29auf die ein Coding-Agent zugreifen können soll.
00:08:34Das nenne ich das so für...
00:08:38Nun, da ich spreche, kann ich definieren, was ich will.
00:08:41Das ist meine Definition.
00:08:42Ich spreche hier also nicht von Wissen, das in ein LLM eingespeist wird,
00:08:46das Tool-Aufrufe tätigt, oder?
00:08:48Es ist keine KI, die allgemeine Aufgaben erledigt.
00:08:51Es ist eine KI als Coding-Agent, der jedes Problem löst, das man ihm vorsetzt, richtig?
00:08:56Etwas ähnlich dem vorherigen Vortrag, den Sie vielleicht gehört haben,
00:09:00nämlich der Idee: Können wir nicht einfach einen Coding-Agenten nutzen, um allgemeine Probleme zu lösen?
00:09:04Genau das ist es.
00:09:05Im trivialsten Fall, wenn Sie sagen: Hey, schreib mir einen Tweet, schreiben Sie ein kleines Skript, das einen KI-Aufruf für einen kurzen Tweet macht, oder?
00:09:13Das müssen Sie wahrscheinlich gar nicht tun.
00:09:14Die KI selbst kann Ihnen den Tweet einfach direkt zurückgeben.
00:09:17Aber im Grunde wird Claude Code für alles verwendet.
00:09:20Claude co-work hat dieselbe Architektur.
00:09:22Die Codex-App hat dieselbe Architektur, nämlich die Erkenntnis, dass man Coding-Agenten für allgemeine Probleme nutzen kann.
00:09:28Dafür bauen wir das Gehirn.
00:09:30Wir bauen keinen gigantischen Wissensgraphen oder keine Wissensbasis für das Unternehmen, um diese dann abzusichern.
00:09:34Das hat sowieso nicht funktioniert und wird auch nicht funktionieren.
00:09:39Wie wollen wir also an das Design des Unternehmensgehirns herangehen? Sollten wir ein Unternehmensgehirn bauen?
00:09:50Wenn Sie in einem Unternehmen arbeiten und dafür bezahlt werden, Däumchen zu drehen, dann gefällt Ihnen die Idee eines Unternehmensgehirns.
00:09:57Weil Sie sagen: Ja, ich übernehme ein zweijähriges Projekt und baue das Unternehmensgehirn für J.P. Morgan.
00:10:02Das wird nicht passieren.
00:10:03Man kann kein Unternehmensgehirn für eine 100 Jahre alte Organisation bauen, oder?
00:10:07Man kann es kaum für die eigene Familie bauen, die vielleicht erst Monate oder Jahre alt ist, richtig?
00:10:13Die Idee und Vorgehensweise beim Bau eines Unternehmensgehirns ist vielmehr, dass jede Person, die ein wenig im Unternehmen arbeitet, ihren Teil des Gehirns besitzt und aufbaut, oder?
00:10:23So sollten wir es aufbauen.
00:10:25Das ist also quasi Einschränkung Nummer zwei, die ich nenne.
00:10:27Erstens war die Definition des Unternehmensgehirns und zweitens der Ansatz, wie ein Unternehmensgehirn aufgebaut werden soll.
00:10:33Mir gefällt folgende Formulierung: Wir werden ein Unternehmensgehirn wachsen lassen, wir bauen keins, oder?
00:10:41Wir lassen es sozusagen entstehen.
00:10:43Es einfach zusammenwachsen lassen.
00:10:44Das System muss organisch wachsen, sonst ist es nicht baubar.
00:10:47Genau.
00:10:48Im Großen und Ganzen möchten wir jedem ermöglichen, seinen Teil des Unternehmensgehirns im Self-Service zu pflegen, und das sind im Grunde die Schritte, die man befolgen sollte.
00:10:57Ich komme darauf später noch genauer zurück, falls wir Zeit haben, aber fangen wir mit einem konkreten Anwendungsfall an, oder?
00:11:03In diesem speziellen Fall habe ich eine Situation, die als greifbares Beispiel für Sie dienen soll.
00:11:12Ich habe eine E-Mail erhalten, einfach ein Beispiel für einen Sicherheitsfragebogen, richtig?
00:11:15Hey, ich habe eine E-Mail von Dave bei Stitch Fix bekommen, und da ist eine Reihe von Fragen, die ich beantworten muss, oder?
00:11:20Sie ruft also meine E-Mail auf, zeigt einen Screenshot des Sicherheits-Onboardings und beginnt dann, diese Fragen zu beantworten, richtig?
00:11:30Ich habe keine Ahnung, woher sie das wusste.
00:11:32Ich war sehr überrascht zu sehen, dass sie all die Fragen beantwortete wie: Hey, das ist unser Trust Center, so sieht unser Sicherheitszeug aus, sie haben ein Gateway, oder?
00:11:40Es tut irgendwas.
00:11:41All das stammt quasi aus dem Unternehmensgehirn als Antwort darauf, und dann fahre ich fort und sage: Hey, schick das einfach ab.
00:11:50Mir gefällt dieser Entwurf, schick diesen Entwurf an Dave, richtig?
00:11:53Und dann wird diese E-Mail verschickt, ein wirklich einfaches Beispiel für das, was ich tun möchte.
00:11:57Die Herausforderung und das Problem hierbei ist nun: Wie bauen wir ein System, zu dem jemand anderes beitragen kann und das eine dritte Person nutzt?
00:12:13Wie kam dieses Wissen über unsere Sicherheitspraktiken zustande?
00:12:18Vermutlich hatte jemand anderes an genau demselben Sicherheitsfragebogen gearbeitet, oder?
00:12:22Sie hatten also zum Beispiel einen Hermes-Agenten oder ähnliches.
00:12:24Sie haben daran gearbeitet.
00:12:25Sie haben automatisch etwas Speicher gespeichert.
00:12:27Vielleicht hat jemand eine Fähigkeit niedergeschrieben.
00:12:28Irgenwie muss dieses Stück Information zu meinem KI-Agenten gelangen.
00:12:32Wie sollen wir das möglich machen, oder?
00:12:35Versuchen wir es mit dem naheliegenden Punkt Nummer eins: Jeder schreibt auf GitHub geteilte Fähigkeiten füreinander.
00:12:42Als das erste Mal der Sicherheitsfragebogen von Ihrer Sicherheits- und Compliance-Person beantwortet wurde – stellen Sie sich diese Person gerade bildlich vor...
00:12:50Nun, stellen Sie sich vor, nachdem sie den Fragebogen ausgefüllt haben (Fragebögen auszufüllen ist furchtbar)...
00:12:56Nachdem sie dieses gigantische Excel-Blatt ausgefüllt haben, sind sie zu GitHub gegangen und haben eine geteilte Fähigkeit aktualisiert, richtig?
00:13:04Viele von Ihnen haben das Glück, mit Leuten zu arbeiten, die unserem Heiland gleichen, die so nett sind und in einem GitHub-Repo geteilte Fähigkeiten aktualisieren, oder?
00:13:16Die meisten tun das nicht.
00:13:18Niemand schreibt Fähigkeiten für eine andere Person auf GitHub.
00:13:24Das liegt uns einfach nicht im Blut, oder?
00:13:27Im Arbeitsalltag entscheiden wir uns nicht plötzlich: Oh, das könnte vielleicht sehr nützlich sein für jemanden, den ich gar nicht kenne und mit dem ich in dieser Situation nicht verbunden bin.
00:13:39Das passiert nicht.
00:13:40Ich schaffe es kaum, mein eigenes Gedächtnis und meinen Kontext zu pflegen.
00:13:44Ich habe einfach keine Zeit, es jemand anderem zu schicken oder es für jemand anderen aufzuschreiben.
00:13:49Zweitens: Statt eines Firmengehirns, warum machen wir kein Teamgehirn?
00:13:53Warum nutzt nicht einfach jeder ein gemeinsames?
00:13:55Warum nutzt das Sicherheitsteam nicht eine Art gemeinsames Silo, in dem man das tun kann, richtig?
00:14:01Baut also einen Agenten und lasst ihn quasi selbst im Speicher sichern, richtig?
00:14:04Und das ist vermutlich die Architektur, die viele von Ihnen haben, vielleicht mit etwas wie Hermes zu Slack hinzugefügt.
00:14:09Hat zufällig jemand so eine Art Teamgehirn-Situation, wo ihr eine KI habt, die von mehreren Leuten genutzt wird, die automatisch Speicher speichert und Kontext hinzufügt?
00:14:18Hat jemand von Ihnen so eine Art Skill, der das bereits macht, nur für ein kleines Team?
00:14:23Einer. Noch jemand? Okay.
00:14:24Okay, ein paar von Ihnen haben das. Das ist cool.
00:14:26Das ist nett, aber das Problem ist, es ist immer noch kein Firmengehirn, weil es nach wie vor isoliert ist, richtig?
00:14:31Es ist also wie ein weiteres Silo, richtig? Zum Beispiel, wenn das passiert, wie bei Claw Tag, hat es einen Speicher pro Kanal, richtig?
00:14:40In jedem Kanal wird es also gespeichert, aber jetzt ist es ein weiteres Silo in genau diesem Kanal, oder?
00:14:46Es ist also wieder an einen Ort gebunden, der nirgendwo anders verwendet werden kann.
00:14:50Wenn also jemand dem Kanal hinzugefügt wurde, würde es funktionieren, aber ansonsten eben nicht, richtig?
00:14:55Und das ist nun die dritte Option.
00:14:59Die dritte Option besteht darin, dass der gesamte Kontext in ein einziges gemeinsames Wiki fließt.
00:15:06Ein Wiki ist eine Sammlung von Markdown-Dateien, und Markdown-Dateien können aufeinander verweisen.
00:15:08Stellen Sie sich also einen gigantischen Ordner vor.
00:15:10Der Ordner enthält jede Menge Markdown-Dateien, richtig?
00:15:13Und Markdown-Dateien können aufeinander verlinken.
00:15:16Anstatt den gesamten Kontext also in einem Ordner zu speichern oder abzukapseln,
00:15:21legen Sie ihn in einer Markdown-Datei ab, dem Äquivalent einer Markdown-Datei,
00:15:25und lassen zu, dass sie miteinander verknüpft werden.
00:15:28Das Zweite, was Sie tun, ist, jeder Datei Bereiche zuzuweisen,
00:15:33wer Lese- und Schreibzugriff auf diese Datei haben darf.
00:15:38Das Dritte, was Sie tun, und das ist das Wichtigste:
00:15:42Sie lassen den Agenten den Speicher nicht automatisch hinzufügen.
00:15:49Sie lassen es nicht automatisch hinzufügen, denn wenn es automatisch geschieht, haben Sie keine Ahnung, was passiert ist, richtig?
00:15:55Man kann – wir sind wieder am selben Punkt, wo manches einfach hinzugefügt wird,
00:16:00und solange man sich im Speicher dieses Agenten befindet, hat man Glück, richtig?
00:16:04Das dritte Element besteht also darin, den Agenten Dinge nicht automatisch hinzufügen zu lassen,
00:16:07sondern etwas zu tun, das es Ihrem Agenten erlaubt vorzuschlagen, was mit welchen Bereichen hinzugefügt wird,
00:16:16und dann lässt man den Menschen akzeptieren oder ablehnen.
00:16:21Es ist also nicht so aufwendig wie GitHub, wo ich das selbst schreiben, einen geteilten Skill aktualisieren,
00:16:28einen PR-Review machen und es dann mergen muss.
00:16:30Aber es ist auch nicht so YOLO, dass der Speicher einfach vom Agenten selbst zusammengeschrieben wird,
00:16:36richtig? Es ist genau der Punkt, wo man während der Arbeit
00:16:40das aufruft, die richtigen Bereiche vorschlägt und es jemanden hinzufügen lässt.
00:16:45Durch diese sehr einfache Ergänzung passiert nun folgendes: Man kann Leute zu einem gigantischen Wiki hinzufügen lassen,
00:16:51aber man lässt diese Person die Verantwortung dafür übernehmen, was sie sehen kann oder eben nicht.
00:16:57Wenn ich also etwas zum Finanz-Wiki hinzufüge, möchte ich sicherstellen – ich füge etwas
00:17:01Sensibles hinzu und will sichergehen, dass es einen Finanzbereich hat.
00:17:03Füge ich etwas Persönliches hinzu, möchte ich sicherstellen, dass das einen persönlichen Bereich hat.
00:17:06Ich zeige Ihnen mal eine Beispiel-UX, wie das aussehen könnte. Das ist, was wir machen.
00:17:15Das ist eine kürzliche E-Mail, die ich von einem unserer Vertriebsmitarbeiter bekommen habe, der mich zu einem Call hinzugefügt hat.
00:17:33Ich habe mir die E-Mail angesehen, bei der Beantwortung geholfen und dann ein kleines Feld erhalten, das eine
00:17:39Reihe von Stichpunkten vorschlug, die mir zeigten, was hinzugefügt werden soll, richtig?
00:17:43Und wenn ich auf Zum Wiki hinzufügen klicke – ist es für mich viel einfacher zu überprüfen, was hinzugefügt wird.
00:17:47Es ist mir egal. Es ist mir egal, ob es in diese Markdown-Datei oder jene Markdown-Datei eingefügt wird,
00:17:52um welche Links sich der Agent kümmert. Mir ist wichtig: Sind diese Fakten korrekt?
00:17:58Wenn diese Fakten stimmen, klicke ich auf Zum Wiki hinzufügen und bin fertig, richtig?
00:18:02Und beim Hinzufügen zum Wiki kann ich pro Wikiseite auswählen, welche Bereiche hinzugefügt werden müssen oder nicht,
00:18:08richtig? Jede Wikiseite kann also bestimmte Bereiche erhalten, bei denen Sie entscheiden möchten,
00:18:12wer worauf Zugriff erhält, zum Beispiel, richtig? Also zum Beispiel meine E-Mail, das ist die Wikiseite,
00:18:17die ich für meine E-Mails und deren Priorisierung habe, und ich kann nun entscheiden, wer darauf zugreifen darf,
00:18:22wer die Besitzer dafür sind und wie die rollenbasierte Zugriffskontrolle (RBAC) aussieht. Wie das System auch aussieht,
00:18:26bleibt Ihnen überlassen, aber die Kernidee ist, dass der Agent eine Änderung vorschlagen soll,
00:18:32anstatt sie einfach durchzuführen. Gut. Also zwei Regeln. Erstens: Stellen Sie sicher, dass alles in ein einziges
00:18:38unternehmensweites Wiki fließt, weichen Sie von dieser Regel nicht ab. Zweitens: Stellen Sie sicher, dass als Teil davon
00:18:44jede Änderung mit dem Namen eines Menschen versehen ist. Nichts sollte im Wiki landen mit dem Vermerk, dass Claude
00:18:51das hinzugefügt hat oder Ihr KI-Agent oder Hermes. Nein, Tanmay hat das hinzugefügt. Dieser Name muss
00:18:57dort stehen, damit man es auf die Person zurückführen kann, die Mist gebaut und es allen ermöglicht hat,
00:19:04etwa die Gehaltsabrechnung aller einzusehen, richtig? Und was auch immer, jetzt können Sie Korrekturmaßnahmen einleiten,
00:19:09richtig? Was auch immer das ist. Setzen Sie sie auf einen Leistungsverbesserungsplan. Sie wussten nicht, wie man ein Wiki bearbeitet. Das ist also sehr,
00:19:14sehr wichtig. Und Regel Nummer zwei, wenn Sie das entschieden haben, können Sie zum zweiten Bereich übergehen, nämlich
00:19:19okay, Sie müssen es ihnen leicht machen, was uns zu diesem Konzept der Bereiche bringt,
00:19:23bei dem jede Datei entsprechend dem Zugriffsrecht eingeteilt wird. Sie bauen darum eine Art System.
00:19:26So sieht ein Architekturdiagramm dazu aus: Es gibt Benutzer,
00:19:32Benutzer sprechen mit dem Agenten. Der Agent verwendet beim Lesen des Kontextes die Berechtigungen genau dieses Benutzers, richtig?
00:19:39Wenn ich also etwas zur Lösung eines Finanzproblems lese, nutzt es meine Finanz-Berechtigungen, um als
00:19:46ich zu lesen, weil ich Zugriff auf das Finanz-Wiki hatte, sodass ich es lesen kann, und das geschieht jedes einzelne Mal, richtig?
00:19:52Der Agent verwendet also immer die Anmeldedaten des Benutzers, um den richtigen Teil des Wikis zu lesen.
00:20:00Gut. Meine Zeit für den zweiten Anwendungsfall ist weitgehend um. Was ich also tun werde, ist, Ihnen einen
00:20:06schnellen Vorgeschmack auf den zweiten Anwendungsfall zu geben, aber diese Idee zu erweitern. Das ist der große Anwendungsfall. Das ist wie,
00:20:13das ist der Haupt-Anwendungsfall. Das ist ein wirklich komplizierter Anwendungsfall, weil jetzt
00:20:17nicht nur eine Person eine E-Mail beantwortet. Es ist eine Gruppe von uns, die den gemeinsamen Kontext nutzt,
00:20:25um ein Problem mit verschiedenen Eskalations- bzw. Privilegienstufen gleichzeitig zu lösen,
00:20:31richtig? Und das sind so die Interaktionen mit KI, bei denen die meiste
00:20:36Wissensbasis im Firmengehirn geschaffen wird, richtig? Zum Beispiel werde ich Ihnen ein kurzes echtes
00:20:42Beispiel zeigen, wie das für uns aussieht. Das ist ein Fall aus einer SRE-Situation, in der
00:20:50jemand meinte: Hey, unser automatisiertes Lernen, unser Wiki-Lernen, recht meta, schlug fehl. Es funktionierte
00:20:57nicht. Was ist los, richtig? Und dann fängt er an zu untersuchen, und es ist blöd, weil es
00:21:02keinen Skill hatte. Es schlug fehl. Also heißt es: Bruder, mach das nicht. Bitte verwende diesen OpenTelemetry-Span-Namen.
00:21:07Es hat einen OpenTelemetry-Span-Namen verwendet. Es hat einen etwas besseren Job gemacht, war aber immer noch sehr langsam. Also
00:21:13hat er sich den Code angesehen und meinte: Oh, du verwendest eine Like-Abfrage. Du bist ein Vollidiot.
00:21:18Das ist Opus 4.5. Äh, mach das lieber nicht. Richtig? Also sagt er: Verwende keine Like-Abfrage,
00:21:24verwende eine Equals-Abfrage, richtig? Und dann macht es eine Equals-Abfrage, fördert ein paar Details zutage und
00:21:29dann sagt er: Oh, grab da mal tiefer. Und es sagt, wie auch immer, das ist die Codezeile, aus der
00:21:33der Fehler kommt. Einfache Sachen, richtig? Hier zeigt sich nun etwas Wissen und es sagt:
00:21:39Aha, ich habe gelernt, dass ich Equals und nicht Like verwenden sollte, richtig? Ich habe gelernt, dass ein benutzerdefinierter
00:21:45Präfix bei Wikiseitennamen Probleme verursachen kann. Richtig? Ähm, es bietet also diese Erkenntnisse an,
00:21:50die man annehmen kann. Also ist er tiefer in das Problem eingetaucht.
00:21:56Jemand anderes hat sich dem Gespräch angeschlossen, richtig? Und meinte: Die technische Entscheidung, die wir hier getroffen haben, ist
00:22:02falsch. Warum passiert das? Und jetzt fangen zwei Leute an zu argumentieren, richtig? Sie haben eine Meinungsverschiedenheit.
00:22:09Sie sagen: Hey, das sollte nicht so sein. Es sollte so sein. Aber warum ist es so? Aber es sollte
00:22:12so sein, richtig? Diese Diskussion erzeugt Wissen, weil das eigentliche Problem darin bestand, dass jemand eine
00:22:17technische Entscheidung getroffen hatte, die nicht dokumentiert war. Richtig? Wenn sie beschließen, das Problem zu beheben,
00:22:22feststellen, dass dies tatsächlich die Hauptursache ist, und beschließen, dass es so gelöst werden soll:
00:22:26Hey, wir sollten dieses Präfix entfernen, das das Problem verursacht, was auch immer es ist,
00:22:31entsteht der hochwertigste Kontext, der Ihrem Gehirn hinzugefügt werden kann. Denn der vorherige Vorschlag lautete,
00:22:38zu sagen, äh, Seiten sollten keine Präfixe haben, aber die Tatsache, dass Seiten ein Präfix haben, ist ein Problem.
00:22:44Genau. Was Sie jetzt also im Brain dokumentieren, ist, dass Pages kein Präfix haben sollten.
00:22:49Wenn sie ein Präfix haben, kann das zu Suchproblemen in der Produktion führen. Das passiert, wenn mehrere Leute miteinander
00:22:54sprechen, richtig? Und gemeinsam Probleme lösen. Genau das passiert in einem Slack-Thread, wenn zwei Personen miteinander
00:22:59sprechen und ein Problem lösen. Es erzeugt den hochwertigsten Kontext. Und das ist im Grunde das,
00:23:05was Sie hier wollen. Aber die Herausforderung ist, dass die Privilegienerweiterung dabei sehr,
00:23:10sehr ernst wird. Wenn man einen Agenten baut, der von mehreren Personen umgeben alles tun kann,
00:23:18ist das beängstigend. Weil es dem Entwickler erlaubt war, die PR-Arbeit zu machen, aber ich jetzt denselben Agenten nutzen kann,
00:23:23um in der Produktion zu deployen. Das ist zu gruselig. Ich kann kein Gespräch führen, bei dem ich debugge und
00:23:29sicher deploye, richtig? Besonders, wenn man in einer Bank ist. Richtig? Die Leute, die debuggen,
00:23:35auf Staging deployen, einen Alarm einrichten und deployen, sind nicht dieselben. Aber dieselben zu sein hat
00:23:40viel Wert, weil sich dort das gesamte Wissen befindet, richtig? Und das bringt uns im Grunde zur
00:23:45zweiten Architektur, auf die ich nicht allzu detailliert eingehen werde. Aber stellen Sie es sich einfach vor als dieselbe
00:23:49Idee, bei der Benutzeranmeldedaten und Berechtigungen zum Lesen des Kontextes verwendet wurden. Verwenden Sie stattdessen auch Benutzeranmeldedaten.
00:23:58Richtig? Wenn der Code Tools ausführt. Speichern Sie also niemals Anmeldedaten in der Sandbox.
00:24:05Injizieren Sie stattdessen auf der HTTP-Schicht und der SQL-Schicht die Anmeldedaten des Benutzers, sodass sich die KI bei einer bestimmten
00:24:13Interaktion wie der Mensch verhält, richtig? Hier gibt es also interessante Details. Aber genau das ermöglicht es,
00:24:20dass eine gemeinsame KI mit gemeinsamem Kontext arbeitet, richtig? Und das sind im Grunde die zwei Hauptkomponenten,
00:24:25mit denen man arbeitet. Ich würde also zusammenfassen: Diese Architektur ist nicht sonderlich kompliziert, aber es ist sehr einfach,
00:24:30von diesen beiden Regeln auszugehen. Speichern Sie keine Anmeldedaten in der Cloud-Sandbox. Und zweitens:
00:24:36Virtualisieren Sie alle Interaktionen mit echten Daten, proxys Sie sie, virtualisieren Sie sie – welches Wort Sie auch immer verwenden wollen –
00:24:41und lassen Sie die Benutzer sie steuern. Der Benutzer, der ein bestimmtes Tool hinzufügt, sollte also kontrollieren, wer Zugriff auf
00:24:48genau dieses Tool erhält. Man kann also das Ganze herleiten, wenn man einfach diesen vier Prinzipien folgt
00:24:53und von dort aus rückwärts arbeitet. Es gibt nur eine einzig mögliche Architektur, die Sinn ergibt
00:24:58hinsichtlich der Verwaltung von Kontext, den festgelegten Einschränkungen, der Tool-Verwaltung und den Sicherheitsregeln,
00:25:02die man aufstellt. Das war meine Zeit. Ich unterhalte mich nach dem Vortrag gerne noch weiter. Wir haben auch einen Stand,
00:25:10also unterhalte ich mich gerne darüber, was die Nuancen in dieser Architektur sind. Ich bin Tanmay Goh auf
00:25:16Twitter. Wir heißen PromptQL. Schauen Sie gerne vorbei. Letztendlich, innerhalb der KI-Engineering-Community,
00:25:24werden wir ein Produktlaunch machen. Und ich würde das sehr gerne mit allen teilen.
00:25:30Ich mache jetzt ein Foto mit allen auf der Bühne, um das teilen zu können. Lassen Sie mich das also tun, solange ich hier bin.
00:25:40Alles klar. Wollen die Leute Cheese sagen?
00:25:45Vielen herzlichen Dank. Halten Sie also danach Ausschau. Es ist unser Ansatz für Cloud Tag, nämlich PromptQL Tag,
00:25:52was den hier besprochenen Ideen sehr ähnelt, nur dass Sie nicht an Cloud gebunden sind.
00:25:57Sie können GLM und GPT verwenden, und wenn Sol herauskommt, können wir das nutzen und viel Spaß haben.
00:26:03Schauen Sie sich das also unbedingt an. Ansonsten sehen wir uns bald wieder.
00:26:19Wir sind gleich zurück.

Key Takeaway

Sichere Unternehmensgehirne basieren auf einem einzigen verknüpften Markdown-Wiki, in dem KI-Agenten Änderungen nur vorschlagen und Benutzeranmeldedaten den Zugriff auf der HTTP- und SQL-Schicht steuern.

Highlights

  • Ein ungesichertes Firmengehirn leitet Unternehmensgeheimnisse und Gehaltsdetails an unerwartete Personen weiter.

  • PromptQL nutzt rund 5.000 miteinander verknüpfte Markdown-Seiten als unternehmensweites Wiki.

  • Ein gesundes Firmengehirn zeigt einen kontinuierlich steigenden Trend bei den täglichen Updates.

  • Die Benutzeranmeldedaten werden dynamisch auf der HTTP- und SQL-Schicht injiziert, um unbefugten Zugriff durch KI-Agenten zu verhindern.

  • Jede Änderung im Wiki muss explizit mit dem Namen eines Menschen versehen und freigegeben werden.

Timeline

Sicherheitsrisiken und Herausforderungen beim Firmengehirn

  • Unternehmensgehirne bergen das Risiko, vertrauliche Informationen wie Gehaltsdetails preiszugeben.
  • Das Team hinter PromptQL entwickelte zuvor die GraphQL-Engine, die bei Apple, Meta und JPMorgan zum Einsatz kommt.
  • Ein gesundes Firmengehirn verzeichnet einen kontinuierlichen Anstieg der täglichen Updates.

Der Aufbau eines zentralen Wissensspeichers scheitert häufig an strengen Sicherheitsvorgaben von Großbanken und Technologieunternehmen. Bei der Analyse von rund 5.000 miteinander verknüpften Seiten zeigt sich, dass mit zunehmendem Nutzen des Systems auch die tägliche Anzahl der Aktualisierungen stetig wächst.

Anwendungsfälle und Architektur des Wissensmanagements

  • Unternehmensgehirne dienen sowohl als Wissensquelle für einzelne KI-Agenten als auch als kollaborative Plattform.
  • Zentrales Wiki statt isolierter Silos verhindert fragmentierte Datenbestände in Teams.
  • Automatische Speicherung durch Agenten ohne menschliche Prüfung führt zu unkontrollierten Datenabflüssen.

Zwei Hauptanwendungsfälle bestimmen die Nutzung: das Beantworten von Sicherheitsfragebögen durch KI und das kollaborative Vorfallmanagement. Statt isolierter Kanalsilos fungiert eine Sammlung verknüpfter Markdown-Dateien als einheitliche Wissensbasis, bei der Änderungen stets von Menschen vorgeschlagen und validiert werden.

Berechtigungskontrolle und Zugriffssicherheit

  • Jede Wiki-Seite enthält spezifische Bereiche zur Definition von Lese- und Schreibrechten.
  • Änderungen werden mit dem Namen des verantwortlichen Menschen markiert, um Rückverfolgbarkeit zu gewährleisten.
  • Die dynamische Injektion von Benutzeranmeldedaten auf HTTP- und SQL-Ebene schützt sensible Produktionsdaten.

Um Sicherheitsrisiken bei der Agentenausführung zu minimieren, verwenden Agenten stets die Anmeldedaten des jeweiligen Benutzers für den Zugriff auf den Kontext. Dadurch wird verhindert, dass unberechtigte Personen oder Prozesse auf sensible Finanz- oder Produktionsdaten zugreifen können.

Community Posts

View all posts