Ein Forschungsinstitut entwickelt eine Plattform, auf der Wissenschaftler Papiere austauschen, Daten gemeinsam auswerten oder Software erproben können. Zunächst läuft das Projekt im Kollegenkreis. Dann kommen externe Hochschulen hinzu, später Unternehmen. Spätestens jetzt trägt das Institut Verantwortung für Inhalte, Daten, Verfügbarkeit und Sicherheit eines Dienstes, dessen rechtliche Konstruktion oft noch aus einer Datenschutzerklärung und einigen technischen Nutzungsregeln besteht.
Doch das reicht nicht: Wer eine digitale Plattform betreibt, stellt keine neutrale Infrastruktur bereit. Er organisiert fremde Kommunikation, verarbeitet Daten, entscheidet über Zugänge, moderiert Inhalte und verspricht eine technische Leistung. Wird die Lösung für Dritte geöffnet oder als Produkt angeboten, kommen Vertragsrecht, Plattformregulierung und Produkthaftung hinzu. Gerade wissenschaftliche Einrichtungen unterschätzen diesen Rollenwechsel, weil das Projekt aus Forschung, Lehre oder Technologietransfer entstanden ist. Das Recht interessiert sich für diese Entstehungsgeschichte nur begrenzt.
Ich berate seit Jahren solche Projekte mit dem Ziel, eigene Plattformen zu schaffen, speziell von Universitäten betrieben. Vor der Öffnung einer Plattform für externe Nutzer sollten Betreiberrolle, Diensteeinordnung, Datenflüsse, Rechtekette, Moderationsverfahren, Sicherheitskonzept und Vertragsstruktur gemeinsam geprüft werden. Bei bereits laufenden Angeboten empfiehlt sich eine Bestandsaufnahme, bevor neue Partner, Funktionen oder Vertriebsmodelle hinzukommen.
Der Betreiber trägt Verantwortung
Am Anfang steht eine Frage, die banal klingt und selten sauber beantwortet wird: Wer betreibt die Plattform?
Ein Institut besitzt häufig keine eigene Rechtspersönlichkeit. Vertragspartner, datenschutzrechtlich Verantwortlicher und Diensteanbieter ist dann die Hochschule oder eine andere Trägerorganisation. Das Projektteam entwickelt und administriert die Plattform, kann aber weder wirksam Verträge schließen noch sämtliche rechtlichen Pflichten selbst erfüllen. Werden Leistungen über eine Ausgründung, eine Projektgesellschaft oder einen Forschungspartner angeboten, verschiebt sich die Verantwortung erneut.
Diese Zuordnung muss vor dem Start feststehen. Sie bestimmt, wer Nutzungsverträge schließt, Beschwerden bearbeitet, Datenschutzrechte erfüllt, Sicherheitsvorfälle meldet und für Schäden einsteht. Unklare Zuständigkeiten verschwinden nicht im Organigramm. Sie treten beim ersten Konflikt offen zutage.
Auch das Geschäftsmodell gehört auf den Tisch. Eine Plattform für Mitglieder eines geschlossenen Forschungsverbunds ist rechtlich anders zu behandeln als ein öffentliches Repositorium. Wer Zugänge an Unternehmen verkauft, Speicherplatz bereitstellt oder eine entwickelte Lösung als Softwaredienst vertreibt, handelt zudem wirtschaftlich. Für eine öffentlich finanzierte Einrichtung stellen sich dann Fragen des Haushalts-, Zuwendungs- und Beihilferechts. Ein Forschungsetikett ersetzt keine marktgerechte Kalkulation.
Der DSA erreicht Forschungsplattformen
Sobald Nutzer eigene Inhalte hochladen, speichert die Plattform Informationen in ihrem Auftrag. Damit rückt sie in den Anwendungsbereich des Digital Services Act. Bei einer Veröffentlichung für einen unbestimmten Personenkreis kann sie über den Hostingdienst hinaus als Online-Plattform einzuordnen sein. Die Bezeichnung als Repositorium, Forschungsumgebung oder Community ändert daran nichts.
Das Haftungsprivileg für fremde Inhalte bleibt praktisch entscheidend. Der Betreiber haftet nicht automatisch für jedes rechtswidrige Dokument, jede Abbildung oder jede Äußerung eines Nutzers. Der Schutz endet jedoch dort, wo er konkrete Kenntnis von einer rechtswidrigen Information erhält und nicht zügig reagiert. Eine Meldung muss deshalb eine festgelegte Prüfung auslösen. Ein Postfach, das nur gelegentlich jemand durchsieht, ist kein Verfahren.
Noch gefährlicher ist das Zu-eigen-Machen fremder Inhalte. Prüft das Institut Beiträge redaktionell, versieht sie mit eigenen Empfehlungen oder präsentiert sie so, dass sie als eigenes Angebot erscheinen, kann aus fremder Information ein eigener Inhalt werden. Wissenschaftliche Qualitätssicherung und rechtliche Distanz geraten hier in Spannung. Eine fachliche Kuratierung ist möglich, muss aber in Rollen, Darstellung und Nutzungsbedingungen sauber von einer inhaltlichen Übernahme getrennt werden.
Der DSA verlangt je nach Dienst weitere Vorkehrungen, darunter Kontaktstellen, verständliche Nutzungsbedingungen, Begründungen für Moderationsentscheidungen und ein Meldeverfahren für rechtswidrige Inhalte. Kleine Einrichtungen profitieren von einzelnen Ausnahmen. Eine Befreiung von jeder Organisationspflicht gibt es nicht. Wer Inhalte sperren kann, muss festlegen, nach welchen Regeln er dies tut.
Urheberrecht und wissenschaftliches Teilen
Ein Dokument ist wissenschaftlich relevant? Daraus folgt kein Recht, es öffentlich nach Gutdünken bereitzustellen: Autoren haben Verlagen häufig ausschließliche Nutzungsrechte eingeräumt. Dann kann selbst der eigene Aufsatz nicht ohne Weiteres in ein Repositorium hochgeladen werden. Das gesetzliche Zweitveröffentlichungsrecht hilft nur unter seinen Voraussetzungen. Es erfasst weder jede Publikation noch jede Fassung und erlaubt keine pauschale Freigabe sämtlicher Beiträge nach Ablauf einer beliebigen Wartezeit.
Die Plattform braucht daher eine klare Rechtekette. Der Nutzer muss über die erforderlichen Rechte verfügen und der Betreiber benötigt eine Lizenz, die Speicherung, technische Vervielfältigung, öffentliche Zugänglichmachung, Formatumwandlung und Sicherungskopien abdeckt. Bei Abbildungen, Datensätzen, Karten oder eingebetteten Materialien können weitere Rechte betroffen sein. Eine Creative-Commons-Kennzeichnung beantwortet die entscheidende Vorfrage nicht: Durfte der Hochladende diese Lizenz überhaupt erteilen?
Eine Garantie in den Nutzungsbedingungen löst das Problem ebenfalls nicht. Sie schafft einen vertraglichen Rückgriff, verhindert aber weder Unterlassungsansprüche noch die Pflicht, einen beanstandeten Inhalt zu prüfen. Gute Plattformregeln verbinden deshalb Rechtezusicherung, nachvollziehbare Meldestrukturen und ein Verfahren, das den betroffenen Nutzer vor einer endgültigen Löschung anhört, soweit kein sofortiges Handeln geboten ist.
Forschungsdaten sind nicht frei
Forschungsdaten wirken auf den ersten Blick sachbezogen. Tatsächlich enthalten sie häufig personenbezogene Informationen, etwa über Probanden, Patienten, Beschäftigte, Autoren oder Nutzer der Plattform. Hinzu kommen Kennungen, Protokolldaten, IP-Adressen und Angaben über Downloads oder Zusammenarbeit. Aus einem Dokumentenspeicher wird schnell ein System zur Beobachtung wissenschaftlichen Verhaltens.
Das sogenannte Forschungsprivileg ist kein Generalschlüssel. Datenschutzrechtliche Erleichterungen für wissenschaftliche Forschung setzen eine echte Forschungsfunktion, geeignete Schutzmaßnahmen und eine belastbare Zweckbestimmung voraus. Die Verwaltung von Benutzerkonten, die Reichweitenmessung oder der Vertrieb eines Softwaredienstes werden nicht schon deshalb zur Forschung, weil eine Hochschule die Plattform betreibt.
Vor der Entwicklung muss geklärt werden, welche Daten zu welchem Zweck verarbeitet werden und wer darüber entscheidet. Mehrere Hochschulen können gemeinsam verantwortlich sein. Ein externer Cloudanbieter verarbeitet Daten häufig im Auftrag. Nutzt er Informationen für eigene Zwecke, reicht ein Vertrag zur Auftragsverarbeitung nicht. Die Rollen folgen der tatsächlichen Entscheidungsmacht, nicht der Überschrift des Vertrags.
Besondere Kategorien personenbezogener Daten verschärfen die Anforderungen. Bei medizinischen, biometrischen oder sozialwissenschaftlichen Datensätzen kann eine Datenschutz-Folgenabschätzung erforderlich sein. Pseudonymisierung mindert Risiken, macht aus personenbezogenen Daten aber keine anonymen Daten. Echte Anonymisierung verlangt, dass eine Zuordnung mit vertretbaren Mitteln nicht mehr möglich ist. Das scheitert bei Forschungsdaten häufiger, als Projektverantwortliche annehmen.
Eigene Cloud = eigene Verantwortung
Viele Plattformen laufen auf fremder Infrastruktur, was technisch vernünftig ist … und rechtlich anspruchsvoll: Der Cloudanbieter übernimmt Betrieb, Wartung und Teile der Sicherheit. Die rechtliche Verantwortung des Plattformbetreibers wandert jedoch nicht mit den Servern ab. Das Institut muss den Anbieter auswählen, seine Schutzmaßnahmen prüfen und vertraglich festlegen, was bei Ausfällen, Sicherheitsvorfällen, Datenverlust oder Vertragsende geschieht.
Cloud-Verträge dürfen sich nicht auf Verfügbarkeit und Preis beschränken. Entscheidend sind Leistungsbeschreibung, Reaktions- und Wiederherstellungszeiten, Datensicherung, Verschlüsselung, Unterauftragnehmer, Änderungsrechte, Kontrollmöglichkeiten und Datenexport. Wer diese Punkte erst bei einem Anbieterwechsel verhandelt, verhandelt aus einer schlechten Position.
Besonders heikel sind Plattformen, die selbst als SaaS, PaaS oder gehostete Lösung an Dritte vertrieben werden. Das Institut verspricht seinem Kunden dann eine Leistung, die es teilweise von einem Voranbieter bezieht. Beide Vertragsstufen müssen zusammenpassen. Eine Verfügbarkeit von 99,9 Prozent lässt sich schwer garantieren, wenn der eigene Infrastrukturvertrag weniger zusagt. Gleiches gilt für Wiederherstellungszeiten, Löschfristen und Support.
Ein Exit-Konzept gehört deshalb an den Anfang. Daten müssen in einem dokumentierten, nutzbaren Format herausgegeben werden können. Schnittstellen, Metadaten und Berechtigungsstrukturen dürfen nicht im System zurückbleiben. Ohne diese Regeln wird technische Bequemlichkeit zur dauerhaften Abhängigkeit.
Sicherheit beginnt mit Zuständigkeit
Wissenschaft und Forschung sind attraktive Angriffsziele. Sie verfügen über unveröffentlichte Ergebnisse, personenbezogene Datensätze, Rechenkapazitäten und internationale Zugänge. Zugleich arbeiten viele Einrichtungen mit wechselnden Projektteams und einer großen Zahl externer Konten. Das erleichtert Zusammenarbeit. Es erleichtert auch Angriffe.
IT-Sicherheit ist deshalb keine Klausel für die Datenschutzerklärung. Der Betreiber braucht ein Sicherheitskonzept, das den Dienst über seinen gesamten Lebenszyklus erfasst. Dazu zählen Rollen- und Berechtigungskonzepte, Mehrfaktorauthentifizierung, Protokollierung, Patchmanagement, Datensicherung, Wiederherstellung und ein Verfahren für Sicherheitsvorfälle. Die Verantwortlichen müssen wissen, wer einen kompromittierten Zugang sperrt, wer Nutzer informiert und wer über eine Abschaltung entscheidet.
Besondere Aufmerksamkeit verdienen Abhängigkeiten von Bibliotheken und anderen Softwarekomponenten. Plattformen bestehen selten nur aus eigenem Code. Eine Schwachstelle in einer nicht mehr gepflegten Bibliothek kann den gesamten Dienst betreffen. Wer Software an Dritte liefert, muss deshalb seine Komponenten kennen, Sicherheitsmeldungen verfolgen und Aktualisierungen bereitstellen können. Ein Softwareverzeichnis oder eine Software Bill of Materials ist dafür kein Selbstzweck, sondern eine Voraussetzung geordneter Produktpflege.
Die gesetzlichen Anforderungen steigen. Je nach Größe, Einordnung und Funktion der Einrichtung können Vorgaben zur Cybersicherheit und zur Behandlung erheblicher Vorfälle hinzukommen. Verträge müssen diese Pflichten abbilden, dürfen sie aber nicht ersetzen. Ein Provider kann bei der Erkennung helfen. Melde- und Leitungsverantwortung bleiben bei der verpflichteten Organisation.
Software wird zum Produkt
Solange ein Forschungsprototyp intern verwendet wird, lassen sich Mängel oft im Projektbetrieb auffangen. Mit der Abgabe an Dritte ändert sich der Maßstab. Der Nutzer erwartet eine definierte Funktion, Sicherheitsaktualisierungen und verlässlichen Support. Aus dem Forschungsprojekt wird ein Produkt.
Die neue europäische Produkthaftung bezieht Software ausdrücklich ein und erfasst auch verbundene digitale Dienste, soweit sie für die Funktion eines Produkts erforderlich sind. Fehlerhafte Updates, unterlassene Sicherheitsaktualisierungen und unzureichende Cybersicherheit können deshalb haftungsrechtlich Gewicht erhalten. Für Anbieter eigener Plattformlösungen ist das kein fernes Zukunftsthema. Entwicklungsdokumentation, Tests und Updateprozesse müssen heute so organisiert werden, dass sich später erklären lässt, welche Entscheidungen getroffen wurden.
Bei Kunden aus der öffentlichen Hand kommen Vergabe- und Haushaltsfragen hinzu. Werden öffentliche Stellen oder Unternehmen bedient, entscheiden ferner Haftungsbegrenzungen, Service Levels und Auditmöglichkeiten über die wirtschaftliche Tragfähigkeit. Eine Plattform lässt sich nicht seriös bepreisen, solange unbekannt ist, welche Betriebs- und Einstandspflichten der Anbieter übernimmt.
Daneben bleibt das Vertragsrecht. Bei einer dauerhaft bereitgestellten Softwareleistung schuldet der Anbieter keine einmalige Übergabe, sondern einen funktionierenden Dienst über die Vertragslaufzeit. Leistungsumfang, Wartung, Weiterentwicklung und Support müssen getrennt beschrieben werden. Unbestimmte Versprechen wie „fortlaufende Verbesserung“ helfen niemandem. Sie schaffen Erwartungen, ohne den geschuldeten Zustand festzulegen.
Code braucht klare Rechte
Universitäre Softwareprojekte leben von personellen Wechseln. Beschäftigte, studentische Hilfskräfte, Doktoranden, freie Entwickler und Projektpartner arbeiten am selben Code. Wer später Nutzungsrechte einräumen oder die Lösung vertreiben will, muss nachweisen können, dass er hierzu befugt ist.
Der urheberrechtliche Schutz von Software konzentriert sich auf die geschützten Ausdrucksformen des Programms. Funktionalitäten, Ideen und technische Aufgabenstellungen sind davon zu unterscheiden. Moderne Plattformen bestehen allerdings aus mehr als einer einzelnen Quellcodedatei. Frameworks, Bibliotheken, Schnittstellen, Datenbankstrukturen und erzeugte Komponenten bilden ein Geflecht verschiedener Rechte und Lizenzen.
Open-Source-Software ist dabei kein kostenfreier rechtsfreier Raum. Permissive Lizenzen verlangen häufig Hinweise und Lizenztexte. Copyleft-Lizenzen können weitergehende Pflichten auslösen. Bei netzbasierten Diensten verdienen Lizenzen besondere Aufmerksamkeit, die bereits an die Nutzung über ein Netzwerk anknüpfen. Wer erst vor dem Vertrieb eine Lizenzprüfung beginnt, kann feststellen, dass sich das geplante Modell mit dem vorhandenen Code nicht vereinbaren lässt.
Rechteklärung ist daher Teil der Entwicklung. Beiträge müssen Personen und Vertragsgrundlagen zugeordnet, Drittkomponenten erfasst und Lizenzpflichten dokumentiert werden. Das wirkt pedantisch, solange das Projekt klein ist. Beim Technologietransfer entscheidet genau diese Dokumentation darüber, ob überhaupt ein verkehrsfähiges Produkt existiert.
Daten brauchen Ordnung
Plattformbetreiber sprechen gern von ihren Daten. Juristisch ist diese Sprache zu grob. Daten gehören niemandem in demselben Sinn wie eine körperliche Sache. Ihre Nutzung kann aus Datenschutzrecht, Urheberrecht, Datenbankrecht, Geschäftsgeheimnisschutz, Vertrag oder gesetzlichen Zugangsrechten folgen.
Datenlizenzen müssen deshalb ihren Gegenstand präzise beschreiben. Rohdaten, angereicherte Daten, Metadaten, Auswertungsergebnisse und nutzergenerierte Inhalte sind auseinanderzuhalten. Der Vertrag sollte regeln, wer welche Daten eingeben darf, wer sie für welche Zwecke auswertet und was nach Vertragsende geschieht. Pauschale Klauseln, nach denen „alle Daten“ zur Produktverbesserung verwendet werden dürfen, sind rechtlich angreifbar und im Wissenschaftsbetrieb politisch kaum vermittelbar.
Der Data Act verschiebt die Gewichte bei Daten, die durch vernetzte Produkte und verbundene Dienste erzeugt werden. Für reine Dokumentenplattformen steht er nicht im Zentrum. Entwickelt ein Institut jedoch Lösungen für Laborgeräte, Sensorik oder andere vernetzte Systeme, müssen Datenzugang und Vertragsgestaltung früh berücksichtigt werden. Ein technisches Design, das gesetzlich geschuldete Datenzugänge nicht ermöglicht, lässt sich später nur teuer korrigieren.
Plattformrecht ist Architektur
Der verbreitete Fehler liegt in der Reihenfolge. Ein Projekt entwickelt die Technik, gewinnt erste Nutzer und sucht anschließend nach Nutzungsbedingungen. Dann sind Rollen, Datenflüsse, Moderation und Abhängigkeiten längst festgelegt. Der Vertrag soll Entscheidungen reparieren, die im Code getroffen wurden.
Wer eigene Plattformen anbietet, betreibt ein dauerhaftes Regelwerk aus Technik, Vertrag und Organisation. Forschungseinrichtungen können das leisten. Sie müssen nur aufhören, den Betrieb als Nebenprodukt der Entwicklung zu behandeln.
Doch das gelingt selten: Rechtliche Beratung wirkt bei Plattformen am stärksten vor dem produktiven Betrieb und vor dem Vertrieb. Sie klärt Betreiberrollen, ordnet Daten und Inhalte zu, strukturiert Meldewege, prüft Cloud- und Lizenzabhängigkeiten und übersetzt das Geschäftsmodell in belastbare Verträge. Das schützt die Einrichtung vor Haftung. Ebenso wichtig ist der wirtschaftliche Effekt: Eine sauber dokumentierte Plattform lässt sich leichter erweitern, lizenzieren, ausgliedern oder gemeinsam mit Partnern betreiben.
Als Lehrbeauftragter an der FH Aachen (Wirtschaftsstrafrecht und IT-Compliance) doziert er zu KI-Kompetenz und strategischem Denken und publiziert regelmäßig in straf- und IT-rechtlichen Fachaufsätzen sowie in der Kommentierung im BeckOK StPO (IT-Strafprozessrecht, digitale Beweismittel). Überdies beschäftigt er sich mit den rechtsstaatlichen Grundlagen moderner Arbeit und moderner Technologie – insbesondere mit der Frage, wie Bewusstsein, Verantwortung und Cybersecurity-Awareness im KI-geprägten Alltag Freiheitsräume und europäische Rechtsprinzipien sichern.
Wir übernehmen im IT-Recht und Strafrecht nur bestimmte Bereiche. So im IT-Recht allein im Softwarerecht mit darauf bezogenem IT‑Vertragsrecht und Lizenzrecht sowie rund um Cybersicherheit. Im Strafrecht übernehmen wir ausschiesslich Strafverteidigungen in Bereichen, auf die wir uns spezialisieren: Jugendstrafrecht, Sexualstrafrecht, BtMG/KCang/AMG, Medizinstrafrecht, Cybercrime & Medienstrafrecht, Wirtschaftsstrafrecht mit Schwerpunkten Arbeitsstrafrecht und Steuerstrafrecht