KI in der Produktentwicklung: Von der Discovery bis zum Betrieb

KI in der Produktentwicklung heißt zweierlei: KI als Werkzeug im Prozess, von der Kundenrecherche bis zum Code-Review, und KI als Bestandteil des Produkts, das dein Team baut. Beides folgt derselben Regel: Die KI bereitet vor, erzeugt und prüft; die Entscheidung über Anforderung, Architektur und Release bleibt beim Team, und kein KI-generierter Code geht ohne menschliches Review in Produktion.

Dieser Artikel geht die fünf Phasen der Produktentwicklung durch, Discovery, Spezifikation, Bauen, Testen, Betrieb, zeigt je Phase, was KI übernimmt, und behandelt danach KI als Produktbestandteil und die Governance. Er ergänzt den Guide KI für Unternehmen und die technischen Deep Dives zu Code-Generierung, Datenextraktion, Evaluation und Workflow-Design.

Was KI in der Produktentwicklung heute leistet

Die Versprechen sind groß, und die Praxis ist differenzierter. Code-Assistenten optimieren auf "sieht plausibel aus", nicht auf "ist sicher und korrekt"; sie kennen weder dein Bedrohungsmodell noch deine internen Standards noch deine Compliance-Anforderungen. Der Produktivitätsgewinn entsteht deshalb nicht durch das Werkzeug allein, sondern durch die Pipeline und die Regeln darum.

Was für Code gilt, gilt für jede Phase: Ein Modell erzeugt eine Persona, eine Spezifikation, einen Testfall oder einen Statusbericht in Minuten. Ob das Ergebnis trägt, entscheiden die Eingabe, die Prüfung und die Frage, welche Entscheidung damit besser wird. Ein KI-Projekt, das mit dem Modell statt mit der Entscheidung beginnt, liefert am Ende ein Modell und kein System.

Phase 1: Discovery und Kundenverständnis

Produktentwicklung beginnt mit der Frage, für wen. Der Persona-Artikel zeigt einen Ablauf in unter 60 Minuten: Datenquellen identifizieren (10 Minuten), KI-Werkzeuge für die erste Recherche nutzen (15 Minuten), Validierung durch Social Listening in echten Gesprächen (20 Minuten), Persona-Profil synthetisieren (15 Minuten). Der dritte Schritt ist der, den die meisten auslassen; ohne ihn ist die Persona ein plausibler Text ohne Bezug zur Realität.

Die Persona ist erst dann Produktarbeit, wenn sie benutzt wird: für die Priorisierung von Anforderungen, für die Sprache in der Oberfläche, für die Reihenfolge im Onboarding. Der Persona-Artikel nennt vier Verwendungen, von der Content-Strategie bis zu personalisierten Sequenzen; für die Produktentwicklung gilt dieselbe Regel, sonst verstaubt die Persona im Wiki.

Für den Markt liefert der Teardown-Ansatz das Gegenstück: Scoping, sauberes Einsammeln von Websites und Pitchdecks, Zerlegung nach Botschaften und Beweisen, Synthese und Aktivierung im Team. KI beschleunigt das Zerlegen und Verdichten; welche Erkenntnis ins Produkt einfließt, entscheidet der Mensch.

Phase 2: Anforderungen und Spezifikation

Die Spezifikation eines KI-Features beginnt nicht mit dem Modell, sondern mit dem Output-Contract: Was genau kommt raus, wer bekommt es, in welchem Format, mit welcher Begründung, mit welcher Handlungsempfehlung. Der Output-Contract ist das Pflichtenheft des Systems. Dazu die Frage, die jedes KI-Vorhaben in einem Satz beantworten muss: Welche Entscheidung wird dadurch schneller oder besser?

Für Features, die Daten aus Texten ziehen, heißt Spezifikation: das Schema zuerst. Die Architektur für zuverlässige Extraktion definiert das Zielschema mit Typen und Pflichtfeldern, erzwingt strukturierten Output, validiert das Ergebnis und gibt je Feld eine Konfidenz zurück; Felder mit niedriger Konfidenz landen in einer Prüfwarteschlange. Im Enterprise-Einsatz ist "ungefähr richtig" nicht akzeptabel.

KI hilft auch beim Schreiben der Spezifikation selbst: Anforderungen aus Kundengesprächen und Meetings herausziehen, Widersprüche zwischen Dokumenten finden, offene Punkte markieren. Der Artikel zur Prozessdokumentation zeigt das für SOPs; für Produktanforderungen funktioniert es gleich, mit derselben Regel: Review durch die Fachseite, fünf bis zehn Minuten statt einer Stunde manueller Erstellung.

Phase 3: Bauen mit Code-Assistenten

Die Werkzeuglandschaft hat drei Typen: Autocomplete in der IDE für das ganze Team, KI-native Editoren mit Mehrdateien-Bearbeitung und Codebase-Kontext, und terminalbasierte Agenten, die Architektur-Absicht verstehen und Migrationen über viele Dateien ausführen. Die Empfehlung des Artikels: Autocomplete für alle, Editor oder Agent für Senior-Entwickler bei komplexen Architekturaufgaben.

Die fünf größten Sicherheitsrisiken von KI-generiertem Code: fehlende Input-Validierung (SQL Injection, XSS, Command Injection), hardcodierte Secrets, veraltete Abhängigkeiten wegen des Trainingsstands, Logikfehler in komplexer Geschäftslogik und blindes Vertrauen ("Vibe Coding"): Der Code besteht den Unit-Test und öffnet gleichzeitig eine Hintertür.

Dagegen stehen vier Säulen: Secure-by-Default-Konfiguration mit Team-Regeln für den Assistenten ("immer parametrisierte Queries, keine hardcodierten Secrets, alle Eingaben prüfen") und Pre-Commit-Hooks mit Secret-Scanner; eine automatisierte Security-Pipeline aus statischer Analyse, Secret-Erkennung, Abhängigkeitsprüfung, KI-spezifischer Analyse, Review durch Mensch und KI und Integrationstests; Human-in-the-Loop, kein KI-Code ohne Review in Produktion; Governance mit Audit-Trail, Prüfung der Datenresidenz und einer Regel, welche Module manuell geschrieben werden.

Für Teams ohne Entwickler gilt derselbe Ansatz eine Stufe tiefer: Der Bericht über eine in fünf Stunden gebaute Power App zeigt, wie ein Assistent Formeln erklärt, Fehler deutet und Best Practices nennt. Die Regel des Autors: nicht blind kopieren, verstehen, anpassen, testen. Low-Code heißt nicht No-Brain.

Phase 4: Testen und Evaluieren

Ein KI-Feature testet man anders als eine deterministische Funktion. Das Evaluations-Framework hat vier Stufen: Golden Set Testing mit echten, schwierigen Fällen; automatische Metriken für Format, Fakten und Konsistenz; A/B-Tests gegen die bisherige Lösung; Continuous Evaluation in Produktion. Wer nur den Happy Path testet, erlebt die schwierigen 20 Prozent der Fälle beim Kunden.

Die Produktions-Checkliste für Extraktions-Pipelines gilt für jedes KI-Feature: Schema mit 50 oder mehr echten Dokumenten validiert, Konfidenz-Tracking mit kalibrierten Schwellen, Prüfwarteschlange für unsichere Fälle, Logging auf Feldebene, Retry-Logik, Kosten-Monitoring je Aufruf, Drift-Erkennung gegen eine Ground-Truth-Stichprobe.

Drei Fehlerquellen tauchen in fast jedem KI-Feature auf, das Daten verarbeitet: Halluzination bei fehlenden Daten (das Modell erfindet ein Feld, statt es leer zu lassen), Format-Inkonsistenz (Datum und Zahl mal so, mal so) und numerische Präzision (Rundung, Dezimaltrennzeichen, Währung). Alle drei lassen sich mit Schema, Validierung und Konfidenz-Signal abfangen; keine davon durch einen strengeren Prompt.

Und Tests sind kein einmaliges Ereignis: Modelle ändern sich, Prompts degradieren. Ein Prompt, der vor acht Monaten funktionierte, verhält sich nach einem Modell-Update anders. Die Evaluation läuft deshalb bei jedem Modellwechsel erneut, mit demselben Golden Set.

Phase 5: Betrieb und technische Schulden

KI-Systeme im Betrieb sammeln eigene Schulden. Der Artikel zu technischen Schulden in KI-Automation-Stacks nennt sieben Arten, darunter Workflow Sprawl (Workflows ohne Registry und Lifecycle), Prompt Rot, Integration Debt (fragile Punkt-zu-Punkt-Anbindungen ohne Fehlerbehandlung), Knowledge Debt (die Logik existiert nur im Kopf dessen, der sie gebaut hat) und Testing Debt.

Mit Agenten kommt eine neue Dimension dazu: Agent Sprawl, Permission Creep (schrittweise mehr Zugriffsrechte), Context Rot (Leistung sinkt mit der Länge der Konversation) und Coordination Debt in schlecht koordinierten Multi-Agent-Systemen. Teams, die Zeit in den Abbau dieser Schulden investieren, bauen langfristig schneller neue Features als Teams, die alles in neue Features stecken.

Die Gegenmittel stehen im Workflow-Design: EVA-Architektur, Idempotenz, Human-in-the-Loop an den Stellen mit Schaden, Modularität, Fallback-Ketten, Observability, Versionierung und Rollback. Ein KI-Feature ohne diese sieben Prinzipien ist ein Prototyp, und Prototypen gehören ins Labor, nicht in den Betrieb.

KI als Produktbestandteil: Prompting, RAG oder Fine-Tuning

Wenn KI ins Produkt kommt, stellt sich die Frage nach der Methode. Die Entscheidungsmatrix des Fine-Tuning-Artikels ist kurz: Brauchst du Fine-Tuning? Nein: gutes Prompting plus RAG reicht. Ja: bei klarer Ground Truth und einfacher Anpassung Supervised Fine-Tuning, bei Reasoning mit mehreren gültigen Antworten GRPO, jeweils mit einer Evaluation, die nichts beschönigt.

Fine-Tuning ist sinnvoll bei einem sehr spezifischen Format, das Prompting nicht zuverlässig reproduziert, bei proprietärem Domänenwissen, das in keine Wissensdatenbank passt, bei Latenzanforderungen und bei hohem Volumen mit Kostendruck. Es ist falsch als Ersatz für gutes Prompt Engineering. Für die meisten Produkt-Features im Mittelstand reicht die Kombination aus Prompting und Wissensanbindung; wie sie funktioniert, erklärt der Artikel Retrieval Augmented Generation erklärt.

Die Modellwahl dahinter ist eine Architekturfrage mit fünf Dimensionen: Task-Komplexität, Daten-Sensitivität, Volumen und Latenz, Integration, Total Cost of Ownership. 80 Prozent der Aufgaben sind Klassifikation, Extraktion und Zusammenfassung, für die kleine und mittlere Modelle reichen; das Frontier-Modell bleibt den komplexen Fällen vorbehalten.

Governance: EU AI Act, DSGVO, Mitbestimmung

Für KI-Coding-Werkzeuge gilt nach dem Code-Generation-Artikel: Als Betreiber dokumentierst du, welche Werkzeuge du einsetzt, für welche Code-Bereiche, welche Daten an die APIs gehen und welche Governance du anwendest. Auftragsverarbeitungsverträge mit den Anbietern prüfen, Opt-out für Trainingsdaten im Enterprise-Tier sicherstellen, und die Mitbestimmung nach § 87 BetrVG beachten, weil Acceptance Rates und Produktivitätsmetriken Leistung erfassen können.

Für KI als Produktbestandteil kommt die Rolle dazu: Wer ein KI-System entwickelt oder unter eigenem Namen anbietet, ist Anbieter im Sinne des EU AI Act, mit den entsprechenden Pflichten je Risikoklasse. Ein Textassistent im eigenen Produkt ist minimales Risiko mit Transparenzpflicht nach Artikel 50; ein Feature, das über Menschen entscheidet, etwa Bewerber vorsortiert, ist Hochrisiko nach Anhang III. Die Fristen und Pflichten stehen im Artikel EU AI Act für Unternehmen.

Datenschutz gilt in beiden Fällen: Rechtsgrundlage vor dem Einsatz, Auftragsverarbeitungsvertrag, Datenklassifikation, PII-Filter, EU-Region. Die Checkliste steht im Artikel zur DSGVO-konformen KI-Implementierung.

Fazit

KI in der Produktentwicklung trägt in allen fünf Phasen, wenn drei Dinge stehen: die Entscheidung, die das Produkt verbessern soll, ein Output-Contract mit Quality Gates und ein Mensch, der jeden Code und jedes Feature prüft. Die Werkzeuge sind austauschbar; Pipeline, Evaluation und Governance sind es nicht. Wer damit beginnt, baut schneller. Wer mit dem Werkzeug beginnt, baut schneller Schulden.

Quellen

• Verordnung (EU) 2024/1689, Artikel 3 (Begriffsbestimmungen), Artikel 4 und 50, Anhang III, eur-lex.europa.eu/eli/reg/2024/1689/oj; Artikeltexte auf Deutsch unter artificialintelligenceact.eu/de/
• § 87 Betriebsverfassungsgesetz (Mitbestimmungsrechte), gesetze-im-internet.de/betrvg/__87.html
• Eigene Artikel: Code Generation in Enterprise, Strukturierte Daten aus Texten extrahieren, Prompt Testing und Evaluation, Workflow Design für KI-Systeme, Technical Debt in KI-Automation-Stacks, Buyer Persona mit KI, Wettbewerbsanalyse mit KI, Warum KI-Projekte am Output scheitern, Fine-Tuning 2026, Modellwahl im Unternehmen, Prozessdokumentation mit KI, Wie ich in 5 Stunden eine Power App baute, DSGVO-konforme KI-Implementierung; Studien- und Benchmark-Zahlen aus diesen Artikeln sind hier bewusst nicht übernommen.