Die KI von smao: Modelle, Datenpfad und Architektur

Was „die KI von smao" konkret bedeutet

Ein KI-Telefonassistent verbindet Telefonie, Spracherkennung, Antworterzeugung und Sprachausgabe. Für die technische Bewertung zählt, welche Komponenten ein Gespräch verarbeiten und wer sie betreibt. Der Produktname allein beantwortet diese Frage nicht.

Beim KI-Telefonassistenten von smao ist die Antwort darauf der Kern des Produkts und kein Nebensatz im Datenschutzhinweis. Telefonie-Layer, Orchestrierung und Anwendung sind selbst entwickelt, und die Sprachmodelle betreibt smao selbst, statt sie als API bei einem Modellanbieter aufzurufen. In der Gesprächsverarbeitung sind weder OpenAI noch US-KI-Subprozessoren beteiligt. Die smao Cloud wird in Deutschland gehostet. Bei smao On Premises werden lokale Dienste, Funktionsumfang, Telefonie und externe Verbindungen für die Zielumgebung vereinbart.

Dieser Artikel beschreibt, was das technisch bedeutet: welchen Weg ein Anruf nimmt, welche Systeme ihn verarbeiten, woher die Antworten kommen, was nach dem Gespräch passiert und wo die Grenzen liegen. Wer stattdessen Preise und Funktionen sucht, findet die im Anbietervergleich am Ende der Seite.

Der Weg eines Anrufs durch die KI

Der folgende Ablauf beschreibt die Aufgaben eines smao Telefonassistenten. Welche Aktionen und Anbindungen freigegeben sind, wird für den jeweiligen Prozess konfiguriert; bei On Premises gehört die Telefonie-Anbindung zur projektbezogenen Abnahme.

• Annahme und Spracherkennung: Der Anruf kommt über einen SIP-Trunk von smao oder über die eigene, angebundene Telefonanlage. Gesprochenes wird in Text überführt.
• Anliegen verstehen: Das Sprachmodell erfasst, worum es geht, in welcher Sprache gesprochen wird und wie dringend der Fall ist.
• Wissen abrufen: Der Assistent sucht die Antwort in der freigegebenen Wissensbasis, nicht im allgemeinen Modellwissen.
• Handeln: Antworten, Termin im Kalender prüfen und buchen, Ticket anlegen, Rückrufwunsch aufnehmen oder per Warm Transfer an die richtige Person weiterleiten.
• Übergeben: Anliegen, Kontaktdaten, Dringlichkeit und Zusammenfassung landen als strukturierte Felder im Zielsystem, dazu kommt das dokumentierte Gesprächsprotokoll.

Welche Modelle das Gespräch verarbeiten

Für den Gesprächspfad unterscheiden wir Herkunft der Modelle, Betrieb der Modelle und die eigene Plattform darum herum.

Selbst betriebene Modelle statt eingekaufter Modell-APIs

In der Gesprächsverarbeitung kommen selbst betriebene Open-Source-, Open-Weight- und lizenzierte Modelle zum Einsatz. OpenAI und US-KI-Subprozessoren sind an der Gesprächsverarbeitung nicht beteiligt. Die Architekturseite beschreibt den Geltungsbereich dieser Produktangaben.

Telefonie, E-Mail und optionale Integrationen sind eigene Datenwege und müssen im Gesamtprozess berücksichtigt werden. Für On Premises werden die lokalen Dienste und erforderlichen Verbindungen mit der Zielumgebung abgeglichen. Selbst betriebene Modelle bedeuten daher keine pauschale Zusage, dass sämtliche Verbindungen eines Projekts lokal bleiben.

Offene Modellgewichte und Open Source sind unterschiedliche Aussagen. Die Open Source AI Definition 1.0 der OSI berücksichtigt neben Freiheiten zur Nutzung und Änderung auch den Zugang zu Code, Parametern und Informationen über Trainingsdaten. Für ein konkretes Modell sind deshalb die zugehörigen Lizenzbedingungen zu prüfen.

smao behauptet nicht, eigene Sprachmodelle von Grund auf zu trainieren. Die eigene Leistung liegt in der Telefonie, Orchestrierung und Anwendung sowie im Betrieb der eingesetzten Modelle.

Telefonie-Layer und Orchestrierung sind selbst gebaut

Telefonie-Layer, Orchestrierung und Anwendung sind bei smao selbst entwickelt. LiveKit oder Pipecat sind keine Grundlage dieses Gesprächspfads. Diese Produktangabe beschreibt die Herkunft der Plattform; sie ist kein Vergleich der Sprachqualität oder Zuverlässigkeit anderer Produkte.

Für eine IT-Prüfung bleibt entscheidend, welche Komponenten, Verbindungen und Zuständigkeiten im konkreten Betriebsmodell tatsächlich vorgesehen sind. Die Herkunft einer Codebasis ersetzt diese Prüfung nicht.

Eine Codebasis für Telefon, Chat und E-Mail

Der heutige Produktschwerpunkt ist KI-Telefonassistenz. Erste Chat- und E-Mail-Funktionen bauen auf derselben Plattformgrundlage auf. Daraus folgt keine Zusage einer vollständigen Omnichannel-Suite oder identischer Fähigkeiten in jedem Kanal und jeder On-Premises-Zielumgebung.

Wo die KI läuft: zwei Betriebsmodelle

Die beiden Betriebsmodelle unterscheiden sich bei Infrastruktur und Verantwortung. Der Funktionsumfang von smao On Premises wird für die Zielumgebung vereinbart; eine pauschale Funktionsgleichheit mit der Cloud ist nicht zugesagt.

smao Cloud, gehostet in Deutschland

• Hosting der smao Cloud in Deutschland.
• Gesprächsverarbeitung ohne OpenAI und ohne US-KI-Subprozessoren.
• Das Sprachmodell wird im Gespräch nicht als externe Modell-API aufgerufen.
• Kein KI-Training mit Kundendaten.
• Saubere Mandantentrennung über Konten hinweg.
• Kein eigener Server nötig: Konto anlegen, Assistent konfigurieren, Testanruf führen.

Betrieb auf eigener Infrastruktur

Die Referenzbereitstellung von smao On Premises nutzt kundeneigene Linux- und Docker-Infrastruktur. Modellinferenz, Spracherkennung, Sprachausgabe, Wissenssuche sowie Anwendungs- und Objektdaten können in der Kundenumgebung laufen. Ein Telefonie-Gateway gehört nicht zum generischen Anwendungsstack: Telefonie, E-Mail, Updates und optionale Integrationen werden pro Projekt über dokumentierte, freigegebene Verbindungen angebunden. Funktionsumfang, Betriebsverantwortung und Wartung werden vor dem Start vereinbart.

Welche Dienste lokal laufen und welche Verbindungen erforderlich sind, wird für die Zielarchitektur geprüft. Daraus folgt weder eine allgemeine Air-Gap-Zusage noch geprüfte Kompatibilität mit jeder Telefonanlage.

Headless per API

Für Produktteams gibt es einen dritten Weg: Die Voice AI lässt sich per API headless einbinden, also ohne die smao-Oberfläche, als Baustein im eigenen Produkt. Dazu kommen SIP-Trunk und Webhooks für die Anbindung an bestehende Telefonie und Systeme.

Woher die KI ihre Antworten nimmt

Für die Antwortqualität sind freigegebene Inhalte und der Umgang mit fehlenden Informationen entscheidend.

Die smao Wissensdatenbank stellt freigegebene Inhalte für den Assistenten bereit. Fachlich Verantwortliche legen fest, welches Wissen verwendet werden soll und wann eine Rückfrage oder Übergabe erforderlich ist. Für ein Projekt müssen diese Regeln mit realistischen Fragen geprüft werden.

Und wenn das Wissen nicht reicht: Dann erfindet der Assistent keine Antwort. Er sagt, dass er es nicht weiß, nimmt das Anliegen auf, verspricht Rückruf oder leitet an einen Menschen weiter. Welche Fälle er selbst klärt und welche grundsätzlich an einen Menschen gehen, legst du in den Eskalationsregeln fest.

Eine Garantie fehlerfreier Antworten folgt daraus nicht. Prüfe getrennt, ob die richtige Information gefunden wird und ob die Antwort sie korrekt wiedergibt. Das RAG-Glossar erklärt diese Unterscheidung, ohne jedem smao Deployment dieselbe technische Sucharchitektur zuzuschreiben.

Was die KI nach dem Gespräch auslöst

Der Teil, der im Betrieb über den Nutzen entscheidet. Ein Assistent, der freundlich annimmt und ein Transkript ins Postfach legt, verschiebt Arbeit statt sie abzunehmen.

• Anrufanalysen: konfigurierbare Workflows, die nach jedem Anruf automatisch auslösen. Datenextraktion, Ticket-Erstellung, Lead-Qualifizierung oder Benachrichtigungen, je nach definierter Regel.
• Strukturierte Übergabe: Kontaktdaten, Anliegen, Dringlichkeit und Ergebnis landen als Felder im Zielsystem, nicht als Freitext. Genau hier unterscheidet sich der Aufwand nach dem Anruf von dem eines klassischen Telefonservice.
• 70+ Integrationen und offene API: Vorhandene native Konnektoren und individuell geplante API-Anbindungen sind getrennt ausgewiesen. Funktionsumfang, Berechtigungen und Datenpfade werden für das konkrete CRM-, Ticket-, Kalender- oder Telefoniesystem geprüft.
• Persönliche Vermittlung: Warm Transfer an die richtige Person oder Queue, mit Notizen und Kontext, damit niemand sein Anliegen wiederholen muss.
• Protokolle: Gesprächsdaten können die Qualitätsprüfung unterstützen. Welche Informationen gespeichert, zugänglich gemacht und aufbewahrt werden, muss zum konkreten Einsatz und dessen Regeln passen.

Was mit den Gesprächsdaten passiert

Kundendaten werden nicht für KI-Training genutzt. Aufbewahrung und Löschfristen werden für den konkreten Einsatz festgelegt, nicht pauschal gesetzt.

Die Architekturseite ordnet Unterlagen wie AVV, technische und organisatorische Maßnahmen sowie Lösch- und Aufbewahrungsregeln ein. Welche Nachweise für den Einsatz benötigt werden, hängt von Rolle, Zweck und Risiken ab; die DSGVO enthält dazu unter anderem Artikel 28, 32 und 35.

Benötigst du Zertifizierungen oder vertragliche Betriebszusagen, lass dir den jeweils aktuellen Nachweis für den konkreten Leistungsumfang vorlegen. Eine geplante Zertifizierung wird nicht als vorhandenes Zertifikat gewertet.

Datenpfade anderer Anbieter vergleichen

Für einen Vergleich benötigst du je Anbieter dieselben Angaben: Modellbetrieb, Verarbeitungsorte, Subprozessoren und vorgesehene Betriebsoption. Beziehe die Antwort auf das konkret angebotene Produkt und die gewählte Region.

Die Anbieterübersicht mit Quellen führt die Produktvergleiche zusammen. Die Modellbeschreibung hier konzentriert sich auf smao; sie enthält keine zusätzliche, separat zu pflegende Rangliste.

Was die KI von smao nicht ist

Zur Architekturbeschreibung gehören auch diese Grenzen:

• Kein Ersatz für dein Team. Die KI fängt ab, was sonst liegen bleibt: Überlauf zu Stoßzeiten, Randzeiten, wiederkehrende First-Level-Fragen. Alles, was Urteilsvermögen oder Verantwortung braucht, gehört an einen Menschen, und die Eskalationsregeln sind dafür da, das verlässlich zu machen.
• Keine Zusage, dass jede Antwort stimmt. Antworten kommen aus freigegebenem Wissen und der Assistent sagt es, wenn er etwas nicht weiß. Eine Garantie fehlerfreier Gespräche ist das nicht, und niemand in diesem Markt sollte eine geben.
• Keine selbst trainierten Sprachmodelle. Die Modelle kommen aus dem Open-Source- und Open-Weight-Ökosystem oder sind lizenziert. smao betreibt sie selbst und hat die Plattform darum herum selbst gebaut; daraus folgt nicht, dass smao ein eigenes Sprachmodell trainiert hat.
• Keine Contact-Center-Plattform. Für ein eigenes Routing-Regelwerk über hunderte Agents mit vielen Skill-Gruppen ist smao nicht gebaut. Dafür gibt es Enterprise-Plattformen, und die stehen im Anbietervergleich mit Namen.
• Kein „100 % DSGVO-sicher". Die Architektur unterstützt eine datenschutzgerechte Ausgestaltung durch Hosting in Deutschland, dokumentierte Datenpfade und die passenden Unterlagen. Die Bewertung selbst hängt von Zweck, Rechtsgrundlage, Aufbewahrung, Integrationen und gewähltem Betriebsmodell ab. Wer Pauschalzusagen macht, sagt mehr über sein Marketing als über seine Technik.

Was Teams im Betrieb davon merken

Für den Einstieg und die Kapazitätsplanung unterscheiden sich Cloud und On Premises. Die folgenden Verweise führen zu den jeweils maßgeblichen Produktinformationen.

• smao Cloud: Einstieg, enthaltene Leistungen und Konditionen stehen auf der aktuellen Preisseite. Angaben zum schnellen Cloud-Test sind keine Einführungszeit für ein On-Premises-Projekt.
• smao On Premises: Anrufaufkommen, Parallelität und Hardware werden zusammen mit der Zielumgebung dimensioniert. Die Kapazität einer kundeneigenen Installation folgt nicht aus einem Cloud-Tarif.
• Strukturierte Übergabe: Prüfe an einem eigenen Beispiel, welche Daten im Zielsystem ankommen und welche Arbeit dem Team danach noch bleibt.
• Qualitätsprüfung: Teste auch fehlendes Wissen, eine nicht erreichbare Zielperson und Fehler eines angebundenen Systems.

Prüfstand und Quellen

Die Produktbeschreibung stützt sich auf die dokumentierten smao Betriebsmodelle und ihre Einschränkungen. Externe Quellen erklären Begriffe und rechtliche Bezugspunkte; sie sind keine unabhängige Zertifizierung der smao Implementierung. Dieser Beitrag enthält keine eigenen Modellbenchmarks oder pauschalen Kapazitätszusagen.