Projektformate
Das passende Format hängt von der offenen Frage ab.
LatentDrift arbeitet in drei Formaten. Welches passt, hängt davon ab, was noch unklar ist: der fachliche Nutzen, die Systemarchitektur oder das Verhalten eines kritischen Ablaufs unter realen Bedingungen. Die Formate bauen nicht aufeinander auf, sondern bieten unterschiedliche Einstiege.
Projektformate
Der KI-System-Check klärt, ob ein Anwendungsfall fachlich sinnvoll und technisch tragfähig ist. Im Mittelpunkt stehen Zielprozess, Datenverfügbarkeit, Nutzerrollen, Rechte, Latenz, Erklärungsbedarf und besonders kritische Fehlentscheidungen. So wird klar, welche Voraussetzungen fehlen, welcher Systemteil relevant ist und ob das Vorhaben umgesetzt, gezielt nachgeschärft oder bewusst gestoppt werden sollte.
Der Architektur-Sprint klärt die zentralen technischen Entscheidungen für einen bereits eingegrenzten Anwendungsfall. Dazu gehören Rollen und Zustände im System, Speicher- und Datenregeln, zulässige Zugriffe sowie Schnittstellen, Prüfungen und Freigaben. Die Ergebnisse geben Produkt-, Entwicklungs- und Betriebsteams eine gemeinsame Grundlage für die Umsetzung.
Die Pilot-Umsetzung erprobt einen kritischen Teil des späteren Systems unter realistischen Bedingungen – etwa im Agentensystem, im Daten- und Evidenzraum oder in der Echtzeit-Interaktion. Oberfläche und vollständiger Systemlauf gehören zum Test. Quellen, Zustände, Messwerte, Fehlerpfade und menschliche Freigaben machen überprüfbar, wie sich der Ansatz im vorgesehenen Ablauf verhält.
Ergebnisse
Auch Monate später muss verständlich sein, warum eine Entscheidung getroffen wurde und wo ihre Grenzen liegen. Deshalb werden fachliche Annahmen und technische Regeln ebenso festgehalten wie aussagekräftige Tests und Systemläufe. So bleibt erkennbar, was geprüft wurde, was bereits funktioniert und was noch offen ist.
Die Entscheidungsgrundlage beschreibt, welche Nutzer mit dem System arbeiten, welche Daten benötigt werden, welche Fehler besonders kritisch sind und woran ein erster sinnvoller Einsatz gemessen wird. Dazu gehört auch, welche Erklärungen Nutzer, fachlich Verantwortliche oder technische Teams brauchen. So wird sichtbar, was bereits entschieden werden kann und welche Fragen noch geprüft werden müssen.
Der Systemrahmen verbindet Zustände, Speicherregeln, Zugriffe und Modellrouting mit dem Verhalten der Schnittstellen und den Punkten, an denen Menschen eingreifen. Auch Protokollierung, Quellenbezug, Prüfung und Rücksetzung sind Teil des Rahmens. So können Teams die Architektur umsetzen, überprüfen und bei einem späteren Modell-, Daten- oder Oberflächenwechsel gezielt neu bewerten.
Tests, beispielhafte Systemläufe und bekannte Fehlerfälle machen den Reifegrad sichtbar. Offene Entscheidungen und Hinweise für den Betrieb zeigen, welche Teile erprobt sind, welche noch experimentell bleiben und wo fachliche, technische oder regulatorische Fragen offen sind. Damit können interne oder externe Teams gezielt weiterarbeiten.
Pragmatismus
Nicht jedes Vorhaben braucht mehr Agenten oder ein größeres Modell. Manchmal sind ein klarerer Ablauf, eine bessere Datenstruktur, ein kleineres Modell oder klassische Software die bessere Lösung. Eine Architektur sollte nur so komplex sein, wie es die kritische Entscheidung oder der Prozess erfordert. Zusätzliche Komponenten sind dann sinnvoll, wenn Messungen einen klaren fachlichen oder betrieblichen Vorteil zeigen.
Anwendungsfall einordnen
Für eine erste Einschätzung genügen wenige Angaben: Welcher Prozess soll besser werden? Welche Datenarten stehen zur Verfügung, und wer arbeitet mit dem System? Welche Fehlentscheidung wäre besonders kritisch? Vertrauliche oder personenbezogene Inhalte sind dafür nicht nötig.
Anwendungsfall skizzieren