Diese Seite gibt einen technischen Überblick über die Systemarchitektur von ALTERNIS und NOTITIA: welche Komponenten es gibt, wie sie miteinander kommunizieren, über welche Schnittstellen und Protokolle das geschieht – und welche der drei Betriebsarten (100 % On-Premise, Sphere, Cloud) sich daraus ergeben. Sie richtet sich an alle, die eine Netzwerk- oder Systemumgebung für den Einsatz von ALTERNIS und/oder NOTITIA planen und wissen möchten, welche Kommunikationspfade dafür je nach gewählter Betriebsart eingerichtet werden müssen.
| Komponente | Rolle |
|---|---|
| ALTERNIS | Call-Handling – Sprachverarbeitung (Transkription, Übersetzung, Synthese) für Telefongespräche |
| NOTITIA | Process-Handling – Prozessunterstützung und Auswertung von Dialogen mittels Natural Language Understanding |
| LLM-Gateway | LLM-Request-Handling – nimmt LLM-Anfragen von NOTITIA entgegen und leitet sie an die passende Verarbeitungsebene weiter |
| Authenticator | Auth-Handling – zuständig für die Authentifizierung; kann optional an ein bestehendes Verzeichnis des Kunden angebunden werden |
| License Server | LiveReader License Issuer – validiert Lizenzen und nimmt Telemetriedaten entgegen |
ALTERNIS und NOTITIA verfügen jeweils über einen eigenen GPU-Cluster für die rechenintensive KI-Verarbeitung (ALTERNIS Compute bzw. NOTITIA Compute).
Je nach Komponente kommen unterschiedliche Protokolle zum Einsatz:
| Protokoll | Verwendung |
|---|---|
| HTTP/TCP | Steuerung, API-Aufrufe |
| SSE/HTTP (Server-Sent Events) | Echtzeit-Ereignisströme, z. B. laufende Transkriptions- oder Prozessupdates |
| WS/TCP (WebSocket) | Bidirektionale Echtzeitkommunikation mit NOTITIA |
| RTP/UDP | Audiostrom in Echtzeit (ein- und ausgehend bei ALTERNIS) |
| LDAP (optional) | Anbindung des Authenticators an ein bestehendes Verzeichnis des Kunden |
NOTITIA kommuniziert dabei sowohl mit ALTERNIS (HTTP/TCP, SSE/HTTP) als auch mit dem Authenticator (HTTP/TCP) und dem LLM-Gateway (HTTP/TCP, SSE/HTTP). Sowohl ALTERNIS als auch NOTITIA melden sich zudem stündlich mit einem Lizenz-Ping beim License Server.
Die Grafik zeigt drei Zonen – Cloud, Sphere und 100 % On-Premise – die jeweils eine eigene Betriebsart abbilden. Sie unterscheiden sich vor allem darin, wo Daten verarbeitet und wo sie ggf. gespeichert werden.
Die höchste Stufe an Privatsphäre. Die gesamte Systemumgebung läuft in der Infrastruktur des Kunden. An LiveReader werden ausschließlich Metadaten und Telemetriedaten in regelmäßigen Abständen übermittelt – für den Lizenzabgleich mit dem License Server. Personenbezogene Daten verlassen die Systemumgebung des Kunden zu keinem Zeitpunkt.
Bei Sphere verbleiben sämtliche Daten ebenfalls in der Systemumgebung des Kunden. Ausgelagert wird lediglich die Rechenleistung (Compute): Diese kann bei LiveReader in der Sphere-Umgebung gehostet werden. Kennzeichnend für dieses Modell ist, dass bei LiveReader keinerlei Daten gespeichert werden – Daten werden nur zur Verarbeitung übertragen und unmittelbar danach wieder verworfen. Es findet also keine Persistierung auf Datenträgern statt; alles, was zur Verarbeitung benötigt wird, existiert nur kurzfristig im Arbeitsspeicher.
Bei LiveReader Cloud wird die gesamte Systemumgebung bei LiveReader gehostet. Da hierbei Daten bei LiveReader verarbeitet und gespeichert werden, ist zwischen Kunde und LiveReader ein Auftragsverarbeitungsvertrag (AVV) abzuschließen, in dem u. a. geregelt wird, welche Daten wann gelöscht und wie sie verwaltet werden.