Sicherheit und Compliance

Kaya ist für den Einsatz im sensiblen Praxisumfeld konzipiert. Diese Seite erklärt verständlich, wie Kaya Daten trennt, technische Schutzmaßnahmen umsetzt und externe Anbieter begrenzt einsetzt.

1. Sicherheitsgrundsatz

Kaya ist nicht als zentrale Cloud für Gesundheitsdaten aufgebaut. Kaya wird als Verbund getrennter Praxisinstanzen betrieben: Jede Praxis nutzt ihre eigene Praxisinstanz mit eigener technischer Grenze, eigener Datenhaltung, eigenen Zugriffsrechten und eigener Verantwortlichkeit für fachliche Praxisdaten. Zentrale Kaya-Dienste dienen vor allem neutralem Patienten-App-Login, Praxisfindung, CRM-, Betriebs-, DNS-, Zertifikats- und Verwaltungsfunktionen. Technische Praxisdomains wie 1000.mykaya.de zeigen per DNS direkt auf den jeweiligen Praxisserver; app.mykaya.de ist hierfür kein Proxy, kein Tunnel, kein Relay, kein CDN, keine WAF und kein Load Balancer.

Gesundheitsbezogene Inhalte, Patientenakten, Behandlungsdaten, medizinische Dokumente, Praxis-Chats und fachliche Workflows laufen nicht über app.mykaya.de als zentrale Fachcloud. Nach der Auswahl oder Verbindung mit einer Praxis erfolgt die fachliche Kommunikation direkt zwischen App und der jeweiligen Praxisinstanz.

2. Trennung von zentralen Diensten und Praxisdaten

3. Praxisinstanzen

Eine Praxisinstanz ist der getrennte technische Betriebsbereich der jeweiligen Praxis. Sie enthält die fachlichen Funktionen, die lokale Datenhaltung, das lokale Berechtigungsmodell und die für die Praxis aktivierten Module. Fachliche Praxis- und Mitarbeiterberechtigungen, Rollen, Standorte und Modulfreigaben werden in der jeweiligen Praxisinstanz verwaltet.

Die Kaya Mitarbeiter-App verwendet nach Praxis- beziehungsweise Standortauswahl die jeweilige Praxisinstanz als fachliches Zielsystem. Aktive Staff-Memberships, das Modul mitarbeiter_app, Rollen, Organisationen, Push-Zuordnungen und Praxisfunktionen werden nicht als zentrale Fachdaten-Cloud auf app.mykaya.de betrieben.

Kaya unterstützt Praxen bei technischer Einrichtung, DNS, Zertifikaten, Updates und Sicherheitskonfiguration. IONOS sieht bei DNS-only-Praxisdomains nur technische DNS-Daten wie Hostname, Record-Typ und Ziel-IP, aber keine HTTPS-Inhalte, URL-Pfade, Header, Cookies, Tokens oder Request-Bodies der Praxisserver. Soweit Administrations- oder Supportleistungen vereinbart sind, erfolgen sie zweckgebunden und im Rahmen der jeweiligen Kundenbeziehung. Der fachliche Datenverkehr der Praxis wird dadurch nicht zu einem zentralen app.mykaya.de-Datenfluss. Praxisbezogene Gesundheitsdaten verbleiben im vorgesehenen Datenraum der Praxisinstanz.

4. Hosting und C5-orientierte Nachweise

Für öffentliche Kaya-Dienste und praxisbezogene Instanzen werden freigegebene Infrastrukturstandorte und Anbieter mit dokumentierter Anbieterakte genutzt. Der aktuelle Standardpfad für Praxisinstanzen ist der dokumentierte Hetzner-Scope; alternative IaaS-Anbieter werden erst nach eigener Anbieterakte, Region-/Transferbewertung, AVV-/DPA-Prüfung und Kundenscope-Freigabe eingesetzt. Die jeweilige Praxisinstanz bleibt dabei ein getrennter Datenraum der Praxis.

Für eingesetzte Praxisserver-Ressourcen werden relevante Sicherheits-, Hosting- und C5-bezogene Nachweise scopebezogen gepflegt. Kunden können die für ihren Betrieb relevanten Scopes und Nachweise im Adminbereich einsehen und exportieren, soweit diese für die konkrete Instanz bereitgestellt sind. Kaya behauptet keine eigene C5-Zertifizierung der Software.

5. Verschlüsselung und Zugriffsschutz

Kaya setzt auf mehrere Schutzebenen: verschlüsselte Verbindungen, getrennte Datenräume, rollenbasierte Berechtigungen, technische Zugriffsbeschränkungen, sichere Session-Verwaltung, auditierbare Verwaltungsaktionen und eine klare Trennung zwischen neutralen Konto-/Betriebsdaten und fachlichen Praxisdaten.

Für sensible Praxisdaten ist der Standard nicht nur Transportverschlüsselung, sondern feld- beziehungsweise objektbezogene Schutzlogik. Fachliche Klartexte werden nur dort verarbeitet, wo dies für die konkrete Funktion erforderlich und freigegeben ist. Ein Login allein bedeutet nicht automatisch, dass zentrale Systeme fachliche Praxisdaten entschlüsseln können.

6. Telefonie und Telefon-KI

Wenn Telefonie oder Telefon-KI aktiviert ist, arbeitet Kaya im Standardpfad mit einem SIP-basierten Telefoniefluss auf der jeweiligen Praxisinstanz. Der Standardpfad sieht verschlüsselte SIP-Signalisierung und verschlüsselten Medientransport vor, insbesondere SIP-TLS und SRTP, soweit dies vom Anbieter technisch unterstützt wird.

Die Praxis bleibt Eigentümerin beziehungsweise Nutzungsberechtigte der eingesetzten Telefonnummern. trainity stellt keine Telefonnummern bereit und übernimmt keine Anbieterrolle für Praxisrufnummern. Kaya unterstützt nur die technische Anbindung an den jeweils freigegebenen Telefoniepfad.

Im Kaya-Standardpfad wird keine von Kaya betriebene PBX-Zwischenanlage genutzt. Telefoninhalte werden von Kaya in diesem Pfad nicht standardmäßig aufgezeichnet, nicht als technische Transkriptlogs geführt und nicht als Prompt oder LLM-Anfrage an den Telefonanbieter übergeben. Telefonanbieter können jedoch die für Telefonie, Routing und Transport erforderlichen Verbindungs- und Transportdaten verarbeiten.

Praxen können eigene SIP- oder Telefonieanbieter einsetzen, sofern diese von der Praxis selbst beauftragt und verantwortet werden und die technische Anbindung mit dem Kaya-Sicherheits- und Datenschutzmodell vereinbar ist.

7. KI-, Speech- und Medienverarbeitung

Kaya trennt fachliche Gesundheitsdaten von externen Marketing-, Tracking- und allgemeinen Medienflüssen. Für gesundheitsbezogene KI-, Speech- und Telefon-KI-Verarbeitung nutzt Kaya feste, von trainity selbst betriebene Inferenzressourcen über private Verbindungen. Diese Ressourcen sind keine externe Modell-Cloud und kein frei skalierender Cloud-Dienst. Externe KI-, Speech- oder Telefonie-KI-Dienste sind kein Standard- oder Ersatzpfad für Gesundheitsdaten.

Optionale Medienfunktionen, etwa für generische Avatar- oder Aufklärungsinhalte, sind nicht für individuelle Patientendaten bestimmt. Sie dürfen nicht mit Patientenbildern, Patientenstimmen, patientenbezogenen Prompts oder Gesundheitsdaten befüllt werden. Eine hiervon abweichende Nutzung wäre kein Standardbetrieb und bräuchte eine gesonderte technische, vertragliche und datenschutzrechtliche Freigabe.

8. Push, E-Mail und Meetings

Push-Benachrichtigungen werden so gestaltet, dass externe Push-Transportdienste keine fachlichen Inhalte, keine Patientennamen und keine Gesundheitsdaten erhalten. Benachrichtigungen enthalten neutrale technische Hinweise; fachlicher Kontext wird in der geschützten Anwendung beziehungsweise Praxisinstanz nachgeladen.

E-Mail-Versand durch trainity erfolgt für eigene System- und Betriebsnachrichten, etwa Verifizierungsmails oder angefragte Konfigurationen. Wenn eine Praxis eigene SMTP- oder Kommunikationsanbieter in ihrer Praxisinstanz hinterlegt, nutzt sie hierfür ihre eigenen Anbieter und Zugangsdaten.

Kaya Meets wird über eigene Dienste betrieben. Kamera, Mikrofon und Bildschirmfreigabe werden nur nach Browserfreigabe genutzt. Eine dauerhafte Aufzeichnung von Kaya Meets findet nicht statt.

9. Logging und Nachvollziehbarkeit

Technische Logs sind für Betrieb, Sicherheit und Fehleranalyse erforderlich. Kaya unterscheidet dabei zwischen technischen Logs und fachlichen Inhalten. Standardlogs enthalten nur notwendige technische Informationen wie Status, Fehlerklassen, Zeitpunkte, pseudonyme IDs und Betriebsereignisse enthalten.

Prompts, Audioinhalte, Transkripte, Patientenakten, Gesundheitsdaten, Rohantworten externer Anbieter und vertrauliche Zugangsdaten dürfen nicht in technischen Standardlogs landen. Für sicherheitsrelevante oder administrative Aktionen werden Nachvollziehbarkeit, Zugriffsbeschränkung und Zweckbindung berücksichtigt.

10. Externe Anbieter und Subunternehmer

Externe Anbieter werden nur eingesetzt, soweit sie für Hosting, Domains, E-Mail, Telefonie, Push-Transport, optionale Medienfunktionen oder sichere Betriebsprozesse erforderlich sind. Dienstleister werden sorgfältig ausgewählt und, soweit rechtlich erforderlich, vertraglich eingebunden.

Eine aktuelle Übersicht steht unter Subunternehmer und externe Dienste. Dort wird auch abgegrenzt, wann ein Anbieter durch trainity eingesetzt wird und wann eine Praxis eigene Anbieter wie SMTP- oder SIP-Dienstleister selbst beauftragt und verantwortet.

11. Support und Administration

Support- und Administrationszugriffe sind keine regulären Gesundheitsdatenflüsse. Sie können aber technisch wirksam sein und werden deshalb organisatorisch und technisch begrenzt. Dazu gehören Zweckbindung, Rollen- und Rechtekonzepte, Protokollierung, Freigabeprozesse und die Möglichkeit, Zugriffe zu sperren oder zu rotieren.

Für sensible Fälle gilt: Zugriff darf nur erfolgen, soweit er für Betrieb, Sicherheit, Fehlerbehebung, Support oder vertraglich vereinbarte Leistungen erforderlich ist. Routinezugriff auf fachliche Klartexte ist nicht das Betriebsmodell von Kaya.

12. Was Kaya nicht macht

• Keine Tracking- oder Marketing-Cookies auf der öffentlichen Website.
• Keine zentrale app.mykaya.de-Cloud für Patientenakten und Behandlungsdaten.
• Kein fachlicher App-Traffic über app.mykaya.de als Proxy, Relay oder Tunnel.
• Keine fachlichen Push-Inhalte an externe Push-Transportdienste.
• Keine Übergabe von Telefon-KI-Prompts, Transkripten oder LLM-Anfragen an den Telefonanbieter im Kaya-Standardpfad.
• Keine externe Modell-Cloud und keine externen KI-/Speech-Dienste als Standard- oder Ersatzpfad für Gesundheitsdaten.
• Kein Verkauf personenbezogener Daten und keine Weitergabe für fremde Werbung.

13. Nachweise für Kunden

Kaya pflegt technische, organisatorische und anbieterbezogene Nachweise für die relevanten Betriebsbereiche. Dazu gehören je nach Leistungsumfang Datenschutzinformationen, Subunternehmerlisten, Hosting- und Sicherheitsnachweise, technische Beschreibungen, Lösch- und Logginggrundsätze, Anbieterakten sowie Vertragsanlagen wie AVV und TOMs.

Kunden erhalten die für ihren Einsatz relevanten Informationen im Rahmen der Website, der Vertragsunterlagen, des Adminbereichs oder auf Anfrage. Maßgeblich ist immer der konkret aktivierte Leistungsumfang der jeweiligen Praxis.

14. Kontakt

Datenschutzfragen können an datenschutz@mykaya.de gerichtet werden. Fragen zu Sicherheit oder Compliance können an mail@mykaya.de gerichtet werden. Sicherheitsrelevante Hinweise enthalten eine möglichst genaue Beschreibung, betroffene Systeme, Zeitpunkt und reproduzierbare Schritte.

Stand: Juli 2026