Zum Inhalt springen

// journal / ki-automatisierung-software / prompt-engineering-reicht-nicht

Prompt Engineering reicht nicht: Warum produktive KI gute Workflows braucht

Prompt Engineering ist der sichtbare Teil, aber der unsichtbare entscheidet: Eval-Schleifen, strukturierte Outputs, Fallback-Pfade, Tool-Use, Memory. Was zwischen einem cleveren Prompt und einer produktiven KI-Anwendung liegt.

Von createIF Labs
Veröffentlicht am
  • Prompt Engineering
  • Workflows
  • Eval
  • Produktion
  • LLM Ops
Schichten-Diagramm: Prompt, Input-Validierung, strukturierte Outputs, Eval, Fallback, Audit als fünf Ebenen produktiver KI-Systeme
Schichten-Architektur einer produktiven KI-Pipeline: Prompt-Layer (oben sichtbar), darunter Input-Validierung mit PII-Filter, strukturierte Output-Schemata mit JSON-Schema/Pydantic, Eval-Layer mit reproduzierbaren Testfällen, Fallback-Pfade für Modellfehler und Audit-Logging für Compliance.

Prompt Engineering ist ein berechtigter Beruf, aber ein unzureichender Plan. Wer eine KI-Anwendung in Produktion bringen will, braucht mehr als clever formulierte Anweisungen — er braucht ein System rundherum, das Fehler abfängt, Qualität misst und Reproduzierbarkeit sichert. Dieser Beitrag zeigt die fünf Schichten, die zwischen einem guten Prompt und einer produktiven Lösung liegen.

1. Warum Prompts allein nicht reichen

Ein guter Prompt produziert in 80% der Fälle gute Antworten. In Produktion sind 80% katastrophal — jeder fünfte Vorgang Murks. Was im Demo charmant aussieht, vernichtet in Produktion Vertrauen.

Das Problem ist nicht der Prompt. Das Problem ist die fehlende Struktur drumherum: keine reproduzierbare Validierung, keine Fehlerbehandlung, keine Audit-Pfade, keine Maintenance. Wer das übergeht, baut keinen Use Case, sondern einen technischen Schuldenberg.

2. Die fünf Schichten produktiver KI

Zwischen einem Prompt und einer produktiven Lösung liegen fünf Schichten:

  1. Strukturierte Outputs — JSON-Schema, Pydantic statt freier Text.
  2. Input-Validierung — was darf überhaupt in den Prompt rein?
  3. Eval-Harness — woher wissen wir, dass das System besser wird?
  4. Fallback-Pfade — was passiert bei einem Fehler?
  5. Audit-Logging — wer kann später nachvollziehen, was passiert ist?

Ohne diese fünf Schichten ist Ihr „KI-System” ein Tech-Demo, kein Produkt. Mit ihnen wird es belastbar, auditierbar und wartbar.

3. Schicht 1: Strukturierte Outputs

Wenn das Modell „Ja, das ist eine Reklamation” antwortet, müssen Sie diesen Text parsen — und stoßen auf hundert Varianten. Wenn es {"category": "complaint", "priority": "high"} antwortet, lässt sich der Output direkt programmatisch nutzen.

So erzwingen Sie strukturierte Outputs 2026:

  • JSON Schema als Vorgabe (OpenAI, Anthropic, lokale Modelle unterstützen das).
  • Pydantic-Modelle als Validator nach dem LLM-Call.
  • Constrained Decoding bei Open-Weight-Modellen für noch härtere Garantien.

Strukturierte Outputs sind 2026 keine Option mehr, sondern Default.

4. Schicht 2: Input-Validierung

Bevor irgendetwas an das Modell geht: prüfen, ob es darf. Drei typische Validierungen:

  • PII-Filter — entfernt oder pseudonymisiert personenbezogene Daten (siehe KI und Datenschutz).
  • Längenbegrenzung — verhindert Prompt-Injection durch Riesendokumente.
  • Inhaltliche Whitelist/Blacklist — was darf der Nutzer überhaupt fragen?

Ohne Input-Validierung ist Ihre KI-Anwendung ein Einfallstor — siehe Sichere KI-Integration.

5. Schicht 3: Eval-Harness

Eval = Evaluation. Ein reproduzierbares Set von Testfragen mit erwarteten Antworten, das Sie vor jedem Deploy ausführen.

Minimum für produktive Systeme:

  • 30–50 hand-gelabelte Beispiele pro Anwendungsfall.
  • Aufgabenpassende Metriken — Klassifikationsrate, Faithfulness, Hit@k, Latenz.
  • Versionierung: jeder Eval-Run mit Modell-Version, Prompt-Version, Timestamp.
  • Automatisch im CI/CD bei jedem Pull Request.

Tools 2026: Promptfoo, Inspect-AI, Ragas, oder ein eigenes Python-Skript. Hauptsache eingebaut.

6. Schicht 4: Fallback-Pfade

Wenn das Modell etwas nicht kann oder nicht darf: was passiert?

  • Niedrige Confidence? → Eskalation zum Menschen.
  • Output-Validierung fehlgeschlagen? → Retry mit anderer Formulierung; bei wiederholtem Fehler: Fallback-Antwort.
  • API-Fehler? → Cache, Sekundärmodell, klare Fehlermeldung.
  • Verbotene Eingabe? → höfliche Ablehnung mit Erklärung.
  • Zeitüberschreitung? → asynchrone Verarbeitung mit Benachrichtigung.

Eine KI-Pipeline ohne Fallbacks ist ein System, das alle paar Stunden „kaputtgeht” — auch wenn technisch nichts abstürzt.

7. Schicht 5: Audit-Logging

Jeder Modell-Aufruf wird geloggt:

  • Zeitstempel
  • Eingabe (gehasht, wenn PII)
  • Ausgabe (gehasht oder strukturiert)
  • Modell-Version, Prompt-Version
  • Aufrufender Nutzer (pseudonymisiert)
  • Latenz, Token-Count
  • Eval-Score (falls verfügbar)

Diese Logs sind 2026 Pflicht für DSGVO-Rechenschaft, für EU AI Act-Konformität und für jede Form von Fehlersuche oder Verbesserung. Ohne sie laufen Sie blind.

8. So setzen wir das in der Praxis um

In einem typischen Projekt bauen wir zuerst die Pipeline-Skeleton — alle fünf Schichten in einfachster Form — und befüllen sie dann mit dem konkreten Use Case. So entsteht in 4–8 Wochen ein produktiver Use Case, und der Pipeline-Skeleton ist wiederverwendbar.

Nächste Use Cases dauern dann nur noch 2–4 Wochen — weil das Schwere (Eval-Harness, Audit, Output-Schemas) schon steht. Das ist der wirtschaftliche Hebel von gutem KI-Engineering: jeder neue Use Case wird schneller, nicht langsamer.

Wer mehr über die organisatorischen Faktoren erfolgreicher KI-Projekte wissen will, sollte Warum viele KI-Projekte scheitern lesen — die Liste der häufigsten Fehler beginnt nicht selten bei einer fehlenden Eval-Suite.

// FAQ

Häufige Fragen.

  1. / 01Ist Prompt Engineering 2026 noch ein eigener Beruf?

    Als isolierter Beruf nimmt seine Bedeutung ab — moderne Modelle sind deutlich robuster gegen Prompt-Variationen. Als Teilkompetenz im LLM-Engineering bleibt es wichtig. Wer 'Prompt Engineer' als Jobtitel verkauft, sollte daneben auch Eval, strukturierte Outputs und Pipelines beherrschen.

  2. / 02Was sind strukturierte Outputs und warum sind sie wichtig?

    Strukturierte Outputs zwingen das Modell, in einem definierten Format zu antworten — z. B. JSON gemäß Schema. Dadurch lassen sich Antworten programmatisch weiterverarbeiten, validieren und in nachgelagerte Systeme einspeisen. Ohne strukturierte Outputs ist KI-Output für die meisten Produktionsanwendungen unbrauchbar.

  3. / 03Wie sieht eine gute Eval-Suite aus?

    Mindestens: 30–50 hand-gelabelte Beispiele pro Anwendungsfall, reproduzierbar im CI ausführbar, mit aufgabenpassenden Metriken (Klassifikationsrate, Faithfulness, Hit@k). Tools: Promptfoo, Inspect-AI oder ein eigenes Python-Skript. Wichtig: vor jedem Deploy laufen lassen, Ergebnisse versioniert speichern.

  4. / 04Was sind Fallback-Pfade in einer LLM-Pipeline?

    Vordefinierte Handlungswege, wenn das Modell etwas nicht kann oder nicht darf: Niedrige Confidence → Mensch fragen. Output ungültig → Retry mit anderer Formulierung. API-Fehler → Cache nutzen. Verbotene Eingabe → klare Ablehnung. Ohne Fallbacks ist Ihr System produktionsuntauglich.

  5. / 05Welche Tools setzen Sie für produktive KI-Pipelines ein?

    JSON-Schema oder Pydantic für Outputs. Promptfoo oder Inspect-AI für Eval. LangGraph oder eigener Code für Orchestrierung. OpenTelemetry für Logs. Prometheus + Grafana für Monitoring. Plus ein versioniertes Prompt-Repository. Welches Tool genau, hängt vom Stack ab — das Prinzip ist wichtig.

  6. / 06Wie lange dauert es, eine Pipeline aus Prompt + Schichten aufzubauen?

    Pilot-Pipeline mit allen fünf Schichten für einen Use Case: 4–8 Wochen. Wiederverwendbares Pipeline-Framework, das für weitere Use Cases dient: 2–4 Monate. Die Investition lohnt sich, weil dann jeder neue Use Case innerhalb von 2–4 Wochen produktiv ist.

// Weiterlesen

Weiterlesen