Ausgewählte Arbeit · Interner Case
Human-governed KI-Wissenssystem.
Ein internes Betriebssystem, das auf einem Grundsatz aufbaut: KI klassifiziert und triagiert, Menschen validieren jede wesentliche Entscheidung. Wissen akkumuliert durch Review. Workflows verbessern sich durch kontrollierte Iteration — nicht durch Automatisierung.
- —Gegenstand: ein internes Wissens-Capturing- und Workflow-Verbesserungssystem.
- —Architektur und Governance-Modell offen; Systemidentität zurückgehalten.
- —Zeigt das Governed-AI-Muster in einem realen, produktiven Kontext — nicht als Behauptung, sondern als laufendes System.
// Engagement-Shape
- Kunde
- Internes Projekt (anonymisiert)
- Rolle
- Designer, Entwickler, Betreiber
- Status
- Live im Produktivbetrieb
- Offenlegung
- Architektur und Governance-Modell offen; Systemidentität zurückgehalten
- Grenzen
- Nur interner Betriebskontext; keine Kundendaten involviert
Kontext
Operatives Wissen löst sich auf, wenn es keine Capture-Struktur gibt.
Im operativen Betrieb entsteht kontinuierlich Wissen — getroffene Entscheidungen, identifizierte Muster, bewertete Werkzeuge, angepasste Workflows. Ohne eine strukturierte Erfassung löst es sich auf: Entscheidungen werden wiederholt, Muster bleiben ungenutzt und institutionelles Wissen bleibt implizit.
Die Designherausforderung war nicht die Fähigkeit — sie war die Governance. Ein System, das Einträge klassifiziert und Workflows automatisch aktualisiert, produziert etwas, das kein Betreiber vollständig nachvollziehen kann. Die Anforderung war das Gegenteil: KI-gestützte Triage mit menschlicher Validierung als Pflicht bei jeder wesentlichen Entscheidung.
Das Ergebnis ist ein System, das durch Nutzung besser wird — nicht durch autonomes Lernen, sondern durch strukturierte menschliche Review-Zyklen, die validierte Muster in explizite operative Entscheidungen zurückführen.
Designentscheidungen
Vier Constraints, die das System definieren.
-
Erst erfassen, dann klassifizieren.
Alle eingehenden Einträge landen in einem strukturierten Staging-Bereich, bevor jegliche KI-Verarbeitung stattfindet. Das System hält Einträge im Pending-Status, bis ein Mensch die Triage initiiert. Das trennt das Erfassungsproblem vom Klassifikationsproblem und verhindert stille Automatisierung.
-
Menschliche Prüfung als Schema-Feld, nicht als Konvention.
Der Review-Status ist ein verpflichtendes Erstklassen-Feld in jedem Eintrag. Eine KI-Klassifikation ohne menschliche Review-Aktion und Zeitstempel ist keine validierte Entscheidung. Die Datenschicht erzwingt das — Prozesskonventionen allein reichen nicht aus.
-
Eine feste Taxonomie vor dem ersten Eintrag.
Kategorien, Prioritätsstufen und Review-Kriterien werden schriftlich definiert und festgeschrieben, bevor der erste Eintrag die Pipeline betritt. Die KI klassifiziert innerhalb eines festen Vokabulars; sie erweitert oder revidiert die Taxonomie nicht ohne explizite Betreiber-Freigabe.
-
Workflow-Änderungen folgen geprüften Mustern, nicht dem KI-Output.
Wenn validierte Einträge ein wiederkehrendes Muster zeigen, wandelt eine menschliche Entscheidung dieses in eine operative Anpassung um. Die KI bringt Kandidatenmuster ans Licht; der Betreiber handelt. Kein Workflow-Element ändert sich direkt durch KI-Output.
Was gebaut wurde
Fünf Komponenten, jede mit einer Governance-Rolle.
// Systemkomponenten
- 01
Eintragsschema
review_status · priority · category · date
Pflichtfelder auf jedem Eintrag. Ein Eintrag ohne review_status kann nicht weiterverarbeitet werden — das Schema codiert das Governance-Modell strukturell, nicht per Konvention.
- 02
KI-Triage-Pipeline
Klassifikation · Priorisierung · Routing
Eingehende Einträge werden klassifiziert, priorisiert und in die Review-Queue geroutet. Alle Outputs sind Vorschläge. Kein Eintrag wird durch die Pipeline allein verarbeitet.
- 03
Review-Interface
Einzelprüfung · explizite Begründung · Audit-Log-Eintrag
Jeder konsequente Eintrag wird einzeln geprüft. Batch-Freigaben sind für kritische Kategorien untersagt. Prüfer dokumentieren die Begründung; das System protokolliert die Aktion mit Zeitstempel und Ergebnis.
- 04
Mustererkennung
validierte Cluster → Workflow-Kandidaten
Freigegebene Einträge werden zu Kandidatenmustern gruppiert und dem Betreiber zur Prüfung vorgelegt. Der Pass schlägt vor; er führt nicht aus. Workflow-Änderungen erfordern eine gesonderte menschliche Entscheidung.
- 05
Audit-Trail
Prüfer · Zeitstempel · KI-Vorschlag · menschliches Ergebnis
Jede Review-Aktion wird protokolliert. Jeder Eintrag ist rekonstruierbar: was die KI vorgeschlagen hat, wann ein Mensch geprüft hat, was das Ergebnis war und ob es in eine Workflow-Anpassung eingeflossen ist.
Ergebnis
Kontrollierte Verbesserung, kein algorithmisches Drift.
Das System macht keine Geschwindigkeits- oder Kosteneinsparungsversprechen. Es beansprucht eine operative Eigenschaft: Wissens- und Workflow-Entscheidungen werden von Menschen getroffen, im Audit nachvollziehbar, und systematisch in verbesserte operative Muster zurückgespielt.
- ✓ Operatives Wissen, das während der täglichen Arbeit entsteht, wird in einem konsistenten Schema gesichert — statt in Ad-hoc-Notizen zu verschwinden.
- ✓ Workflow-Muster verbessern sich durch validierte Review-Zyklen — nicht durch algorithmisches Drift oder ungeprüfte KI-Vorschläge.
- ✓ Das System ist vollständig auditierbar: Jede wesentliche Entscheidung lässt sich auf einen menschlichen Prüfer, einen Zeitstempel und eine Begründung zurückführen.
- ✓ Ein Betreiber kann das System betreiben und erweitern, weil der KI-Mensch-Vertrag explizit dokumentiert ist — nicht implizit.
Grenzen
Was dieser Case ist und was nicht.
Die Grenzen werden explizit benannt. Ein Leser sollte wissen, was dieser Case belegt und wo das Material endet.
- — Systemname, spezifischer Tooling-Stack und interne Taxonomie werden nicht offengelegt. Dies ist ein Architekturmuster, keine Produktreferenz.
- — Keine Durchsatz-Benchmarks oder Review-Latenzdaten werden genannt. Der Case beschreibt Governance-Design, keine Performance-Claims.
- — Dies ist ein interner Case. Er ersetzt keine namentliche Kunden-Referenz — diese existieren unter NDA und sind in Scoping-Gesprächen zugänglich.
- — Das Muster lässt sich auf Kundenkontexte mit fachspezifischen Taxonomien, Compliance-Anforderungen und Integrationsanforderungen übertragen.
Nächster Schritt
Das gleiche Muster, angewendet auf eure Wissensdomäne oder euren Workflow.
Die obige Architektur — strukturiertes Capturing, begrenzte KI-Klassifikation, verpflichtende menschliche Prüfung, mustergetriebene Iteration — ist ein Governance-Modell, kein Produkt. Es passt sich an fachspezifische Taxonomien, Compliance-Anforderungen und Integrationsanforderungen an.