Self-Hosted Voice-AI-Plattform für Teams mit Datenresidenz-Anforderungen

Das Problem

Voice-AI-Plattformen wie Parloa, Cognigy, Vapi oder Retell sind nützlich, aber Enterprise-Teams brauchen oft mehr Kontrolle, als ein gehostetes Voice-SaaS bietet. Die wiederkehrenden Fragen:

• Wohin gehen die Anrufdaten?
• Lässt sich das System in einer vertrauenswürdigen VPC betreiben?
• Können STT-, LLM- und TTS-Anbieter ausgetauscht werden?
• Lassen sich die Kosten im Skalierungsfall kontrollieren?
• Können Erkenntnisse aus Anrufen ins Geschäft zurückfließen?
• Lässt sich der Workflow prüfen, bevor Änderungen die Produktion erreichen?

Die Lösung

Eine produktionsorientierte Self-Hosted-Voice-AI-Bereitstellung — operative Kontrolle ist der Designkern:

• Dograh als Open-Source-Orchestrierung für Voice-Agenten.
• GPU-gestützte lokale STT-, LLM- und TTS-Inferenz hinter OpenAI-kompatiblen Endpunkten, damit einzelne Anbieter ausgetauscht werden können, ohne die Anrufer-Seite neu zu verdrahten.
• Persistentes Modell-/Runtime-Volume, sodass Compute heruntergefahren und wieder hochgefahren werden kann, ohne lange Re-Download-Zyklen.
• Evidenz-Artefakte für Maschinen-Nachweis, Modell-Preload, Health-Checks, Benchmark und Smoke-Tests.
• Runbook zur Reproduktion des Setups auf RunPod oder in einer kundenseitig gewählten VPC.

Kundenkontext bevor das erste Wort fällt

Ein zentraler Designpunkt ist der Pre-Call-Kontext-Lookup. Bevor der Anrufer zu sprechen beginnt, kann das System bekannte Account- oder Kundeninformationen abrufen und sich daran anpassen: Begrüßung, Tonalität, Produktkontext, Support-Tier, nächste sinnvolle Frage, Routing-Entscheidung, Handoff-Schwelle. Der Agent verhält sich dadurch weniger wie ein generischer Bot und mehr wie ein vorbereiteter Mitarbeiter, der weiß, wer anruft.

Was wir gemessen haben

Die erste Validierungsumgebung lief auf RunPod Secure Cloud in EU-RO-1 mit einer RTX 5090 und einem dedizierten 300-GB-Persistent-Volume. Die lokale Voice-AI-Schicht hat Chat-Antwortgenerierung, Text-to-Speech-Audiogenerierung, Speech-to-Text-Transkription, Health-Checks und einen Warm-Benchmark vollständig durchlaufen.

Business-Outcome-Loop

Das System ist darauf ausgelegt, strukturierte Session-Ergebnisse an ein Backend zurückzuschreiben, sodass aus Anrufen messbarer Geschäftsfortschritt wird — nicht nur “ein Voice-Bot hat geantwortet”.

Pro Session erfasste Metriken: Anruf angenommen, Anruf abgeschlossen, erfolgreicher Handoff, ohne Handoff gelöst, qualifizierter Lead, disqualifizierter Lead, Disqualifikationsgrund, offene Frage, Einwand-Kategorie, Follow-up erforderlich, geschätzter Wert, Kosten pro abgeschlossenem Anruf, Kosten pro qualifiziertem Lead.

Ein erfolgreicher Handoff bedeutet: Der Agent hat erkannt, dass ein Mensch übernehmen sollte, das Ziel war korrekt, der Mensch hat Kontext erhalten, und der Anrufer musste seine Geschichte nicht erneut erzählen. Beispiel-Payload:

{
  "session_id": "sess_123",
  "handoff_target": "sales_engineering",
  "caller": {
    "company": "Acme GmbH",
    "support_tier": "priority"
  },
  "reason": "VPC deployment and security review question",
  "summary": "Caller wants self-hosted voice AI in their own VPC and asked about data residency.",
  "recommended_next_action": "Schedule technical architecture call."
}

Jede Session erzeugt zusätzlich Learning-Items, damit Anrufe in Vertrieb, Support, Produkt, Marketing und Operations zurückfließen:

{
  "session_id": "sess_123",
  "type": "knowledge_gap",
  "source": "voice_call",
  "text": "Caller asked whether STT can run fully inside an EU VPC.",
  "recommended_action": "Add VPC-local STT section to security FAQ.",
  "priority": "high"
}

Minimaler Backend-API-Vertrag:

POST /call-session/start
POST /call-session/event
POST /call-session/outcome
POST /handoff-summary
POST /learning-items

Datenmodell: caller_profiles, call_sessions, call_events, handoffs, outcomes, learning_items, agent_versions, workflow_versions.

Guardrail

Eine einzelne Session darf das Produktionsverhalten nicht automatisch überschreiben. Empfohlener Ablauf:

1. Learning-Item schreiben.
2. Ähnliche Items gruppieren.
3. Review.
4. Prompt / Workflow / Wissensbasis aktualisieren.
5. Versionsstand ändern.
6. Testen.
7. Veröffentlichen.

Fünf Capabilities, die diese Bereitstellung belegt

1. Ultra-niedrige Latenz durch lokale GPU-Inferenz.
2. Anbieter-Unabhängigkeit auf Modellebene.
3. Menschliche Interaktionsführung über Kontext- und Handoff-Logik.
4. Transiente Spezialisten-Agenten hinter dem Live-Voice-Agenten.
5. Enterprise-Workflow-Kontrolle über visuelle Guardrails und Persistenz.

Ehrlicher Status

Die Infrastruktur und der Nachweis der lokalen Inferenz sind abgeschlossen. Der nächste Produktionsnachweis besteht darin, die Dograh-Orchestrierung an die lokalen Inferenz-Endpunkte anzuschließen, den Pre-Call-Kundenkontext anzubinden und den Backend-Learning-Writeback zu aktivieren.

Wenn Sie heute Voice AI auf einem gehosteten SaaS betreiben und die oben genannten Fragen zu Datenresidenz, Anbieter-Wechsel oder Business-Outcomes anfangen zu stören, gehe ich gern dreissig Minuten lang Ihren spezifischen Stack mit Ihnen durch — keine Folien.