Sieben Entscheidungskriterien

Chatbot, RAG oder KI-Agent

0:00 In vielen Unternehmen steht derzeit derselbe Satz im Protokoll: Wir wollen etwas mit KI machen. Was danach kommt, ist meistens eine Begriffsdebatte. Brauchen wir einen Chatbot? Oder doch RAG? Oder gleich einen Agenten? Diese Debatte führt selten zu einer Entscheidung, weil sie am falschen Ende beginnt. Die drei Begriffe sind keine konkurrierenden Produkte, zwischen denen man sich entscheidet wie zwischen zwei Datenbanken.

0:25 Sie beschreiben unterschiedliche Fähigkeiten, und die Frage ist, welche davon der konkrete Anwendungsfall wirklich braucht. Genau dafür gibt es in den nächsten Minuten sieben Kriterien — nachprüfbar, herstellerübergreifend und am Ende zu einem Ergebnis zusammengeführt, das man einem Entscheidungsgremium vorlegen kann.

Vier Muster, eine Entscheidung

0:44 Bevor wir bewerten, müssen wir sortieren. Im ersten Kapitel geht es deshalb um die vier Muster selbst: einfacher Dialog, RAG, festgelegter Workflow und Agent. Sie klingen wie Alternativen, sind aber eher Stufen — jede fügt eine Fähigkeit hinzu, und jede kostet dafür etwas. Wer diese Ordnung einmal im Kopf hat, führt die Begriffsdebatte gar nicht mehr — er fragt stattdessen, welche Fähigkeit fehlt. Und das ist eine Frage, die sich beantworten lässt.

1:12 Ein Hinweis vorweg, damit die Erwartung stimmt: Am Ende dieses Moduls steht keine Empfehlung für ein Muster. Es gibt sie nicht. Was es gibt, ist ein Entscheidungsprofil — sieben Kriterien, die Sie für Ihren Fall bewerten, und daraus eine Architekturhypothese mit Begründung. Das klingt bescheidener, als es ist. Eine Hypothese, die benennt, welche Annahmen noch offen sind und wie man sie prüft, ist in einem Projektmeeting deutlich mehr wert als eine feste Empfehlung ohne Grundlage.

1:39 Und sie hat den angenehmen Nebeneffekt, dass sie überprüfbar bleibt, wenn sich in einem halben Jahr die Anforderungen ändern. Schauen wir uns an, warum die Begriffe nicht auf derselben Ebene liegen. Ein Chatbot ist zunächst nichts weiter als eine Oberfläche — ein Dialogfenster. Über die Architektur dahinter sagt das Wort nichts. RAG dagegen beschreibt, woher das Wissen kommt: aus Ihren eigenen Dokumenten statt allein aus dem Modell.

2:06 Ein Workflow beschreibt, wie der Ablauf organisiert ist, nämlich in vorher festgelegten Schritten. Und ein Agent beschreibt, wer den Ablauf bestimmt — hier nämlich das Modell selbst, zur Laufzeit. Vier verschiedene Fragen also: Oberfläche, Wissen, Ablauf, Steuerung. Deshalb lassen sich die Muster auch kombinieren, statt sich auszuschließen.

2:27 Die Schichtung ist bewusst so gewählt: Jede Ebene setzt auf der darunter auf. Der Dialog kommt mit dem aus, was im Modell steckt und was in der Frage steht. Kommt Wissen dazu, kann das System auf Ihre Dokumente zugreifen und Fundstellen nennen. Kommt der Ablauf dazu, laufen mehrere Schritte in fester Ordnung — mit dem angenehmen Effekt, dass ein Fehler einem Schritt zuzuordnen ist.

2:49 Und erst ganz oben kommt die Handlung: Das System wählt Werkzeuge selbst und verändert etwas in anderen Systemen. Wichtig ist die Blickrichtung: Man steigt nicht auf, weil es geht, sondern weil eine Stufe tiefer die Aufgabe nicht löst. Anthropic hat für diese Unterscheidung eine Formulierung gefunden, die hilft. Sie trennt agentische Systeme in zwei Klassen.

3:11 In einem Workflow werden Modelle und Werkzeuge über vorgegebene Codepfade orchestriert — der Entwickler hat den Ablauf hingeschrieben. In einem Agenten steuert das Modell seinen Ablauf und seine Werkzeugnutzung dynamisch selbst. Der Unterschied liegt also nicht in der Menge der Werkzeuge und auch nicht in der Qualität des Modells, sondern in der Kontrolle: Wer entscheidet, was als Nächstes passiert?

3:33 Diese eine Frage beantwortet in der Praxis überraschend viel — auch die nach Testbarkeit, Kosten und Fehlersuche. Über allen sieben Kriterien steht eine Leitlinie, und sie ist unspektakulär: Fangen Sie mit der einfachsten Architektur an, die ausreicht, und erweitern Sie erst, wenn der Nutzen belegt ist. Das ist keine Bequemlichkeit, sondern Erfahrung.

3:54 Mehr Autonomie bedeutet mehr Modellaufrufe, längere Laufzeiten, höhere Kosten und vor allem eine deutlich schwierigere Fehlersuche — bei einem Agenten müssen Sie erst rekonstruieren, welchen Weg er überhaupt genommen hat. Und die gute Nachricht: Sie müssen sich nicht für ein Muster entscheiden. Ein Agent darf eine RAG-Suche als Werkzeug aufrufen, ein Workflow darf einzelne Schritte an ein Modell geben.

4:17 Vier Dinge hört man häufig, die eine Entscheidung nur behindern. Das erste: Wir brauchen einen Agenten — als Projektziel formuliert, nicht als Ergebnis einer Bewertung. Damit steht die Antwort vor der Frage. Das zweite: ein überzeugender Prototyp. Der beweist, dass das Modell die Aufgabe im Prinzip kann, nicht dass die Anwendung produktionsfähig wird.

4:38 Das dritte: RAG einplanen, obwohl das nötige Wissen längst in der Anfrage steht — dann bauen Sie eine Suchinfrastruktur für nichts. Und das vierte, das häufigste: das Muster festlegen, bevor überhaupt aufgeschrieben ist, was das System eigentlich tun soll.

Aufgabe, Wissen und Handeln

4:55 Damit sind wir bei den Kriterien. Die ersten drei sind die fachlichen: Was soll das System tun, was muss es dafür wissen, und was darf es auslösen? Diese drei entscheiden in der Praxis schon einen großen Teil der Architektur — und das Angenehme daran: Sie lassen sich beantworten, ohne eine einzige Zeile Code zu schreiben.

5:13 Ein Nachmittag mit dem Fachbereich reicht oft weiter als zwei Wochen Prototyp. Kriterium eins ist die Aufgabe selbst, und hier lohnt sich ehrliche Genauigkeit. Texte formulieren, übersetzen, zusammenfassen, einzelne Eingaben klassifizieren — dafür genügt ein einfacher Dialog, und das ist kein Armutszeugnis, sondern ein Kostenvorteil.

5:32 Geht es um Fragen zu Richtlinien, Handbüchern oder Produktunterlagen, wird RAG interessant, weil das Modell dieses Wissen schlicht nicht hat. Sind die Schritte bekannt und wiederholen sich, spricht das für einen festgelegten Workflow. Und erst wenn die Aufgabe offen ist, wenn es mehrere Lösungswege gibt und der richtige erst unterwegs erkennbar wird, kommt ein agentisches System ernsthaft in Betracht.

5:56 Diese vier Wörter sind die nützlichste Abkürzung des ganzen Moduls — fragen Sie sie in jedem Projektgespräch ab. Soll das System informieren, empfehlen, vorbereiten oder selbst handeln? Die Reihenfolge ist kein Zufall: Jeder Schritt nach rechts verschiebt Verantwortung vom Menschen zur Maschine. Informieren heißt, der Mensch entscheidet alles.

6:16 Empfehlen heißt, die Maschine schlägt vor. Vorbereiten heißt, sie erstellt schon den Entwurf — aber das Absenden bleibt beim Menschen. Und selbst handeln heißt, sie löst aus. Erfahrungsgemäß landet eine ehrliche Antwort deutlich weiter links, als der erste Projektwunsch vermuten ließ. Kriterium zwei klingt nach Technik, ist aber vor allem eine Fleißaufgabe: Welches Wissen braucht das System wirklich?

6:41 Nicht jede Wissensanforderung rechtfertigt eine Vektordatenbank. Manches steht bereits in der Anfrage. Manches ist stabiles Allgemeinwissen, das im Modell steckt. Manchmal genügt es, wenige Dokumente gezielt mitzugeben — das ist kein RAG, das ist ein größeres Kontextfenster. Erst wenn es um umfangreiche, sich ändernde Bestände geht, lohnt der Aufbau einer Suchstrecke.

7:03 Und eine Frage entscheidet oft mehr als alle anderen: Sind die Inhalte vertraulich oder berechtigungsabhängig? Dann wird aus einem Suchproblem ein Berechtigungsproblem. Wie RAG arbeitet, lässt sich in zwei Hälften erzählen. Die erste läuft im Voraus: Dokumente werden aufbereitet, in Abschnitte zerlegt, in Vektoren übersetzt und indexiert.

7:24 Das ist die Indexierungspipeline — vergleichbar mit dem Anlegen eines guten Sachregisters. Die zweite läuft im Moment der Frage: Es wird gesucht, über Schlüsselwörter, über Vektorähnlichkeit oder beides zusammen, und die gefundenen Abschnitte gehen als Kontext an das Modell. Wichtig ist der letzte Halbsatz. Das Modell bekommt Material geliefert und formuliert daraus. Es prüft nicht, ob das Material stimmt — und genau deshalb lohnt der nächste Blick.

7:52 Diese Tabelle ist im Grunde eine Fehlerkette, und sie erklärt ein Phänomen, das viele RAG-Projekte kennen: Die Antwort ist falsch, und niemand weiß, warum. Der Grund ist, dass zwischen Dokument und Antwort sieben Stellen liegen, an denen es schiefgehen kann — und nur die letzte hat mit dem Modell zu tun. Veraltete Quellen, unglücklich zerschnittene Abschnitte, fehlende Metadaten, ein löchriger Berechtigungsfilter, eine Suchanfrage, die die Wörter der Dokumente nicht trifft.

8:19 Deshalb bewertet man Retrieval und Antwort getrennt. Eine einzelne Gesamtnote sagt Ihnen, dass es nicht funktioniert, aber nie, wo Sie ansetzen müssen. Kriterium drei fragt, was das System auslösen darf — und hier machen viele Architekturen denselben Denkfehler. Sie zählen Werkzeuge. Entscheidend ist aber nicht, wie viele es sind, sondern was sie verändern. Ein lesender Zugriff braucht eine Berechtigungsprüfung und ein Protokoll, mehr nicht.

8:45 Eine verändernde Aktion braucht zusätzlich eine Freigabe und einen Weg zurück. Die Spezifikation des Model Context Protocol formuliert das ausdrücklich: Es soll immer ein Mensch in der Schleife sein, der einen Werkzeugaufruf ablehnen kann. Das ist keine Formalie — es ist die Stelle, an der aus einem interessanten Experiment ein betreibbares System wird.

9:07 Machen wir das an einem Beispiel fest, das uns durch den Rest des Moduls begleitet. Haltbar baut Hausgeräte und hat einen Support mit Handbüchern, Ersatzteilen und Tickets. Sie sehen hier fünf Klassen, und der Aufwand an Kontrolle steigt nicht linear, sondern sprunghaft. Bestand lesen — Protokoll genügt. Einen Reparaturweg vorschlagen — ein Mensch prüft. Eine Rückrufmail entwerfen — Freigabe vor dem Absenden. Einen Termin reservieren — Bestätigung und eine Rücknahme.

9:36 Und eine Gutschrift auslösen — ausdrückliche Freigabe und starke Autorisierung. Der praktische Rat daraus: Sortieren Sie jedes geplante Werkzeug in genau eine dieser Zeilen ein, bevor Sie es bauen. Beim Zuschnitt der Werkzeuge passieren vier typische Fehler. Der erste: ein Werkzeug, das liest und schreibt. Dann greift die Freigabe entweder für beides — und nervt — oder für nichts, und das ist gefährlich. Der zweite: Berechtigungen im Prompt beschreiben.

10:05 Ein Prompt ist eine Bitte, keine Durchsetzung; wirksam wird sie erst serverseitig. Der dritte: Werkzeugbeschreibungen einfach aus der Schnittstellendokumentation übernehmen. Sie werden aber von einem Modell gelesen, nicht von einem Menschen, und müssen entsprechend geschrieben sein. Und der vierte: Werkzeugmetadaten für vertrauenswürdig halten.

10:26 Die Spezifikation sagt ausdrücklich, dass Clients sie als nicht vertrauenswürdig behandeln müssen.

Lösungsweg, Autonomie und Risiko

10:32 Die ersten drei Kriterien haben beschrieben, was das System tun soll. Die nächsten drei drehen die Perspektive um: Wie viel Freiheit bekommt es dabei, wer schaut zu, und was passiert, wenn es danebengeht? Das sind die Kriterien, bei denen Architektur und Sicherheit dieselbe Sprache sprechen müssen — und erfahrungsgemäß die Kriterien, bei denen sich eine Entscheidung noch einmal deutlich verschiebt.

10:55 Kriterium vier ist die Frage nach der Vorhersehbarkeit — und sie lässt sich erstaunlich gut entlang dieser Gegenüberstellung beantworten. Links: Die Schritte sind bekannt, es gibt Vorgaben je Schritt, Fehler müssen zuordenbar sein, Wiederholbarkeit ist die eigentliche Anforderung. Das ist ein Workflow, und dafür gibt es seit Jahrzehnten bewährte Mittel.

11:15 Rechts: Der Weg hängt von Zwischenergebnissen ab, Ausnahmen prägen den Normalfall, und die Pfade ließen sich zwar ausprogrammieren, aber nicht wirtschaftlich. Dann lohnt ein Agent. Ein ehrlicher Hinweis: Viele Aufgaben, die sich zunächst offen anfühlen, stehen nach einer Woche Analyse plötzlich links. In der Praxis ist die reine Form selten, und das ist keine Schwäche.

11:37 Die tragfähigen Systeme sehen fast immer so aus: Ein ganz gewöhnlicher, deterministischer Prozess setzt die Grenzen und die Kontrollpunkte. Innerhalb dieser Grenzen übernimmt das Modell die Entscheidungen, die sich schlecht in Regeln fassen lassen — etwa, ob eine Kundenbeschwerde technisch oder kaufmännisch ist. Der Agent darf planen, aber nur in einem begrenzten Raum. Kritische Ergebnisse gehen durch Regeln oder durch Menschen. Und alles Übrige bleibt normaler Code.

12:04 Genau diese Reihenfolge empfiehlt auch Anthropic: einfach anfangen, Komplexität nur dort, wo sie sich belegen lässt. Kriterium fünf ist die Autonomiestufe, und es hilft, sie nicht als Schalter zu denken, sondern als Leiter mit sechs Sprossen: antworten, vorschlagen, vorbereiten, nach Freigabe handeln, begrenzt selbst handeln, eskalieren.

12:24 Jede Sprosse höher kostet zusätzliche Kontrolle, zusätzliche Protokollierung und zusätzliche Tests — und zwar dauerhaft, nicht einmalig. Die Regel lautet deshalb: die niedrigste Stufe wählen, die den fachlichen Nutzen noch trägt. Und die Eskalation gehört von Anfang an dazu. Ein System, das nicht sauber abbrechen und übergeben kann, ist kein fertiges System, sondern eines, dem ein Ausgang fehlt.

12:49 Hier wird es unbequem, denn ein beliebtes Beruhigungsmittel funktioniert nicht so gut wie gedacht. Anthropic hat gemessen, wie Menschen tatsächlich mit Bestätigungsdialogen umgehen. Das Ergebnis: Je vertrauter das Werkzeug wird, desto häufiger wird automatisch bestätigt — der Anteil steigt von rund zwanzig auf über vierzig Prozent.

13:08 Gleichzeitig greifen erfahrene Nutzer aber gezielter ein, wenn wirklich etwas schiefläuft. Die Schlussfolgerung ist deshalb nicht, dass Aufsicht sinnlos wäre, sondern dass sie anders aussieht: Wirksame Aufsicht heißt, eingreifen zu können, wenn es darauf ankommt — nicht, jede einzelne Aktion abzunicken. Wer jeden Schritt bestätigen lässt, erzieht zum Wegklicken.

13:30 Kriterium sechs ist das Risiko, und die entscheidende Frage lautet schlicht: Was wäre der größte Schaden, wenn das System falsch entscheidet? Vier Punkte stehen dabei regelmäßig oben. Prompt Injection, auch indirekt — über ein Dokument, das das System selbst lädt und in dem eine Anweisung versteckt ist. Zu weite Berechtigungen, oft aus Bequemlichkeit im Prototyp entstanden und nie zurückgenommen. Datenabfluss über Modelle, Werkzeuge und ausgerechnet Protokolle.

13:57 Und fehlende Nachvollziehbarkeit: Wenn hinterher niemand rekonstruieren kann, wer was wann ausgelöst hat, ist auch der beste Freigabeprozess wertlos. Diese Tabelle beantwortet die Frage, die in Sicherheitsgesprächen zu selten gestellt wird: Was gehört beim gewählten Muster zum Mindestumfang? Beim einfachen Dialog ist die Liste kurz. Bei RAG kommt etwas hinzu, das gern übersehen wird — der Berechtigungsfilter muss im Index sitzen, nicht erst in der Antwort.

14:25 Beim Workflow geht es um Regeln je Schritt und reproduzierbare Läufe. Und beim Agenten wird die Liste deutlich länger: getrennte Lese- und Schreibwerkzeuge, Allowlists, Grenzen für Schritte, Laufzeit und Kosten, dazu ein vollständiger Audit Trail. Die OWASP Top 10 für agentische Anwendungen nennen genau diese Angriffsflächen — Behavior Hijacking, Tool Misuse, Privilege Abuse.

Qualität, Matrix und typische Ergebnisse

14:48 Bleibt das siebte Kriterium, und es ist das, an dem Projekte am häufigsten scheitern — nicht an der Technik, sondern daran, dass niemand vorher gesagt hat, woran man Erfolg erkennt. Danach führen wir alle sieben Kriterien in einer Matrix zusammen und sehen uns an, welche Ergebnisse dabei typischerweise herauskommen. Es sind weniger, als man erwarten würde, und eines davon lautet: noch nicht anfangen.

15:11 Kriterium sieben verlangt etwas Unbequemes: Zahlen, bevor gebaut wird. Welche Antwortqualität wird erwartet, welche Fehlerrate ist zulässig, welche Quellenabdeckung nötig? Wie schnell muss geantwortet werden, was darf ein Vorgang kosten? Wie viele Fälle dürfen eskalieren, wie zuverlässig müssen Werkzeugaufrufe gelingen?

15:30 Das wirkt im frühen Projektstadium wie Bürokratie, ist aber das Gegenteil: Ohne diese Zahlen gibt es kein Abbruchkriterium, und ohne Abbruchkriterium läuft ein Prototyp weiter, bis das Budget alle ist. Wer den Testdatensatz und die Abnahmekriterien vor der Musterwahl festlegt, hat die halbe Entscheidung bereits getroffen.

15:50 Was hier steht, ist eine der praktischsten Einsichten des Moduls: Jedes Muster braucht eigene Prüfungen — was bei RAG gemessen wird, sagt über einen Agenten nichts. Beim Dialog geht es um Nützlichkeit, Tonalität und Instruktionstreue. Bei RAG um die Relevanz der Treffer, um Groundedness und um korrekte Quellenangaben. Beim Workflow um Übergänge, Fehlerfälle und Reproduzierbarkeit.

16:13 Und beim Agenten um Zielerreichung, Werkzeugwahl, die Argumente der Aufrufe und um unnötige Schritte, die Geld kosten. Zwei Begriffe werden dabei oft verwechselt: Groundedness fragt, ob die Antwort durch den Kontext gedeckt ist. Vollständigkeit fragt, ob nichts Wichtiges fehlt. Jetzt zur Anwendung. Stufen Sie zuerst jedes Kriterium ein — Muss, Wichtig oder Wünschenswert.

16:37 Diese Gewichtung muss vorher stehen, sonst gewichten Sie hinterher auf das Ergebnis hin, das Sie ohnehin wollten. Dann kreuzen Sie je Kriterium die Spalte an, die Ihr Fall verlangt. Markieren Sie dabei jede Annahme, die Sie noch nicht belegen können — diese Markierungen sind später Ihr Prüfauftrag. Und dann kommt die wichtigste Regel: nicht addieren.

16:59 Die Matrix wird gewichtet gelesen, nicht ausgezählt. Am Ende steht kein Punktestand, sondern eine Architekturhypothese mit Begründung. So sieht das Raster aus: sieben Zeilen für die Kriterien, vier Spalten für die Muster. Nehmen Sie es mit, es ist der eigentliche Mitnahmewert dieses Moduls. Was Sie beim Ausfüllen schnell merken: Die Kreuze verteilen sich selten sauber auf eine Spalte.

17:22 Typisch ist ein Bild, bei dem Wissen und Aufgabe klar auf RAG zeigen, die Aktionen aber einen kleinen Workflow verlangen. Genau das ist ein brauchbares Ergebnis und kein Widerspruch — es beschreibt eine hybride Lösung. Erst wenn eine Spalte bei einem Muss-Kriterium leer bleibt, haben Sie einen echten Ausschluss gefunden.

17:41 In der Praxis laufen die meisten Bewertungen auf eines von vier Bildern hinaus. Erstens: Ein einfacher Dialog genügt — kein internes Wissen, keine Aktionen, der Nutzer prüft ohnehin jedes Ergebnis. Zweitens: ein RAG-Assistent, weil die Antworten eigene Quellen und Fundstellen brauchen und Berechtigungen mitgedacht werden müssen.

18:01 Drittens: ein definierter Workflow, weil der Ablauf bekannt ist und nur einzelne Schritte ein Modell benötigen. Und viertens: ein begrenzter Agent — mehrere Wege, mehrere Werkzeuge, dafür klare Grenzen und eine definierte Eskalation. Bemerkenswert ist, wie selten das vierte Bild herauskommt, wenn ehrlich bewertet wird. Es gibt ein fünftes Ergebnis, das niemand gern hört, das aber viel Geld spart: Der Anwendungsfall ist noch nicht so weit. Erkennbar ist das an vier Zeichen.

18:30 Es lässt sich kein geschäftlicher Nutzen benennen, sondern nur ein Technologiewunsch. Die Daten sind nicht verfügbar, nicht gepflegt oder haben kein Berechtigungsmodell. Verantwortlichkeiten und Freigaben sind ungeklärt — dann gibt es später niemanden, der bestätigt. Und Erfolg ist nicht messbar definiert, womit auch das Abbruchkriterium fehlt.

18:51 Ein Projekt in diesem Zustand zu starten, heißt nicht, früh zu lernen. Es heißt, die eigentliche Arbeit zu verschieben. Vier Wege, die Matrix zu entwerten. Erstens: Kreuze zählen statt gewichten. Vier kleine Vorteile schlagen kein verletztes Muss-Kriterium — eine Punktzahl verdeckt genau das. Zweitens: die Gewichtung erst nach dem Ausfüllen festlegen. Das ist kein Bewerten mehr, das ist Begründen im Nachhinein.

19:17 Drittens: Kriterien beantworten, ohne den eigenen Datenbestand und die Berechtigungen geprüft zu haben — die schönste Bewertung hilft nicht, wenn niemand weiß, in welchem Zustand die Dokumente sind. Und viertens: die Matrix allein in der Entwicklung ausfüllen. Fachbereich und Datenschutz haben zu mehreren Zeilen die besseren Antworten.

Übung

19:39 Bleibt der Teil, der aus Zuhören Erkenntnis macht. Nehmen Sie sich nach diesem Video zwanzig Minuten und wenden Sie die sieben Kriterien einmal auf einen echten Fall aus Ihrem Haus an. Wer gerade keinen zur Hand hat, nimmt unseren Beispielhersteller — die Kriterien wirken an beidem gleich. Entscheidend ist, dass Sie einmal schreiben und nicht nur denken — im Kopf wirkt jeder Anwendungsfall klar.

20:01 Haltbar baut Hausgeräte und betreibt einen Support, wie es ihn in vielen Unternehmen gibt: Produkthandbücher, Supportartikel, interne Richtlinien, ein Ersatzteilbestand und ein Ticketsystem. Der Auftrag aus der Geschäftsführung lautet, man möge doch irgendetwas mit KI im Support machen. Genau in diesem Zustand kommen solche Vorhaben meistens bei der Entwicklung an — mit einem Wunsch, aber ohne Muster. Das ist übrigens kein Vorwurf an die Geschäftsführung.

20:27 Die Entscheidung, welches Muster passt, ist eine technische Bewertung, und sie ist genau die Leistung, die an dieser Stelle gefragt ist. Die Aufgabe ist bewusst so geschnitten, dass sie ohne Werkzeuge funktioniert — Papier genügt. Ordnen Sie einen Anwendungsfall anhand der sieben Kriterien einem Muster zu, statt die Architektur aus einem Schlagwort abzuleiten.

20:48 Fertig sind Sie, wenn zu allen sieben Kriterien eine Einordnung, die offene Annahme und der Prüfweg schriftlich vorliegen, dazu eine Freigabematrix und drei messbare Erfolgskriterien. Die Freigabematrix ist dabei der Teil, der im Alltag am meisten bewegt: Sobald schwarz auf weiß steht, welche Aktion ein Mensch bestätigen muss, wird aus einer Architekturdebatte eine Absprache, die auch andere Abteilungen verstehen.

21:11 Fangen Sie mit fünf Sätzen an, mehr braucht es zunächst nicht. Wer verwendet die Lösung? Welche Aufgabe soll erledigt werden? Welches Wissen wird dafür gebraucht? Welche Systeme und Werkzeuge müssten angesprochen werden? Und welche Aktionen dürfen nur nach menschlicher Freigabe erfolgen? Diese fünf Fragen sind kein Formular, sie sind ein Filter.

21:32 Erfahrungsgemäß scheitert ungefähr die Hälfte der Ideen schon am dritten Satz, weil niemand genau sagen kann, wo das nötige Wissen eigentlich liegt. Und was übrig bleibt, hat danach eine Architekturhypothese und eine Liste der Annahmen, die ein Test belegen muss.

Und jetzt?

21:48 Halten wir fest: Was Sie mitnehmen, ist ein Entscheidungsprofil für einen konkreten Fall, keine Rangliste der Muster. Die gibt es nicht, und wer sie verspricht, hat die Frage nicht verstanden. Steht Ihre Hypothese und wollen Sie sie in ein Produkt übersetzen — Werkzeuge schneiden, Kontext aufbauen, Freigaben verankern, Qualität messen —, dann führt der Weg in unser Seminar KI-Features im eigenen Produkt.

22:12 Besonders lohnt sich das, wenn Fachbereich, Entwicklung und Datenschutz die Lage unterschiedlich einschätzen. Denn dann ist das eigentliche Problem selten technisch, sondern eines der gemeinsamen Grundlage. Mehr dazu auf learning-master.de.