Subunternehmer und externe Dienste
Diese Übersicht beschreibt, welche externen Anbieter die trainity GmbH für Kaya einsetzt und welche Datenarten dabei betroffen sein können.
1. Grundsatz
Kaya ist so aufgebaut, dass Gesundheitsdaten aus der fachlichen Nutzung nicht zentral auf app.mykaya.de oder mykaya.de verarbeitet werden. app.mykaya.de dient als internes CRM-System der trainity GmbH und als neutrale Login- und Account-Grundlage für Nutzer der mobilen Kaya Apps. Nach Auswahl oder Verbindung mit einer Praxis läuft die anschließende fachliche Kommunikation nicht über app.mykaya.de, sondern direkt zwischen App und jeweiliger Praxisinstanz.
Fachliche Praxis- und Mitarbeiterberechtigungen, Rollen, Standorte und Modulfreigaben werden in der jeweiligen Praxisinstanz verwaltet. Jede Praxisinstanz ist ein eigener Server im Verantwortungs- und Rechtsbereich der jeweiligen Praxis. Kaya stellt für die technische Erreichbarkeit DNS-, Domain- und Zertifikatsprozesse bereit. Technische Praxisdomains wie 1000.mykaya.de zeigen per DNS direkt auf den jeweiligen Praxisserver. Die zentrale Control Plane app.mykaya.de ist hierfür kein Proxy, kein Tunnel, kein Relay, kein CDN, keine WAF und kein Load Balancer; der fachliche Datenverkehr bleibt auf der Praxisinstanz und wird nicht über einen von Kaya bereitgestellten zentralen Cloud-Dienst geleitet.
Die Kaya Mitarbeiter-App ist eine zentrale mobile App, aber kein zentraler Fachdatenkanal. Nach Auswahl der Praxis beziehungsweise des Standorts laufen Mitarbeiterdaten, Rollen, Module, Aufgaben, Chats, Arbeitszeit- und Praxisfunktionen direkt gegen die jeweilige Praxisinstanz.
Externe Anbieter werden nur eingesetzt, soweit dies für Hosting, Domains, E-Mail, Telefonie, Push-Transport oder optionale Medienfunktionen erforderlich ist. Wir verkaufen keine personenbezogenen Daten und setzen auf der öffentlichen Website keine Tracking- oder Marketing-Cookies ein.
2. Aktive Subunternehmer und externe Dienste
| Anbieter | Zweck | Datenarten | Standort / Region | Gesundheitsdaten |
|---|---|---|---|---|
| Hetzner Online GmbH | Hosting und Serverinfrastruktur für mykaya.de, app.mykaya.de, Kaya Meets sowie Serverressourcen für kundeneigene Praxisinstanzen, sofern eine Praxis einen Hetzner-Server nutzt. | Server- und Verbindungsdaten, technische Zugriffsdaten, Login-/Accountdaten für mobile App-Logins, CRM-Daten, Meetingdaten, System- und Sicherheitslogs. Bei kundeneigenen Praxisinstanzen verarbeitet der jeweilige Praxisserver die dort lokal anfallenden Praxisdaten im Verantwortungsbereich der Praxis. | Deutschland / EU. Für den dokumentierten Hetzner-Scope werden C5-Typ-2-, ISO-, AVV-/DPA- und TOM-Nachweise scopebezogen geführt; die jeweiligen Nachweise können Kunden im Adminbereich einsehen und exportieren, soweit sie die konkrete Instanz betreffen. | Auf mykaya.de und app.mykaya.de nein. Auf kundeneigenen Praxisinstanzen können Gesundheitsdaten verarbeitet werden; dieser fachliche Datenverkehr läuft nicht über app.mykaya.de oder einen zentralen Kaya-Cloud-Dienst. |
| Weitere freigegebene IaaS-Anbieter | Alternative Serverressourcen für kundeneigene Praxisinstanzen nur nach Anbieterakte, Region-/Transferbewertung, AVV-/DPA-Prüfung, Nachweisbewertung und Kundenscope-Freigabe. | Server- und Verbindungsdaten sowie lokale Praxisinstanzdaten, soweit eine Praxis ihre eigene Instanz auf einem freigegebenen alternativen IaaS-Anbieter betreibt. | EU oder freigegebene Region nach Anbieterakte. C5- oder gleichwertige Nachweise werden scopebezogen bewertet und in der Kundenakte geführt. | Nur auf der jeweiligen kundeneigenen Praxisinstanz, wenn die Praxis Kaya dort mit Gesundheitsdaten nutzt. Kein fachlicher Gesundheitsdatenverkehr über app.mykaya.de. |
| IONOS SE | DNS, Domain-Verwaltung und E-Mail-/SMTP-Versand der trainity GmbH. Für Praxisdomains verwaltet IONOS nur DNS-Zonendaten; die Einträge zeigen direkt auf die jeweilige Praxisinstanz. | DNS-Zonendaten wie Hostname, Record-Typ und Ziel-IP sowie technische E-Mail-Verbindungsdaten, Empfängeradresse und Inhalt der von trainity versendeten System-E-Mails, insbesondere Verifizierungs-E-Mails für die erstmalige App-Registrierung. IONOS sieht bei DNS-only-Praxisdomains keine HTTPS-Inhalte, URL-Pfade, Header, Cookies, Tokens, Request-Bodies oder Antworten des Praxisservers. | Deutschland / EU. | Nein. Über IONOS werden durch trainity keine Gesundheitsdaten versendet. Nummerische Praxisdomains enthalten keinen Praxisnamen, Patientennamen oder medizinischen Kontext; IONOS erhält keine fachliche Zuordnung NNNN = Praxis X. |
| Zadarma | Telefonanbieter und SIP-Trunk für Telefonie und Telefon-KI, soweit diese Funktion aktiviert ist und die jeweilige Praxis den Standard-Telefoniepfad über Zadarma nutzt. Rufnummern werden von der Praxis bereitgestellt und verantwortet; trainity stellt keine Telefonnummern bereit. | Rufnummern der Praxis und der Anrufenden, Verbindungsdaten, SIP-/Telefonie-Metadaten und technisch erforderlicher Media-Transport. Der Kaya-Standardpfad nutzt verschlüsselte SIP-Signalisierung und verschlüsselten Medientransport, insbesondere SIP-TLS und SRTP, soweit dies vom Anbieter technisch unterstützt wird. Die Anbindung erfolgt ohne von Kaya betriebene PBX-Zwischenanlage; Telefoninhalte werden von Kaya in diesem Pfad nicht aufgezeichnet, nicht als Transkript protokolliert und nicht als Prompt oder LLM-Anfrage an den Telefonanbieter übergeben. | EU / je nach Anbieter- und Routingstruktur. | Keine Patientenakten, keine strukturierten Kaya-Anwendungsdaten, keine Prompts, keine Transkripte und keine LLM-Anfragen an den Telefonanbieter. Je nach Gesprächsinhalt kann der reine Sprachtransport Gesundheitsbezug enthalten; der Telefonanbieter verarbeitet dann nur die für Telefonie, Routing und Transport erforderlichen Daten. |
| Expo Push Service, Apple Push Notification service, Google Firebase Cloud Messaging | Push-Transport für mobile App-Benachrichtigungen. | Push-Token, technische Geräte- und Transportkennungen, neutrale Benachrichtigungs-IDs und technische Zustellinformationen. | EU / USA / weltweit je nach Plattformanbieter. | Nein. Push-Nachrichten enthalten keine fachlichen Inhalte, keine Patientennamen und keine Gesundheitsdaten. |
3. Optionale Funktionsanbieter
Die folgenden Anbieter werden nur eingesetzt, wenn die jeweilige optionale Funktion aktiv genutzt wird. Diese Funktionen sind nicht Teil des normalen Website-Trackings und dienen nicht der Werbung.
| Anbieter | Zweck | Datenarten | Gesundheitsdaten |
|---|---|---|---|
| Runway | Generische Bild- oder Medienerstellung für Avatar- und Aufklärungsinhalte. | Generische Prompts, Referenzmedien, generierte Medien und technische Auftragsdaten. | Nein. Diese Funktion ist auf generische Inhalte ausgelegt und nicht für individuelle Patientendaten bestimmt. |
| WaveSpeed | Generische Video- oder Medienerstellung für Avatar- und Aufklärungsinhalte. | Generische Prompts, Audio-/Bild-/Videodaten, generierte Medien und technische Auftragsdaten. | Nein. Diese Funktion ist auf generische Inhalte ausgelegt und nicht für individuelle Patientendaten bestimmt. |
4. Praxis-eigene SMTP-, Telefonie- und Kommunikationsdienste
Wenn eine Praxis eigene SMTP- oder Kommunikationsdaten in ihrer Praxisinstanz hinterlegt, nutzt die Praxis hierfür ihre eigenen Anbieter und Zugangsdaten. Diese Anbieter sind dann nicht Subunternehmer der trainity GmbH für den Versand der jeweiligen Praxisnachrichten.
Gleiches gilt für praxis-eigene oder abweichende SIP- und Telefonieanbieter, soweit diese von der Praxis selbst beauftragt, verantwortet und in ihrer eigenen Praxisinstanz hinterlegt werden. Eine technische Anbindung solcher Anbieter erfolgt nur, wenn sie mit dem Sicherheits- und Datenschutzmodell von Kaya vereinbar ist, insbesondere mit Blick auf Transportverschlüsselung, Protokollierungsumfang, Anbieterrolle und vertragliche Grundlage. Wenn die trainity GmbH einen Telefonieanbieter selbst als Dienstleister für Kaya beauftragt oder steuert, wird dieser Anbieter in der Subunternehmerliste geführt.
Telefonnummern, öffentliche Praxis-DIDs, Empfangsnummern, SIP-Zugangsdaten und Providerverträge werden von der Praxis gestellt und verantwortet. trainity übernimmt keine Eigentümer- oder Anbieterrolle für Telefonnummern. Kaya unterstützt nur die technische Anbindung und das Routing, soweit dies rechtlich, vertraglich und mit dem Sicherheitsmodell vereinbar ist.
Die trainity GmbH versendet aus ihrer eigenen Infrastruktur nur eigene System-E-Mails, insbesondere Verifizierungs-E-Mails für die erstmalige App-Registrierung und betrieblich erforderliche Kommunikation im Zusammenhang mit eigenen Diensten.
5. Keine Subunternehmer in diesem Sinne
Nicht als externe Subunternehmer gelten selbst betriebene oder lokal installierte Softwarekomponenten, die von Kaya beziehungsweise auf der jeweiligen Praxisinstanz betrieben werden. Dazu gehören insbesondere Basisdienste für Identität, Datenhaltung, Speicher, Schlüsselverwaltung, Realtime-/Telefonie-Funktionen und KI-Verarbeitung auf eigener oder praxisbezogener Infrastruktur. Diese Komponenten sind keine externen Cloud-Dienste Dritter.
Für gesundheitsbezogene LLM-, Speech-to-Text- und Text-to-Speech-Verarbeitung nutzt Kaya im Standardpfad feste, von trainity selbst betriebene Inferenzressourcen über private Verbindungen. Externe KI-, Speech- oder Telefonie-KI-Dienste, die nicht Teil dieses freigegebenen Produktionspfads sind, werden nicht als aktive Subunternehmer für Gesundheitsdaten geführt und sind kein Standard- oder Ersatzpfad für Gesundheitsdaten.
6. Änderungen der Subunternehmerliste
Wir aktualisieren diese Übersicht, wenn neue Subunternehmer hinzukommen, Anbieter entfallen oder sich der Zweck einer Verarbeitung wesentlich ändert. Kunden erhalten die jeweils vertraglich vereinbarten Informationen zu Unterauftragnehmern im Rahmen ihrer Vertrags- und Datenschutzunterlagen. Wesentliche Änderungen im AVV-Scope laufen über den vereinbarten Informations-, Zustimmungs- und Widerspruchsprozess.
Stand: Juli 2026