Ihre Meeting-Medien sind nicht unser Datenprodukt.

Die „Nein“-Liste.

Nichts davon existiert irgendwo in CodeB Sovereign Communications. Keine Ausnahmen, kein „aber nur, wenn Sie zustimmen“, keine Sternchen.

• Keine Drittanbieter-Analytics — kein Matomo, kein Plausible, kein Mixpanel, kein Amplitude, kein Segment — auch keine First-Party-Analytics.
• Keine Werbe-Tracker — keinerlei Werbenetz-Pixel. Keine Retargeting-Tags, keine Audience-Pixel.
• Keine Cookies — wir setzen keine Cookies, weder First-Party noch andere. Die App nutzt localStorage ausschließlich für Ihre eigenen Präferenzen, und auch das bleibt auf Ihrem Gerät.
• Keine Session-Recordings, Heatmaps oder Scroll-Tracker — kein FullStory, Hotjar, LogRocket, Mouseflow oder Ähnliches.
• Keine A/B-Test-Plattformen — kein Optimizely, kein LaunchDarkly, kein Feature-Flag-Service jeglicher Art.
• Kein Error-Reporting an Dritte — kein Sentry, kein Bugsnag, kein Datadog RUM. Fehler bleiben in Ihrer Browser-Konsole.
• Keine CDN-Abhängigkeiten im Anrufpfad — der QR-Code-Generator, der WebRTC-Client und der Signaling-Endpunkt werden allesamt von phone.codeb.io ausgeliefert.
• Keine Pflicht-Drittanbieter-Logins — kein Social-Account-Login, kein Microsoft-Konto, kein SSO nötig, um einem Raum beizutreten. Sie geben einen Raumcode ein — und sind drin.
• Keine Identity-Provider zwischendrin — Ihr Name ist das, was Sie eintippen; wir gleichen ihn nicht gegen ein externes Verzeichnis ab.
• Keine Meeting-Persistenz auf irgendeinem Server — Aufzeichnungen existieren nur auf dem Gerät, das aufzeichnet; Chat lebt nur im Browser-Speicher und ist weg, wenn der Tab schließt.
• Keine Telemetrie aus der App selbst — der laufende Browser-Code sendet keine „Nutzer hat X geklickt“-Events an irgendeinen Endpunkt. Punkt.
• Keine werbefinanzierte Stufe — auf keiner Seite gibt es jemals Anzeigen.

Die „Ja — kurz“-Liste.

Die Liste der Dinge, die tatsächlich passieren, passt kurz und bündig auf diese Seite.

• Der IIS-Server hält eine kurze In-Memory-Liste „Wer ist gerade in welchem Raum“, um Signaling zwischen Ihnen weiterzuleiten. Verlässt die letzte Person den Raum, ist der Eintrag weg. Nichts wird auf Platte geschrieben.
• Standard-IIS-Access-Logs verzeichnen HTTP-Requests (URL, Statuscode, IP, User Agent), wie es jeder Webserver tut. Die meisten Betreiber rotieren diese nach 14 Tagen weg. Wir werten sie nicht aus.
• Ihr Browser speichert eine Handvoll Präferenz-Keys in localStorage: Anzeigename, gewählte Kamera/Mikrofon, Spiegel-Toggle, Push-to-Talk, Auto-Spotlight, Hintergrund-Unschärfe, Stumm-beim-Beitritt und Kamera-aus-beim-Beitritt. Browserdaten löschen — weg sind sie.
• Für Meetings, die es benötigen, wird beim Raumbeitritt ein HMAC-SHA1-TURN-Credential für Ihren Browser erzeugt. Das Credential läuft nach einer Stunde ab. Es enthält weder Ihren Namen, Ihre E-Mail noch irgendeinen dauerhaften Identifier.

Wo Bytes unser Netz verlassen.

Drei externe Hosts können vom Browser kontaktiert werden, je nachdem, welche Funktionen Sie nutzen. Keiner davon sieht je Ihr Video, Audio, Chat oder Ihre Dateien.

Für eine Air-Gap-Installation können WebRTC-Signaling, TURN-Relay, JS, CSS, Fonts und ML-Modell alle im LAN des Kunden leben. Der Build unterstützt das; das Rezept steht im Deployment-README.

Warum das Farbschema aussieht wie ein Terminal aus den 1980ern.

Die Akzentfarbe, die Sie überall in CodeB Sovereign Communications sehen — dieses warme #f5a524 auf dem tiefen #0a0d12-Hintergrund — ist eine bewusste Höflichkeit vor Bernstein-Phosphor-Bildschirmröhren.

Rund fünfzehn Jahre lang, von Ende der 1970er bis Anfang der 1990er, starrten die Menschen, die die wichtigsten Computer der Welt bedienten, auf bernsteinfarbene Bildschirme. Der IBM 5151, der Wyse 50, Terminals an Krankenhaus-Schwesternstationen, Fertigungs-SPS, Flugverkehrs-Konsolen, Defense-Command-Terminals — sie alle glühten in demselben warmen Gelb bei etwa 580 nm Wellenlänge.

Der Grund war nicht ästhetisch. Bernstein-Phosphor (P3, später P134) wurde gewählt, weil er im Sweet Spot der photopischen Empfindlichkeitskurve des menschlichen Auges liegt. Operatoren, die zehn oder zwölf Stunden auf einen Bildschirm starrten — Radiologen, Fluglotsen, Werkzeugmaschinen-Programmierer — erlebten messbar weniger Augenermüdung mit Bernstein als mit dem sonst üblichen grünen P1-Phosphor und deutlich weniger als mit den später modisch gewordenen weißen CRTs. Bernstein war die Farbe von Werkzeugen für Menschen, deren Arbeit zuählte.

Diese Linie wollten wir CodeB einfärben. Ein ernsthaftes Werkzeug für ernsthafte Arbeit — Klinik, Engineering, Fertigung, öffentlicher Dienst, Verteidigungs-Lieferketten — dieselben Menschen, die CodeB Identity Solutions seit zwei Jahrzehnten bedient. Die codeb.io-Designsprache nutzt Bernstein, wie es jene Terminals taten: viel Signal, kein Schmuck. Es gibt eine Akzentfarbe, weil die Arbeit zählt; das Chrome sollte ihr nicht Konkurrenz machen.

(Und es gibt einen kleinen praktischen Bonus: gegen einen dunklen Hintergrund hat Bernstein den höchsten wahrnehmbaren Kontrast jeder einzelnen Akzentfarbe und bleibt auch für Menschen mit den häufigsten Formen einer Rot-Grün-Sehschwäche unterscheidbar. Die Ingenieure der 1980er wählten es aus ergonomischen Gründen; wir aus denselben — und aus ein wenig historischem Respekt.)

Das Versprechen, schriftlich.

Sollte einer der Punkte aus Abschnitt 01 („Was wir nicht tun“) jemals nicht mehr stimmen, ändert sich diese Seite, bevor die Änderung ausgeliefert wird. Wir bauen Tracker nicht heimlich ein. Wir vergraben neue Analytics nicht drei Menüebenen tief.

Der Quellcode von CodeB Sovereign Communications lebt auf Ihrem eigenen IIS-Server. Jede JavaScript-Datei, jeder C#-Handler und der gesamte TURN-Service stehen jedem in Ihrer Organisation zur Inspektion offen. Es gibt keine Obfuskation, keinen Minify-Schritt, der Logik verbirgt, und kein kompiliertes Binärformat, das etwas enthielte, das nicht im Quellcode sichtbar wäre.

Sehen Sie etwas in der laufenden App, das diesem Manifest widerspricht, schreiben Sie bitte an info@codeb.ioAnrufen. Ein echter Mensch liest diesen Posteingang — oder geht an dieses Telefon.

Wo sich KI-Anrufe von Meetings unterscheiden.

Die vollständige KI-Anrufe-Datenschutz- & Datenfluss-Seite lesen →

Die obige Datenschutzhaltung gilt für CodeB-Conference-Meetings und CodeB-Phone-(SIP)-Anrufe zwischen Menschen. CodeB Voice AI ist anders, denn die KI-Rezeption und das ausgehende KI-Anruf-Feature senden Anrufer-Audio per Design an ein Echtzeit-Sprachmodell. Wir dokumentieren das ehrlich, damit Operatoren und Endnutzer genau wissen, was sie erwartet.

Das Modell-Backend ist pro Deployment austauschbar.

Die Bridge lässt sich auf eine der folgenden Optionen konfigurieren:

• Eine Cloud-KI-Voice-Engine — bidirektionale Echtzeit-Sprache. Anrufer-Audio wird an die API des konfigurierten Cloud-Engine-Anbieters gestreamt und dort verarbeitet; die Datenhaltungs-Bedingungen des Cloud-Engine-Anbieters gelten. Transkripte kommen über dieselbe WebSocket zurück.
• Eine andere Cloud-KI-Voice-Engine — gleiches Architekturmuster. Anrufer-Audio wird an den konfigurierten Cloud-Engine-Anbieter gestreamt; die Bedingungen des Cloud-Anbieters gelten.
• On-Premise-KI-Voice-Engine — ausschließlich statisches Text-to-Speech. Kein externes Modell. Anrufer-Audio verlässt niemals die Maschine. Wird als Fallback eingesetzt, wenn das Cloud-Modell nicht erreichbar ist, und als primäres Backend in Air-Gap-Deployments, wo externer Traffic inakzeptabel ist.

Welches Backend in diesem Deployment aktiv ist, wird in App_Data/<tenant>/appsettings.json vom Operator gesetzt. Es gibt keine Standard-Cloud-Verbindung — ohne konfiguriertes Modell laufen KI-Anrufe gar nicht.

Was das Deployment verlässt, wenn ein Cloud-Modell aktiv ist.

• Anrufer-Audio — in Echtzeit zur konfigurierten Modell-API gestreamt, 16 kHz PCM. Die Bridge speichert keine Kopie des Audios nach Anrufende.
• Anrufer- und KI-Transkripte — von der Modell-API zurückgegeben. Die Bridge schreibt sie in eine mandantenlokale Datei (unter App_Data/<tenant>/ai-transcripts/) und versendet, falls konfiguriert, eine Kopie per E-Mail an die Operator-Adresse, die am Vnum oder an der Kampagne hängt.
• Der Persona-System-Prompt — bei jedem Anruf gesendet, um das KI-Verhalten zu setzen. Vom Operator verfasst; vor dem Deployment in der Persona-Datei prüfbar.
• Tool-Call-Metadaten — ruft die KI transfer_to_user oder hangup auf, fließen die Argumente (Zielnummer, Grund) für die Antwort über die Modell-API zurück.

Was im Deployment bleibt.

• Die Rufnummern-Whitelist und Pro-Anruf-FraudGuard-Zähler — werden nie an ein Modell gesendet.
• Die SIP-Trunk-Zugangsdaten — werden nie an ein Modell gesendet.
• Die Webhook-Liste, REST-API-Schlüssel und OIDC-Signierschlüssel — werden nie an ein Modell gesendet.
• Die Transkript-Dateien auf der Festplatte — mandantenlokal, unter App_Data/<tenant>/ai-transcripts/. Werden ohne operatorseitiges Backup nirgendwohin synchronisiert.

Operator-Pflichten bei aktivierten KI-Anrufen.

Wenn Ihr Deployment KI-Anrufe mit einem Cloud-Modell ausführt, sind Sie in den meisten Jurisdiktionen der Datenverantwortliche für diese Anrufe. Sie sind verantwortlich für:

• Eingehenden Anrufern (typischerweise per Begrüßung beim Annehmen oder per Halte-Ansage) offenzulegen, dass sie mit einer KI sprechen und dass ihre Stimme von einer Drittanbieter-Modell-API verarbeitet wird.
• Ein Modell-Backend zu wählen, dessen Datenverarbeitungs-Bedingungen zu Ihrer regulatorischen Umgebung passen. Für EU-Gesundheits-, Rechts- oder öffentliche Deployments ist das On-Premise-KI-Voice-Engine-Backend oder ein On-Premise-Inferenzserver der konservative Default.
• Eine angemessene Aufbewahrungs-Richtlinie für Transkripte zu setzen — die Bridge speichert Transkripte standardmäßig zeitlich unbegrenzt auf der Festplatte; die Rotation liegt in Ihrer Verantwortung.

Wenn Sie ein Air-Gap- oder vollständig on-premise KI-Voice-Erlebnis benötigen, kontaktieren Sie uns — on-premise Inferenz-Deployments (ein kleines Open-Weights-Speech-to-Text-Modell plus LLM auf derselben Windows-Maschine) werden unterstützt, benötigen aber operatorseitige Hardware.