KI-Prototyping: 5 Methoden, mit denen Sie KI-Projekte absichern – ohne sechsstellige Fehlinvestitionen

1. Warum Prototyping bei KI anders ist

Bei klassischer Software wissen Sie vorher ziemlich genau, was rauskommt: Ein Button löst eine Aktion aus, eine Datenbank gibt Daten zurück, eine Berechnung liefert ein Ergebnis. Bei KI ist das fundamental anders:

• Nicht-deterministisch: Dieselbe Frage kann zu unterschiedlichen Antworten führen
• Kontextabhängig: Die Qualität hängt massiv von Prompt, Trainingsdaten und Integrationsumgebung ab
• Nutzungsabhängig: Erst im echten Betrieb zeigt sich, ob Mitarbeiter oder Kunden die Lösung annehmen
• Kosten schwer vorhersagbar: Wie viele API-Calls entstehen im Realbetrieb?

Deshalb funktioniert „Anforderungsdokument schreiben → programmieren → testen → ausrollen" nicht. Sie brauchen Methoden, die Unsicherheit gezielt reduzieren – und zwar schnell und billig.

2. Methode 1: Wizard-of-Oz-Testing

Der Klassiker aus der UX-Forschung, perfekt für KI-Projekte. Der Name kommt vom Zauberer von Oz: Der „Zauberer" ist in Wirklichkeit ein Mensch hinter einem Vorhang.

So funktioniert es bei KI: Sie bauen eine minimale Benutzeroberfläche – ein Chat-Fenster, eine Upload-Maske, ein Dashboard. Der Nutzer interagiert damit wie mit dem fertigen KI-System. Aber: Im Hintergrund sitzt ein Mensch (z. B. Ihr Fachexperte), der die Anfragen manuell beantwortet. Der Nutzer merkt davon nichts.

Ein konkretes Beispiel: Ein Maschinenbauer will eine KI für technischen Support. Statt direkt ein RAG-System zu bauen, setze ich ein simples Chat-Interface vor den Servicetechniker. Kunden tippen ihre Frage ein – der Techniker beantwortet sie manuell, aber in einem standardisierten Format. Nach 50–100 echten Kundenfragen weiß ich:

Ob aus dem Wizard-of-Oz-Test später ein Agent wird, hängt vom Prozess ab. KI-Agenten im Mittelstand kontrollieren erklärt, ab wann ein Agent sinnvoll ist und welche Kontrollmechanismen nötig sind.

• Welche Fragen kommen wirklich? (Nicht: Welche glauben wir, dass kommen)
• Welche Antwortstruktur funktioniert?
• Wo braucht es Bildmaterial oder Dateianhänge?
• Bei wie vielen Fragen muss der Techniker wirklich selbst nachdenken vs. Standardantworten?

Aufwand: 2–5 Tage für das Interface, 1–2 Wochen für die Testphase

Erkenntnisgewinn: Hoch. Sie validieren den gesamten Workflow, ohne eine Zeile KI-Code geschrieben zu haben.

3. Methode 2: Der KI-Design-Sprint

Der Design Sprint (nach Google Ventures) ist eine 5-Tage-Methode, um schnell von der Idee zum getesteten Prototyp zu kommen. Für KI-Projekte habe ich ihn angepasst:

Tag 1 – Understand & Map

• Was genau soll die KI tun? In einem Satz – und nur einem.
• Wer sind die Nutzer? (Nicht „das Unternehmen", sondern: Frau Schmidt aus der Buchhaltung, die 80 Eingangsrechnungen pro Woche bearbeitet)
• Was ist der Erfolgsmaßstab? („Antwortzeit unter 2 Minuten" oder „Fehlerquote unter 5 %")
• Was sind die Kill-Kriterien? („Wenn die Antwortqualität schlechter ist als unsere FAQ-Seite, lohnt es nicht")

Tag 2 – Sketch & Ideate

Nicht programmieren – skizzieren. Jeder Teilnehmer zeichnet auf ein DIN-A4-Blatt, wie die KI-Lösung aus Nutzersicht aussieht. Das können sein:

• Der Bildschirm, den ein Mitarbeiter sieht, wenn die KI ein Angebot vorschlägt
• Die E-Mail, die der Kunde als automatische Antwort bekommt
• Das Dashboard, das dem Teamleiter zeigt, wie viele Anfragen automatisch gelaufen sind

Tag 3 – Decide & Select

Alle Skizzen an die Wand. Jeder Teilnehmer klebt Punkte auf die besten Ideen. Am Ende steht eine klare Richtung – nicht 15 Features, sondern die 3, die den Unterschied machen.

Tag 4 – Prototype

Ein klickbarer Prototyp in Figma oder direkt in HTML. Keine echte KI dahinter – hartcodierte Antworten, die realistisch aussehen. Dieser Prototyp geht am nächsten Tag in den Nutzertest.

Tag 5 – Test mit echten Nutzern

5 Nutzer, 5 Szenarien, 5 Beobachtungen. Die Kernfragen:

• Versteht der Nutzer, was die KI macht?
• Vertraut er dem Ergebnis?
• Wo zögert er? Wo wird er skeptisch?
• Würde er das im echten Arbeitsalltag nutzen?

Aufwand: 5 Tage mit 3–5 Personen aus dem Unternehmen

Erkenntnisgewinn: Extrem hoch für den Preis. Sie haben am Freitagabend entweder ein klares Go oder klare No-Go-Gründe.

4. Methode 3: RAG-Test-Framework

Wenn Sie eine Wissens-KI bauen wollen (z. B. interner Chatbot für Handbücher, Support-Dokumentation oder Produktdaten), ist RAG (Retrieval-Augmented Generation) der Standardansatz. Aber: Ein RAG-System ohne systematische Tests ist eine Blackbox.

Die häufigsten Ursachen schlechter RAG-Ergebnisse – von veralteten Quellen bis zu fehlenden Metadaten – analysieren wir im Artikel Warum interne Wissens-KI oft schlechte Antworten gibt.

Mein RAG-Test-Framework besteht aus vier Teilen:

4.1 Ground-Truth-Testset

Sie brauchen 50–100 Testfragen mit bekannten, korrekten Antworten. Diese Fragen schreibt Ihr Fachexperte – nicht die KI. Für jede Frage: Was muss die Antwort enthalten? (Fakten, Daten, Verweise auf das Originaldokument).

Beispiel für einen HVAC-Großhändler: „Wie hoch ist der Mindestbestellwert für kostenlose Lieferung?" → Erwartete Antwort: „75 € netto, seit 01.01.2026, siehe AGB Seite 3, Absatz 4".

4.2 Retrieval-Qualität messen

Bevor Sie die generierte Antwort testen, prüfen Sie: Holt die Retrieval-Komponente die richtigen Dokumente? Metriken:

• Precision@K: Von den Top-K abgerufenen Dokumenten – wie viele sind relevant?
• Recall: Wurde das korrekte Dokument überhaupt abgerufen?

Das können Sie mit einem 50-Zeilen-Python-Skript messen. Keine teure Infrastruktur nötig.

4.3 Antwortqualität bewerten

Zwei Dimensionen:

• Faktentreue (Faithfulness): Enthält die Antwort nur Fakten, die in den Quellen stehen? Eine KI, die den Mindestbestellwert erfindet, ist gefährlicher als eine, die sagt „weiß ich nicht".
• Relevanz: Beantwortet die Antwort die Frage vollständig? Nichts bringt einen genervteren Nutzer als eine KI, die an der Frage vorbei antwortet.

4.4 Iterativer Optimierungszyklus

Aus dem Testset ergeben sich konkrete To-Dos: Chunking-Strategie ändern, System-Prompt nachschärfen, bestimmte Quellen höher gewichten. Dann: Erneut testen. Nach 3–5 Iterationen liegt die Genauigkeit typischerweise bei 85–95 %. Ab da lohnt der Pilot.

Aufwand: 1 Woche für Fachexperte (Testfragen schreiben), 1 Woche für Techniker (Framework aufsetzen und iterieren)

Erkenntnisgewinn: Sie wissen genau, wo Ihr RAG-System steht – und was noch fehlt, bevor es produktiv gehen kann.

5. Methode 4: A/B-Pilot mit echten Nutzern

Der A/B-Pilot ist die Königsdisziplin – aber auch die aufwändigste. Sie setzen die KI-Lösung in einer minimalen, aber funktionsfähigen Version auf und lassen eine kleine Gruppe echter Nutzer parallel zum bestehenden Prozess damit arbeiten.

So setze ich das auf:

1. Pilotgruppe definieren: 5–8 Nutzer, die repräsentativ für die spätere Zielgruppe sind – nicht die KI-Begeisterten, sondern der Querschnitt
2. Minimallösung bauen: Nur die Kernfunktion, kein „Nice to have". Authentifizierung, Logging, Monitoring – ja. Aber keine Admin-Oberfläche für seltene Konfigurationsänderungen
3. Parallelen Prozess beibehalten: Die Pilotnutzer arbeiten 2–4 Wochen mit der KI UND dem alten Prozess. Warum? Weil Sie messen wollen: Wie oft entscheiden sie sich freiwillig für die KI?
4. Metriken definieren: Annahmequote (wie oft wird die KI genutzt, wenn sie verfügbar ist), Bearbeitungszeit (vorher/nachher), Fehlerquote, Nutzerzufriedenheit (kurzer Fragebogen nach jeder Nutzung)
5. Wöchentliches Review: Jeden Freitag 30 Minuten mit den Pilotnutzern: Was funktioniert? Wo hakt es? Was fehlt?

Entscheidungskriterien nach dem Piloten:

• Annahmequote > 60 % → Skalieren
• Annahmequote 30–60 % → Nachbessern, zweiter Pilot in 4 Wochen
• Annahmequote < 30 % → Stopp oder grundlegend neu denken

Aufwand: 3–6 Wochen Entwicklung, 2–4 Wochen Pilotlauf

Erkenntnisgewinn: Höchster. Sie wissen nicht nur, ob die Technik funktioniert – Sie wissen, ob Menschen sie nutzen.

6. Methode 5: Fake-Door-Testing

Die schnellste und billigste Methode – und gleichzeitig die mit dem geringsten Erkenntnisgewinn. Aber manchmal genau richtig.

So funktioniert es: Sie bauen einen Button oder ein Feature in Ihre bestehende Software ein, das die KI-Funktion ankündigt („KI-gestützte Angebotserstellung – jetzt testen"). Klickt ein Nutzer darauf, erscheint: „Diese Funktion ist bald verfügbar. Möchten Sie informiert werden, sobald sie live geht?"

Was Sie messen: Wie viele Nutzer klicken auf den Button? Das sagt Ihnen, ob überhaupt Bedarf besteht, bevor Sie einen Prototyp bauen. Wenn nach zwei Wochen nur 3 von 50 Nutzern geklickt haben, wissen Sie: Diesen Use Case sollten Sie nicht verfolgen – zumindest nicht so kommuniziert.

Aufwand: 1–2 Stunden für Button + Tracking

Erkenntnisgewinn: Gering, aber für den Preis extrem effizient

7. Welche Methode für welchen Use Case?

Hier meine Daumenregel, die ich in der Beratung verwende:

Viele dieser Methoden lassen sich mit Low-Code-Plattformen wie n8n, Make und Flowise auch ohne Entwicklerteam umsetzen – ideal für schnelle Prototypen.

8. Die ersten 3 Schritte

1. Use-Case-Shortlist erstellen: Schreiben Sie alle KI-Ideen auf, die in Ihrem Unternehmen kursieren. Sortieren Sie nach: „potenzieller Business-Impact" und „Umsetzbarkeit". Meine Erfahrung: Von 20 Ideen bleiben nach diesem Filter 3–5 übrig. Mehr zum Priorisieren: Warum KI-Projekte scheitern – und wie Sie es besser machen.
2. Die richtige Prototyping-Methode wählen: Nutzen Sie die Entscheidungsmatrix aus Abschnitt 7. Die meisten Unternehmen überspringen das und bauen direkt einen Piloten – das ist teuer und oft unnötig. Ein Fake-Door-Test kostet nichts und kann Ihnen 20.000 € sparen.
3. Maximal zwei Wochen für den ersten Prototyp: Nicht perfekt, nicht vollständig, aber echt genug, dass Nutzer Feedback geben können. Am Ende der zwei Wochen haben Sie entweder Go, No-Go oder einen klaren Plan, was noch fehlt.

Über den Autor

Ivo ist Experte für KI-Strategie und Automatisierung im Mittelstand. Er hilft Unternehmen dabei, Corporate LLMs und KI-Agenten sicher und profitabel in bestehende Geschäftsprozesse zu integrieren.

Zur kostenlosen KI-Erstanalyse →