Arbeitsweise
Forschung muss sich im System bewähren.
LatentDrift arbeitet mit Fachbereichen, Produkt- und Entwicklungsteams an den Entscheidungen, von denen ein KI-System im Betrieb abhängt. Neue Verfahren setzen wir nur ein, wenn sie im konkreten Anwendungsfall einen erkennbaren Nutzen haben, ihre Grenzen prüfbar und ihre Schnittstellen klar sind. Fachliche Anforderungen und technische Folgen betrachten wir gemeinsam, damit weder ein überzeugender Prototyp noch die Wahl eines einzelnen Modells den Systementwurf vorgibt.
Arbeitsweise
Fachliche Entscheidungen, technische Architektur und späterer Betrieb lassen sich nicht getrennt planen. Deshalb arbeiten die beteiligten Rollen mit denselben Annahmen, Risiken und Qualitätsmaßstäben. Forschung liefert Optionen. Der Anwendungsfall entscheidet, welche davon sinnvoll sind. Entscheidungen bleiben so verständlich, Tests beziehen sich auf reale Arbeitssituationen und andere Teams können den Stand später weiterentwickeln.
Neue Verfahren prüfen wir auf Wiederholbarkeit, Messbarkeit und ihre Einbindung in ein bestehendes System. Bei Agentensystemen fragen wir zum Beispiel: Welcher Agent kennt welche Informationen? Was darf er tun, wie werden Aufgaben verteilt und was geschieht nach einem Fehler? Eine Methode fließt in ein Projekt ein, wenn diese Fragen beantwortet und ihre Grenzen in realistischen Tests sichtbar werden – nicht allein, weil sie in einer Veröffentlichung überzeugt.
Wir betrachten fachliche Anforderungen, Datenzugriffe und Systemzustände gemeinsam. So wird klar, wer welche Entscheidung trifft, welche Informationen ein Ergebnis stützen und an welcher Stelle eine Freigabe nötig ist. Damit passen Architektur und tatsächlicher Arbeitsablauf zusammen.
Bereits im Entwurf muss klar sein, woran Nutzer den Zustand des Systems erkennen, wie sie Ergebnisse prüfen und wann sie eingreifen oder übernehmen. Diese Fragen betreffen nicht nur die Oberfläche. Sie verbinden Fachprozess, Systemverhalten und Verantwortung – bei Cockpits ebenso wie bei Sprachschnittstellen oder avatarbasierten Anwendungen.
Zusammenarbeit
Im Mittelpunkt stehen der konkrete Anwendungsfall, verfügbare Daten, beteiligte Rollen, kritische Fehlentscheidungen und klare Qualitätsmaßstäbe. Diese Punkte bleiben mit den Architekturentscheidungen und Tests verbunden. So können Fachbereich und Technik ihre Abwägungen gemeinsam prüfen, ohne Konzept, Entwicklung und spätere Weiterarbeit künstlich voneinander zu trennen.
Festgehalten wird, welcher Prozess besser werden soll, wer damit arbeitet und welche Fehlentscheidungen besonders kritisch wären. Daraus lassen sich Datenzugriffe, Speicherregeln und Freigaben begründen. Auch verworfene Optionen und offene Fragen bleiben sichtbar, damit spätere Änderungen nicht wieder bei null beginnen.
Jede Umsetzung muss konkrete Systemfragen beantworten: Funktioniert der Datenzugriff? Bleiben Agenten in ihren Rollen? Reagiert die Schnittstelle bei Unterbrechung verständlich? Realistische Beispiele und fachliches Feedback zeigen, ob sich der Ansatz bewährt. Qualität, Reaktionszeit und Kosten bleiben messbar, sodass nötige Änderungen früh sichtbar werden.
Code, Tests und Dokumentation bilden gemeinsam den aktuellen Stand ab. Typische und fehlerhafte Läufe zeigen, wie das System reagiert. Entscheidungen und bekannte Grenzen bleiben im Repository nachvollziehbar. Damit ist klar, was bereits belastbar ist, was bewusst experimentell bleibt und wo noch fachliche oder regulatorische Fragen offen sind.
Anwendungsfall
Für einen ersten Austausch reichen der betroffene Prozess, die verfügbaren Datenarten, die beteiligten Rollen und die wichtigsten Risiken. Daraus lässt sich klären, welche fachlichen und technischen Fragen gemeinsam bearbeitet werden müssen. Vertrauliche oder personenbezogene Inhalte werden dafür nicht benötigt und gehören nicht in die E-Mail.
Anwendungsfall skizzieren