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 trennt zentrale Konto-, Verzeichnis-, Sicherheits- und Betriebsfunktionen von fachlichen Praxisdaten. Jede Praxis nutzt eine getrennte, ihr zugeordnete Praxisinstanz mit eigener Datenhaltung, eigenen Zugriffsrechten und eigener Verantwortlichkeit für fachliche Praxisdaten.
Gesundheitsbezogene Inhalte, Patientenakten, Behandlungsdaten, medizinische Dokumente, Praxis-Chats und fachliche Workflows werden in der jeweils zugeordneten Praxisinstanz verarbeitet. Zentrale Kaya-Dienste verarbeiten nur die Informationen, die für Konto, Betrieb, Sicherheit und die bereitgestellten Funktionen erforderlich sind.
2. Trennung von zentralen Diensten und Praxisdaten
| Bereich | Zweck | Datenabgrenzung |
|---|---|---|
| mykaya.de | Öffentliche Website, Produktinformationen, Kontakt-, Demo- und Preisanfragen. | Keine zentrale Verarbeitung von Gesundheitsdaten. Keine Tracking- oder Marketing-Cookies. |
| app.mykaya.de | Eigenes CRM der trainity GmbH, neutrale Konto- und Login-Grundlage für Nutzer der mobilen Kaya Apps, interne Betriebsfunktionen und Kaya Meets. | Keine Patientenakten und keine Behandlungsdaten als zentraler Kaya-Datenbestand. |
| Praxisinstanz | Fachliche Nutzung von Kaya durch die jeweilige Praxis. | Eigener Datenraum der Praxis mit lokaler Anwendung, eigener Datenhaltung, eigenen Rollen und eigener technischer Grenze. |
| Kaya Patienten-App | Verbindung von Patientinnen und Patienten mit ihrer Praxisinstanz. | Nach Verbindung mit einer Praxis erfolgt die fachliche Nutzung in der jeweils zugeordneten Praxisinstanz. |
| Kaya Mitarbeiter-App | Mobile Arbeitsoberfläche für Praxisteams mit Praxis-/Standortauswahl. | Mitarbeiterdaten, Rollen, Module, Aufgaben, Chats, Arbeitszeit- und Praxisfunktionen laufen nach Auswahl der Praxis direkt gegen die jeweilige Praxisinstanz. |
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, Rollen, Organisationen, Push-Zuordnungen und Praxisfunktionen werden grundsätzlich in der jeweiligen Praxisinstanz verwaltet.
Kaya unterstützt Praxen bei technischer Einrichtung, DNS, Zertifikaten, Updates und Sicherheitskonfiguration. Soweit Administrations- oder Supportleistungen vereinbart sind, erfolgen sie zweckgebunden und im Rahmen der jeweiligen Kundenbeziehung. Fachliche Praxisdaten verbleiben grundsätzlich 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, verarbeitet der jeweils eingesetzte Telefonieanbieter die für Verbindungsaufbau, Routing und Sprachtransport erforderlichen Daten. Die Übertragung erfolgt über gesicherte, vom jeweiligen Anbieter unterstützte Transportverfahren.
Die Praxis bleibt nutzungsberechtigt und verantwortlich für die 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.
Patientenakten, strukturierte Kaya-Anwendungsdaten und KI-Modellanfragen werden im Standardpfad nicht an den Telefonieanbieter übergeben. Abhängig vom Gesprächsinhalt kann der Sprachtransport einen Gesundheitsbezug aufweisen.
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. Gesundheitsbezogene KI-, Speech-to-Text- und Text-to-Speech-Verarbeitung erfolgt im Standardbetrieb über kontrollierte Infrastruktur in Deutschland. Externe öffentliche KI- oder Speech-Dienste werden hierfür nicht als regulärer Verarbeitungsweg eingesetzt.
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 werden für Betrieb, Sicherheit, Nachvollziehbarkeit und Fehleranalyse geführt und nach dem Grundsatz der Datenminimierung gestaltet.
Fachliche Inhalte sind nicht Bestandteil der regulären Betriebs- und Analyselogs. Soweit für klar definierte Support- oder Sicherheitsfälle zusätzliche Informationen erforderlich sind, gelten gesonderte Zugriffs-, Zweckbindungs- und Löschregelungen.
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.
- Keine zentrale app.mykaya.de-Patientenakte.
- 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 externen öffentlichen KI-/Speech-Dienste als regulärer Standardpfad 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