EU Data Act: Zwischen Datenfreiheit und Geschäftsgeheimnissen

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Gil: Herzlich willkommen zu einer neuen Ausgabe unseres Podcasts CTO Need to Know. Mein Name ist Gil Bret, und wir werden uns heute mit dem EU Data Act befassen. Ich freue mich ganz besonders über unseren Gast, den ich für das Thema eingeladen habe, denn ich durfte ihn dieses Jahr auf dem Tech Radar Festival in Köln erleben, wie er den AI Act sehr praxisorientiert, sehr unterhaltsam und sehr spannend eingeordnet hat. Für mich war klar, als wir uns entschieden haben, dass der EU Data Act unser nächstes Thema beim Podcast sein wird, dass ich ihn als unseren Gast einladen möchte. Jens, ich würde mich freuen, wenn du dich einmal vorstellen würdest für unsere Zuhörer, die dich vielleicht noch nicht kennen.

Jens: Zunächst herzlichen Dank, dass ich zum Gespräch eingeladen bin. Ich freue mich, das Thema aufbereiten zu dürfen. Zu mir, in ein paar wenigen Worten: Ich bin Rechtsanwalt, Fachanwalt für IT-Recht, Datenschutz-Auditor, IT-Compliance Manager, Compliance Officer – das sind die Titel, die man auf der Brust tragen darf. Ich bin in diesem Geschäft seit 25 Jahren tätig, habe die Cloud-Entwicklung mitgenommen, ursprünglich das Internet überhaupt, dass es funktioniert, das World Wide Web mit allen seinen lustigen Dingen, und jetzt ist die dritte Welle, wo die EU das Füllhorn der Regelungen aufmacht und über uns auskippt. Insofern begegne ich der Situation auch mit einer gewissen Gelassenheit, aber du hast recht, der EU Data Act ist komplexer, als man denkt. Denn entweder hat man zunächst das Gefühl, da steckt so viel drin und es überrascht, wie wenig, oder umgekehrt. Deswegen ist es schön, dass wir darüber sprechen können.

Gil: Super. Komplex, das ist richtig. Er ist auch noch gar nicht so lange in Kraft getreten. Das war im September dieses Jahres. Angekündigt wurde er, ich glaube, Ende 2023, da war das schon absehbar. Ich habe im Vorfeld Kolleginnen, Kollegen, Partner, Freunde, auch die Familie gefragt, was sie am Data Act umtreibt. Die habe ich heute mitgebracht, und es sind nicht wenige. Ich bin gespannt, ob wir sie alle durchgehen werden, aber ich fand sie alle spannend, und man sieht auch an der Spannbreite der Fragen, dass es ein, wie du eben schon so schön gesagt hast, komplexes Thema ist. Bevor wir mit den Fragen einsteigen, möchte ich mit einer Zahl beginnen: Bei der Recherche zum Act findet man recht schnell auf der Webseite der EU die Aussage, dass man sich von der Umsetzung bis 2028 – und das ist schon in drei Jahren – bis zu 270 Milliarden Euro erhofft, die man durch diesen Act innerhalb der EU generieren kann. Das ist eine große Zahl. Ich bin selbst etwas überrascht, wie man mit einer Regulierung auch zu einem wirtschaftlichen Wachstum kommen möchte. Ganz ehrlich, kannst du das für mich einordnen? Woher kommt nicht unbedingt die Zahl, aber was verspricht man sich davon? Wie kann das sein?

Jens: Was soll ich sagen? Die Zahl ist erschreckend groß, und als Jurist tut man sich mit Zahlen immer schwer. Judex non calculat. Deswegen haben wir alle Jura studiert, weil wir nicht rechnen können. Entschuldigung, liebe Kollegen, ich kann das nicht sagen. Mir treibt das ein Schmunzeln ins Gesicht, denn wie du sagst, es ist eine Regulierung. Es ist kein Innovationsförderungsgesetz, sondern auch kein Gesetz, das staatliche Investitionen freigibt oder dergleichen. Sondern wir haben einen Rechtsakt, der im Kern klassisch kartellrechtlich oder das Gesetz gegen Wettbewerbsbeschränkungen flankiert. Er greift Überlegungen auf, die wir Ende der 90er, Anfang der 2000er Jahre bei der Deregulierung von regulierten Märkten wie Post, Telekommunikation, Eisenbahn hatten. Bei letzterer wissen wir, es hat nicht funktioniert. Im Bereich Telekommunikation hat es ganz gut funktioniert, und ich tue mich etwas schwer, Neues zu generieren, weil dadurch ja etwas Neues entstehen müsste. Wenn man sich die Regelungen anschaut, sind die alle darauf gerichtet, dass man weiteren Playern in dem Markt, der reguliert wird – wir haben ja zwei: das Internet of Things einerseits und Kapitel 6, das Cloud Switching – eigentlich schon zwei Dinge mit drin, auf die man gar nicht erst kommt. Beim Cloud Switching kann man es vielleicht am ehesten machen. Es soll das Wechseln von einem Dienst zu einem anderen ermöglichen. Wenn ich als Nachfrager 100.000 € in Cloud Services ausgebe und die dir zahle und jetzt ein Cloud Switching von dir weg kann, um die 100.000 € jemand anderem zu zahlen, sehe ich noch nicht so ganz, wie dadurch mehr entsteht. Die Überlegung beim IoT: Wir kommen an Daten, die originär derjenige hat, der die digitalen Produkte oder die verbundenen Dienste anbietet, und die werden auf Verlangen des Nutzers weiteren zur Verfügung gestellt, die dann auch Geschäftsmodelle anbieten können. Das ist ein Bereich, wo ich sagen kann, da kann ich mir vorstellen, dass auf der Grundlage derselben Daten weitere Geschäftsmodelle angeboten werden können. Hier haben wir ein Potenzial für neues Geschäft. Anyway, ich muss auch erst einmal – ich als derjenige, dessen Daten jetzt andere kriegen – das Geld haben, um die weiteren Services beauftragen zu können. Deswegen, netter Ansatz, ich habe es auch recherchiert, ich finde auch keine rechte Begründung, wie es berechnet wurde. Vielleicht ist das das Prinzip Hoffnung: Wenn man eine groß genug Zahl in den Raum stellt, dann kommt wenigstens irgendetwas dabei heraus. Ich bin kein Zyniker. Ist mir nach.

Gil: Nein, das kann ich gut nachvollziehen. Ich war bei der Zahl auch so überrascht. Ich habe es als juristisches Marketing für mich abgespeichert, um das Ganze vielleicht spannender oder interessanter zu machen. Genau.

Jens: Guter Aspekt. So greife ich die Zahl zukünftig auf. Ich erzähle Ihnen nichts mehr dröge über die Anforderungen des Data Acts, sondern von dem Schöpfer der 270 Milliarden neuem Geschäft. Das mache ich jetzt. Eine gute Idee, nehme ich mit.

Gil: Sehr gut. Dem gegenüber steht eine andere Zahl, die sicherlich jedes Unternehmen für sich selbst bewerten muss, nämlich wie viel es investieren muss, um die Data Act Compliance umzusetzen. Da würde mich natürlich gerade aus deiner Praxis-Brille interessieren: Sollten Unternehmen jetzt eine Standard-Compliance-Plattform wählen oder sollten sie in eine eigene Entwicklung investieren? Das ist immer die Frage selbst, also die klassische Build-versus-Buy-Entscheidung, wenn es um eine technische Umsetzung geht. Wie siehst du das? Wie ist deine Einordnung?

Jens: Ich glaube, es gibt zwei Aspekte, deswegen würde ich die Frage zweiteilig beantworten. Der erste Punkt ist: Lösungen von der Stange passen nur für Unternehmen von der Stange.

Gil: Jens: Deswegen tue ich mich immer etwas schwer. Wir haben hier auch nichts, was simpel ist, bei den Daten, auf die zugegriffen werden soll. Das heißt, wir haben in der Praxis recht spezifische Gegebenheiten, die natürlich über eine Zeit hinweg gewachsen sind, an die jetzt vermittelt durch eine rechtliche Lösung angedockt wird. Das heißt, es ist ganz schwer aus meiner Sicht, dort wirklich zu sagen, ich habe hier ein Produkt von der Stange. Man wird das mit großer Besorgfalt angehen. Ich hätte jetzt fast gesagt, mit Vorsicht, das möchte ich nicht sagen, aber mit großer Sorgfalt angehen und zumindest nicht glauben, dass wenn ich da irgendwas kaufe, ich es habe. Das ist das eine: ‘Lösungen von der Stange gibt es nur für Unternehmen von der Stange’ ist bei mir ein geflügelter Satz, den wir haben, weil wir es aus der Rechtsberatung eben auch so sehen. Das andere ist: Wir haben hier auch eine ganz andere Rahmenbedingung als vielleicht bei der Datenschutzgrundverordnung oder beim AI Act. Bei der Datenschutzgrundverordnung hast du viele Dokumentationen zu erbringen: Verzeichnis von Verarbeitungstätigkeiten, Hinweise und dergleichen. Beim AI Act auch Konformitätsbescheinigungen, Produkthandbücher und so weiter. Viel Paperwork, würde ich sagen. Die Grundüberlegung beim Data Act ist, wenn es um das Sharen von Daten geht – im Kapitel 1, Kapitel 2 ist es dann Data Access by Design. Da geht es um die Ermöglichung eines technischen Zugangs des Nutzers, sodass er die Daten direkt ausgeleitet bekommt. Oder wenn das nicht geht, eine Möglichkeit, dass ihm die Daten vom Verpflichteten in Echtzeit kontinuierlich zur Verfügung gestellt werden. Da muss ich natürlich Schnittstellen finden, Schnittstellen bauen, die absichern, und da gibt es sicherlich auf den unterschiedlichen Plattformen, die großen Plattformanbieter bieten ja auch schon Lösungen mit an. Dazu gibt es etwas. Aber wie bei der Datenschutzgrundverordnung, wo ich mir ein Dokumentationstool oder ein Einwilligungsmanagement-Tool zulege, das sehe ich da noch nicht, weil die Industrie auch zu unterschiedlich gewachsen ist. Gleich beim Cloud Switching: Vertragstexte, wir wissen nicht, was wir reinschreiben müssen, aber das technische Ermöglichen des Wechsels. Da werden wir Parallelitäten und Standardisierungen haben, aber aus den Lösungen und Plattformen heraus, die wir nutzen, nicht von extern nach dem Motto: ‘Ich habe da mal eine Funktionalität und damit könnt ihr.’ Ich tue mich da etwas schwer mit der Vorstellung.

Gil: Danke für die Einordnung. ‘Lösungen von der Stange sind für Unternehmen von der Stange’ – das muss ich mir merken, das finde ich gut. Du hast aber gerade ein Dilemma angesprochen, und das ist auch eine der zentralen Fragen, die, glaube ich, gerade insbesondere CTOs umtreibt. Jetzt muss ich Datenzugang für Nutzer gewähren. Steht das nicht irgendwie im Konflikt mit der Aufgabe, Geschäftsgeheimnisse zu schützen? Wie sollte ich mich da jetzt als Entscheider verhalten? Zum einen das Gesetz korrekt umsetzen, aber zum anderen natürlich die Interessen meines Unternehmens sicherstellen?

Jens: Du hast ja Sharing kartellrechtlich gegen Vendor Lock, und Innovationsförderung ist immer eine tolle Idee. Zwei Gegenplayer stehen dem entgegen. Zum Datenschutzrecht kommen wir sicher nachher noch. Der Schutz von Geschäftsgeheimnissen: Der Data Act will nicht die Förderung der Aufgabe von Geschäftsgeheimnissen fördern. Geschäftsgeheimnisse sind anerkannt und sollen auch geschützt werden. Um etwas technischer, juristisch technischer zu werden: Wir haben die drei grundlegenden Zugangsregelungen in Artikel 3, Artikel 4 und Artikel 5. Das sind drei Zugangsansprüche, die dann mit viel Gedöns abgesichert werden. Deswegen ist das Ding eigentlich simpel gestrickt. Artikel 3 regelt Data Access by Design. Das heißt, der Nutzer soll selbst direkt auf die Daten zugreifen können, die er selbst generiert, eins zu eins. Vom Grundansatz her habe ich da gar keinen Zugang zu Geschäftsgeheimnissen. So ist das Konstrukt aufgebaut. Anders ist es in den Konstellationen, bei denen ich Daten gemäß Artikel 4 an den Nutzer selbst ausleite oder Daten gemäß Artikel 5 auf Verlangen des Nutzers an einen Dritten ausleite. Dort ist sehr genau definiert, welche Daten ausgeleitet werden müssen. Es steht auch drin, dass die Metadaten mitgeliefert werden müssen, die es ermöglichen, mit den ausgelieferten Daten überhaupt etwas anzufangen. In den Regelungen der Artikel 4 und 5 und auch in den fortfolgenden Regelungen sind sehr umfassende Bestimmungen zum Schutz von Geschäftsgeheimnissen im Gesetz enthalten. Es gibt mehrere Absätze, die sich mit der Anerkennung und dem Schutz von Geschäftsgeheimnissen beschäftigen, sowie Regelungen dazu, wie die Beteiligten miteinander umzugehen haben, wenn sie sich nicht einig sind, ob ein Geheimnis geschützt ist oder nicht. Deswegen haben wir Schutz, aber ganz klar keine klare Definition, was darunterfällt. Das bedeutet für mich aus Sicht des Verpflichteten, der Daten herausgeben muss, dass ich die Datenkategorien, die ich potenziell herausgebe, erstmal für mich selbst klastern muss. Daten, die ohnehin frei zugänglich sind, Daten, die nur dadurch entstehen, dass der Nutzer die Maschine nutzt, Daten, die Rückschlüsse zulassen – ich klastere sie, um die Sensitivität und Schutzbedürftigkeit, nicht datenschutzrechtlich, sondern unternehmensseitig, zu definieren. Dann gehe ich erstmal eine restriktive Politik an. Ich gehe davon aus, dass ich dem Kunden das liefere, was er unbedingt braucht. Dann soll er mir erklären, warum das im Sinne des Gesetzes nicht reicht, und dann wird man das ausdiskutieren oder ausverhandeln. Der erste Schritt ist, ich muss es identifizieren, einordnen und bewerten. Dann gehe ich das eher konservativ an, und dann schaut man, wie man sich am Ende des Tages austariert.

Gil: Wir werden später noch mal darauf eingehen, aber ich glaube, da schwingt auch die Sorge von Unternehmen mit: Wenn ich diese Daten so freigebe, könnten andere vielleicht konkurrierende Angebote, Produkte oder Services bauen. Das ist aber, glaube ich, die Frage, die da mitschwingt, und lass uns das gleich noch mal beleuchten.

Jens: Gerne.

Gil: Eine Frage, die ich mir notiert habe, ist, glaube ich, etwas, das ich schon fast als typisch deutsch bezeichnen würde, aber ich finde es gut, dass diese Frage gestellt wird: Im Act gibt es eine spannende Passage zum Thema Vorschriften, die es öffentlichen Stellen ermöglichen sollen, für bestimmte Zwecke von öffentlichem Interesse auf Daten des privaten Sektors zuzugreifen und diese nutzen zu dürfen. Da würde mich aus deiner Sicht eine Einschätzung interessieren, bezüglich privater Nutzerdaten. Es gibt immer diese Angst: Was darf der Staat jetzt? Wie darf der Staat vielleicht auf meine oder unsere Daten zugreifen? Wie ordnest du diese Sorge ein, die da gerade jetzt mitschwingt?

Jens: Genau, da muss man ganz klar und fairerweise auch sagen, dass bei der Diskussion – und das erlebst du ja auch, und deswegen stellst du ja auch die Frage – die Frage gar nicht vollständig gestellt wird. Das ist Kapitel 5 des Data Act, und da muss man sich die Kapitelüberschrift kurz vor Augen führen, dann wird das auch nachvollziehbar. Es geht natürlich auch nur um die Daten, um die es im Data Act geht, sonst nichts. Es ist eingeordnet, deswegen ist der Begriff ‘private Daten’ für den Juristen schon immer ein bisschen schwer verdaulich. Die Kapitelüberschrift heißt aber: ‘Bereitstellung von Daten für öffentliche Stellen, die Kommission, die Europäische Zentralbank und Einrichtungen der Union wegen außergewöhnlicher Notwendigkeit’.

Jens: Das ist dann eine große Schadenslagensituation. Nochmal so eine Pandemie oder Ähnliches, wo man dann einfach sagt: Wir haben eine ganz außergewöhnliche Notwendigkeit, wir kommen an die Daten auch nicht anders heran, und dann besteht das. Es ist nicht vergleichbar mit dem, was man immer so sagt, wie Vorratsdatenspeicherung, Zugriff auf Bestandsdaten und Verkehrsdaten. Das geht überhaupt nicht in diesem Sinn hinein. Wenn man sich das anschaut: Die außergewöhnliche Notwendigkeit der Nutzung bestimmter Daten im Sinne dieses Kapitels ist zeitlich befristet und im Umfang begrenzt und gilt nur unter einem der folgenden Umstände als gegeben. Wir haben dann einen öffentlichen Notstand, beispielsweise, auf den man zugreifen kann. Wir könnten eine Situation wie die Bankenkrise 2009 haben. Das sind Konstellationen, auf die es am Ende des Tages abzielt. Das sind nicht die Regelungen, die einem beim Data Act in erster Linie Sorgen machen sollten.

Gil: Okay. Ich höre zwei Dinge für mich dabei heraus. Das eine ist: Die Hürde, an diese Daten zu kommen, ist schon groß. Aber die Begründung dafür, sage ich mal, ist – das höre ich auch ein bisschen heraus – interpretierbar. Aber ich glaube, die Sorge – und das hast du ja noch mal herausgestellt – ist, ich will nicht sagen unbegründet, aber es kommt jetzt keine neue Dimension oder eine neue Möglichkeit des Zugangs oder Ähnliches dazu.

Jens: Deswegen auch der Vergleich zur Vorratsdatenspeicherung oder dergleichen, die immer wieder genannt wird: Das ist es nicht. Es ist wirklich so, überspitzt formuliert, wir haben eine Krisenlage, und zu deren Bewältigung braucht man einfach diese Informationen. Dann darf man das auch, und ich glaube, dann ist es auch gut so. Man muss auch sehen, da sind noch ein paar Hürden enthalten: sich zeitlich zu befristen. Selbst wenn sie greift, gibt es den Klageweg dagegen. Wir haben hier eben keine Vorratsdatenspeicherung für bestimmte Daten durch die Hintertür. Das ist es nicht, was wir bekommen werden.

Gil: Danke noch mal für die Klarstellung. Wer von Daten spricht, muss natürlich auch davon sprechen, wie der Datenaustausch erfolgen kann. Jetzt werden wir ein bisschen in technische Implementierungen und Standards eintauchen. Keine Sorge, ich werde dich jetzt nicht gleich fragen, ob du eine REST API empfehlen würdest oder ob der einfache CSV-Export genügt. Mir geht es eigentlich um etwas ganz anderes: Im Act wird für APIs, also für diese Schnittstellen, der automatische Zugang und die Übertragung von Daten in Echtzeit gefordert. Da werden sich gerade jedem ITler und jeder ITlerin ein bisschen die Nackenhaare aufstellen, wenn es um das Wort Echtzeit geht. Dazu gibt es vortrefflich viele Definitionen und Diskussionen, die wir nicht aufmachen werden. Es gibt aber einen Begriff, über den ich gestolpert bin: das Thema dieser harmonisierten Standards der EU-Kommission. Jetzt mache ich es mal ganz konkret: Ich muss diese Regulierung implementieren, ich muss das umsetzen. Welche Mindestanforderungen sind mir da auferlegt? Wann habe ich es richtig gemacht und wann muss ich noch mal nachbessern? Was muss ich unter harmonisierten Standards verstehen? Kannst du das mal ein bisschen für mich als Nichtjurist klarziehen?

Jens: Sagen wir mal so: Wir wissen es nicht, um es ganz nüchtern zu sagen. Den harmonisierten Standard würde man dann vielleicht auch eher als harmonisierenden Standard beschreiben können. Den soll es ja erstmal geben, und wenn es ihn dann gibt, setzen wir ihn um. Wir haben die Hoffnung, dass er dann so konkret ist, dass wir wissen, was wir tun sollen. Darauf zielt es dann auch ab. Ein harmonisierter Standard macht natürlich nur Sinn, wenn möglichst wenig Interpretationsspielräume enthalten sind. Wenn ich aber einen Standard habe, mit dem ich Interoperabilität schaffen will, der dann so viel Spielraum lässt, dass der eine A sagt und der andere B sagt, anstatt dass sie beide A sagen, um eine Schnittstelle tatsächlich hinzubekommen, dann macht das keinen Sinn. Das ist im Übrigen auch der Grund, warum der Gesetzgeber das nicht selbst in die Verordnung geschrieben hat. Das ist eine klassische gesetzgeberische Mechanik: zu sagen, wir stecken im Gesetz den Rahmen und schaffen dann im Gesetz die Ermächtigung an eine Instanz, die sich die Zeit und Kompetenz nehmen kann, um dann etwas konkreter zu regeln, denn ein Gesetz braucht immer einen gewissen Abstraktionsgrad. Die werden dann kommen, und dann werden wir uns die anschauen und schauen, was wir mit ihnen machen können und wie konkret sie sind. Deswegen kann ich dir das momentan auch gar nicht beantworten.

Gil: Ich finde das auch vollkommen in Ordnung an der Stelle. Man muss jetzt wahrscheinlich einfach mal warten, wie die Dinge sich entwickeln und sich in der Praxis bewähren.

Jens: Genau, wir haben keine Definition für Latenzen. Im Zweifelsfall, wenn man sich das auch mit der Überlegung aus dem Cloud Switching anschaut: Es heißt ja dann, Artikel 5 des Data Act, Artikel 3 des Data Act ist ‘by Design’. Da greife ich schnell selbst als Nutzer auf die Schnittstelle zu und bekomme die Daten eins zu eins. Das kann einfach nur ein Display am Gerät sein. Da sehe ich die sozusagen live. Bei den ganzen Push- oder an Dritte-Szenarien steht ja drin: kontinuierlich in Echtzeit. Der Vergleichsmaßstab wird dann schon der sein, wie schnell oder wie gleichzeitig der Verpflichtete selbst die Daten nutzen kann. Das muss man ja sehen: Das ist eine Regelung, die Wettbewerbsbeschränkung und Behinderung entgegenwirken soll. Wenn der eine sie wirklich sofort zieht und derjenige, an den es ausgeleitet wird, mit spürbarem Versatz, der es dann unmöglich macht, tatsächlich ein Parallelprodukt anzubieten, dann haben wir keine Echtzeit. Das wird im Zweifelsfall eine Dimension sein, dass man sich anschaut, wie schnell man es selbst nutzen kann. Man muss natürlich auch sehen: Andere Konfigurationen, Schnittstellen – Schnittstellen verlangsamen immer. Kabellängen, man muss ja auch ehrlich sein, selbst ein langes Kabel führt zu einer Verzögerung. Das wird man berücksichtigen müssen. Aber vielleicht kann man es dann versuchen, es so zu verstehen: abzüglich der Verzögerung, die durch die technische Übertragung entsteht, zeitgleich zu dem, was der Verpflichtete hat. Das wird ein bisschen die argumentative Richtung sein.

Gil: Mhm, ja. Ich stelle mir das auch schwierig vor, weil das Gesetz oder diese Regulierung viele Unternehmen aus vielen verschiedenen Bereichen und Branchen betrifft. Und wie du schon sagst, die Menge an Daten, die zur Verfügung gestellt wird, und die Geschwindigkeit, in der sie konsumiert werden, schwankt sehr stark. Du hast aber gerade Interoperabilität angesprochen, und das führt unweigerlich zu einem, ich nenne es mal, Elefanten, der damit im Raum schwingt. Da geht es um das Thema Cloud Switching und auch Lock-in, denn es ist ja schon so, und das ist sehr zeitnah, ab Januar 2027 sollen alle Cloud Switching Gebühren verboten werden. Und jetzt kommt eine weitere tolle Begrifflichkeit, wie ich finde: funktionale Äquivalenz muss gewährleistet werden. Also mal ganz ehrlich, was darf ich denn unter funktionaler Äquivalenz hier verstehen? Auch gerne mal deine ganz persönliche Interpretation, was sich die EU dabei gedacht hat.

Jens: Genau. Also, man muss vielleicht noch ganz kurz einen Schritt weitergehen. Uns beiden ist das klar, ob das den Zuhörern so klar ist, ist vielleicht noch ein anderer Punkt. Wir haben ja im Data Act zwei Regelungsstränge. Wir haben uns bisher den Zugang zu IoT-Daten angeschaut, der in Kapiteln zwei bis fünf geregelt ist. Und dann ist in Kapitel sechs noch mal eine Sonderthematik drin: das Cloud Switching. Das ist ein bisschen auch an die Diskussion um Souveränität angelehnt, aber da verfolgt der Gesetzgeber einen gedanklichen Ansatz, den man wohl in der Parallele zur Rufnummernportabilität sehen kann, wie wir sie aus dem TK-Bereich kennen. Der TK-Bereich ist liberalisiert worden, als wir plötzlich mit unserer Rufnummer vom Anbieter A zum Anbieter B gehen konnten. Da fiel dieser Lock-in-Effekt weg, und plötzlich, wer das bessere Angebot hatte, ich habe gewechselt, und dadurch ist da viel in Bewegung gekommen. Eine ähnliche Überlegung liegt auch diesem Cloud Switching zugrunde. Ich muss Hindernisse abbauen, die es unmöglich machen, und muss beim Wechsel unterstützen. Das ist sozusagen die Grundüberlegung. Die Zielsetzung ist der Abbau dieser Lock-in-Effekte. So, und da kommen jetzt zwei Dinge mit rein, die wir gerade angesprochen haben. Es macht natürlich nur Sinn, wenn ich irgendwo anders hingehe, wenn ich da eine Funktionsäquivalenz habe. Im Telefoniebereich ist es so: Wenn ich wechseln will, weil ich da günstiger telefonieren möchte, ist es doof, wenn ich da nur SMS versenden kann. Ganz rudimentär und wirklich sehr schemenhaft. Und das ist die Frage: Kann ich es genauso nutzen? Das ist die Funktionsäquivalenz. Und das andere ist im Hintergrund dann noch: Was darf es nicht kosten? So, und jetzt gucken wir uns die Funktionsäquivalenz an. Die Funktionsäquivalenz ist definiert. Wenn wir Juristen etwas können, das ich als Jurist etwas kann, bevor sich noch jemand auf den Schlips getreten fühlt, ist es Definition. Und der Data Act definiert Funktionsäquivalenz wie folgt: Die Wiederherstellung auf der Grundlage der exportierbaren Daten und digitalen Vermögenswerte des Kunden, eines Mindestmaßes an Funktionalität in der Umgebung eines neuen Datenverarbeitungsdienstes der gleichen Dienst Art nach dem Wechsel, wenn der übernehmende Datenverarbeitungsdienst als Reaktion auf dieselbe Eingabe für gemeinsame Funktionen, die dem Kunden im Rahmen des Vertrags bereitgestellt werden, ein materiell vergleichbares Ergebnis. So, wären wir auf einer Bühne, würde ich jetzt das Mikro ausstrecken und einen kleinen Mic Drop machen und sagen: Und jetzt kommt ihr Techniker. Was macht ihr daraus? Also, das ist es, was wir haben. Scherz beiseite, wir wissen es nicht ganz genau, was das am Ende des Tages bedeutet. Materiell vergleichbares Ergebnis, das ist Funktion A bei Anbieter A muss wesentlich dasselbe können wie bei Anbieter B. Einfach ist es Textverarbeitungsprogramm A, Textverarbeitungsprogramm B. Beide können Texte schreiben. Vielleicht nicht so schön formatiert, dann ist es vergleichbar. Es muss nicht gleich sein. Jetzt muss man nur immer eins überlegen: Es soll dem Kunden das Cloud Switching ermöglicht werden. Das heißt, von einem Anbieter zu einem anderen mit der gleichen Dienstart. Das heißt also, es muss schon eine Vergleichbarkeit da sein. Nur wenn es zu einem anderen Dienst mit vergleichbarer oder mit gleicher Dienstart geht, greifen überhaupt die Pflichten zum Cloud Switch. Das heißt, wir haben das, und dann muss man ihm helfen, dass es dann halt schon so funktioniert, aber man muss ihn, überspitzt formuliert, man muss ihm die Brücke bauen, aber man muss ihm nicht das Haus auf der gegenüberliegenden Seite auf dem Grundstück eines anderen Vermieters aufbauen, damit er da genauso hübsch auf den Fluss schauen kann wie bei mir. Das muss ich nicht. Ich muss ihm die Brücke bauen, die Brücke zeigen. Ich muss ihm über die Brücke helfen, ihm sagen, wie gefährlich der Weg über die Brücke ist, und wenn er stolpert, muss ich ihm helfen, und ich muss ihm auch gegebenenfalls auf halbem Weg wieder mit zurücknehmen. Aber das war’s. Das Haus da drüben, das muss im Wesentlichen ein anderer gebaut haben, dass man ihm dann vielleicht auch sagt, eine Treppe wäre im zweiten Stock ganz toll. Deswegen, wir wissen es nicht ganz genau, aber was ich auch immer höre: Beim Anbieter A, Datenverarbeitungsdienst A, muss nicht seinen eigenen Service beim Datenverarbeitungsdienst B aufbauen, damit der Kunde von A nach B gehen kann. Das ist nicht die Intention des Gesetzes.

Gil: Okay.

Jens: Jetzt müssen wir Wechselentgelte noch besprechen, aber du willst zuerst noch eine Frage stellen, befürchte ich.

Gil: Ja, also ich versetze mich gerade mal in die Lage des einen, der den Umzug sicherstellen muss, und des anderen, der den Einzug sicherstellt. Ich bleibe mal bei deinem Bild des Hauses. Ich mutmaße jetzt einfach mal, weil du hast ja gerade schon gesagt, wir wissen es nicht. Also, das heißt für mich, wenn ich eine Äquivalenz anbieten möchte, muss ich jetzt nicht die identische Performance garantieren oder vergleichbare Funktionalität. Ich muss sicherstellen können, dass ich dich mit deinem Service, mit deinem Dienst, aufnehmen kann. Okay. Heißt aber für mich, wenn ich verhindern möchte – wir bleiben beim Lock-in –, dass jemand umzieht, dann muss ich eigentlich ein proprietäres Angebot schaffen, sodass es keinen vergleichbaren Dienst auf der Gegenseite gibt, der das darstellen kann. Das ist eigentlich die besondere Situation, die wir auch heute schon haben. Da frage ich mich natürlich, löst das jetzt wirklich das Problem, oder könnte es das eher noch verschärfen, dass ich eigentlich nicht so frei wechseln kann, und der Lock-in dadurch noch irgendwo stärker wird? Ich bin mal gespannt.

Jens: Gute Frage. Ja, also man muss jetzt auch sehen, und die Frage wird schon auch sein, was hat der Gesetzgeber bei Cloud Services vor Augen gehabt? Also im Erwägungsgrund 81, wenn man von Datenverarbeitungsdienst spricht, der an Software as a Service, Platform as a Service, Infrastructure as a Service, bei Infrastructure as a Service ist es ja noch am leichtesten denkbar, da spricht er dann im Erwägungsgrund 86 auch extra die Funktionsäquivalenz an. Aber bei Produkten über die Storage as a Service spricht er auch an: Je weiter wir in einem Stack sind, umso schwerer wird es. Und da wird wahrscheinlich dann eine Funktionsbetrachtung anzustellen sein. Und wenn es diesen einen Dienst nur einmal gibt, dann hast du ohnehin die Situation: Wohin will er gehen? Wenn ich aber den grundsätzlich gleichen Dienst, der den gleichen Job macht, zweimal am Markt finde und ich von dir nur nicht weg kann, dann spricht vieles dafür, dass die Aufsichtsbehörde das als Indiz dafür sieht, dass du Hindernisse aufgebaut hast.

Gil: Mhm.

Jens: Die du abbauen musst, damit es ermöglicht wird. Das Gesetz selbst regelt in Artikel 31 Ausnahmen von der Verpflichtung zum Angebot des Cloud Switching, und die laufen vereinfacht gesagt darauf hinaus, dass du einen Dienst aufgebaut hast, den du für einen Kunden aufgebaut hast, nicht parametrisiert, ein bisschen customized, sondern wirklich den Dienst, den du für einen Kunden gebaut hast, dann bist du komplett raus.

Gil: Ja.

Jens: Das würde ich, wenn man es auslegt, wohl als Indiz dahin werten, dass du unterhalb dieser Schwelle dir sehr schwer tun wirst, ein Argument zu finden, warum es nicht funktioniert. Denn das muss man sich ganz kurz auch vor Augen führen: Artikel 23 des Data Acts ist ja für das Cloud Switching so ein bisschen die Generalklausel oder die Richtung vorgibt, und der formuliert zwei Dinge: keine vorkommerziellen, gewerblichen, technischen, vertraglichen oder organisatorischen Hindernisse aufzwingen, und jetzt kommt’s, und müssen solche Hindernisse beseitigen, wenn sie die Kunden daran hindern zu wechseln. Das heißt also, hier wird unter Umständen auch so ein bisschen die Situation entstehen, dass ich Dienste nivellieren muss. Und da sehe ich eher ein Risiko darin, wenn die Aufsichtsbehörde das zu extensiv handhabt, dass wir hier einfach eine Innovationshemmnis-Situation haben.

Gil: Mhm.

Jens: Deswegen, aber wir wissen es einfach, wir wissen es noch nicht. Die Regelung, in Kraft getreten ist sie vor zwei Jahren, vor anderthalb Jahren, anzuwenden ist sie jetzt noch nicht mal einen Monat. Wir haben eigentlich noch nichts. Wir haben ja noch nicht mal eine Aufsichtsbehörde in Deutschland. Der nationale Gesetzgeber hat jetzt aktuell wieder ein Data Act Durchführungsgesetz, ein DADG, vorgeschlagen, also die Bundesnetzagentur soll es werden, aber wir haben sie noch nicht mal. Mit wem soll ich jetzt sowas mal besprechen? Und alle anderen EU-Mitgliedstaaten: gleiche Regelungen, Auslegung, Handhabung, einheitlich funktioniert, aber das war so ein bisschen der Punkt, wo ich sage, wir bemühen uns drum, auf Anbieterseite lege ich das eher restriktiv aus. Mal schauen, wie es runtergeht. Auf Nachfragerseite werden, also momentan wird es noch nicht gefordert, aber auf Nachfragerseite werden wir uns recht nass vorstanden, fordern, also das wird sich ausdiskutieren, auspegeln müssen.

Gil: Ja, ja. Ja, spannend. Ich bin mal gespannt, in welche Richtung sich das entwickeln wird an der Stelle. Du hast es aber eben schon angesprochen, klar, wir müssen auch über das Thema Kosten sprechen und insbesondere über diese kostenbasierten Gebühren, die da auch noch gedeckelt sein sollen. Du wolltest das Thema gerade schon aufmachen, deswegen lass uns einmal darüber sprechen, bitte.

Jens: Jetzt müssen wir bei den Kosten unterscheiden. Kosten sind im Data Act zweimal geregelt. Die Kosten sind einmal beim Data Sharing geregelt, wenn ich vom Dateninhaber verlange, die Daten an einen Dritten weiterzugeben, der dann etwas damit machen darf. Dann dürfen Entgelte erhoben werden. Man kann damit auch Geld verdienen, man muss es nicht verschenken. Das sind die Kostenregelungen, die im Kapitel zwei oder drei geregelt sind. Das ist das eine. Das andere ist die Abschaffung der Wechselentgelte, die auch so heißen und im Gesetz definiert sind. Die Definition lese ich nicht vor, weil sie mehr Fragen aufwirft, als sie löst. Diese sollen abgeschafft werden. Das Gesetz besagt: Ab dem 12. Januar 2027 dürfen Anbieter von Datenverarbeitungsdiensten für den Vollzug des Anbieterwechsels keine Wechselentgelte mehr erheben. Eine erste Diskussion ist, ob man für das Löschen der Daten ein Löschentgelt erheben darf, da das Gesetz dies gar nicht regelt. Vielleicht finden wir da noch eine Lücke. Hier wird auf Null runtergefahren. Das werden wir bis dahin sehen. Genau genommen dürfen seit dem 11. Januar 2024 bis dorthin gemäßigte Wechselentgelte erhoben werden. Das sind die Kosten, die dem Anbieter im unmittelbaren Zusammenhang mit dem betreffenden Wechsel entstehen. Hier findet jetzt die Diskussion statt, ob Gemeinkosten mit reinfallen oder nicht, und was unmittelbar entstehende Kosten sind. Das werden wir diskutieren. Die Anbieter legen es großzügig aus, die Nachfrager werden es enger auslegen, und ein Gericht wird es entscheiden.

Gil: Sehr schön. Dann schauen wir mal, wie sich das entwickeln wird.

Jens: Mir nur.

Gil: Ja.

Jens: Die Unternehmen werden gezwungen sein, denn das kostet ja Geld, anyway. Ramp Down kostet Geld. Ich kenne Geschäftsmodelle, bei denen wahrscheinlich mehr beim Ramp Down verdient wird als mit dem operativen Betrieb, die auch so gerechnet sind. Zum Teil haben wir Modelle, die so gerechnet sind, dass die Ramp Down Kosten über die Laufzeit abschmelzen. Das sind alles Dinge, die ich mir jetzt gut anschauen würde. Ich darf es ab dem 12. Januar 2027 nicht mehr. Das heißt, ich muss mir überlegen, vielleicht muss ich das allgemein einpreisen, dann steigen die Kosten insgesamt. Das ist vielleicht auch fair, aber möglicherweise ist es nicht schlau, es so zu machen, zu sagen: ‘Wir verwechseln, wir mit Sicht auf die Wechselentgelte, aber hochgerechnet auf 24 Monate Laufzeit, erheben wir genau dieselbe Summe mehr.’ Das ist ein bisschen der Autobahnmaut-Trick. Wir erheben eine Autobahnmaut und geben sie den deutschen Bürgern über die Steuer wieder zurück und sind dann überrascht, dass ein Gericht kommt und sagt: ‘Der Trick ist aber ein schlechter Taschenspieler.’

Gil: Das ist leider immer so, wenn man versucht, über eine Regulatorik, über die Politik, die Dinge zu verteilen oder zu steuern. Das will ich jetzt gar nicht so sehr vertiefen, aber deswegen bin ich gespannt, wie sich das entwickelt, weil, wie du schon sagst, linke Tasche, rechte Tasche. Ich glaube, was als Unternehmen wichtig ist, wenn ich mich jetzt damit auseinandersetzen muss, das umzusetzen, ist auch der Punkt davor mit dem Switching. Ich muss eine gewisse Wechselfähigkeit sicherstellen und noch genauer hinschauen als vorher, in welche Abhängigkeit ich mich gegebenenfalls bewege und was das kostentechnisch bedeutet. Das war vorher auch schon so, und ich glaube, das wird jetzt dadurch noch ein Ticken wichtiger.

Jens: Ich bin gespannt. Wenn man es aus Nachfragesicht betrachtet: Ich berate ohnehin immer, wie mir ein Familienrechtler vor Neujahr erklärte, dass Verträge in guten Zeiten für schlechte Zeiten gemacht werden.

Gil: Mhm.

Jens: Die schlechte Zeit in jedem Vertrag ist die Beendigung der Situation, dass immer ein Service eingekauft wird. Das heißt, ich bin immer gut beraten, sicherzustellen und mir gut anzuschauen, wie es an diesem Punkt läuft. Ich denke, es wird vergleichbar für die Kunden, aber ob sie damit so viel gewinnen, ist eine andere Frage.

Gil: Mhm. Danke. Ich würde gerne den Horizont erweitern. Es ist ein EU Data Act, aber wer über den EU Data Act spricht, muss natürlich auch über den US Cloud Act sprechen. Oder was heißt, wer muss? Es passiert oft, dass wir immer wieder eine Fragestellung hören, die lautet, dass deutsche Unternehmen mit US-Geschäft gegebenenfalls zwischen dem EU Data Act und dem US Cloud Act stehen und ob der Data Act verbieten könnte, wenn ein US-Gericht Datenzugang fordert. Ich glaube, das muss man wirklich klarstellen und richtigstellen, was hier eigentlich greift. Vor allen Dingen, und das wäre meine Anschlussfrage an dich, wie unterstützt mich gegebenenfalls der Gesetzgeber? Denn wir haben ja gerade in dieser Diskussion über die digitale Souveränität gelernt: Auch wenn ich ein US-amerikanisches Unternehmen im Cloud-Bereich in Europa habe, ist oft die klare Aussage gekommen: ‘Verlangt die US-Regierung von uns eine Datenausgabe, dann werden wir dem Folge leisten.’ Das möchte ich gar nicht mit dir vertiefen. Ich möchte nur wissen: Siehst du eine Möglichkeit, dass uns der Gesetzgeber schützt? Aber noch mal ganz klar: Muss ich mich jetzt als deutsches oder europäisches Unternehmen zwischen dem EU Data Act und dem US Cloud Act entscheiden?

Jens: Nö.

Gil: Nein.

Jens: Das war zu einfach, oder? Zu klar. Die Diskussion ist ein bisschen die Fortsetzung der Diskussion US Cloud Act versus EU DSGVO, EU Datenschutzgrundverordnung. Das macht Sinn. Darauf kommen wir gleich noch mal kurz zurück, aber wenn wir uns das jetzt anschauen: Der US Cloud Act regelt vereinfacht die Verpflichtung von US-Unternehmen zur Beschaffung von Daten, die bei deren US- oder EU-Tochtergesellschaften gewünscht werden. Es ist sehr rudimentär beschrieben. Eine Pflicht, die sie trifft, ist keine Pflicht, die deutsche Unternehmen trifft, weil sie diese theoretisch auch ignorieren könnten. Aber dann fahren wir nie wieder in die USA als Geschäftsführer. Deswegen ist es ein bisschen relativiert, aber da haben wir dieses Spannungsfeld. Was haben wir aber beim Data Act? Der Data Act regelt im Kern zwei Dinge: Nämlich den Zugang des Nutzers zu seinen Daten im IoT-Umfeld. Es entsteht kein Sperrverhältnis zum US Cloud Act. Der US Cloud Act verlangt die Herausgabe von Daten. Der Data Act regelt den Zugang zu Daten, verhindert aber nicht für Dritte den Zugang zu Daten. Er regelt in diesem Punkt wirklich etwas, was wir nicht haben: ‘Du musst mir meine Daten geben oder du musst meine Daten auch an einen Dritten geben, du darfst nicht monopolistisch auf meinen Daten glucken.’ Es ergibt sich kein ordinäres Spannungsverhältnis zum Cloud Act. Auch beim Cloud Switching: Du kannst vom Cloud Service Anbieter A zu Cloud Service Anbieter B ohne Wechselentgelt wechseln, und das muss dann bei B funktionsäquivalent funktionieren wie bei A. Ich habe auch keinen ordinären Konflikt zum US Cloud Act, denn das haben wir einfach nicht, weil die sich nicht entgegenlaufen. Dass im Data Act ‘Data’ drinsteckt, hat nichts mit der General Data Protection Regulation, also der GDPR, zu tun. In beiden steckt zufällig der Begriff ‘Data’ drin. Und Achtung, tatsächlich zufällig, denn die Datenschutzgrundverordnung (GDPR) definiert personenbezogene Daten, aber der Data Act definiert Daten anders. Man hat selbst diesen gleichen Aufhänger ‘Daten’ oder ‘Data’, aber es meint Verschiedenes, und wir haben dieses Spannungsverhältnis einfach nicht. Klar, der Data Act sagt überall, das Datenschutzrecht bleibt unberührt und ist zu beachten. Stimmt. Das ordinäre Spannungsverhältnis zwischen US Cloud Act und GDPR Datenschutzgrundverordnung besteht, das bleibt auch bestehen. Das gilt im Zweifelsfall auch für Daten, die unter den Data Act fallen, aber zwischen Data Act und US Cloud Act haben wir kein natürliches Spannungsverhältnis.

Gil: Sehr schön, dann hoffe ich, dass das jetzt ein für alle Mal beantwortet ist. GDPR ist ein guter Übergang. Ich würde gerne über unsere Nachbarn sprechen, die näher sind als die USA: UK. Vielleicht kannst du dazu noch kurz eine Einordnung geben, weil es dort ja kein Äquivalent zum Data Act gibt. Jetzt bin ich vielleicht ein deutsches Unternehmen, habe aber auch Geschäfte in UK. Gibt es da etwas, wo ich eine Empfehlung von dir bekommen kann? Worauf sollte ich da achten, was einen gemeinsamen Nenner angeht, was den Ansatz betrifft?

Jens: Datenschutzrechtlich haben wir jetzt weniger Probleme, weil wir ja diesen Angemessenheitsbeschluss haben. Das heißt, momentan gehen wir noch davon aus, dass in UK das gleiche Datenschutzniveau herrscht. Wenn ich Daten aus der EU nach UK geben will, habe ich keine größeren Herausforderungen unter der Datenschutzkonformität. Das ist sozusagen eins, nur aus Vereinfachungsgründen so dargestellt. Insofern haben wir da auch keine Spannungsverhältnisse. Spannender könnte es für Unternehmen werden, wenn sie Daten haben, die nach dem UK Privacy Law oder Data Protection Law geschützt sind, die sie aber nach dem Data Act teilen müssen. Es kann tatsächlich ein Konflikt zwischen UK Datenschutzrecht und EU Daten-Sharing-Pflicht entstehen. Das ist tatsächlich denkbar, und man hat dann auch die Situation, dass der EU Data Act eigentlich keine Rechtsgrundlage oder kein Rechtsrahmen ist, der vom UK Privacy Law zwingend berücksichtigt werden müsste. Da haben wir eigentlich mal die ganz umgekehrte Situation, die wir uns immer vorstellen, dass wir viel strenger sind als die anderen und deswegen eigentlich viel besser sind. Hier kann es tatsächlich passieren, dass es andersherum läuft. Das hätten wir aber beispielsweise auch bei der Schweiz. Die Schweizer haben ja meistens ein Datenschutzniveau, die haben die DSGVO praktisch übernommen. Und jetzt pass auf: Nach Schweizer Datenschutzrecht sind natürlich juristische Personen auch geschützt. Bei uns sind ja nur natürliche Personen geschützt. Das heißt, gerade in der Schweiz kann es dir viel schneller passieren, dass du Daten hast, die du nach dem EU Data Act vielleicht teilen musst, die aber durch das Schweizer Datenschutzrecht geschützt sind, und dann hast du dieses Spannungsfeld. Darauf muss ich achten, wenn ich grenzüberschreitend außerhalb der EU tätig bin.

Gil: Ich denke, das wird sogar schon eine nächste Frage beantworten, denn die fand ich auch spannend, die hatte ich selber gar nicht auf dem Schirm, wenn ich jetzt nach China schaue. Dort gibt es ein – und jetzt bin ich gespannt, ob ich es richtig ausspreche – PIPL. Das ist wohl strenger als GDPR. Mich würde interessieren, siehst du das ähnlich wie bei UK? Ist das die gleiche Sicht, auch wenn es China ist, das natürlich ein anderer Markt mit anderer Größenordnung ist, oder hast du da eine andere Sicht drauf, wenn es um China geht?

Jens: Das Problem bleibt das gleiche. Man kann sogar noch weiter abstrahieren: Immer wenn ich im EU-Ausland ein Recht habe, das die Daten, die ich nach dem Data Act teilen muss, stärker schützt oder überhaupt schützt im Gegensatz zum Inland, habe ich ein Problem. Weil ich dagegen verstoße. Zum PIPL, dem chinesischen PIPL, bin ich mal vorsichtig zurückhaltend, weil die anders als UK und anders als die Schweiz, die wir uns ja gerade eben betrachtet haben, zum Verständnis des Datenschutzes ein ganz anderes Grundmodell haben. Es ist gedanklich nicht vergleichbar, deswegen halte ich da mal die Füße still. Aber die Grundüberlegung ist immer die, die man immer vor Augen haben muss: Wenn ich nach dem Data Act Daten teilen muss, die einen Bezug zu einer Rechtsordnung außerhalb der EU haben und nach dieser Rechtsordnung geschützt sein können – kann auch ein Geschäftsgeheimnisschutz sein, muss gar nicht Privacy Law sein – dann habe ich ein Problem nach dem ausländischen Schutzrecht.

Gil: Okay. Danke für die Einordnung. Ich fasse den Rahmen jetzt wieder ein bisschen kleiner, ich ziehe die Grenzen wieder ein bisschen kürzer. Wir konzentrieren uns jetzt wieder ein bisschen mehr auf die EU und Deutschland an der Stelle. Du hast es eben schon gesagt, die Bundesnetzagentur wird vermutlich, oder ich glaube, das ist jetzt mittlerweile schon Gesetz, die zuständige Behörde sein in Deutschland, wenn es um das Thema Data Act geht, also das Überwachen. Ich würde gerne ein bisschen in die Richtung kommen, ich nenne es mal Handlungsempfehlungen, also was würdest du tun? Da wäre meine Frage, was glaubst du, wo die Aufsichtsbehörden im ersten Jahr nach Inkrafttreten dieser Regulierung genauer hinschauen werden? Oder anders gesprochen, wo sollte ich, wenn ich das jetzt umsetzen muss, vielleicht meine Prioritäten setzen, damit ich meine Ressourcen richtig nutze und einsetze an der Stelle?

Jens: Das ist gar nicht so leicht zu sagen beim Data Act. Ich bin da immer schnell mit schnellen Action Plans dabei. Wir müssen beim Data Act zunächst mal unterscheiden: Bin ich im Bereich des Cloud Switching? Da würde ich tatsächlich sagen, ich muss mir erstmal meine Dienste anschauen, dann muss ich tatsächlich für mich hinterfragen: gleiche Dienstart, Funktionsäquivalenz, Ausnahmeregelung. Dann würde ich allerdings den Fokus erstmal darauf legen, dass ich einem Kunden, der unter den Rahmenbedingungen wechseln will, das auch tatsächlich ermöglichen kann. Ich muss Verträge anpassen, ich brauche Hinweise und so weiter und so fort. Aber wenn ich noch gar nichts habe, würde ich mich darauf fokussieren, es ermöglichen zu können, wenn es passieren soll. Denn die Ausrede ‘es geht nicht’ ist schwer. Dass man dann vielleicht sagt, gut, gibt doch kein Geld oder wir diskutieren noch mal über Geld, das eine und vertragliche Regelung hin und her, da kann man ja am Ende des Tages kulant sein. Nur bei Technik kann ich nicht kulant sein, es funktioniert oder es funktioniert nicht. Das heißt, hier würde ich den Augenmerk tatsächlich auf den Bereich der technischen Seite legen. Das schmerzt mich als Juristen total, weil eigentlich der Vertrag das Richtigste überhaupt ist, aber wenn ich es möglich machen kann, ist das Ärgerpotential erstmal am kleinsten. Das war beim Cloud Switching. Bei dem Zugang zu Daten muss man jetzt sehen, die Regelung über Data Access by Design, also der eigene Zugang nach Artikel 3, für die Regelung gibt es erstmal noch eine weitere Übergangsfrist, weil der Gesetzgeber auch gesehen hat, das muss in die Geräte eingebaut werden. Das ist nicht so, dass ich mal eine Schnittstelle außen dran habe, sondern das muss tatsächlich integriert werden. Deswegen haben wir da noch mal einen weiteren Übergangszeitraum, da würde ich jetzt aber mal Gas geben. Ich habe zwar noch 12 Monate, aber 12 Monate sind nicht viel, da muss auch ein bisschen was passieren, das ist nicht so leicht. Deswegen habe ich momentan in erster Linie die beiden Regelungen, die ich jetzt in Anführungszeichen mal als Ausleitung in Echtzeit und kontinuierlich betrachte. Das heißt, entweder an den Nutzer selbst in Echtzeit und kontinuierlich oder auf dessen Verlangen an einen Dritten in Echtzeit und kontinuierlich. Und da sehe ich das genauso: Ich fokussiere mich jetzt erstmal darauf, wie kann ich das machen? Vielleicht erstmal mit einem Workaround oder mit der von dir angesprochenen REST API. Ob die dann insgesamt funktioniert, weiß ich nicht, oder ich schaue es mir an und komme zu dem Ergebnis, und deswegen muss ich es mir technisch anschauen: Dadurch wird die Sicherheit des Produkts gefährdet. Dann habe ich auch erstmal ein ‘aber’, denn das sagt der Data Act auch: Die Sicherheit des Produkts geht vor. Auch hier kümmere ich mich in erster Linie mal um die technische Seite, denn aus einem ‘das geht nicht, bei uns im Produkt geht es generell nicht’, dann funktioniert das Produkt sicherlich nicht mehr sicher. Das sind Argumente, die sind einfach handfest. Wenn ich dann weiß, was ich kann und wie ich es kann, dann habe ich eine Gesprächsgrundlage mit demjenigen, der es haben möchte. Da muss der aber auch noch ein paar neudeutsch ‘Requirements’ erfüllen, damit es überhaupt funktioniert, denn wenn ich nur einen Zugang über eine REST API ermögliche, muss der ja auch noch andocken können. Und dann ist der nächste Schritt natürlich, das sollte parallel dazu passieren an der Stelle, also insofern mehrstufiger Action Plan, parallel, das werden andere Arbeitsgruppen machen, mal die Sensibilität der Daten und der Schutzbedürftigkeit, Geheimnisschutz, Geschäftsgeheimnis, Betriebsgeheimnis und so weiter und so fort, zu überlegen. Und dann, wenn ich das habe und mir damit mal die Karten gelegt habe, wo ich überhaupt stehe und was ich kann, dann fange ich mal an, die Vereinbarung zum Schutz zu stricken und so weiter und so fort. Also, wer noch nichts hat, nicht in blinde Hektik verfallen, denn Daten, die man rausgegeben hat, Geschäftsgeheimnisse, die man rausgegeben hat, die kriegt man nicht mehr wieder. Punkt. Deswegen erstmal sich selbst die Karten legen. Das kann bedeuten, dass man Ärger kriegt mit der Bundesnetzagentur, das kann sein, dass man verklagt wird, das kann sein, dass man Schadensersatz zahlen muss. Es kann sein, dass es unlustig wird. Geschenkt. Dann hätte man vor 18 Monaten anfangen müssen. Aber hätte, hätte, Fahrradkette. Deswegen nur weil der Anwendungsbeginn erreicht ist oder überschritten ist, gibt es ja auch noch eine Abstufung in Artikel 50, was wann gilt, nicht in blinden Aktionismus verfallen. Man muss es ja auch so sehen, selbst wenn ich es kann und es nicht verhindern darf und es herausgeben muss, dann ist es auch sinniger, das strukturiert und sinnvoll aufzubauen, als jetzt eine Quick-and-Dirty-Lösung zu haben, die rumpelt und das Ganze dann noch mal zu machen und dann richtig zu machen. Kostet auch Geld. Und wenn ich es so halblebig gemacht habe und damit nicht in Echtzeit und kontinuierlich, habe ich den Anspruch auch nicht auf die Güte, habe ich gesagt, ich habe mich bemüht. Aber da kann man immer noch sagen, nicht rechtzeitig. Also deswegen Ruhe bewahren. Nicht verwechseln mit ‘ich lege mal die Hände in den Schoß und warte, bis der Druck groß genug ist’. Das kann man immer noch machen, wenn man dann, wenn der Druck kommt, auch schnell sagen kann, ‘ich kann morgen früh’. Da war schon alles da. Das ist anders, aber Ruhe bewahren, Ruhe dran haben, sich die Karten legen, sich die Technik anschauen, was habe ich, was kann ich machen, was muss ich machen und wie schütze ich mich? Das sind die Punkte an der Stelle. Leider nicht die juristischen Dinge zuerst, das schmerzt mich, aber ich nehme das mal so hin.

Gil: Dass man die Hände nicht in den Schoß legen darf und kann, ich glaube, da hat die EU auch, wenn ich mich nicht täusche, mit Strafen bis zu 20 Millionen Euro oder 4 % des globalen Umsatzes eine ausreichend große Motivation geschaffen. Was ich an deiner Aussage aber sehr gut finde, ist:

Jens: Eins anbringen. Ja, die Sanktionen klingen ja so ähnlich wie die DSGVO-Sanktionen. Also da haben wir jetzt nicht so die explosionsartigen, mega heftigen, ständigen Bußgeldeinschläge gehabt. Diese Erfahrung aus der Grundverordnung würde ich nicht eins zu eins auf den Data Act und die Bundesnetzagentur als Aufsichtsbehörde übertragen. Also das nur mal vorweggeschickt. Es ist ein anderes Gesetz und es ist eine andere Aufsichtsbehörde, die Wahrscheinlichkeit, dass da was passiert, ist signifikant größer.

Gil: Das ist noch mal ein guter Hinweis, weil diesem Trugschluss könnte man ja erliegen, dass man sagt, so schlimm wird es nicht kommen. Darauf würde ich mich also nach deiner Aussage nicht verlassen. Aber was ich auch noch mal ganz klar sagen muss, du hast eben etwas sehr Wichtiges und Schönes an der Stelle gesagt: Security, ich drücke es mal etwas flapsig aus, Security schlägt da API. Also wenn die Sicherheit gefährdet wird, dann hat das eben Vorrang statt einer komplett durchdeklinierten vielleicht technischen Umsetzung oder so etwas. Also das finde ich gut an der Stelle. Ich würde dann gerne ein bisschen dieses, ich nenne das mal das Fahrwasser des Risikos durch so eine Strafe verlassen. Ich rede nämlich gerne im Kontext auch von so einem AI Act, gerne auch von Chancen, und du hast eben auch das Thema beleuchtet der Interoperabilität. Und wir haben es ganz am Anfang einmal gesagt, und deswegen ist es wahrscheinlich auch mit Blick auf die Zeit gleich ein guter Beginn eines Abschlusses unserer Folge. Und das ist nämlich die Möglichkeit, durch das Bereitstellen von Daten vielleicht auch Geschäftsmodellinnovationen durch diesen Datenzugang zu fördern. Ich habe es zwar auch, auch wenn das jetzt vielleicht erstmal wieder ein Risiko ist, dargestellt, na ja, wenn ich meine Daten rausgebe, könnte es ja sein, dass jemand auf Basis meiner Daten oder sagen wir besser gesagt, der Daten, die ich als Unternehmen generiere, ein Konkurrenzprodukt zu mir aufbaut.

Jens: Das ist nicht zulässig.

Gil: Das ist eine wunderbar klare Aussage.

Jens: Das verbietet der Data Act. Also der Data Act regelt beispielsweise auch, dass an die Gatekeeper, du kannst es gar nicht verlangen, dass an die Gatekeeper, die großen Player nach Digital Markets Act, Daten herausgegeben werden, weil die sind schon groß genug, die braucht man nicht mehr zu unterstützen. Das regelt der Data Act auch explizit. Aber der regelt auch explizit, dass die Daten nicht verwendet werden dürfen, um dem Verpflichteten, sage ich mal, in seinem Primärmarkt Wettbewerb zu machen. Ja, ist natürlich immer die Frage, wie beweise ich es, wie verhindere ich es tatsächlich, aber das will das Gesetz explizit nicht, es verbietet es auch. Und dementsprechend wird es dann auch Wege geben, es zu verhindern, wahrscheinlich dann eben auch über den Weg der Gerichte. Also das ist nicht gewollt, die Geschäftsmodelle sollen sich sozusagen im Sekundärmarkt entwickeln können.

Gil: Das ist die.

Jens: Das heißt.

Gil: Im Umkehrschluss, wir können wahrscheinlich am Sekundärmarkt eigentlich aus Konsumentensicht, wahrscheinlich jetzt vielleicht auch noch mehr Angebote oder neue Dienstleistungen, Services irgendwie vielleicht erwarten auf Basis dieser Daten, die ich generiere, durch ein Unternehmen verarbeitet werden, dann nach draußen gegeben werden. Also ich stelle mir das so vor für irgendeines meiner Geräte, Fahrzeuge, was auch immer, darf ich vielleicht zukünftig Produkte erwarten auf Basis meiner Daten, die es so bisher nicht gab. Verstehe ich das richtig, ist das eine Chance vielleicht an der Stelle?

Jens: Das schließt sich wieder zu diesen 270 Milliarden, die wir vorher angesprochen haben. Das ist die Überlegung, dass die Möglichkeit entstehen soll, dass mit den Daten nicht nur die eigentlichen Services, die Sekundärservices, substituiert werden, sondern sich tatsächlich auch innovativ neue Dinge entwickeln können, die derjenige, der die Daten primär generiert – der Dateninhaber – gar nicht entwickeln kann, nicht entwickeln will, was auch immer. Dass die tatsächlich im Primär-Sekundärmarkt – das ist nicht ganz richtig, das muss man ganz kurz sagen – aber ein Bild, dass hier dann ein echter Markt besser entsteht. Das ist die Zielsetzung, da in zwei Jahren 270 Milliarden. Gut, das sehe ich noch nicht ganz, aber das ist die Idee, die man hatte. Ich glaube auch, dass man das so sehen muss. Es ist tatsächlich auch so, dass die Unternehmen das insofern auch als Chance sehen können, weil möglicherweise zu ihren Produkten andere Services mit angeboten werden, die ihre Produkte überhaupt erst attraktiver machen. Es gab ja in der Vergangenheit immer wieder, dass Primärprodukte erst durch Sekundärleistungen spannend wurden. Ein Smartphone ohne großen App Store mit Angeboten von Dritten ist auch nur ein Telefon. Insofern ist das schon eine Chance. Es kann aber auch sein, dass beispielsweise jemand, der im Primärmarkt tätig ist, da weniger erfolgreich ist, aber dafür im Sekundärmarkt tatsächlich hervorragend ist, dass der tatsächlich ein ganz anderes Geschäftsfeld noch zusätzlich mit entwickelt. Insofern kommt da schon Bewegung rein und deswegen vielleicht auch noch mal der Rücksprung, mit dem ich vorher angefangen habe: die Liberalisierung des Telekommunikationsmarktes, beginnend in den 90er Jahren, richtig in den Nullerjahren auch. Da sind ja auch viele neue Geschäftsfelder entstanden. Ich rede jetzt nicht vom Klingeltonmarkt, aber das war auch zeitweise ein Markt, den man hatte, dass die sich verändern. Aber in dieser Öffnungsphase sind neue Geschäftsmodelle entstanden, erfolgreiche Geschäftsmodelle, es ist Geschäft generiert worden, es sind Services angeboten worden. Manche interessiert heute niemand mehr, aus anderen Gründen, aber es lag nicht an der Wechselmöglichkeit.

Gil: Ja, lassen wir das mal auf uns zukommen. Ich bin gespannt, welches vielleicht erste größere Startup sich dem Thema annimmt und da vielleicht wirklich ein spannendes Geschäftsmodell umsetzen wird. Ich würde dir gerne noch ein, vielleicht zwei Fragen zum Abschluss stellen. Was ist aus deiner Sicht, aus der Beratungspraxis heraus, dieser eine Fehler, den man bei der Umsetzung einer solchen Regulierung machen kann oder immer wieder macht? Was ist so das eine, wo du sagen würdest: Bitte nicht schon wieder?

Jens: Ja, genau, ich kann es technisch nicht beurteilen. Deswegen aber dieses, was wir sehr häufig haben: dieses ‘Ich habe es gelesen und ich habe es verstanden.’ Das ist dieses typische: ‘Ich lese das Gesetz aus meinem Selbstverständnis heraus und ich lese darin, was ich lesen möchte.’ Das ist ein wahnsinnig großer Fehler, denn der führt dazu, dass hier tatsächlich dann – überspitzt formuliert – in die falsche Richtung gebaut wird.

Gil: Mhm.

Jens: Zu niedrig, zu hoch, was auch immer. Also dieses ‘Ich habe das Basiswissen’ mit dem klassischen Bias in der Psychologie, aber im AI- und KI-Umfeld sagt man auch der Bias, also aus seiner subjektiven Betrachtung heraus zu interpretieren. Was schon zu lustigen Diskussionen führte, was ein Wechselentgelt ist, und der gleich sagt: ‘Das Wechselentgelt.’ Und wenn er ja, kann man machen. Oder auch exportierbare Daten sind definiert, also es ist so viel definiert, Testdaten. Es ist so viel mit drin, bei dem dann viele Leser, gerade eben die, die sehr schnell ran wollten – und das passiert vor allem dann, deswegen sage ich: Eile mit Weile – wenn der Druck da ist, weil dann ist keine Zeit zur Selbstreflexion, dann kann man auch nicht diskutieren, dann muss man. Deswegen der größte Fehler ist immer der, einen solchen Rechtsakt einfach zu lesen mit dem Anspruch: ‘Ich weiß, was es bedeutet.’

Gil: Okay, dann die letzte Frage an der Stelle: Denken wir mal so in 90 Tagen, also im Zeitrahmen von 90 Tagen. Versuch mal jetzt so ein CTO zu sein. Was ist deine Empfehlung innerhalb der ersten 90 Tage jetzt nach dem Inkrafttreten? Womit sollte ich mich befassen? Organisatorisch vielleicht, was für Maßnahmen? Was wäre dein Schlachtplan für die ersten 90 Tage? Du hast eben schon gesagt: Eile mit Weile, nichts tun ist keine Option.

Jens: Mein Schlachtplan: Wenn wir jetzt davon ausgehen, die ersten 90 Tage sind jetzt in Kraft getreten vor 18 Monaten, die habe ich einfach liegen lassen und beim Anwendungsbeginn fällt mir auf: ‘Ups!’ Und dann erzählt mir der Anwalt: ‘Pass auf, die Übergangsfrist fängt nicht an, die ist jetzt 18 Monate her und abgelaufen, und jetzt brauche ich einen 90-Tage-Actionplan, weil ich keine 18 Monate habe.’ Also nehmen wir mal das Szenario. Ich würde genau dasselbe machen, was ich vor 18 Monaten gemacht hätte, nur intensiver, schneller, also mit mehr Manpower. Ich würde mir anschauen, ausgehend vom Gesetz: Falle ich in den Anwendungsbereich rein? Was habe ich? Was habe ich technisch? Muss ich überhaupt die Pflichten erfüllen? Ja, kann man fast schon antizipieren und sagen: ‘Ja.’ Und dann würde ich mich sehr intensiv mit dem ‘Wie’ beschäftigen. Das würde ich machen und das würde ich nach Möglichkeit nicht nach 90 Tagen, sondern nach den ersten 30 Tagen geklärt haben: Wie geht es überhaupt? Dann vielleicht noch mal 30 Tage: Geht es so sicher? Und dann die letzten 30 Tage mir überlegen: Wie bastele ich es drumherum und wie weit will ich eigentlich gehen? Das ist das, was ich eigentlich vorher schon sagte: sich erstmal selbst die Karten zu legen, technisch, aber vor allem auch im Bezug auf den Schutz der eigenen Assets, sowohl unter dem Aspekt der IT-Sicherheit als auch unter dem Aspekt des Intellectual Property. Und eben immer die Ruhe bewahren. Die 90 Tage in drei Happen einteilen, aber mit dem selben Fahrplan, den ich habe. Als Erstes würde ich mir, glaube ich, wenn ich ganz ehrlich bin – es gibt ja ganz viele Umsetzungsanbieter, die ganz viele tolle, lustige Sachen schon im Netz stehen haben, die auf 18 Monate gestreckt sind – das würde ich mal auf 90 Tage stauchen und dann versuchen, davon ein Drittel umzusetzen.

Gil: Sehr schön, wunderbar. Jens, wir sind am Ende der Folge angelangt. Ich kann nur sagen, vielen herzlichen Dank. Das waren einige Fragen, an denen wir vorbeigekommen sind. Wenn ich ehrlich bin, es gab hier und da noch ein paar mehr. Mal schauen, vielleicht machen wir im Nachgang noch mal etwas in textueller Form, wenn wir das noch veröffentlichen. Ich gehe auf jeden Fall heute schlauer raus, als ich reingegangen bin, so wie es auch beim AI Act im Frühjahr war, als ich dich beim Tech Riders Festival erleben durfte. Vielen Dank für deine Zeit und danke sehr.

Jens: Ja, danke für die Gelegenheit und die Fragen. Es war nett, dabei gewesen zu sein.