Das IntakeOps Manifesto
Ihr Unternehmen hat einen Datenfriedhof. Jedes Unternehmen hat eines.
Acht Jahre Jira-Tickets. Tausende Confluence-Seiten. Störungsberichte, Threads zu Problemumgehungen, geschlossene Tickets ohne Lösungshinweise. Die gesamte Historie aller Probleme, die Ihr Team je gelöst hat – vergraben, unauffindbar, praktisch verloren.
Das ist operativer Wissensverfall. Und er verstärkt sich jedes Quartal.
Wenn erfahrene Ingenieure das Unternehmen verlassen, geht auch wertvolles Fachwissen verloren. Mit steigendem Ticketaufkommen sinkt das Verhältnis von relevanten zu irrelevanten Informationen. Mit der zunehmenden Verbreitung von KI-Tools in Ihrer Systemarchitektur wiederholt sich diese Fragmentierung in größerem Umfang – schneller und gleichzeitig auf mehr Systemen.
Das Ergebnis sind drei sich gegenseitig verstärkende Funktionsstörungen:
Expertenengpässe. Ihre leitenden Ingenieure verbringen ihre Zeit damit, Probleme zu lösen und Fragen zu beantworten, die bereits vor Jahren irgendwo von irgendjemandem beantwortet wurden. Sie können keine Innovationen entwickeln, weil sie den Betrieb aufrechterhalten müssen.
Institutionelle Amnesie. Ihr Team löst immer wieder dieselben Probleme, weil die Lösungen versteckt und unzugänglich sind. Jeder neue Mitarbeiter fängt bei null an. Jede Vorfallsuntersuchung rekonstruiert bereits vorhandene Zusammenhänge.
Gescheiterte KI-Initiativen. Ein Chatbot, der auf einem Datenfriedhof basiert, ist lediglich ein schnellerer Weg, falsche Antworten zu erhalten. Generische KI-Tools setzen saubere, strukturierte Daten voraus. Die Realität sieht jedoch anders aus: unübersichtliche Tickets, informelle Workarounds und implizites Wissen, das nie dokumentiert wurde.
In risikoreichen Industrieumgebungen ist dies kein Produktivitätsproblem. Produktionsausfälle in großem Umfang kosten Millionen pro Stunde. Die Unfähigkeit, jetzt die richtige Lösung zu finden, hat einen messbaren Preis.
Warum bestehende Ansätze scheitern
Die erste Generation von KI-Systemen versuchte, dieses Problem mit verbesserter Suche und größeren Modellen zu lösen. Es hat nicht funktioniert – nicht weil die Modelle schwach sind, sondern weil das Fundament mangelhaft ist.
Auf unstrukturiertem Chaos lassen sich keine verlässlichen Erkenntnisse gewinnen. Die Suche nach Daten auf einem Datenfriedhof liefert nur unbrauchbare Inhalte. Das Problem ist nicht das darüberliegende Modell, sondern die darunter liegende, jahrzehntelange Betriebshistorie – unstrukturiert, unbeschriftet und ohne jegliche Erkenntnisse.
Die Tools, zu denen die meisten Teams greifen – Dokumentensuche, generische Chatbots, vorgefertigte Copiloten – sind für saubere Daten konzipiert. Sie funktionieren in Demos. Im Produktivbetrieb versagen sie, wo das wirklich relevante Wissen in alten Tickets, abgeschlossenen Vorgängen und im Gedächtnis von Mitarbeitern gespeichert ist, die möglicherweise nicht mehr im Unternehmen arbeiten.
Die Architektur ist wichtiger als die Modellgröße. Auf dieser Überzeugung basiert unser gesamtes Werk. Auf dieser Überzeugung haben wir aufgebaut.
Was wir glauben
Operative Intelligenz sollte auf bereits vorhandenen Daten basieren – nicht auf Daten, die jemand erst nach einiger Zeit dokumentiert hat. Die 80 % des operativen Wissens, die in Tickets, Protokollen und informellen Kanälen verborgen sind, sind kein Rauschen. Sie stellen die präziseste Aufzeichnung des tatsächlichen Verhaltens Ihrer Systeme dar.
KI-Systeme sollten ihre Funktionsweise offenlegen. Wenn eine Empfehlung eine Produktionsentscheidung, einen Wartungsauftrag oder ein Compliance-Ergebnis beeinflusst, benötigt Ihr Team mehr Informationen als die Systemergebnisse. Es muss wissen, wie diese zustande kamen – welche Quellen herangezogen wurden, welche Signale relevant waren und wo Unsicherheiten bestehen. Transparenz ist keine optionale Funktion, sondern eine Grundvoraussetzung für operatives Vertrauen.
Systeme sollten aus dem lernen, was passiert, nicht aus dem, woran sich die Benutzer erinnern, es zu melden. Explizites Feedback verliert in jeder Betriebsumgebung schnell an Bedeutung. Echte Verbesserungen ergeben sich aus Verhaltenssignalen – welche Empfehlungen umgesetzt, welche ignoriert und wo die Ingenieure nach zusätzlichen Informationen gesucht haben. Das System sollte sich durch Nutzung verbessern, nicht durch Disziplin.
Ihre operativen Informationen sollten Ihr Eigentum bleiben. Es sollte auf Ihrer eigenen Infrastruktur laufen, mit von Ihnen freigegebenen Modellen und in jedem Entscheidungspunkt transparent sein. Keine obligatorische externe Datenübertragung. Keine Abhängigkeit von einem einzelnen Anbieter. Keine Blackbox, die Sie nicht überprüfen oder austauschen können.
Die Architektur ist genauso wichtig wie das Modell. Zuverlässige KI für den Produktiveinsatz erfordert eine strukturierte Datenerfassung, einen persistenten Speicher, eine deterministische Steuerung und kontinuierliches Lernen aus realen Abläufen. Dies sind technische Probleme, keine Modellierungsprobleme.
Die dafür erforderliche Disziplin: IntakeOps
Jede ausgereifte Entwicklungsorganisation bewältigt Komplexität bereits durch disziplinierte Vorgehensweisen. DevOps steuert die Codebereitstellung. MLOps steuert den Modelllebenszyklus. Eine dritte Disziplin fehlte bisher – eine, die die chaotische Realität des tatsächlichen Einfließens von Arbeit in KI-Systeme berücksichtigt.
IntakeOps ist die Ingenieursdisziplin für KI-Eingaben.
Während DevOps den Code verwaltet und MLOps die Modelle, kümmert sich IntakeOps um die unübersichtliche, mehrkanalige Realität menschlicher Anfragen – Tickets, Sprachnachrichten, Chat, E-Mails, Protokolle – und schafft die strukturelle Ebene, die operative Störungen in eine saubere, agentenbereite Ausführung verwandelt.
Ohne IntakeOps arbeitet jeder Agent und jede Automatisierung mit den jeweils verfügbaren Daten. Mit IntakeOps hingegen verfügen alle Agenten, Automatisierungen und Workflows über eine gemeinsame Intelligenzebene: strukturierten Kontext, persistenten Speicher und validiertes Betriebswissen.
Dies ist die Grundlage, die KI im Produktiveinsatz zuverlässig macht – nicht das Modell, nicht die Schnittstelle, sondern die Disziplin, die Eingaben zu verwalten.
So bauen wir: Compositional Agentic Architecture
Unsere Implementierung der IntakeOps-Prinzipien ist als Compositional Agentic Architecture — CAA formalisiert. Es handelt sich um einen strukturierten Entwurf für den Aufbau zuverlässiger, produktionsreifer operativer KI-Systeme mit fünf Schichten, die LLM-Schlussfolgerungen in zuverlässige Ausführung umsetzen.
CAA ist kein proprietäres Dogma. Sein Kern ist unter der Apache-2.0-Lizenz veröffentlicht. Wir tragen offen bei, weil sich das Fachgebiet schneller weiterentwickelt, wenn architektonisches Denken geteilt wird – und weil unser Vorteil darin besteht, diese Prinzipien in realen Betriebsumgebungen anzuwenden, nicht sie geheim zu halten.
Die fünf Schichten:
Kontext – Wandelt Rohdaten in strukturierte, typisierte und versionierte Informationen um. Die KI agiert kontextbezogen, nicht auf Basis von Vermutungen. Keine zusammengefügten Rohdaten. Keine unstrukturierten Eingabeaufforderungen.
Verhalten – Eine explizite, nachvollziehbare Planungsebene, die festlegt, was zu tun ist, bevor irgendetwas ausgeführt wird. Die Begründung ist sichtbar und nicht in einer einzigen, monolithischen Eingabeaufforderung verborgen.
Ausführung – Deterministische Arbeitsabläufe und Werkzeugaufrufe mit typisierten Schnittstellen, klarer Zielsetzung und vorhersehbaren Nebenwirkungen. Agenten, die handeln, nicht nur solche, die reagieren.
Status – Ein persistenter, strukturierter Arbeitsspeicher, der den Fortschritt über mehrstufige Arbeitsabläufe hinweg verfolgt. Das System merkt sich den Status. Der Kontext wird angesammelt, anstatt zurückgesetzt zu werden.
Zusammenarbeit – Mensch-Maschine-Interaktion ist von Anfang an in die Architektur integriert. Unterstützung für Unterbrechung, Überwachung, Überprüfung und Korrektur – nicht nachträglich hinzugefügt.
Zwei übergreifende Aspekte durchdringen alle Ebenen: Observability – vollständige Nachverfolgung, Metriken und Debugging an jedem Entscheidungspunkt – und Sicherheit – Authentifizierung, Isolation, Compliance und Governance. Hinzu kommt ein Aspekt des gesamten Lebenszyklus: Lernen und Anpassen – kontinuierliche Verbesserung anhand realer Betriebssignale, nicht synthetischer Benchmarks.
Diese Architektur wurde vom BSFZ – der staatlichen Zertifizierungsstelle für Forschung und Entwicklung in Deutschland – validiert, was bestätigt, dass unsere Forschung und Entwicklung strenge Standards für Innovation, technisches Risiko und systematische Planung erfüllt.
Warum der technische Support der richtige Ausgangspunkt ist
Operative Intelligenz muss sich in der Praxis bewähren, bevor sie flächendeckend eingesetzt werden kann. Sie benötigt ein Umfeld, in dem Wissen schnell validiert, Fehler rasch aufgedeckt und die Diskrepanz zwischen dokumentierten Prozessen und der operativen Realität täglich sichtbar wird.
Technischer Support ist diese Umgebung.
Jedes Ticket stellt eine Frage dar, die die Organisation anhand der vorhandenen Dokumentation nicht beantworten konnte. Jede Lösung ist ein wertvoller Erkenntnisgewinn. Jeder wiederkehrende Vorfall offenbart ein Muster, das es aufzudecken gilt. Das Ticketaufkommen ist hoch, die Rückmeldungen erfolgen schnell, und die Folgen von Fehlern sind sofort sichtbar.
Deshalb beginnt jede ArtiQuare-Implementierung hier – nicht nur, weil technischer Support der einzige Anwendungsfall ist, sondern weil dies der schnellste Weg zu validierten operativen Erkenntnissen ist. Die in dieser Umgebung entdeckten Muster, das strukturierte Wissen und die entwickelten Schlussfolgerungsketten bilden das Fundament für alles Folgende.
Ein System, das die Lücke schließt, die es eigentlich lösen sollte
Die Dokumentation hinkt der praktischen Realität stets hinterher. Bis eine Lösung dokumentiert ist, tritt das Problem bereits in einer neuen Variante auf. Bis ein Workaround dokumentiert ist, hat der Entwickler, der ihn entdeckt hat, das Projekt längst verlassen. Dies ist kein Disziplinproblem, sondern ein strukturelles. Menschliche Dokumentation erfasst immer nur einen Bruchteil des tatsächlichen Geschehens.
Arti wurde entwickelt, um diese Lücke automatisch zu schließen.
Das System lernt im laufenden Betrieb aus den täglichen Entscheidungen der Ingenieure – welche Empfehlungen umgesetzt, welche angepasst, welche verworfen wurden und warum. Es erkennt Dokumentationslücken, wenn Fragen nicht anhand vorhandener Quellen beantwortet werden können, und macht diese sichtbar, damit sie geschlossen werden können. Es erfasst das im täglichen Betrieb gewonnene Wissen – Lösungen, Workarounds, Musterkorrekturen – und integriert es in die operative Intelligenzschicht.
Dadurch entsteht ein positiver Kreislauf: Das System verbessert sich ohnehin durch die Arbeit Ihres Teams, ohne dass dafür gezielter Aufwand für das Wissensmanagement nötig ist. Die operative Realität fließt kontinuierlich in die Wissensebene zurück. Die Diskrepanz zwischen Dokumentation und Wissen verringert sich mit der Zeit, anstatt sich zu vergrößern.
The 80% of dark data doesn’t have to stay dark. Sie werden zum Trainingssignal.
Das Gesamtbild
Das heutige operative Datenchaos ist die unternehmensweite Herausforderung von morgen. Mit der zunehmenden Verbreitung von KI-Assistenten auf verschiedenen Plattformen, Tools und in individuellen Implementierungen wiederholt sich dieselbe Fragmentierung in großem Umfang – schneller und mit weitreichenderen Folgen.
Die Antwort liegt nicht in mehr KI-Werkzeugen. Sie besteht in einer gemeinsamen Intelligenzgrundlage.
Die IntakeOps-Schicht von Arti skaliert von operativer Effizienz zu einer einheitlichen Interaktionsarchitektur: eine einzige, kontrollierte Quelle für operative Kontextinformationen, aus der jeder Agent, jede Automatisierung und jeder Workflow in der Organisation Schlüsse ziehen kann. Keine Ansammlung unverbundener KI-Piloten. Eine kohärente operative Intelligenz, die mit jedem Einsatz dazulernt und sich weiterentwickelt.
Wir beginnen mit operativer Effizienz. Wir entwickeln uns hin zu organisatorischer Intelligenz.
Der Weg ist konsequent: strukturierte Datenaufnahme aus den bereits bestehenden Systemen, persistenter Speicher, der aus realen Betriebsdaten aufgebaut ist, deterministische Kontrolle, die an jedem Entscheidungspunkt sichtbar ist, und kontinuierliche Verbesserung durch die Arbeit, die Ihre Teams jeden Tag leisten.
Dies ist kein mehrjähriges Transformationsprogramm. Es beginnt mit einem zweiwöchigen Reibungsanalyse-Audit – einer Diagnose, die Ihre Betriebsdaten erfasst, die relevanten Muster aufdeckt und einen konkreten Plan dafür erstellt, was zuerst automatisiert werden sollte und warum.
Von der Prüfung bis zur Produktion in weniger als 90 Tagen. Und von da an verstärkt sich die Intelligenz.
So sieht operational intelligence in der Realität aus
Kein Chatbot. Kein Suchtool. Nicht noch eine weitere Abrufschicht über einem Datenfriedhof.
Ein Denksystem, das mit Ihren operativen Daten so arbeitet, wie sie tatsächlich vorliegen – unübersichtlich, unvollständig, über verschiedene Systeme verteilt – und die darin verborgenen Muster, Ursachen und institutionellen Kenntnisse sichtbar macht. Transparent. Nachvollziehbar. Auf einer Infrastruktur, die Sie kontrollieren.
Die Intelligenz war immer vorhanden. Sie war nur unzugänglich.