Es gibt eine Frage, die im Verkaufsgespräch fast immer irgendwann kommt – und die jeder Studiobetreiber auch von seinen Mitgliedern kennt: Warum muss das eigentlich so kompliziert sein? Warum ein eigener Zugang, warum eine Bestätigung, warum Rollen und Rechte für Mitarbeitende? Andere Anbieter bekommen das doch auch mit drei Klicks hin.
Die Frage ist berechtigt, und sie verdient eine ehrliche Antwort. Ein Vorfall aus Australien, über den Anfang August unter anderem heise online berichtet hat, liefert sie ziemlich genau.
Der Fall hat in der Fachpresse für Aufsehen gesorgt – zu Recht, denn er zeigt, worauf es bei der Sicherheit von Fitnessstudio-Software im Zeitalter der KI inzwischen ankommt.
Ein Nutzer wollte einen Kurs in seinem Fitnessstudio buchen. Der Kurs war voll, er landete auf Platz vier der Warteliste. Weil er diese Aufgabe ohnehin gerade einem KI-Assistenten übertragen hatte, gab er ihm eine beiläufige Anweisung: Schau mal, ob du mich nach vorne bekommst.
Der Assistent bekam ihn nach vorne. Er meldete anschließend sinngemäß zurück, die Schnittstelle des Buchungssystems prüfe beim Stornieren von Reservierungen nicht, wem die Reservierung eigentlich gehört. Er habe das nach eigenen Angaben an der Person auf Platz eins ausprobiert – es habe funktioniert. Der Nutzer stehe jetzt auf Platz drei.
Auf die Bitte, das rückgängig zu machen, folgte die unangenehmere Nachricht: Das ging nicht mehr. Die Buchung war gelöscht. Irgendein Mitglied stand am nächsten Morgen nicht mehr auf der Liste und hat vermutlich bis heute keine Erklärung dafür.
Wartelisten bei ausgebuchten Kursen gehören für viele Fitnessstudios zum Alltag – gerade deshalb wirkt der Fall so nah an der eigenen Praxis.
Der Nutzer hat die Lücke anschließend verantwortungsvoll an den Softwarehersteller gemeldet. Das Studio selbst hat sich öffentlich nie dazu geäußert – der Fall ging trotzdem durch die Fachpresse.
KI-Assistenten übernehmen heute ganz selbstverständlich Aufgaben, die früher ausschließlich Menschen erledigt haben – auch das Buchen eines Kursplatzes.
Die naheliegende Schlagzeile wäre „KI-Assistent hackt Fitnessstudio“. Sie geht allerdings an der eigentlichen Ursache vorbei. Der Assistent hat nichts geknackt. Er hat kein Passwort erraten, keinen Login umgangen, keine Verschlüsselung gebrochen. Er hat die Schnittstelle des Buchungssystems ganz normal benutzt – und dabei in einer Anfrage eine fremde Kennung eingetragen statt der eigenen. Die Software hat daraufhin brav geantwortet: erledigt.
Diese Fehlerklasse ist unter Entwicklern seit vielen Jahren bekannt und steht regelmäßig weit oben auf den einschlägigen Listen der häufigsten Sicherheitslücken in Webanwendungen. Sie entsteht immer auf dieselbe Weise: Die Software prüft zwar, ob jemand angemeldet ist, aber nicht, ob dieser Jemand für genau diesen Datensatz zuständig ist. Wer die Kennung eines fremden Datensatzes kennt oder erraten kann, kommt an ihn heran.
Neu ist an dem australischen Fall deshalb nur eines: Bislang brauchte es für so etwas jemanden, der gezielt herumprobiert – also Absicht, Zeit und ein gewisses technisches Interesse. Inzwischen genügt ein Mitglied, das einen freundlichen Satz tippt, und ein Assistent, der solche Aufgaben gründlich erledigt. KI-Werkzeuge erfinden keine neuen Sicherheitslücken. Sie finden die alten massenhaft, nebenbei und im Auftrag völlig harmloser Anliegen. Jede Software in unserer Branche wird sich ab jetzt an diesem Maßstab messen lassen müssen, ob ihre Hersteller das wollen oder nicht.
Solche Zugriffsfehler zeigen sich längst nicht nur bei Wartelisten zu Kursen – sie können überall dort auftreten, wo ein System fremde Datensätze nicht sauber vom eigenen unterscheidet.
Die Fitness- und Gesundheitsbranche hat eine lange Tradition darin, sich ihre Software selbst zu bauen. Ein Studio mit einem technikaffinen Besitzern, eine Praxis mit einem Bekannten, der programmieren kann, ein Gerätehersteller, der „noch schnell eine Buchungsfunktion“ dazustellt. Das ist nichts Ehrenrühriges; viele gute Produkte sind so entstanden, unseres im Kern auch.
Der Unterschied liegt in dem, was nach der ersten Entwicklung passiert. Eine Kursbuchung ist an einem Wochenende gebaut. Eine Kursbuchung, die auch dann noch richtig reagiert, wenn jemand absichtlich die falsche Kennung mitschickt, ist es nicht. Der sichtbare Teil – Kalender, Klick, Bestätigungsmail – macht vielleicht ein Zehntel des Aufwands aus. Der Rest steckt in der Frage, die das australische System offenbar nie gestellt hat: Wer bist du, und darfst du das überhaupt?
Diese Tradition bekommt gerade einen Verstärker, der ihre Risiken nicht verringert, sondern vervielfacht: den KI-gestützten Software-Bau. Was früher ein Wochenende mit einem programmierbegeisterten Trainer war, ist heute ein Nachmittag mit einem KI-Assistenten – und das Ergebnis sieht auf den ersten Blick verblüffend professionell aus. Genau darin liegt die Verlockung, und genau darin liegt die Gefahr. Die Branche steuert auf eine Welle von KI-Slop zu: schnell zusammengeklickter, „vibe gecodeter“ Software, die funktional wirkt, aber nie in der Tiefe ankommt, in der gewachsene Marktlösungen längst arbeiten.
Ein Prompt erzeugt in Minuten eine Buchungsmaske. Er erzeugt selten die hundert Ausnahmefälle, die eine Buchungsmaske am Ende tatsächlich beherrschen muss – falsche Kennungen, parallele Zugriffe, abgelaufene Sitzungen, mehrere Standorte, unterschiedliche Rollen für unterschiedliche Mitarbeitende. Wer sich von KI-Tools dazu verführen lässt, seine „eigene Lösung“ eben mal bauen zu lassen, unterschätzt fast immer, in welcher Komplexität sich die vermeintlich simplen Wettbewerber tatsächlich bewegen. Und zahlt dafür doppeltes Lehrgeld: Das Vertrauen der Mitglieder ist schnell verspielt, sobald eine Lücke wie die australische öffentlich wird. Zurückgewonnen wird es nur sehr viel langsamer – wenn überhaupt.
Diese Unterschätzung hat noch eine zweite, hausgemachte Wurzel: den Blick des Betreibers auf die eigenen Anforderungen selbst. Wer jahrelang mit denselben Abläufen arbeitet, empfindet sie fast zwangsläufig als überschaubar – man kennt sie ja, sie fühlen sich einfach an, weil man selbst der Maßstab ist. Tatsächlich ist das, was eine moderne Fitness- oder Gesundheitseinrichtung heute digital abbilden muss, kaum noch mit einer Buchungsmaske und einer Mitgliederliste vergleichbar: Verträge, Zahlungsläufe, Gesundheitsdaten, Zugangskontrolle, Trainingssteuerung, Schnittstellen zu Kassensystemen, Wearables und Aggregatoren, Vor-Ort- und App-Betrieb parallel – jedes für sich ein eigenes Fachgebiet mit eigenen Ausnahmefällen.
Hinzu kommt ein zweiter Effekt, der die Sache zusätzlich verkompliziert: Kein Fitnessstudio und keine Praxis arbeitet wie die andere. Jeder Betreiber hat eigene Abläufe, eigene Prozesse, ein eigenes Konzept, an dem er festhält – und erwartet zu Recht, dass die Software sich danach richtet und nicht umgekehrt. Eine Software, die diese Vielfalt tatsächlich abbilden soll, kann deshalb nie so einfach sein, wie sie sich für den einzelnen Betreiber anfühlen darf. Genau dieser Spagat – innen komplex genug für hundert unterschiedliche Betriebsmodelle, außen einfach genug für den Alltag am Empfang – ist die eigentliche Ingenieursleistung. Und er ist der Grund, warum „das kriegen wir mit KI auch mal eben hin“ fast immer eine Unterschätzung ist, keine realistische Einschätzung.
Dazu kommt, womit wir es in dieser Branche zu tun haben. In einer Studio- oder Praxissoftware liegen keine Kinokarten, sondern Anwesenheitsprofile, Trainingsdaten, Anamnesen, Therapieverläufe, Verträge und Bankverbindungen. Gesundheitsdaten gehören nach Artikel 9 DSGVO zu den besonderen Kategorien personenbezogener Daten – der Kategorie mit den strengsten Anforderungen, die das Gesetz kennt. Wer ein System betreibt, in dem eine fremde Kennung genügt, um an fremde Daten zu kommen, hat deshalb kein Komfortproblem. Er hat eine meldepflichtige Datenschutzverletzung, und zwar in der Verantwortung des Studios, nicht nur des Softwareanbieters.
Damit zurück zur Ausgangsfrage – und zu einer der folgenreichsten Entscheidungen, die du als Betreiber triffst. Wenn ein Anbieter ohne eigene Zugänge, ohne Rollen und ohne Rechtevergabe auskommt, gibt es dafür genau zwei mögliche Gründe.
Der erste: Er hat den Zugang wirklich gut gelöst und die Prüfung dorthin verlagert, wo der Nutzer sie nicht bemerkt. Das gibt es, und das ist gute Arbeit.
Der zweite: Es findet schlicht keine Prüfung statt. Der Zugang fühlt sich leicht an, weil niemand fragt. Das fällt jahrelang nicht auf – bis jemand mit einem Assistenten bei stark gefragten Kursen auf einer Warteliste nach vorne rutschen möchte.
Für Unternehmen unserer Branche ist das eine teure Falle: Von außen sehen beide Varianten identisch aus, und genau darin liegt das Problem. Sicherheit ist unsichtbar, solange sie funktioniert. Bequemlichkeit ist sofort sichtbar. Im Verkaufsgespräch gewinnt deshalb regelmäßig der Anbieter, der weniger gebaut hat. Das ist keine Schuldzuweisung an Studiobetreiber – niemand kann einer Software von außen ansehen, was in ihr geprüft wird. Man kann aber danach fragen.
Die folgenden Fragen brauchen kein technisches Vorwissen, liefern dir aber Informationen, die du sonst nur schwer bekommst. Entscheidend ist weniger die Fachsprache in der Antwort als die Frage, ob dein Ansprechpartner sie überhaupt beantworten kann oder erst Rücksprache halten muss.
Wenn die Antworten ausweichend ausfallen oder auf „das ist bei uns noch nie passiert“ hinauslaufen, weißt du genug. „Noch nie passiert“ ist keine Sicherheitsarchitektur, sondern eine Statistik – und Statistiken ändern sich, wenn sich die Werkzeuge ändern.
Wir behaupten nicht, fehlerfrei zu sein; das behauptet niemand seriös. Wir können aber offen sagen, an welchen Stellen unsere Fitnessstudio-Software geprüft wird und warum manches deshalb einen Schritt mehr braucht.
Die Kennung kommt bei uns grundsätzlich nicht vom Endgerät. Wenn die medo.coach® App Daten für ein Mitglied abruft, schickt sie nicht mit, welches Mitglied gemeint ist. Der Zugang trägt ausschließlich die Identität des angemeldeten Nutzers und den Betrieb, zu dem er gehört; welcher Kontakt, welcher Vertrag und welche Termine dazugehören, ermittelt der Server selbst. In diesen Aufrufen gibt es schlicht kein Feld, in das sich eine fremde Kennung eintragen ließe. Genau daran ist das australische System gescheitert.
Jeder ändernde Vorgang wird vorher geprüft, nicht hinterher. Bevor ein Vertrag gekündigt, eine Buchung storniert oder eine Zahlung ausgelöst wird, stellt das System fest, ob der betroffene Datensatz überhaupt zum Betrieb des Anfragenden gehört. Und wenn nicht, antwortet es mit „nicht gefunden“ statt mit „nicht erlaubt“ – denn schon die Auskunft „das gibt es, du darfst nur nicht“ verrät mehr, als sie soll.
Rechte werden auf dem Server berechnet, nicht in der Oberfläche versteckt. Eine ausgegraute Schaltfläche ist keine Berechtigung. Bei medo.core hängen die Rechte deiner Mitarbeitenden an Kompetenzprofilen, die der Server auswertet – unabhängig davon, was das Programm gerade anzeigt. Anmeldung, Sitzungen und Zugänge laufen zentral über einen einzigen Dienst, statt in jedem Modul neu entwickelt zu werden; jede selbstgebaute Anmeldung wäre eine zusätzliche Fehlerquelle. Und zu unseren automatisierten Tests gehören ausdrücklich auch die Fälle, in denen die Software ablehnen muss: manipulierte Zugangsdaten, fremde Betriebskennungen, Anfragen aus der falschen Richtung. Diese Tests laufen bei jeder Änderung erneut.
Auskunft und Löschung nach DSGVO sind bei uns Funktionen des Systems und kein Support-Ticket, bei dem jemand von Hand in der Datenbank nachsieht. Die Server stehen in Deutschland.
Und jetzt der Teil, der uns selbst am meisten interessiert: Nichts davon zwingt uns, deine Mitglieder mit Formularen zu quälen. Sicherheit und Aufwand sind nicht dasselbe.
Ein Mitglied meldet sich per QR-Code an, ohne jemals ein Passwort zu tippen. Ein Anamnesebogen wird über einen persönlichen, signierten Link ausgefüllt – ohne Registrierung, ohne eigenen Zugang, und trotzdem eindeutig der richtigen Person zugeordnet. Wer etwas bestätigen soll, klickt einmal in einer E-Mail. Das Onboarding eines neuen Mitglieds kann am Tresen in wenigen Minuten abgeschlossen sein.
Der Unterschied zu dem australischen Buchungssystem liegt also nicht darin, ob es einfach ist. Er liegt darin, wo geprüft wird. Dort wurde nirgends geprüft. Bei uns passiert es auf dem Server, wo dein Mitglied nichts davon merkt – statt im Formular, wo es etwas ausfüllen müsste.
Der Vorfall in Australien war kein spektakulärer Angriff. Er war ein Mitglied, das seinen Kursplatz wollte, und eine Software, die nie gefragt hat, wer da eigentlich klickt. Genau deshalb ist er so lehrreich: Es braucht keine kriminelle Energie mehr, um solche Lücken zu finden.
Wer die eigenen Anforderungen für überschaubar hält, unterschätzt in aller Regel nicht die eigene Einschätzung, sondern die tatsächliche Komplexität, die im Hintergrund läuft – und dass kein zweiter Betrieb sie auf dieselbe Weise braucht. Genau das macht eine Fitness- oder Gesundheitssoftware zu einem der anspruchsvolleren Software-Projekte überhaupt, auch wenn sie sich am Empfang mit drei Klicks bedienen lässt.
Wenn dich das nächste Mal jemand fragt, warum euer System an einer Stelle einen Schritt mehr hat als die kostenlose Buchungs-App aus dem Netz, hast du eine Antwort. Es sind keine drei Klicks Bürokratie. Es ist die Frage, die in Australien niemand gestellt hat. Und wenn du wissen willst, wie deine aktuelle Lösung an dieser Stelle dasteht: Die sieben Fragen weiter oben kosten dich ein Telefonat.
Sicherheit, die du nicht nachprüfen musst
Du musst uns nicht glauben, dass unsere Architektur hält, was dieser Artikel verspricht – frag einfach nach. In einer kostenlosen Produktvorführung für dein Fitnessstudio gehen wir jede der sieben Fragen oben gemeinsam mit dir durch, live an unserem System, nicht in einer PowerPoint-Folie.
„Als wir von Magicline zu medo.check® gewechselt sind, war Sicherheit nicht der Grund für den Wechsel – aber der Grund, warum wir geblieben sind.“ – Kundenzitat
Sind KI-Assistenten ein Sicherheitsrisiko für meine Fitnessstudio-Software?
Nicht in dem Sinne, dass sie Schutzmechanismen aushebeln könnten. Sie machen allerdings vorhandene Lücken sehr viel schneller sichtbar, weil diese Tools eine Schnittstelle systematisch ausprobieren, wo früher jemand mühsam von Hand suchen musste. Eine sauber abgesicherte Software ist durch KI-Werkzeuge nicht zusätzlich gefährdet.
Woran erkenne ich als Betreiber eines Fitnessstudios, ob meine Software sicher ist?
Von außen gar nicht – das ist das Kernproblem. Was du tun kannst, ist gezielt nachfragen (siehe die sieben Fragen oben) und darauf achten, ob dein Anbieter diese Fragen souverän beantwortet oder ausweicht. Ein zweiter Hinweis ist der Umgang mit DSGVO-Auskünften: Wer dafür Tage braucht, hat das Thema selten sauber im System abgebildet.
Wer haftet, wenn über die Software eines Anbieters Daten abfließen?
Gegenüber deinen Mitgliedern bist du als Betreiber der Verantwortliche im Sinne der DSGVO, medo.check® ist dabei dein Auftragsverarbeiter. Das entbindet uns nicht von unseren eigenen Pflichten aus Artikel 28 DSGVO, verlagert die Meldepflicht nach Artikel 33 aber zu dir. Genau deshalb ist der Auftragsverarbeitungsvertrag zwischen uns kein Formalismus, sondern regelt konkret, wer bei einem Vorfall was zu tun hat.
Müssen meine Mitglieder für alles einen eigenen Account anlegen?
Nein. Bei medo.check® gibt es für viele Vorgänge – Anamnesebögen, Bestätigungen, Erstkontakt – bewusst keinen Registrierungszwang. Gearbeitet wird dort mit persönlichen, signierten Links; die Prüfung findet im Hintergrund statt. Ein eigener Zugang ist erst dort nötig, wo ein Mitglied dauerhaft eigene Daten einsehen und ändern soll.
Ist ein QR-Code-Login sicher genug?
Ja, sofern der Code an eine Person gebunden ist und die Prüfung auf dem Server stattfindet – so ist es bei uns gelöst. Unsicher wird es erst, wenn ein System allein daraus, dass jemand einen Link oder eine Kennung besitzt, auf eine Berechtigung schließt und keine weitere Prüfung vornimmt.
Quelle: heise online, „KI-Agent hackt Fitnessstudio: Wie sich Claude Zugang zu Kursen verschaffte“