Ein großer Teil der KI-Governance beginnt bei Dingen, die schiefgehen. Ein Modell halluziniert. Die Evidenz ist schwach. Ein Agent geht in seinem Handeln zu weit. Eine menschliche Freigabe erweist sich als bedeutungslos. Eine Autorisierung ist zum Zeitpunkt der Ausführung nicht mehr gültig. Dann fügen wir eine Kontrolle hinzu. Das ist oft notwendig. Gleichzeitig wird es dadurch immer schwieriger, das Feld als zusammenhängendes Ganzes zu erkennen. Ich glaube, wir setzen eine Ebene zu spät an. Die erste Frage sollte lauten: Was hat sich an der Art von System verändert, die wir zu steuern versuchen? Ich spreche dabei nicht von probabilistischer Berechnung im Allgemeinen. Relevant wird die Frage dort, wo generative Systeme Ergebnisse erzeugen, die semantische oder operative Bedeutung erlangen: Eine Interpretation wird als gültig behandelt, eine Empfehlung beeinflusst eine Entscheidung, eine Klassifikation verändert die Behandlung eines Falls oder der Vorschlag eines Agenten kann zu einer Handlung werden. Genau hier zeigt sich ein wichtiger Unterschied zu klassischer Unternehmenssoftware. Auch klassische Systeme können selbstverständlich falsche Ergebnisse erzeugen. Doch die Abbildung von Eingaben und Systemzustand auf ein Ergebnis wird dort in der Regel durch explizite Logik bestimmt, die untersucht, getestet und rekonstruiert werden kann. Wenn etwas schiefläuft, suchen wir die Ursache normalerweise in den Daten, der Implementierung, der Konfiguration oder dem Systemzustand. Bei generativer KI kann dagegen ein Ergebnis ungültig sein, obwohl Modell, Anwendung, Konfiguration und bereitgestellte Informationen sämtlich so funktionieren, wie sie vorgesehen sind. Das semantische Ergebnis selbst entsteht durch probabilistische Inferenz. Das verändert das Governance-Problem. Die Axiome dieser Serie betreffen das, was probabilistische Inferenz nicht aus sich selbst heraus feststellen kann. Ihre operativen Konsequenzen müssen zugleich zwei Anforderungen folgen, die für Systeme mit realen Konsequenzen entscheidend sind: Gültigkeit muss noch in dem Moment bestehen, in dem eine Konsequenz eintritt, und Governance muss im Nachhinein rekonstruierbar bleiben.

Welche KI nutzt du, um aus einer riesigen Fotomenge die für dich relevanten Bilder zu identifizieren? Ich war vor kurzem bei einem Event mit rund 40 Gästen. Dieses wurde von einem professionellen Fotografen in immer neuen Konstellationen festgehalten. Der Fotograf hat danach knapp 800 Bilder in eine Frame.io-Galerie hochgeladen und zum Download bereitgestellt. Nun hatte ich keine Zeit und vor allem keine Lust, 800 Bilder manuell anzuschauen und die Fotos mit meinem Mann und mir zu sichern. Also habe ich Claude den Link geschickt, dazu ein Foto von mir und eines von meinem Mann als Referenz. Die Aufgabe war klar umrissen. Claude sollte durch die Galerie gehen und die Bilder markieren, auf denen wir beide zu sehen sind. Claude hat sich tatsächlich eingeloggt, die Galerie geöffnet und ist geduldig durch alle 792 Bilder gescrollt. Bei jedem Kandidaten, der auch nur entfernt passen könnte, wurde reingezoomt und mit den Referenzfotos verglichen. Das Ergebnis nach der kompletten Durchsicht war ernüchternd. Kein einziger Treffer, bei dem sich Claude sicher war. Claude vergleicht Bilder offenbar visuell, ähnlich wie ein Mensch beim genauen Hinschauen. Dahinter steckt keine trainierte Gesichtserkennung, die Gesichter in Vektoren umrechnet und exakt matcht. Bei distanzierten Gruppenfotos, Sonnenbrillen, Hüten und Imker-Schleiern wird der Abgleich schnell zum Ratespiel. Genau da hat Claude ehrlich kapituliert, statt mir eine unsichere Vermutung als sicheren Treffer zu verkaufen. Welche Empfehlung hast du für mich, um auf clevere und zeitsparende Weise die Bilder von uns zu erkennen und runterzuladen?

Hi zusammen! Ich arbeite an zwei parallelen Projekten mit KI: 1) Einer Photo-DB, die mir hilf digitale Fotos aus verschiedenen Jahrgängen zu systematisieren und zu kategorisieren. Diese Kategorien werden sobald sie final sind (der Drift entsteht durch neue Bilder) in Sidepockets gepackt und sollen dann in das Repository fließen (bei mir Lightroom Classic). Kernanforderung dabei: - Datenintegrität, - Datensicherheit, - Systematische Reproduzierbarkeit der Kurationsentscheidung über einzelne Fotos - Konnektivität zwischen Klassifizierung und zugrunde gelegter Entscheidung, - Und strategisch, die Ableitung einer Gesamtwerkschau als Fotograf mit konkreten historisch gewachsenen Portefeuille Hier arbeiten zwei LLMs und verschiedene Agenten zusammen an einem gemeinsamen Projekt, ohne direkt miteinander verbunden zu sein. 2) Einem Bewerbungs-Katapult. Hier schicke ich neue Stellen als Text zu Slack und ChatGPT schaut jeden Morgen um 08:00 nach, was neu ist und macht einen Intake-File. Dort wird mein Profil aus einem Repository und domain-spezifischen Anpassungen dagegen gehalten und eine erste Einschätzung über Matching und ATS-Score gemacht. Ferner wird eine Bewerbung als "strong-fit", "aggressiv-stretch", "defensive-stretch" und "not advisable" klassifiziert und Argumentationsanker vorgegeben. Ich prüfe und gebe das "go" oder auch nicht. Claude übernimmt dann baut einen ersten CV lokal auf der Festplatte. Dabei greift er die "Anker" von ChatGPT auf und kombiniert dies mit meinem Candidate.md und den Domain-Anpassung für verschieden Adressatenkreise. Ich passe die Formatierung an, ChatGPT macht materiellen Check mit ATS-Score und Matching sowie Bewerbungsstrategie, Claude macht Machine-Review, ob Parser funktionieren, Schriften, Dateigröße, etc. alles passt und fertig. Kernidee und Anforderung: - Schnelle Produktionspipeline (aktuell 10-12 Bewerbungen pro Tag nebenbei machbar) - Hohe Qualität (wurde von HR-Beratern und auch HR-lern bestätigt - die das kaum fassen konnten) - Gute Interaktion von zwei Systemen (ChatGPT für Argumentation und Einschätzung, Claude für Daten- und Dateimanagement) und Claude-Code für Prozesse und Architektur.

Über Multi-Agenten-Systeme wird viel geschrieben, meist auf der Ebene von Architekturdiagrammen und Produktversprechen. Wie sich zwei unabhängige LLMs im Alltag tatsächlich koordinieren lassen, ohne dass Wissen driftet, Verantwortlichkeiten unklar werden oder am Ende niemand mehr weiß, welcher Stand gerade gilt, zeigt sich eher in der Praxis als in der Theorie. Der folgende Erfahrungsbericht stammt aus einem selbstgebauten, aber vollständig produktiven Fall: einer persönlichen Bewerbungspipeline, in der Claude und ChatGPT arbeitsteilig zusammenarbeiten – gekoppelt über Slack als Signalquelle und eine versionierte, dateibasierte Knowledge Base als gemeinsames Gedächtnis. Der Aufbau: Slack als Sensor, Dateien als Gedächtnis Slack übernimmt in diesem Setup nicht die Rolle einer Chat-Oberfläche für die Agenten, sondern die eines Sensors. Neue Stellenanzeigen landen in thematisch getrennten Kanälen; ein Agent scannt sie, erkennt Statuswechsel und wartet auf klar definierte menschliche Signale in Thread-Antworten – ein einfaches „GO“, „Freigabe“ oder „Sign-off“ genügt, um die Pipeline einen Schritt weiterzuschalten. Slack ist damit Ereignisquelle und Kommunikationskanal zugleich, aber ausdrücklich keine Wissensbasis. Das eigentliche gemeinsame Gedächtnis liegt in einer versionierten Dateistruktur, die beide Systeme lesen und – nach klaren Regeln – auch verändern dürfen. Zentral ist ein einziges Prinzip: Eine Datei ist die alleinige Faktenquelle für den Kandidaten, alle anderen Bestände (historische Bewerbungsunterlagen, Master-Lebensläufe, Slack-Kontext) liefern ausschließlich Kontext – Formulierungen, Gewichtung, Framing –, niemals neue Fakten. Jede Änderung an dieser Faktenbasis muss geschrieben werden, nie „nur im Kopf eines Modells“ bleiben. Genau das ist einmal schiefgegangen: Ein überarbeiteter Stand wurde nur intern in einem der beiden Systeme gepflegt und nie verteilt, sodass eine spätere Anfrage gegen einen veralteten Stand lief, ohne dass es zunächst auffiel. Die Konsequenz war keine neue Regel mit gutem Willen, sondern ein hartes Versionierungs- und Übergabeverfahren: durchgehend nummerierte Gesamtversionen, die je den vollständigen Stand aller Kategorien enthalten, plus eine bewusste Entscheidung gegen Mikro-Releases – kleine Einzeländerungen sammeln sich, bis ein inhaltlich abgeschlossener Block vorliegt, statt bei jeder Kleinigkeit einen neuen Stand zu erzeugen.