KI-Ausführungsstandards

Die Regeln und Erwartungen für die Delegation von Arbeit an KI in der gesamten Organisation.

Organisationsweite Erwartungsrichtlinie

Das operative Prinzip hinter diesen Standards ist die Universelle Übersetzungsregel: „Mensch produziert Artefakt" wird ersetzt durch „Mensch definiert Spezifikation → System produziert Artefakt."

Kernprinzip

KI wird als autonomer Mitarbeiter behandelt, nicht als Chatbot.

Alle an KI zugewiesene Arbeit muss ohne menschliche Echtzeit-Supervision während der Ausführung ausführbar sein. Vor-Ausführungs-Klärung – der Agent legt Annahmen offen und stellt kalibrierte Fragen, bevor er Output produziert – ist erlaubt und wird bei höherer Reife erwartet. Siehe KI-Labor § Die fünf Phasen für das operative Muster.

Obligatorische Arbeitsschichten

Jeder KI-aktivierte Workflow muss die vier Input-Schichten (1–4) definieren. Schicht 5 (Prozessdesign) erweitert sie um die operative Pipeline, die die Inputs verarbeitet; sie ist obligatorisch für Arbeit auf Tier 3 / Sprosse 5 und optional darunter.

Schicht 1 – Prompt-Gestaltung (grundlegende Fähigkeit)

Mitarbeiter müssen:

klare Anweisungen schreiben
Format angeben
Beispiele einbeziehen, wenn sinnvoll
Mehrdeutigkeiten im Voraus klären

Mindestmaßstab: KI-Output sollte ≤ 20 % Korrektur erfordern.

Schicht 2 – Kontext-Engineering

Jedes Team muss eine strukturierte Kontextdatei pflegen, die enthält:

Ziele
Rahmenbedingungen
Terminologie
Qualitätsstandards
relevante Dokumente
Regeln für Werkzeugzugang

Anforderung: KI-Aufgaben müssen diesen Kontext vor der Ausführung laden.

Schicht 3 – Absichts-Engineering

Jeder Workflow muss definieren:

Zielhierarchie
Abwägungsregeln
Eskalationsbedingungen
Was KI entscheiden darf vs. was eskaliert werden muss

Kein Agent darf ohne definierte Absicht ausgeführt werden.

Schicht 4 – Spezifikations-Engineering (höchster Standard)

Alle nicht-trivialen Aufgaben müssen eine schriftliche Spezifikation haben.

Erforderliche Spezifikationskomponenten:

Problemaussage
Umfang
Eingaben
Rahmenbedingungen
Abnahmekriterien
Fehlerbedingungen
Erfolgstests
Abschlussdefinition

Regel: Wenn Erfolg nicht objektiv überprüft werden kann, ist die Aufgabe nicht spezifikationsbereit.

Für Brownfield-Codebasen ist die Inversion entscheidend: Der Code existiert bereits, und Spezifikationen müssen daraus rückwärts entwickelt werden, bevor neue spec-first-Arbeit fortgesetzt werden kann. Siehe Brownfield-Ingenieurstrategie für den Spec-from-Code-Workflow.

Schicht 5 – Prozessdesign

Die operative Schicht. Sobald eine Spezifikation funktioniert, ist die nächste Frage die Pipeline, die sie ausführt. Prozessdesign ist die Disziplin, eingeschränkte, phasengesteuerte Workflows zu gestalten, innerhalb derer KI konsistent operiert – unterscheidet sich von Prompt-Engineering und vom Spezifikationsschreiben an sich. Es ist die Schicht, die Arbeit auf Tier 3 / Sprosse 5 von Tier 2 / Sprosse 4 unterscheidet.

Das Vokabular, übernommen aus Anthropics Building Effective Agents:

Prompt-Verkettung – sequenzielle Einzel-Prompt-Schritte mit zwischenzeitlicher Validierung
Routing – Aufgabe klassifizieren, an den passenden spezialisierten Prompt oder Workflow dispatchen
Parallelisierung – unabhängige Teilaufgaben gleichzeitig ausführen, Ergebnisse aggregieren
Orchestrator-Workers – ein Lead-Agent zerlegt die Aufgabe und dispatcht Worker
Evaluator-Optimizer – ein Generator gepaart mit einem separaten Evaluator, der bewertet und iteriert
Autonome Agenten – offene Erkundung mit Tool-Nutzung und Feedback-Schleifen

Entscheidungsregel: Mit Einzel-Prompt beginnen; Workflow hinzufügen, wenn nötig; Multi-Agent nur hinzufügen, wenn der Wert pro Aufgabe den Token-Aufpreis rechtfertigt (typische Agenten verwenden ~4-fach Tokens von Chat; Multi-Agent ~15-fach, laut Anthropic, 2025). Greifen Sie nicht zu Multi-Agent, weil es ausgefeilt klingt.

Anti-Muster:

Pitfall: Einzelner Mega-Prompt
Kombiniert Fehlermodi; unmöglich zu debuggen.
Pitfall: Multi-Agent um seiner selbst willen
Teuer, fragil, oft ist Einzel-Agent genauso gut.
Pitfall: Kontext-Dumping
Mehr Kontext ist oft schlechterer Kontext.
Pitfall: Evals überspringen
Ohne Evals degradieren KI-Systeme still.
Pitfall: Prompts optimieren, wenn das Problem Kontext ist
Fehlmodus-Fehlattribution.

Die vier Input-Schichten (Prompt → Kontext → Absicht → Spezifikation) beschreiben, was der Mensch vor der Delegation vorbereitet. Schicht 5 beschreibt die Pipeline, die diese Inputs verarbeitet. Auf T3/R5 ist die Pipeline ebenfalls ein gestaltetes Artefakt – und Validierungs-Gates innerhalb davon sind risikoabgestuft (HITL / HOTL / HOOTL).

Spezifikationsprimitive (erlernbare Fähigkeiten)

Spezifikations-Engineering besteht aus fünf Primitiven. Jede ist eine eigenständige Fähigkeit zum Üben. Für Beispiele, Templates und ausgearbeitete Spezifikationen für verschiedene Rollen, siehe den Spezifikations-Leitfaden.

Primitiv 1 – Eigenständige Problemaussagen

Das Problem mit ausreichend Kontext angeben, damit die Aufgabe lösbar ist, ohne dass der Agent weitere Informationen beschaffen muss. Versteckte Annahmen aufdecken. Rahmenbedingungen, die normalerweise implizit bleiben, artikulieren.

Übung: Nehmen Sie eine Anfrage, die Sie normalerweise im Gespräch stellen würden, und schreiben Sie sie um, als ob der Empfänger Ihr Projekt noch nie gesehen hat, Ihre Terminologie nicht kennt und nur Zugang zu dem hat, was Sie einschließen.

Primitiv 2 – Abnahmekriterien

Definieren Sie, wie „fertig" aussieht, sodass ein unabhängiger Beobachter den Output ohne Nachfragen überprüfen kann. Wenn Sie keine drei Sätze schreiben können, die den Abschluss verifizieren, verstehen Sie die Aufgabe nicht gut genug, um sie zu delegieren.

Primitiv 3 – Rahmenbedingungsarchitektur

Vier Kategorien für jede Aufgabe definieren:

Muss – nicht verhandelbare Anforderungen
Darf nicht – verbotene Aktionen oder Outputs
Bevorzuge – Orientierung, wenn mehrere gültige Ansätze existieren
Eskaliere – Bedingungen, unter denen der Agent stoppen und fragen muss

Primitiv 4 – Zerlegung

Aufgaben in Komponenten aufteilen, die unabhängig ausgeführt, unabhängig getestet und vorhersagbar integriert werden können. Zielgranularität: Teilaufgaben von ≤ 2 Stunden mit klaren Eingabe-/Ausgabegrenzen, jede für sich überprüfbar.

Primitiv 5 – Bewertungsdesign

Für jede wiederkehrende KI-Aufgabe 3–5 Testfälle mit bekannt guten Outputs erstellen. Nach Modell-Updates ausführen, um Regressionen zu erkennen. Outputs werden nach Metriken bewertet, nicht nach Aussehen.

Eine gültige Spezifikation muss alle fünf bestehen: eigenständig, testbar, eingeschränkt, zerlegbar, bewertbar.

Delegations-Bereitschafts-Checkliste

Vor der Zuweisung von Arbeit an KI müssen Mitarbeiter bestätigen:

Ich verstehe die Aufgabe vollständig
Ich kann Erfolg objektiv definieren
Ich kann Fehlerfälle aufzählen
Ich kann Rahmenbedingungen beschreiben
Ich kann Ergebnisse ohne Interpretation überprüfen

Wenn eine Antwort = nein → noch nicht delegieren.

Fehlerverantwortungsmodell

Fehler werden nach Schicht zugeordnet:

Fehlertyp	Ursache
Schlechter Output	Prompt-Problem
Irrelevanter Output	Kontext-Problem
Falsche Richtung	Absichts-Problem
Unvollständiger Output	Spezifikations-Problem
Schädigender Output	Berechtigungs- / Wirkungsradius-Problem – der Agent hätte diese Aktion nicht ausführen können dürfen
Unbemerkter Output	Validierungs-Gate-Problem – die falsche Aufsichtshaltung für den Wirkungsradius dieser Aktion (siehe risikoabgestufte Gates)
Falsche Richtung selbstbewusst verteidigt	Klärung übersprungen – der Agent hat sich festgelegt, bevor Annahmen offengelegt wurden

Teams müssen die verantwortliche Schicht beheben, nicht Prompts wiederholen.

Organisationsrollen

Jedes produktive KI-System muss haben:

Spezifikations-Eigentümer – verantwortlich für Spezifikationsqualität, Abnahmekriterien und was „fertig" bedeutet
Kontext-Eigentümer – verantwortlich für Kontextdateien (CLAUDE.md / AGENTS.md), Kontextaktualität und Tool-/Skill-Umfang
Bewertungs-Eigentümer – verantwortlich für die Eval-Suite, Regressionserkennung und Qualitätsmetriken
Berechtigungs-Eigentümer – verantwortlich dafür, was jeder Agent darf und nicht darf, und für die Validierungs-Gating-Stufe (HITL / HOTL / HOOTL) pro Aktionsklasse

Eine Person kann anfangs mehrere Rollen innehaben. Die Rolle des Berechtigungs-Eigentümers wird tragend, sobald Agenten Produktionssysteme mit irreversiblen Nebenwirkungen berühren.

Diese vier Rollen steuern ein produktives KI-System. Sie unterscheiden sich von den drei Rollen, die erforderlich sind, um die KI-Transformation eines Teams zu steuern – siehe Die Transformation führen § Organisationsrollen.

Dokumentationsstandard

Alle internen Dokumente müssen so geschrieben sein, als würde ein Agent sie ausführen.

Dokumente müssen:

Annahmen angeben
Begriffe definieren
Ergebnisse spezifizieren
Rahmenbedingungen einschließen
implizites Wissen vermeiden

Zusammenfassende Regel

Klares Denken geht der KI-Ausführung voraus.

Wenn Sie es nicht spezifizieren können, können Sie es nicht automatisieren.

← Zurück zur Startseite · Das Referenzrahmenwerk · Das KI-Labor · Glossar