Vom KI-Prototyp zur Produktion: Die 15 Dinge, die sich komplett ändern

Die Prototyp-Illusion

Jeder KI-Prototyp funktioniert. Du rufst eine API auf, schickst einen Prompt, bekommst eine Antwort. Die Demo beeindruckt die Stakeholder. Das Team schätzt zwei Sprints bis zur Produktion.

Zwölf Monate später ist das System immer noch nicht in Produktion. Nicht weil die KI nicht funktioniert. Weil alles drum herum nicht funktioniert: Auth, Rate Limiting, Kostentracking, PII-Handling, Fallback-Modelle, Retry-Logik, Versionsverwaltung, Monitoring, Alerting, Compliance-Dokumentation, Multi-Region-Deployment, Disaster Recovery und operative Runbooks.

Das KI-Modell macht vielleicht 10% eines Produktions-KI-Systems aus. Die anderen 90% sind Engineering. Dieser Artikel behandelt die 15 Dinge, die sich komplett ändern, wenn du vom Prototyp zur Produktion wechselst.

Für spezifische Patterns schau dir unsere Guides zu KI-DSGVO-Compliance, KI-Observability und KI-Entscheidungs-Nachverfolgbarkeit an.

Die 15 Dinge

1. Authentifizierung und Multi-Tenancy

Prototyp: ein API-Key hardcoded in der Umgebung.

Produktion: JWT-Tokens mit Tenant-Scoping, API-Key-Management mit Rotation, rollenbasierte Zugriffskontrolle, Rate Limiting pro Tenant, Usage-Tracking pro Tenant.

Jede KI-Anfrage muss eine Tenant-Identität tragen. Jede Antwort muss gescoped sein. Jede Kostenposition muss zugeordnet werden. Schau dir unseren Multi-Tenant Design Guide für die vollständige Architektur an.

2. Kostenmanagement

Prototyp: 50 $/Monat auf der Kreditkarte.

Produktion: 5.000-50.000 $/Monat über mehrere Provider, Modelle und Anwendungsfälle hinweg. Ohne Kostentracking pro Tenant, pro Modell, pro Anwendungsfall kannst du dein Produkt nicht bepreisen, Verschwendung nicht identifizieren und Ausgaben nicht prognostizieren.

// Kosten pro Anfrage tracken
const cost = calculateCost({
    provider: 'openai',
    model: 'gpt-4o',
    promptTokens: response.usage.prompt_tokens,
    completionTokens: response.usage.completion_tokens,
});

await costTracker.record({
    tenantId: ctx.tenantId,
    model: 'gpt-4o',
    useCase: 'customer-support',
    costUsd: cost,
    timestamp: new Date(),
});

3. PII-Handling

Prototyp: rohe Kundendaten in jedem Prompt.

Produktion: semantische Tokenisierung, Trust Boundaries, richtliniengesteuerte Wiederherstellung, Audit Trails ohne PII, DSGVO-Compliance. Schau dir unseren DSGVO-Compliance Guide und Data-Leakage-Prevention Guide für die vollständige Architektur an.

4. Fallback-Modelle

Prototyp: ein Modell, ein Provider. Wenn er ausfällt, ist das System down.

Produktion: primäres Modell mit automatischem Fallback auf ein sekundäres. Verschiedene Modelle für verschiedene Aufgaben (schnelles Modell für Klassifizierung, genaues Modell für Generierung). Redundanz auf Provider-Ebene.

async function generateWithFallback(prompt: string, options: GenerateOptions): Promise<string> {
    const providers = [
        { provider: 'anthropic', model: 'claude-sonnet-4-20250514' },
        { provider: 'openai', model: 'gpt-4o' },
        { provider: 'local', model: 'llama-3.1-70b' },
    ];

    for (const config of providers) {
        try {
            return await llmClient.generate(prompt, config);
        } catch (error) {
            logger.warn('Provider fehlgeschlagen, versuche Fallback', {
                provider: config.provider,
                error: error.message,
            });
            continue;
        }
    }
    throw new Error('All providers failed');
}

5. Rate Limiting

Prototyp: keine Limits.

Produktion: Rate Limits pro Tenant, pro Modell, global. Ohne sie sättigt der Batch-Job eines Tenants die API und jeder andere Tenant bekommt Timeouts.

6. Retry-Logik

Prototyp: wenn es fehlschlägt, nochmal manuell versuchen.

Produktion: exponentielles Backoff mit Jitter bei transienten Fehlern. Circuit Breaker bei Provider-Ausfällen. Kein Retry bei Validierungsfehlern. Unterschiedliche Strategien für unterschiedliche Fehlertypen.

7. Versionsverwaltung

Prototyp: neuestes Modell, neuester Prompt.

Produktion: gepinnte Modellversionen, versionierte Prompts, A/B-Testing zwischen Prompt-Versionen, Rollback-Fähigkeit, Evaluierungs-Suiten die vor dem Deployment einer neuen Prompt-Version laufen.

8. Monitoring und Alerting

Prototyp: in die Konsole schauen.

Produktion: Latenz-Perzentile (p50, p95, p99), Fehlerraten pro Provider, Token-Nutzungstrends, Kosten pro Tag/Woche/Monat, Halluzinationserkennung, Qualitätsbewertung, Alerts bei Anomalien.

// Metriken tracken
const metrics = {
    latency_ms: response.latencyMs,
    tokens_prompt: response.usage.promptTokens,
    tokens_completion: response.usage.completionTokens,
    cost_usd: response.cost,
    model: response.model,
    provider: response.provider,
    status: response.error ? 'error' : 'success',
    finish_reason: response.finishReason,
    tenant_id: ctx.tenantId,
};

await metricsCollector.record('llm_request', metrics);

Schau dir unseren KI-Observability Guide und OpenTelemetry Guide für Implementierungsmuster an.

9. Compliance-Dokumentation

Prototyp: "Wir nutzen GPT-4."

Produktion: Verzeichnis der Verarbeitungstätigkeiten (DSGVO Art. 30), Datenschutz-Folgenabschätzung (Art. 35), Model Cards die Fähigkeiten und Limitierungen dokumentieren, Audit Trails für jede Entscheidung, Freigabeprotokolle für wertvolle Aktionen.

Schau dir unseren KI-Entscheidungs-Nachverfolgbarkeitsguide für die Audit-Architektur an.

10. Caching

Prototyp: jede Anfrage trifft den LLM.

Produktion: semantisches Caching für ähnliche Anfragen, Response-Caching für identische Anfragen, Embedding-Caching für wiederholte Dokumente. Caching reduziert Kosten und Latenz um 30-60% bei typischen Workloads.

11. Input-Validierung

Prototyp: dem User-Input vertrauen.

Produktion: Prompt-Injection-Erkennung, Eingabelängenlimits, Content-Filterung, Spracherkennung, Intent-Klassifizierung vor teuren LLM-Aufrufen.

12. Output-Validierung

Prototyp: dem Model-Output vertrauen.

Produktion: Output Guard für halluzinierte PII, Zitatverifikation gegen abgerufenen Kontext, Structured-Output-Parsing mit Schema-Validierung, Confidence Scoring, Fallback-Antworten für qualitativ schlechten Output.

13. Streaming

Prototyp: auf die vollständige Antwort warten, sie anzeigen.

Produktion: Tokens an den User streamen, während sie generiert werden. Das erste Token erscheint in 200-500ms, obwohl die vollständige Antwort 2-5 Sekunden dauert. Streaming verändert die wahrgenommene Latenz drastisch.

14. Multi-Region

Prototyp: eine Region, ein Deployment.

Produktion: Datenresidenz-Anforderungen (EU-Daten bleiben in der EU), Latenz-Optimierung (Auslieferung aus der nächsten Region), Disaster Recovery (Failover auf sekundäre Region).

15. Der Team-Wandel

Prototyp: ein ML-Engineer oder Full-Stack-Entwickler.

Produktion: du brauchst Leute, die Ops, Infrastruktur, Compliance, Kostenmanagement und Monitoring verstehen. ML/KI-Expertise ist notwendig, aber nicht ausreichend. Das Team braucht:

Die Produktionsreife-Checkliste

Bevor du live gehst, prüfe:

Häufige Fallstricke

1. Produktionszeitplan vom Prototypzeitplan ableiten. Der Prototyp hat 2 Wochen gedauert. Produktion dauert 6-12 Monate. Die KI ist 10% der Arbeit.

2. Kein Kostentracking ab Tag eins. Bis du merkst, dass die Kosten aus dem Ruder laufen, hast du bereits zu viel ausgegeben. Tracke ab der ersten Produktionsanfrage.

3. Abhängigkeit von einem einzelnen Provider. Wenn OpenAI down ist, ist dein System down. Konfiguriere Fallback-Provider.

4. Keine Input-Validierung. Prompt Injection ist ein realer Angriffsvektor. Validiere und bereinige Eingaben, bevor sie den Prompt erreichen.

5. Compliance als Nachgedanke. Legal blockiert deinen Launch, wenn die DSGVO-Dokumentation nicht fertig ist. Starte die Compliance-Arbeit parallel zum Engineering.

6. Kein semantisches Caching. Ähnliche Fragen von verschiedenen Usern lösen jedes Mal die komplette Pipeline aus. Ein semantischer Cache reduziert Kosten erheblich.

7. Monolithisches Deployment. Trenne deinen API-Server von deinen Worker-Prozessen. Eine langläufige KI-Generierung sollte nicht die HTTP-Request-Verarbeitung blockieren.

8. Keine Evaluierungs-Suite. Eine Prompt-Änderung kann die Qualität auf Wegen verschlechtern, die du erst bemerkst, wenn User sich beschweren. Führe Evaluierungen durch, bevor du Prompt-Änderungen deployest.

Wichtigste Erkenntnisse

• Das KI-Modell ist 10% eines Produktionssystems. Auth, Kostentracking, PII-Handling, Monitoring, Compliance, Caching und Reliability Engineering sind die anderen 90%.

• Kostenmanagement ist nicht optional. Tracke pro Anfrage, pro Tenant, pro Modell. Alarmiere bei Schwellenwerten. Setze Budgetobergrenzen. Kosten skalieren schneller als du erwartest.

• Fallback-Provider verhindern Ausfälle. Kein einzelner LLM-Provider hat 100% Uptime. Konfiguriere automatisches Failover.

• Compliance startet an Tag eins, nicht beim Launch. DSGVO-Dokumentation, Audit Trails und Model Governance brauchen Zeit. Parallelisierung mit Engineering spart Monate.

• Das Team verändert sich. Ein Prototyp braucht einen KI-Engineer. Produktion braucht zusätzlich Ops, Infrastruktur, Compliance und Product-Leute.

Wir helfen Teams bei diesem Übergang als Teil unserer KI-Services Praxis. Von der Prototyp-Architekturprüfung bis zum vollständigen Produktions-Deployment, sprich mit unserem Team oder fordere ein Angebot an. Schau dir auch unsere Methodik-Seite an, um zu erfahren, wie wir KI-Projekte angehen.