So arbeitet der LATUS AI Stack

Was ist der LATUS AI Stack

Der LATUS AI Stack ist ein produktiver KI-Stack der LATUS Consulting AG (Chat-Assistent, Firmenwissen-Suche, zentrale Agenten) für das LATUS-Team. Parallel dazu wird die operative Org-Architektur weiterentwickelt, mit der ein KI-Hauptagent (zentrale operative Steuerung) spezialisierte Subagent-Rollen heuert, Wissensbasen pflegt und das klassische 24/7-Bereitschafts-Modell durch automatisierte Detection, Triage und Sofort-Benachrichtigung ablöst (Stephan Klahr als menschliche Freigabe-Instanz bleibt Ziel-Empfänger für P0-Eskalationen). Single Source of Truth: das hier verlinkte Repository plus das Benutzerhandbuch.

Operations-Modell und Funktionsweise

Im Kern arbeitet der LATUS AI Stack als geschlossener Operations-Kreislauf: er beobachtet sich selbst, klassifiziert Störungen, repariert bekannte Störungs-Muster reaktiv über definierte Selbstheilungs-Pfade und speist die Lehren aus jeder Vorfall-Auswertung in seine Weiterentwicklung zurück. Damit ersetzt er das klassische 24/7-Bereitschafts-Modell, ohne die menschliche Freigabe-Instanz bei P0-Eskalationen zu umgehen. Die sechs tragenden Säulen sind Multi-Agent-Orchestrierung, automatisierte Selbstheilung, verpflichtende Vorfall-Auswertung, wiederkehrende Plattform-Prüfungs-Zyklen, gedächtnisbasierte Kontext-Pflege und visuelle Prozess-Dokumentation in einem etablierten Modellier-Standard.

• 24/7-Detection – synthetische End-to-End-Proben prüfen die wichtigsten Pfade im Minuten-Takt, hourly-Smokes verifizieren Container-Health, ein täglicher Health-Report bestätigt am Morgen den Zustand der Plattform. Kein Mitarbeiter muss „auf den Bildschirm starren".
• Triage automatisch – jeder erkannte Vorfall wird gegen die Eskalations-Pipeline klassifiziert (P0 weckt sofort, P3 landet still im Backlog). Severity, Owner-Rolle und Folge-Aktion werden ohne Mensch in der Schleife festgelegt.
• Selbstheilung für bekannte Muster – Container-Healthchecks lösen bei definierten Anomalien automatische Restart-Pfade aus, mit definierter Rückkehr-Stufe. Berechtigungs-Verschiebungen im Storage werden strukturell verhindert. Ein stündlicher Wartungs-Lauf bereinigt hängende Verarbeitungs-Aufträge. Neue, bisher nicht klassifizierte Störungs-Muster werden über Push-Benachrichtigung eskaliert und manuell triagiert – diese Erweiterung um autonome Störungs-Erkennung ist als zwölfte Säule in Aufbau (siehe unten).
• Verpflichtende Vorfall-Auswertung erzeugt Wiederholungs-Anleitungen – jeder relevante Vorfall führt verpflichtend zu einer Auswertung mit Lehren. Aus der Auswertung entsteht eine Wiederholungs-Anleitung, die beim nächsten gleichartigen Symptom als Schablone bereitsteht. Der Stack wird mit jedem Vorfall robuster, statt fragiler.
• Markt-Watch und Plattform-Prüfung proaktiv – wochen- und monats-getaktete Zyklen prüfen Anbieter-Updates, Sicherheits-Hinweise und Wissens-Konsolidierungen sogar dann, wenn nichts gestört ist. So entsteht ein vorausschauender Verbesserungs-Strom statt reaktiver Brandbekämpfung.
• Plattform-Weiterentwicklung aus Störungen heraus – jede Vorfall-Auswertung speist die Aufgaben-Liste mit Feature-, Fehler- und Betriebs-Items. Der Produktmanager priorisiert daraus die nächste Release. Das System lernt nicht nur, sondern entwickelt sich aktiv weiter.

Stand der Säulen:

• Live (heute produktiv): 24/7-Detection im Minuten-Takt, automatische Triage gegen Eskalations-Pipeline, reaktive Selbstheilung für bekannte Störungs-Muster (stündlicher Wartungs-Lauf für hängende Verarbeitungs-Aufträge, strukturelle Verhinderung von Berechtigungs-Verschiebungen im Storage, Container-Neustart-Pfade mit definierter Rückkehr-Stufe). Verpflichtende Vorfall-Auswertung pro Störung.
• Live – Echtzeit-Störungsmanagement jenseits klassischer Ticketsysteme: Statt eines Ticket-Workflows in einem Tool-Silo nutzt der Stack proaktive Push-Benachrichtigungen über gängige Messenger-Kanäle direkt aufs Smartphone. Ein Vorfall der Severity P0 oder P1 erreicht den verantwortlichen Spezialisten unmittelbar am Gerät, ohne dass jemand ein Dashboard öffnen muss. 24 Heartbeat-Monitore senden ihre Ereignisse über einen dedizierten Push-Server, ergänzt um einen Multiplexer-Layer für künftige zusätzliche Empfänger und Kanäle.
• Im Ausbau (laufende Realisierung): Proaktive Bug-Discovery durch wöchentliche Stack-Sweeps und Anomaly-Detection auf Performance- und Verhaltens-Metriken. Autonomer Auto-Fix-Pfad (System erkennt Bug, schlägt Patch vor, validiert ihn in der Pre-Deploy-Stufe, rollt aus) ist als zwölfte Säule in Konzept und ersten Phase-1-Komponenten. Akustischer Sofort-Alarm-Pfad und Auto-Spawn für Recovery-Spezialisten als nächste Ausbau-Stufen.

Strategische Roadmap (in Aufbau)

Diese Säulen sind konzipiert, dokumentiert und schrittweise in Umsetzung. Sie ergänzen die heute live laufenden Mechanismen um weitere Differenzierungs-Achsen.

• Selbst-Bewertung der Antwort-Qualität – Konzept-Stand: kontinuierliche und automatische Qualitaets-Messung der Modell-Antworten, mit Auto-Rollback bei Verschlechterung. Heute manuelle Stichprobe über definiertes Test-Prompt-Set vor jedem Modell-Wechsel; Automatisierung der laufenden Messung ist als Phase-2-Item formuliert, Realisierung im Anschluss an Customer-Pilot.
• Auf LATUS zugeschnittene lokale Sprachmodelle – Die im Haus betriebenen Sprachmodelle werden gewissermaßen auf den LATUS-Flavor hin trainiert: gezielt auf die Themen, Begriffe und Branchen-Sprache abgestimmt, mit denen LATUS-Mitarbeitende täglich arbeiten. Damit antworten sie in den relevanten Themen präziser als allgemeine Standard-Modelle. Der gesamte Zuschnitt erfolgt im Haus, ohne Abhängigkeit von externen Anbietern.
• Compliance-Reife jederzeit sichtbar – Jede interne Regel, jeder Vorfall und jede regelmäßige Wartung wird automatisch mit den jeweils relevanten gesetzlichen und regulatorischen Anforderungen verknüpft. Aus dieser Verknüpfung lassen sich Audit-Berichte auf Knopfdruck erzeugen. Die Vorbereitung von Audits verkürzt sich damit erheblich, regulatorische Reife ist jederzeit nachweisbar.
• Mandantenfähige Plattform-Architektur – Mehrere voneinander getrennte Mandanten können dieselbe Plattform nutzen, ohne dass ihre Daten oder ihre Mitarbeitenden sich vermischen. Jeder Mandant hat seinen eigene geschützten Bereich mit eigene Inhalten und eigenem Zugang, teilt sich aber den bewährten technischen Unterbau. So lassen sich neue Mandanten hinzunehmen, ohne die Plattform pro Mandant neu aufzubauen.
• Workflow-Automatisierung als Plattform- und Geschäfts-Ebene – Eine visuelle Workflow-Plattform übernimmt zwei Rollen gleichzeitig. Erstens als Geschäfts-Ebene: Mail-Eingang, Dokumenten-Änderungen, periodische Berichte und Mitarbeiter-Onboarding-Pfade lösen Workflows aus, die Wissensbasis-Suche, Dokumenten-Erzeugung und externe System-Anbindung kombinieren. Damit wandelt sich der Stack vom reinen Backend-Werkzeug zur durchgängigen Geschäfts-Plattform, die jede Fach-Abteilung selbst weiterentwickeln kann. Zweitens als Plattform-Stabilisierungs-Ebene: Cross-Komponenten-Synchronisation, trigger-basierte Selbstheilungs-Workflows, Wartungs-Zyklen und Health-Probe-Schleifen laufen ebenfalls in derselben Workflow-Plattform – konfigurierbar, mit nachvollziehbarem Vorgangs-Protokoll und ohne in einzelnen Skripten verstreut zu sein. Die zwölfte Säule (autonome Störungs-Erkennung und Selbstreparatur-Pipeline) wird durch diese Plattform-Schicht erst praktisch realisierbar.
• Autonome Störungs-Erkennung und Selbstreparatur-Pipeline – Über die heutige reaktive Selbstheilung hinaus erkennt das System neue Störungs-Muster eigenständig: wöchentliche strukturierte Plattform-Prüfungen kontrollieren jede Komponente gegen Soll-Konfiguration, Anomalie-Erkennung auf Performance- und Verhaltens-Metriken meldet auffällige Verschiebungen, und ein Selbstreparatur-Pfad schlägt Korrekturen vor, validiert sie in einer Pre-Deploy-Stufe und rollt sie nach erfolgreichem Test aus. Erkennung und Behebung werden damit zum kontinuierlichen Hintergrund-Prozess, der ohne menschlichen Anstoß läuft.
• Stack-externe Aussensicht über zweite Internet-Strecke – Eine unabhängige Probe-Strecke prüft den Stack über einen zweiten Internet-Anbieter (Mobilfunk-Backup) und vergleicht ihre Beobachtung kontinuierlich mit der internen Statussicht. Routing- oder Anbieter-spezifische Störungen werden damit sichtbar, die interne Watchdogs nicht erkennen können – etwa wenn der primäre Internet-Pfad gestört ist, der Stack selbst aber erreichbar bleibt. Die Probe-Strecke ist physikalisch unabhängig vom primären Pfad und liefert eine echte Aussensicht-Detection, die über reinen Failover-Backup hinausgeht. Das Pattern ist auf Kunden-Setups mit zwei Internet-Anbindungen direkt übertragbar.

Reifegrad-Stand der Säulen

Stand pro Säule. Klassifikation in drei Stufen: Konzept (dokumentiert, nicht implementiert), Pilot (teilweise implementiert oder unter Beobachtung), Live (produktiv mit beobachtbarem Messpunkt). Belege werden intern vorgehalten und auf Anfrage offengelegt.

Methodik: Reifegrad-Stand pro Säule wird im Quartals-Doku-Pass aktualisiert. Stufen-Wechsel erfordert, dass die Aussage dokumentarisch belegbar ist und auf einer beobachtbaren Quelle ruht. Live-Aussagen ohne Beleg sind unzulässig.

Wie unser KI-Stack denkt

Bis hier ging es um den Reifegrad der Säulen. Jetzt geht es um die Mechanik dahinter: wie der Stack sich Wissen merkt, wie er bei festgefahrenen Fragen rauskommt und wie er bei komplexen Aufträgen mehrere Spezialisten gleichzeitig ansetzt.

Wie wir uns erinnern

Wissen ist nur dann nützlich, wenn es im richtigen Moment wieder auftaucht. Je größer der Stapel an Erinnerungen, desto schwieriger wird genau das. Unser Vorbild dafür ist das menschliche Gehirn.

Statt eines einzigen großen Buchs bauen wir die Wissensbasis als Netz aus kleinen Themen-Inseln, die untereinander verbunden sind. Taucht ein Thema auf, holt sich die KI nur die passenden Inseln dazu, plus die verwandten, die gleich auch wichtig werden. So wie du beim Stichwort „Kunden-Workshop" automatisch an Flipchart und Beamer mitdenkst.

Im Alltag merkst du das daran, dass Antworten schneller und treffender kommen und alte Erkenntnisse nicht verloren gehen, wenn neue dazukommen.

Was passiert eigentlich, wenn wir nicht hinschauen

Wer abends mit einem Problem ins Bett geht und morgens beim Zähneputzen die Lösung im Kopf hat, kennt das Phänomen. Im Schlaf wird einsortiert, gewichtet, mit älterem Wissen verknüpft.

Genau diese Bewegung läuft bei uns regelmäßig im Hintergrund. Tagsüber gesammelte Erlebnisse werden sortiert und ins Langzeit-Wissen abgelegt. Lose Notizen werden zu Themen verdichtet, Unwichtiges verblasst, ohne gelöscht zu werden.

Was du davon merkst: wenn du nächste Woche eine Frage stellst, die an etwas vor zwei Monaten anknüpft, kommt die richtige Verbindung. Nicht weil die KI sich „alles gemerkt" hat, sondern weil zwischendurch jemand aufgeräumt hat.

Wenn wir uns festbeißen

Du sitzt seit Stunden an einem Punkt, bohrst tiefer und tiefer, und der Kollege kommt rein, schaut kurz drüber und sagt: „Vielleicht ist die Frage falsch gestellt." Manchmal ärgerlich, fast immer richtig.

Diese Fähigkeit haben wir unserer KI anerzogen. Merkt sie, dass mehrere Lösungs-Anläufe sich ähneln und nicht treffen, bohrt sie nicht tiefer im gleichen Loch, sondern macht einen Schritt zurück und fragt, ob die Frage eigentlich die richtige ist. Eingebaut haben wir das nach einer eigene fünftägigen Bug-Suche, an deren Ende eine simple Konfigurations-Frage die Antwort war.

Wenn du der KI ein verzwicktes Problem hinlegst und spürst, dass sie zwischendurch innehält und es von einer anderen Seite anguckt, ist das kein Mangel an Geradlinigkeit, sondern Disziplin.

Warum manchmal mehrere Köpfe gleichzeitig denken

Stell dir vor, du sollst in einer Stunde einen Vortrag halten, und die Folien sind nicht fertig, der Co-Referent steht im Stau. Linear hintereinander schaffst du das nicht. Du delegierst, parallelisierst, behältst den Überblick.

Genauso arbeitet der Stack bei größeren Aufträgen. Statt einen Kollegen alles selbst machen zu lassen, schickt die KI mehrere Spezialisten gleichzeitig los, jeder auf sein Fachgebiet fokussiert. Einer schaut auf die Daten, einer auf die Plattform-Schicht, einer auf das Login, einer auf die Modelle. Die Befunde werden zusammengeführt, gegengeprüft und in eine Antwort kondensiert.

Beigebracht haben wir ihr das, weil sie sonst höflich einen Punkt nach dem anderen abarbeitet. Spürst du in einer Antwort, dass mehr drinsteckt als der Überblick eines einzelnen Bearbeiters, ist das die Synthese aus mehreren Köpfen.

So denkt der Stack im Hintergrund. Wie er konkret gebaut ist, beschreiben die nächsten Sektionen.

Architektur unserer lokalen Wissens-Suche

Die lokale Wissens-Suche ist eine Schichtung aus mehreren spezialisierten Komponenten. Jede Schicht trägt einen klar abgegrenzten Beitrag zum Antwort-Pfad bei: vom Verstehen der Dokument-Struktur über die Bedeutungs-Erkennung bis zur Antwort-Formulierung mit Beleg-Marker. Die Bündelung erlaubt Antworten auf Fach-Fragen, ohne dass Firmen-Dokumente die eigene Infrastruktur verlassen.

Schichten der lokalen Wissens-Suche

Was diese Architektur in der Praxis bedeutet

• Datenhoheit ist nachweisbar. Alle Schichten plus das Antwort-Modell laufen auf eigener Hardware. Vertragstexte, Angebote oder Vorgangs-Dokumente verlassen die Infrastruktur nicht. Für regulierte Branchen, kommunale Versorger und alle Organisationen mit Datenhoheits-Pflicht ist das eine Voraussetzung.
• Antworten sind belegbar. Jede Aussage trägt einen Zitat-Marker auf den Original-Beleg. Wer eine Antwort prüft, sieht in einem Klick die Quell-Stelle. Das ist die Grundlage für nachvollziehbare und prüfbare Arbeit mit sensiblen Inhalten.
• Komponenten sind einzeln auswechselbar. Jede Schicht ist ein eigenständiger Baustein. Wenn ein neueres Embedding- oder Sprachmodell deutlich voranzieht, lässt sich die jeweilige Schicht isoliert tauschen, ohne den Rest neu zu bauen. Relevant für Organisationen, die langfristig keine geschlossene Black-Box erben wollen.
• „Im Ausbau" heißt: in geordneter Realisierung. Die mit „Im Ausbau" markierten Schichten haben einen festgelegten Realisierungs-Pfad mit Reihenfolge und Aufwands-Schätzung. Das Reifegrad-Modell trennt belastbar zwischen Live und Plan.

User-Sicht im Benutzerhandbuch (Kapitel 17)

Verwendung der lokalen KI

Antwort-Modelle, Embedding-Modelle und Wissens-Verdichtung laufen auf dedizierter Hardware im Haus. Inhalte verlassen die Infrastruktur nicht, weder Trainings-Daten noch Prompts noch Antworten. Die Latenz unter Nutzer-Last bleibt steuerbar, weil keine Cloud-API-Limits oder Rate-Schwellen greifen.

Schichten der lokalen KI

Was die lokale KI in der Praxis ermöglicht

• Voraussetzung für vertrauliche Anwendungs-Fälle. Inhalte mit hoher Schutz-Stufe lassen sich nur dann KI-gestützt bearbeiten, wenn die Verarbeitung das Haus nicht verlässt. Lokale Modelle sind dafür die erste Wahl – relevant für jede Organisation, die Kunden-, Mandanten- oder Bürger-Daten nicht ins Internet exponieren darf.
• Sichtbare Trennung im Bedien-Modell. Lokale und Cloud-Modelle stehen im selben Picker, sind aber klar markiert. Nutzende treffen die Wahl pro Anfrage bewusst, statt sich auf eine pauschale Voreinstellung zu verlassen.
• Replizierbarer Aufbau. Der Ansatz ist auf eigene Editionen mit eigener Hardware übertragbar. Modell-Wechsel und Hardware-Skalierung sind ohne Stack-Umbau möglich.

Verwandtes Kapitel im Benutzerhandbuch

Verwendung des PII-Filters

Vor jedem Cloud-Modell-Aufruf läuft ein Anonymisierungs-Schritt. Personen-, Organisations-, Adress- und Identifikator-Hinweise werden im Prompt durch Platzhalter ersetzt. Das Cloud-Modell sieht ausschließlich Platzhalter, die Antwort wird beim Eingang wieder ent-anonymisiert. So lassen sich Cloud-Modelle für Anwendungs-Fälle nutzen, die von ihrer Reasoning-Stärke profitieren, ohne dass identifizierende Inhalte das Haus verlassen.

Schichten des PII-Filters

Was der PII-Filter im Alltag bewirkt

• Erweitert die Cloud-Modell-Nutzung um eine Vertraulichkeits-Stufe. Lokale Modelle bleiben für hochvertrauliche Fälle die erste Wahl. Der Filter macht Cloud-Modelle für mittel-vertrauliche Fälle nutzbar, etwa für Stilarbeit oder sehr große Kontexte, die lokal an Grenzen stoßen.
• Schichten produktiv, Modell-Trennung im Bedien-Modell sichtbar. Anonymisierung, Platzhalter-Mapping und De-Anonymisierung laufen produktiv im Anfrage-Pfad. Modelle ohne Filter bleiben für sensible Inhalte sichtbar abgegrenzt.
• Sichtbar im Bedien-Modell. Nutzende sehen vor dem Absenden, ob ein Filter aktiv ist, und wählen Modell-Stufe und Anfrage-Inhalt bewusst dazu passend.

Verwandtes Kapitel im Benutzerhandbuch

Architektur unserer zwei Wissens-Modelle

Unsere Wissens-Suche bietet zwei voneinander getrennte, gleichzeitig adressierbare Wissens-Modelle: ein gemeinsames Organisations-Wissen aus dem zentralen Dokumenten-Repository und eine persönliche Schicht aus dem persönlichen Speicher der einzelnen Mitarbeitenden. Beide Modelle laufen auf derselben lokalen Antwort-Infrastruktur, bleiben aber identitätsbasiert sauber getrennt.

Schichten der zwei Wissens-Modelle

Was die zwei Wissens-Modelle für Nutzende ändern

• Im Markt selten anzutreffen. Eine Marktanalyse vom Mai 2026 über neun untersuchte Vergleichs-Lösungen zeigt: keine erfüllt alle vier Eigenschaften gleichzeitig, also Trennung in zwei adressierbare Modelle, native Anbindung an das vorhandene Dokumenten-Ökosystem, lokale Inferenz und identitätsbasierte Trennung pro Person.
• Cloud-Plattformen verarbeiten in Anbieter-Cloud. Verbreitete Cloud-KI-Plattformen verarbeiten Inhalte in der jeweiligen Anbieter-Cloud. Verbreitete Open-Source-Stacks bringen die identitätsbasierte Trennung pro Person nicht out-of-the-box mit.
• Vertraulichkeits-Profil mit Markt-Seltenheit. Mit der Kombination adressiert die Plattform ein Vertraulichkeits-Profil, das in dieser Form im Markt unüblich ist. Nutzende wählen pro Anfrage bewusst die Quelle.

Verwandtes Kapitel im Benutzerhandbuch

Architektur unserer lebenden Doku

Die LATUS-Doku ist nicht statisch. Sie wird täglich angepasst, sobald sich am Stack, an der Methode oder am Reifegrad einer Funktion etwas verändert. Damit Aussagen jederzeit verlässlich bleiben, läuft die Doku auf einem mehrschichtigen Modell aus Versionierung, Reifegrad-Markierung, Forschungs-Belegen und beidseitiger Verlinkung.

Schichten der lebenden Doku

Was die lebende Doku in der Praxis ändert

• Aussagen bleiben belastbar. Jede Aussage trägt einen Reifegrad und ein Stichdatum. Wer die Doku liest, bekommt keine Werbe-Aussagen ohne Beleg, sondern Stand-Aussagen, die auf der gleichen Quelle wie die Operations-Sicht beruhen.
• Drift wird sichtbar. Sobald sich Stack oder Methode ändern, wird die Doku in derselben Welle nachgezogen. Reifegrad-Marker und Changelog-Eintrag dokumentieren den Übergang, statt ihn unter den Tisch fallen zu lassen.
• Beidseitig nutzbar. Mitarbeitende und Externe lesen unterschiedliche Tiefen, greifen aber auf dasselbe Quellen-Material zu. Das schützt vor doppelter Pflege und vor widersprüchlichen Aussagen zwischen interner Sicht und Außen-Darstellung.
• Replizierbar in eigene Editionen. Die Doku-Mechanik ist nicht an einen bestimmten Inhalts-Korpus gebunden. Sie lässt sich auf eigene Editionen mit eigener Themen-Welt übertragen, ohne den Charakter der lebenden Doku zu verlieren.

Verwandtes Kapitel im Benutzerhandbuch

Architektur unserer Pre-Deploy-Validierung

Änderungen an Konfigurations-Dateien, die im laufenden Betrieb wirken, gehen nicht direkt auf die Production-Schicht. Sie laufen vorher durch eine sechsschrittige Mechanik, die Backup, Lokal-Edit, Validierung, Deployment, Healthcheck und Audit verbindet. Damit lassen sich Service-Glitches durch fehlerhafte Edits verhindern, statt sie nachträglich zu reparieren.

Schichten der Pre-Deploy-Validierung

Was die Pre-Deploy-Validierung im Alltag schützt

• Schutz vor Service-Glitches durch Edit-Fehler. Konfigurations-Brüche fangen an der Validierungs-Schicht ab, statt erst beim Mitarbeitenden im Tool zuzuschlagen. Ein einzelner Tippfehler legt nicht mehr eine ganze Schicht lahm.
• Auditierbarkeit ohne manuellen Aufwand. Audit-Einträge entstehen automatisch im Edit-Vorgang. Der Plattform-Betrieb ist nachvollziehbar dokumentiert, ohne dass jemand parallel ein Edit-Protokoll führen muss.
• Rollback ist Sekunden-Geschäft. Backup mit Hash und automatischer Rollback-Pfad bedeuten, dass eine fehlerhafte Änderung schnell und vollständig zurückgenommen wird. Down-Zeit bleibt im Sekunden-Bereich, nicht im Minuten- oder Stunden-Bereich.
• Replizierbar in eigene Editionen. Die sechs Schritte sind nicht an einen einzelnen Stack gebunden. Sie sind als Pattern auf andere Schichten und auf eigene Hardware übertragbar, ohne dass die Mechanik neu erfunden werden muss.

Verwandtes Kapitel im Benutzerhandbuch

Architektur unserer Identitäts- und Berechtigungs-Schicht

Jede User-sichtbare Funktion läuft hinter einer zentralen Identitäts-Schicht, die Login, Berechtigungen und User-Space-Trennung steuert. Lokale Anbieter-Logins der einzelnen Tools sind als Backdoor strikt abgegrenzt. Damit bleibt der Login-Pfad einheitlich, während die Funktions-Schicht modular bleibt.

Schichten der Identitäts- und Berechtigungs-Logik

Was die Identitäts-Schicht in der Praxis schützt

• Ein Login für alle Tools. Mitarbeitende lernen einen Login-Pfad, nicht zehn. Onboarding und Offboarding einer Person laufen über eine einzige Schicht, statt zehn Tool-Konten einzeln zu pflegen.
• Mandanten-Trennung bleibt klar. Single-Tenant-Abweisung greift vor dem Tool und damit vor jeder Tool-eigene Schwäche. Die Plattform schützt gegen Cross-Tenant-Lecks unabhängig vom Reifegrad einzelner Tools.
• Backdoor ist nicht Bedien-Modell. Service-Eingriffe laufen über klar getrennte Pfade, die im Mitarbeiter-Bedien-Modell nicht erscheinen. Damit bleibt der Mitarbeiter-Pfad konsistent, während Service-Arbeiten eigene Spuren hinterlassen.
• Replizierbar in eigene Editionen. Der Aufbau ist auf eigene Editionen übertragbar, weil Tools und Identitäts-Hub voneinander entkoppelt sind. Ein Wechsel des Identitäts-Hubs ist möglich, ohne jedes einzelne Tool umzubauen.

Verwandtes Kapitel im Benutzerhandbuch

Was wir noch planen

Aktuell laufende Vorhaben in Kurzform. Die strategische Gesamt-Roadmap mit allen sechs Säulen findet sich oben unter Was hier neu ist; die detaillierte Architektur des persönlichen Wissens-Modells ist unter Schichten der zwei Wissens-Modelle beschrieben.

• Persönliches Wissens-Modell: identitätsbasierte personalisierte Wissens-Schicht, Pilot-MVP mit drei Mitarbeitenden geplant. Detaillierte Architektur siehe Schichten der zwei Wissens-Modelle.
• Reranker für Wissens-Suche: zusätzliche Präzisierungs-Schicht beim Treffer-Ranking, sobald die Wissens-Basis größer wird.
• Mandantenfähiges Operations-Modell auf Code-Ebene: Variabilisierung von Hostnamen, Pfaden und Domänen plus getrennte Eskalations-Kanäle pro Kunden-Mandanten.
• Antwort-Qualitäts-Sicherung mit Auto-Rollback: Eval-Sets in deutscher Fach-Sprache der eigene Domäne, Pre-/Post-Edit-Replay, monatliche Set-Pflege.

Was sich davon in eigene Projekten übertragen lässt

LATUS AI ist gleichzeitig Werkzeug für die tägliche Arbeit und Reifegrad-Lieferant für Know-how. Beim Bauen des Stacks ist Praxis-Wissen entstanden, das sich in eigene Kunden-Projekten wiederverwenden lässt - jenseits der konkreten LATUS-Edition. Die folgenden Bausteine haben sich im Live-Betrieb bewährt und sind portierbar in vergleichbare Stacks.

• Lokale KI-Inferenz auf eigener Hardware. GPU-Sizing nach realem Last-Profil, Modell-Auswahl mit Cap-Realismus statt Marketing-Versprechen, getrennte Slots für unterschiedliche Aufgaben-Profile (Standard, Premium, Deep Thinking, lokal vs. Cloud).
• Zwei-Wissens-Modelle-Architektur. Gemeinsames Organisations-Wissen und persönliche Wissens-Schicht laufen parallel auf derselben Antwort-Infrastruktur, bleiben aber identitätsbasiert sauber getrennt. Übertragbar überall, wo persönliches und gemeinsames Wissen koexistieren müssen.
• PII-Filter-Schicht vor Cloud-Modellen. Anonymisierung beim Verlassen des eigene Netzes und De-Anonymisierung beim Rückweg auf identische Token-Marker, damit Cloud-Modelle ohne Klartext-PII arbeiten und der Mitarbeiter trotzdem die echten Namen in der Antwort sieht.
• Zentrale Identitäts-Schicht mit Single-Tenant-Abweisung. Vorgelagerter Zugangs-Filter vor der Applikation, Pass-Through zu einem zentralen Identitäts-Hub und einem zweiten Identitäts-Provider für externe Mitarbeitende. Der Hub ist entkoppelt von einzelnen Tools und austauschbar.
• Lebende Doku mit Reifegrad-Markierung und Versionierung. Jede Aussage trägt einen Reifegrad-Stand (Konzept, Pilot, Live) und ein Stichdatum. Änderungen am Stack führen automatisch zu Doku-Anpassungen, statt Doku als Nachgang zu behandeln.
• Pre-Deploy-Validierungs-Mechanik mit Backup + Rollback + Audit. Vor jeder Mutation entsteht ein Snapshot, jede Änderung wird gegen einen empirischen Pre-Check abgesichert, Rollback ist ein Ein-Befehl-Pfad, Audit-Einträge entstehen automatisch im Edit-Vorgang.

Wer einen dieser Bausteine bei einem Kunden aufsetzt, hat hier eine belastbare Referenz, die nicht nur auf dem Papier funktioniert.

Wie ist die Org aufgebaut

Die Organisationsstruktur ist integraler Bestandteil der LATUS-AI-Entwicklung. Sie ermöglicht proaktives und selbsttätiges Störungs- und Entwicklungsmanagement durch klare Rollen-Verantwortlichkeiten und definierte Eskalationspfade. Die Struktur ist seit 30. April 2026 in produktivem Betrieb.

• Strategische Freigabe-Instanz Stephan Klahr trifft die Final-Decisions.
• LATUS-AI-Hauptagent führt operativ, hired Spezialisten, konsolidiert Berichte.
• Zwei Stabstellen: Hiring-Manager (Multi-Domain-Operations), Produktmanager (Feature-Lifecycle).
• Dreizehn Spezialisten-Rollen: Office-Engineer, LLM-Ops, Knowledge-Pipeline, Observability-Engineer, Security-Audit (Sicherheits-Prüfung, Cred-Hygiene), Portal-UX-Engineer (Kompass-Layout, Accessibility, Kunden-Edition-Templating), Chat-UX, Self-Healing-Engineer, Test-Automation-Manager (Pre-Deploy-Validierung und Post-Deploy-Healthcheck als Schwester-Rolle zur Selbstheilung), Infrastructure-Reliability-Engineer (Hardware, Storage, Kernel, GPU-Scheduling als Schwester-Rolle zur Selbstheilung auf Infrastruktur-Ebene), Doc-Keeper, Memory-Keeper, Strategy-Researcher.

Die Top-5-Prozesse

Reifegrad-Modell mit fünf Stufen (Konzept / Pilot / Etabliert / Reif / Kontinuierlich verbessert, siehe Reifegrad-Definition). Detail je Prozess: Diagramm in einem etablierten Modellier-Standard plus Begleit-Beschreibung.

Weitere Prozesse (z. B. Hiring-Workflow als Top-6, Pre-Compact-Handoff als Top-7) werden in Detail-Seiten geführt, sobald sie regelmäßig nachgefragt werden. Wir vermeiden bewusst „Prozesse für Prozesse"-Bürokratie.

Glossar und Reifegrad-Modell

• Glossar für Externe - LATUS-spezifische Begriffe wie Subagent, Personal-Akte, Schwarzes Brett, Kompass und Reifegrad-Modell.
• Reifegrad-Definition - 5-Stufen-Modell mit Messmethodik und Anti-Inflations-Mechanik.

Zugang für User

Diese Site ist für Förder-Audit und Org-Sicht. Wenn du als Teammitglied ein konkretes „wie nutze ich LATUS AI" suchst, geht es im Benutzerhandbuch weiter.