Identifikation von schützenswertem Wissen im Zeitalter von Industrie 4.0

Zusammenfassung

Der unternehmensübergreifende Datenaustausch in der Welt von Industrie 4.0 birgt für Unternehmen immense Potenziale. So können Unternehmen wertvolles Wissen über den Einsatz ihrer Produkte gewinnen und ihren Kunden innovative Dienstleistungen anbieten. Umgekehrt können Kunden die Produkte zielgerichteter einsetzen, wenn sie beispielsweise Produktions- und Materialdetails kennen. Doch dabei möchte kein Unternehmen für sich geschäftskritisches Wissen an einen Partner im Wertschöpfungsnetzwerk freigeben. Zu groß ist das Risiko, Einblicke in beispielsweise Forschungs- und Entwicklungsergebnisse zu gewähren oder dem Kunden eine Kostenkalkulation aufgrund des genauen Prozessablaufes zu ermöglichen. Es ergibt sich die Frage, welche Daten bedenkenlos ausgetauscht werden können und in welchen Daten implizit wertvolles Wissen enthalten ist. Aus diesem Grund stellt der vorliegende Beitrag ein Vorgehensmodell zur Identifikation von schützenswertem Wissen vor dem Hintergrund des unternehmensübergreifenden automatisierten Datenaustauschs von Maschinen über Netzwerkplattformen vor. Mit Hilfe des Modells lassen sich Daten und Wissen analysieren und auf Basis der Schutzbedarfe und enthaltenen Potenziale einstufen. Ein möglichst umfangreicher unternehmensübergreifender Datenaustausch bei möglichst geringem Verlust von Know-how soll ermöglicht werden. Anschließend wird die Erprobung des Modells im Rahmen eines Anwendungsbeispiels vorgestellt und ein Ausblick gegeben.

Ausgangslage und Zielsetzung

Die zunehmende Verfügbarkeit digitaler Technologien mit der Vision von durchgängig und vollständig vernetzten und virtualisierten Entitäten inner- und außerhalb von Unternehmen, entlang von Wertschöpfungsketten und Objektlebenszyklen bezeichnet man gemeinhin als vierte industrielle Revolution (Industrie 4.0). Diese unternehmensübergreifende Vernetzung besitzt Potenziale, die deutlich über das häufig angeführte Optimierungsvermögen zur Erschließung von Effizienz- bzw. Produktivitätsreserven oder die Steigerung der unternehmensinternen Flexibilität durch eine technologische Befähigung hinausreichen. Beispielsweise können Unternehmen nicht nur von der direkten Nutzung einer vernetzten Lösung profitieren, wie etwa einer adaptiven Prozessrouting-Lösung. Vielmehr entstehen durch den unternehmensübergreifenden Datenaustausch Potenziale für digitale Services, wie kontinuierliche Remote-Interaktionen und Analytik. So können durch die Gewinnung von Prozessdaten aus der Fertigung eines Bauteilproduzenten deren Betriebsmittellieferanten (z. B. Werkzeughersteller) bei der Fehlerbehebung – nunmehr daten- und damit faktenbasiert – unterstützen und Beratungsleistung zum Einsatz der hauseigenen Produkte anbieten. Dies führt zu höheren Anlagenverfügbarkeiten auf Seiten des Bauteilproduzenten und somit einer Kostenreduktion. Anderseits können Betriebsmittellieferanten durch die Prozessdaten profitieren, indem sie Wissen über den Produkteinsatz ihrer Produkte erlangen und somit die eigene Produktentwicklung – auch zum Nutzen der datenbereitstellenden Kunden – profitiert. Darüber hinaus kann der übergreifende Austausch innovative Lösungen für Predictive Maintenance und Inline-Qualitätskontrollen ermöglichen, um nur einige Beispiele zu nennen. Auch aus diesen Gründen sehen über 80 % der Industrieunternehmen in wichtigen Industrienationen die verstärkte Nutzung von Daten in der Wertschöpfung als eine Top-Priorität. Der Großteil des Potenzials in Deutschland wird dabei dem Maschinenbau, der Automobilindustrie sowie Herstellern elektrischer Ausrüstung zugeschrieben. Damit ist die Auseinandersetzung mit Implikationen von Industrie 4.0 für produzierende, größtenteils mittelständische Unternehmen eine besonders wichtige Aufgabe. Dieses immense Wertschöpfungspotenzial teilt sich in bislang unbekanntem Verhältnis zwischen den Fabrik- und Anlagenausrüstern (Anbietern von Industrie‑4.0‑Lösungen) und den Anwendern von Industrie‑4.0‑Lösungen. Die Unternehmen sind gefordert, sich proaktiv mit den möglichen Auswirkungen auf das Produkt- und Servicespektrum in ihrem Geschäftsfeld auseinanderzusetzen.

Jedoch sehen sich Unternehmen vor dem Hintergrund der absehbar zunehmenden, unternehmensübergreifenden Vernetzung einigen Herausforderungen gegenübergestellt. Insbesondere laufen Unternehmen Gefahr, dass durch die Bereitstellung von Daten geschäftskritisches und damit schützenswertes Wissen das Unternehmen verlässt, wie beispielsweise vertrauliche Firmeninformationen. Die stetige Weiterentwicklung von Methoden zur Analyse großer Datenmengen, Big Data Analytics, führt dazu, dass Unternehmen außerordentlich vorsichtig bei der Freigabe von Daten sind. Bis dato beschäftigen sich nur wenige Projekte und Initiativen mit der unternehmensübergreifenden Vernetzung und dem Austausch von Daten in Wertschöpfungsnetzwerken (z. B. Gaia‑X oder der Industrial Data Space). Insbesondere die Souveränität über die eigenen Daten stellt einen kritischen Erfolgsfaktor solcher Vorhaben dar. Um diese jedoch zu erreichen, ist an erster Stelle ein Verständnis über die eigenen Daten notwendig.

Vor allem in Deutschland stellt der Datenschutz – also der Schutz von Daten vor Missbrauch, unberechtigter Einsicht oder Verwendung, Änderung oder Verfälschung – ein relevantes und sensibles Thema dar. Dabei geht es nicht nur um den Schutz personenbezogener Daten, wie es beispielsweise in der EU-Datenschutzgrundverordnung vorgeschrieben ist, sondern insbesondere auch um Daten, bei denen der Schutzbedarf sich aus rein unternehmerischer Perspektive ergibt, da sie wettbewerbsrelevantes Wissen in sich tragen. Oftmals werden die Potenziale durch gezielten Datenaustausch bewusst nicht realisiert, um schwierig zu überschauende Risiken zu vermeiden. Aus diesem Grund stellt sich die Frage, welche Daten ein Unternehmen austauschen kann, ohne dabei geschäftskritisches Wissen zu gefährden und gleichzeitig einen Mehrwert im eigenen Unternehmen und im Wertschöpfungsnetzwerk zu schaffen.

Der vorliegende Beitrag präsentiert ein auf wissenschaftlichen Grundlagen beruhendes Vorgehensmodell mit direktem Praxisbezug zur Identifikation von schützenswertem Wissen und Potenzialen im Kontext unternehmensübergreifenden Datenaustauschs. So sollen die Potenziale des Datenaustauschs gehoben werden, ohne dass es dabei zu Know-how-Verletzungen kommt. In der Literatur findet sich bisher kein Vorgehensmodell, welches in diesem Kontext ohne Anpassung anwendbar wäre. Ein guter Ansatzpunkt für die Entwicklung eines passenden Vorgehensmodells findet sich aber in der Domäne des Wissensschutzes im Kontext von Produktpiraterie: Das von Bahrs et al. und Vladova et al. vorgeschlagene Vorgehen zum Wissensflussmanagement stellt deshalb die Grundlage für die Ableitung eines für den vorliegenden Kontext angepassten Vorgehensmodells dar. Dieses wurde in enger Zusammenarbeit von Wissenschaft und Praxis weiterentwickelt und validiert. Es ist das Ergebnis einer Reihe von Interviews und Workshops mit Wissenschaftlern und Vertretern zweier Industrieunternehmen – einem Fräswerkzeughersteller und einem Fräswerkzeugnutzer –, die in einer Kunden-Lieferanten-Beziehung stehen und partnerschaftlich den vertrauensvollen Austausch ausgewählter Daten entwickeln. Das Vorgehensmodell wird in der Kooperation der beiden Unternehmen angewendet.

Abschn. 2 beschreibt das Vorgehensmodell. Abschn. 3 demonstriert die Anwendbarkeit. Abschn. 4 gibt Handlungsempfehlungen und einen Ausblick.

Vorgehensmodell

Das angewandte Vorgehen basiert auf dem Modell von Bahrs et al. und Vladova et al., welches die Reduzierung von Produktpiraterie mithilfe von Wissensflussmanagement zum Ziel hat. Aus folgenden Gründen waren Anpassungen des Modells notwendig, damit dieses auf den Kontext des unternehmensübergreifenden Datenaustauschs anwendbar ist: Erstens steht, speziell im Industrie 4.0-Kontext, der Austausch von Daten und nicht von Wissen im Vordergrund. Daten werden aus Zeichen nach den Regeln einer Syntax gebildet. Ordnet man diesen Daten anschließend eine Bedeutung zu, werden Daten zu Informationen. Trotz der Differenzierung von Daten und Informationen wird in diesem Beitrag der Einfachheit halber der Begriff ‚Daten‘ als Sammelbegriff für beide Konzepte verwendet. Wissen wird implizit mit den Daten übermittelt. Im Vorgehen von Bahrs et al. und Vladova et al. ist die Unterscheidung von Daten und Wissen nicht relevant. Da im Rahmen des unternehmensübergreifenden Datenaustauschs aber Daten geteilt und gleichzeitig kritisches Wissen geschützt werden sollen, ist diese Unterscheidung wichtig, weshalb Anpassungen in Schritt 1 und 2 des Vorgehensmodells notwendig sind. Zweitens gehen Bahrs et al. und Vladova et al. in ihrem Modell davon aus, dass Wissen das Unternehmen bereits verlässt, und analysieren den Status Quo im Unternehmen, um den Wissensabfluss anschließend zu kontrollieren. Es werden also ex-post explizit Einzelfälle/Schnittstellen benannt, die einer Kontrolle des Wissensabflusses bedürfen. Im vorliegenden Falle steht beim unternehmensübergreifenden Datenaustausch dagegen nicht im Vordergrund, welches derzeit freigegebene Wissen nicht geteilt werden darf, sondern welche Daten zukünftig ausgetauscht werden können. Somit handelt es sich um eine generalistische, ex-ante Betrachtung, in welchen Daten implizit Wissen stecken könnte. Im Gegensatz zur Produktpiraterie handelt es sich hierbei um wesentlich tiefergehende kontinuierlich aufgezeichnete Prozessdaten mit hoher Abtastung. Dieser Perspektivenwechsel zeigt sich v. a. in Schritt 2 des Vorgehens. Letztlich ist der Ansatz von Bahrs et al. und Vladova et al. auf die Reduzierung von Produktpiraterie ausgerichtet und somit stehen ausschließlich Risiken im Vordergrund. Der unternehmensübergreifende Datenaustausch zwischen den Kooperationspartnern findet jedoch überhaupt erst wegen der möglichen resultierenden Vorteile statt, daher ist neben der Risikobewertung, welche nach wie vor relevant ist, auch eine Bewertung der entstehenden Potenziale vonnöten. Deshalb findet sich auch in Schritt 3 des Vorgehensmodells eine dahingehende Anpassung.

Das vorliegende Modell zur Identifikation von schützenswertem Wissen im Kontext des unternehmensübergreifenden Datenaustauschs besteht aus vier Prozessschritten. In einem ersten Schritt sind die verfügbaren Daten zu identifizieren, ehe diese im zweiten Schritt mit dem ihnen innewohnenden Wissen verknüpft werden. Darauf aufbauend sind im dritten Schritt die Schutzbedarfe des Wissens und Potenziale der Daten zu ermitteln. Im vierten und letzten Schritt kann die Ableitung geeigneter Schutzmaßnahmen für die zum Austausch verfügbaren und relevanten Daten auf Grundlage des enthaltenen, schützenswerten Wissens erfolgen. In der vorliegenden Arbeit wird lediglich ein Ausblick auf diesen Prozessschritt gegeben. Abb. 1 fasst das Vorgehensmodell zusammen.

Schematische Darstellung des Vorgehensmodells zur Identifikation von schützenswertem Wissen im Kontext des unternehmensübergreifenden Datenaustausches

Schritt 1 & 2: Identifikation von Daten und Wissen

Nicht alle in einem Unternehmen potenziell verfügbaren Daten sind auch für Dritte, wie z. B. die Unternehmenspartner, wertvoll. Ebenso gilt, dass aufgrund rechtlicher, technischer, organisatorischer und wirtschaftlicher Rahmenbedingungen nicht alle potenziell für den Datenaustausch relevanten Daten verfügbar sind. Um zu beantworten, welche Daten Potenzial bergen und welche Daten schützenswertes Wissen enthalten, muss zuerst erhoben werden, welche Daten prinzipiell zur Verfügung stehen (Schritt 1).

Zur Identifikation und Erhebung von relevanten Daten werden in Schritt 1 die beteiligten Unternehmen in dem für den Austausch relevanten Teil des Wertschöpfungsnetzwerks systematisch betrachtet. Dazu erfolgt eine Analyse der beteiligten Unternehmen auf unterschiedlichen Ebenen in Anlehnung an Gimpel und Röglinger, indem in den einzelnen Unternehmen die vorhandenen Daten identifiziert und erhoben werden. Dies geschieht in den beteiligten Unternehmen unabhängig voneinander und bedingt je nach Unternehmen unterschiedlich viel Aufwand aufgrund der individuellen Gegebenheiten. Dabei werden von jedem Unternehmen die für den jeweiligen Anwendungsfall sinnvollen Unternehmensdaten identifiziert (Ebene 1). Anschließend können in jedem Unternehmensbereich die relevanten Geschäftsprozesse (Ebene 2) und Prozesskomponenten (Ebene 3) erhoben werden. Jede Prozesskomponente kann nun auf die enthaltenen Informationsquellen (Ebene 4) analysiert werden und die verfügbaren Variablengruppen (Ebene 5) und einzelne Variablen (Ebene 6) erhoben werden. Abb. 2 fasst das Ebenen-Modell zusammen und gibt Beispiele je Ebene an. Die Pfeile in der Abbildung verdeutlichen, dass die Analyse nicht Top-Down erfolgen muss. Auch eine Bottom-Up-Analyse, beginnend mit der Identifikation der einzelnen Variablen oder ein Einstieg beispielsweise von einem konkreten Geschäftsprozess ausgehend, kann durchaus sinnvoll sein.

Ebenen-Modell zur strukturierten Identifikation von Daten und Informationen. (In Anlehnung an Gimpel und Röglinger 2017)

Nachdem die vorhandenen Daten in den beteiligten Unternehmen erhoben wurden, wird anschließend das in ihnen enthaltene geschäftskritische Wissen erfragt (Schritt 2). Dazu werden die zur Identifikation der Daten untersuchten Geschäftsprozesse (Ebene 2) und deren Komponenten (Ebene 3) auf das benötigte Wissen in den Geschäftsprozessen hin untersucht. In Anlehnung an Bahrs et al. und Vladova et al. eignen sich dazu Interviews mit Vertretern der Unternehmen sowohl auf der Senderseite als auch der Empfängerseite der möglichen auszutauschenden Daten. Die Senderseite ist dabei das Unternehmen, welches Daten und Informationen zur Verfügung stellt. Die Empfängerseite stellt das Unternehmen dar, welches Daten und Informationen der Senderseite bezieht und daraus Potenziale erschließt. Da der unternehmensübergreifende Datenaustausch im Normalfall auf Gegenseitigkeit beruht und einen Austausch mit Nutzen auf beiden Seiten darstellt, ist jedes Unternehmen entsprechend Empfänger und Sender. Auf beiden Seiten werden dabei sowohl „Generalisten“, wie beispielsweise Führungskräfte, als auch „Spezialisten“, wie beispielsweise Entwicklungsingenieure, mittels semi-strukturierten Interviews entlang der Geschäftsprozesse, deren Komponenten und Informationsquellen detailliert nach dem vorhandenen Wissen befragt.

Schritt 3: Bewertung von Schutzbedarfen und Potenzialen

Wissen entsteht durch die Verknüpfung von Informationen und der Kenntnis über die Zusammenhänge. Deshalb liegt insbesondere auf der Senderseite der Fokus auf dem geschäftskritischen Wissen, welches in den identifizierten Daten beinhaltet ist. So möchten viele Unternehmen beispielsweise weder Wissen über die Produktionsauslastung oder Preisgestaltung ihrer Produkte teilen, noch Details zu Prototypen und damit verbundenes Wissen über neue Produkte preisgeben. Folglich muss die Senderseite sich zunächst bewusst werden, welches Wissen das Unternehmen auf keinen Fall verlassen darf und nicht für den unternehmensübergreifenden Datenaustausch freigegeben ist. Im dritten Schritt wird aus diesem Grund das verfügbare Wissen dem Schutzbedarf entsprechend eingestuft. Dabei kann das enthaltene Wissen im Wesentlichen schützenswert, bedingt schützenswert und nicht schützenswert sein. Bedingt schützenswertes Wissen ist dabei definiert als das Wissen, welches unter bestimmten Auflagen und Restriktionen ausgetauscht werden kann und somit zur Verhandlungssache wird. Als Anhaltspunkt zur Identifikation von Schutzbedarfen wird Wissen als Ressource betrachtet und das VRIN-Framework zum Einsatz gebracht, welches die von Bahrs et al. und Vladova et al. vorgeschlagenen Kriterien leicht erweitert. Gemäß des VRIN-Frameworks kann Wissen dann einen nachhaltigen Wettbewerbsvorteil bringen, wenn es vier Kriterien erfüllt:

• (I.) es muss wertvoll (valuable) sein, in dem Sinne, dass es Chancen nutzt und/oder Bedrohungen im Umfeld eines Unternehmens neutralisiert,
• (II.) es muss selten (rare) im aktuellen und potenziellen Wettbewerb eines Unternehmens sein,
• (III.) es muss unvollkommen imitierbar (imperfectly imitable) sein, und
• (IV.) es kann keinen strategisch gleichwertigen Ersatz (non-substitutable) für diese Ressource geben, der wertvoll, aber weder selten noch unvollkommen nachahmbar ist.

Aus den Anfangsbuchstaben der englischen Namen der Kriterien ergibt sich das Akronym VRIN. Verletzt eine Variable eines dieser vier Attribute, kann dies ein Anhaltspunkt für einen nur (bedingten) Schutzbedarf oder gar keinen Schutzbedarf sein.

Auf der Empfängerseite liegt indes der Fokus auf der Analyse der enthaltenen Potenziale in den vorhandenen Daten. Steht abschließend fest, welches Wissen auf Senderseite ausgetauscht werden kann und welche Daten in welcher Form zur Verfügung stehen, gilt es zu identifizieren, welche Daten Potenziale für Erkenntnisse auf der Empfängerseite bieten. Dazu werden die identifizierten Daten analysiert und irrelevante Datenpunkte vernachlässigt, sodass sich die Menge aller verfügbaren Daten auf die wirklich relevanten Daten einschränkt.

Anschließend werden die Rollen (Sender und Empfänger) der Unternehmen entsprechend getauscht, so dass ein beidseitiges Bild entsteht (vgl. Abb. 3). Insgesamt ist zu beachten, dass sich Potenziale und Schutzbedarfe mit dem situativen Kontext der Unternehmen verändern können und keine allgemeingültigen konstanten Ausprägungen annehmen. Sowohl Potenziale als auch Schutzbedarfe können vom gleichen Unternehmen je nach Geschäftspartner und wirtschaftlicher Situation anders bewertet werden und unterliegen somit einer gewissen Dynamik.

Fragestellungen und Kriterien für den unternehmensübergreifenden Datenaustausch

Ausblick: Schutzmaßnahmen

Die Einstufung der Schutzbedarfe des enthaltenen Wissens in den relevanten Daten und Informationen zieht die Frage nach potenziellen Schutzmaßnahmen nach sich. Während unkritische Daten bedenkenlos ausgetauscht werden können und geschäftskritische Daten nicht zur Verfügung gestellt werden sollten, bilden bedingt austauschbare Informationen einen Trade-Off. Mit Hilfe geeigneter Schutzmaßnahmen lässt sich evaluieren, welche Daten unter gewissen Bedingungen ausgetauscht werden können. Beispielsweise gibt es eine Vielzahl an Methoden, um das enthaltene Wissen in Daten im Rahmen von Analysen zu schützen. Unter anderem sind dies vergleichsweise einfache Modifikationsmethoden, wie beispielsweise einem Hinzufügen von Rauschen, dem Blockieren ausgewählter Daten, der Aggregation von Daten zu Kennzahlen, oder der Kombination von Daten zu einer gröberen Kategorie. Es stehen aber in der wissenschaftlichen Literatur auch komplexe Methoden, wie heuristische, kryptographische oder rekonstruierende Techniken, zur Verfügung. Moderne technische Ansätze finden sich in Themenfeldern wie etwa Privacy Preserving Data Mining oder Secure Multi-party Computation. Aber auch betriebswirtschaftliche, organisatorische und juristische Ansätze, wie eine vertrauenswürdige dritte Partei für das Matching der Daten aus beiden Unternehmen sowie deren Bewertung und vertragliche Absicherungen sind denkbar.

Anwendungsbeispiel

Das beschriebene Vorgehensmodell wurde in einem Projekt erfolgreich angewendet, was Anwendbarkeit und Wirksamkeit des Vorgehensmodells untermauert. In dem Projekt arbeiten unter anderem zwei Industrieunternehmen zusammen, um den Austausch von Prozess- und Produktdaten zu etablieren. Dabei handelt es sich um das Unternehmen A aus der Automobilbranche, mit Fokus auf einen Teilbereich, in dem Umformwerkzeuge für die Karosserie produziert werden. Hierbei kommen unterschiedliche Werkzeuge des Unternehmens B zum Einsatz, welches sich auf die Herstellung von Fräswerkzeugen spezialisiert hat. Während Unternehmen A gemäß EU-Definition als Großunternehmen gilt, ist Unternehmen B ein mittleres Unternehmen (gemäß KMU-Definition). Beide Unternehmenspartner wurden im Rahmen des Projekts durch sowohl Führungskräfte wie auch ausgewiesene Experten aus der Produktentwicklung bzw. Produktion vertreten. Alle Mitarbeiter brachten dabei langjährige Berufserfahrung und Branchenexpertise mit ein.

Schritt 1 & 2: Identifikation von Daten und Wissen

Zunächst haben sich beide Unternehmen, die im Wertschöpfungsnetzwerk (Ebene 0) in einer Lieferanten-Kunden-Beziehung stehen, sich auf einen möglichen Umfang der Kooperation auf den Ebenen von Unternehmensbereichen (Ebene 1) und Geschäftsprozessen (Ebene 2) geeinigt und sich gegenseitig die dort enthaltenen Prozesskomponenten (Ebene 3) aufgezeigt, um einen ersten Eindruck möglicher Potenziale aus dem Datenaustausch zu bekommen. In Unternehmen B werden metallische Rohlinge, die im Wareneingang zuerst geprüft werden, zu Fräswerkzeugen geschliffen, beschichtet und endvermessen. Diese Fräswerkzeuge kommen anschließend in den Produktionsprozessen des Unternehmens A als Betriebsmittel zum Einsatz. Unternehmen A produziert Formwerkzeuge, welche auf Basis von CAD-Daten und unter Verwendung von CAM-Tools in Bearbeitungszentren gefräst werden. Diesem automatisierten Prozess folgen der manuelle Zusammenbau der gefrästen Komponenten zum Formwerkzeug sowie bei Bedarf weitere Veredelungsschritte. Durch Austausch von Produkt- (Fräswerkzeug) und Produktionsdaten (Formwerkzeugbau) erhoffen sich die beiden Unternehmen sowohl wertvolles Wissen beispielsweise für die Produktentwicklung (Fräswerkzeuge) als auch eine Kostenreduktion in der Produktion (z. B. erhöhte Standzeiten und Vermeidung von Werkzeugbruch).

Sowohl Unternehmen A als auch Unternehmen B erstellten darauf aufbauend intern je eine Liste mit bestehenden Variablen (Ebene 6), welche für die zuvor genannten Ziele potenziell genutzt werden können. Trotz der vorherigen Einschränkung auf einzelne Prozesskomponenten war dies eine sehr aufwendige, detailreiche Aktivität. Über Informationsquellen (Ebene 4) nachzudenken half hierbei immer wieder, um eine Vollständigkeit der Variablen zu erreichen. Fragen waren beispielsweise, welche Daten aus der Maschinensteuerung des Bearbeitungszentrums ausgelesen werden können oder welche Daten in der Endqualitätskontrolle erfasst werden können. Es folgte die Herausforderung, die Daten digital verfügbar zu machen. In den Unternehmen lagen Daten zu Projektbeginn zum Teil nur analog, in unterschiedlichen Datenformaten und/oder lokal in unvernetzten Maschinen vor. Insbesondere ältere Maschinen mussten netzwerkfähig gemacht werden, um bestehende Sensorwerte abrufen zu können. Teils wurde Sensorik nachgerüstet.

Als Resultat von Schritt 1 entstand eine Liste mit je mehreren hundert potenziell für den Austausch relevanten Variablen (Ebene 6), die bei den Unternehmen im Rahmen der zuvor eingegrenzten Prozesskomponenten (Ebene 3) zur Verfügung stehen. Um die Komplexität zu reduzieren, wurden die Variablen gruppiert, um über ganze Variablengruppen diskutieren zu können (Ebene 5). Die Diskussion über Variablengruppen (Ebene 5) stellte sich als handhabbarer heraus als die Diskussion über einzelne Variablen (Ebene 6), aber auch als zielführender als eine Diskussion nur über Informationsquellen (Ebene 4). Das Wechselspiel der Analyse auf Ebenen 4, 5 und 6 brachte in einem iterativen Prozess immer wieder neue Ideen hervor, welche Daten existieren.

Im zweiten Schritt wurde erfasst, welches Wissen bei den Projektpartnern in Bezug auf die eigenen Produkte und die eigene Produktion vorhanden ist und potenziell geschützt werden muss. Dazu wurden Workshops mit je beiden Projektpartnern gesondert durchgeführt. Dabei ging es zunächst jeweils um die Frage, welches Know-how bei den jeweiligen Unternehmen in der eigenen Produktion und Produktentwicklung besteht. Die Diskussionen wurden (analog zur Identifikation der Daten) entlang der zuvor definierten und betrachteten Produktionsprozesse (Ebene 2) und Prozesskomponenten (Ebene 3) geführt. Als Ergebnis entstand in beiden Unternehmen eine Auflistung von vorhandenem Wissen, welches im Folgenden auf die Schutzbedarfe hin analysiert werden konnte. Darüber hinaus zeigte die Durchführung des zweiten Schritts im Rahmen des Projekts, dass die integrierte Aufarbeitung von Daten und Wissen einen effektiven Ansatz darstellt. So unterstützt die Übersicht vorhandener Daten dabei, das vorhandene Wissen im Unternehmer umfassend und zielgerichtet erarbeiten zu können. Umgekehrt ermöglicht die Kenntnis über das vorhandene Wissen eine gute Priorisierung der vorhandenen Daten und welches Wissen in diesen steckt.

Schritt 3: Bewertung von Schutzbedarfen und Potenzialen

Im dritten Schritt lag der Fokus nunmehr darauf zu eruieren, inwiefern die identifizierten Wissenselemente geschäftskritisch sind und entsprechende Schutzbedarfe bestehen. Dies geschah in vier Workshops (siehe Abb. 3, ein Workshop je Pfeil). Das Ergebnis der ersten beiden Workshops zur Identifikation des schützenswerten Wissens zeigte ein klares Bild bei beiden Unternehmenspartnern. In den Unternehmen herrscht ein einheitliches Verständnis, welches Wissen als sensibel und welches als unkritisch angesehen werden kann. Grundsätzlich galt jedoch stets, die Kritikalität zu hinterfragen. Eine wesentliche Aufgabe der Workshopmoderatoren war es deshalb, ein Verständnis für die Kritikalität und den betriebswirtschaftlichen Wertbeitrag des Wissens zu entwickeln. Hierfür diente das VRIN-Framework. Dabei stellte sich heraus, dass nicht jedes Wissenselement grundsätzlich schützenwert ist. Beide Unternehmen schätzten das vorhandene Wissen tendenziell zuerst als schützenswert ein und schwächten ihre Einschätzung im Laufe der Diskussion zum Teil ab, wenn sie erkannten, dass ein oder mehrere der VRIN-Kriterien nicht erfüllt waren. Ein wichtiger Erfolgsfaktor der Diskussion war dabei die Einbindung von fachlichen Experten auf beiden Unternehmensseiten, um die Implikationen der Wissensübertragung offen zu diskutieren.

In den beiden weiteren Workshops wurde den Unternehmen anschließend jeweils die Frage nach den erhofften Potenzialen gestellt. Ziel der Workshops war es herauszufinden, welche Daten des jeweils anderen Projektpartners, für das Unternehmen wertvollen Input bedeuten können. Dabei lag der Fokus vor allem auf potenziellem Wissen zur Kostenreduktion in der Produktion (und damit Effizienzsteigerung) durch eine längere Fräswerkzeugnutzung, als auch der Produkt(weiter-)entwicklung des Fräswerkzeuges durch Erkenntnisse aus der Produktnutzung.

Nachdem die erlangten Erkenntnisse aus den Workshops aufbereitet wurden, trafen sich die Unternehmenspartner zu einem gemeinsamen Konsolidierungsworkshop. Dieser hatte zum Ziel, dass beide Unternehmen im Dialog ein gemeinsames Verständnis über den Austausch der Daten und darin enthaltenen Wissens erlangen. In diesem Rahmen wurde diskutiert, welche Wissenselemente auf Basis der diskutierten Einschätzungen bedenkenlos ausgetauscht werden können und welche Wissenselemente unter Auflagen bzw. welche Elemente nicht ausgetauscht werden sollen. Hierbei stellte sich wiederum die Einbindung der fachlichen Experten als wertvoll für die Diskussion heraus. Es entstand ein umfangreiches Bild, indem die Variablengruppen jedes Unternehmens in Kategorien einsortiert wurden: nicht schützenswerte (z. B. öffentliche) Daten, zum Teil schützenswerte Daten (für den bilateralen, vertrauensvollen Austausch oder Daten, die unter bestimmten Auflagen ausgetauscht werden), und schützenswerte Daten, die nicht ausgetauscht werden. Bei den Workshops stellte sich des Weiteren die situative Abhängigkeit der Bewertung von Potenzialen und Schutzbedarfen durch die beteiligten Unternehmen heraus. Gewisse Daten könnten im Rahmen der üblichen Geschäftstätigkeit beispielsweise als schützenswert und nicht auszutauschen eingeordnet werden. Die Bewertung könnte sich nach einer erneuten Abwägung der Chancen und Risiken allerdings ändern, wenn dadurch etwa eine teure Rückrufaktion vermieden oder eingedämmt werden könnte.

Ausblick: Schutzmaßnahmen

Im Anschluss an den Workshop verknüpften die Unternehmenspartner jeweils intern ihre Variablen mit den identifizierten Wissenselementen. Als Basis diente dazu die Klassifizierung des Wissens aus den Workshops. Als Ergebnis ist auf beiden Seiten eine Liste mit vorhandenen Variablen und einer Klassifizierung von Variablen, die (unter Auflagen) ausgetauscht werden können, entstanden. Für Variablen deren Austausch bestimmte Auflagen erfüllen muss, soll in den kommenden Schritten die Identifikation von geeigneten Schutzmaßnahmen erfolgen.

Ausblick & Handlungsempfehlungen

Dieser Beitrag stellt einen Ansatz zur Identifikation von schützenswertem Wissen in Daten für den unternehmensübergreifenden automatisierten Datenaustausch im Sinne Industrie 4.0 vor, um den berechtigten Produkt- und Know-how Schutz eines jeden Geschäftspartners zu wahren. In den ersten beiden Schritten werden dabei zuerst die verfügbaren Daten in den beteiligten Unternehmen identifiziert sowie das in den betrachteten Prozessen geschäftskritische Wissen erhoben. Im dritten Schritt werden anschließend sowohl Potenziale für den jeweiligen Unternehmenspartner wie auch Schutzbedarfe für das bereitstellende Unternehmen abgeleitet. Das Vorgehensmodell stellt einen Schritt auf dem Weg hin zu einer dynamischen und vernetzten Industrie dar. Insbesondere die Ergebnisse, welche im Rahmen des Anwendungsbeispiels entstanden, haben gezeigt, dass gewisse Produkt- und Produktionsdaten – zumeist nach Aufbereitung von Rohdaten – für den vor- bzw. nachgelagerten Unternehmenspartner durch ein Unternehmen bedenkenlos freigegeben werden und die Wertschöpfung erhöhen können. In diesem Sinne stellt dieser Beitrag einen sogenannten „Enabler“ dar, um die langfristige Vision durchgängig und vollständig vernetzter und virtualisierter Entitäten inner- und außerhalb von Unternehmen entlang von Wertschöpfungsketten und Objektlebenszyklen zu erreichen.

Das Vorgehensmodell muss in weiteren Praxis-Projekten angewendet und mit den resultierenden Erkenntnissen generalisiert und weiterentwickelt werden. Insgesamt herrscht heute noch ein Mangel an Konzepten und Standards, die den unternehmensübergreifenden Datenaustausch im Alltag ermöglichen. Neben Methoden zur Bewertung von Risiken und Potenzialen sind dies insbesondere Konzepte und Anreize welche die Wertschöpfung für alle beteiligten Unternehmen erhöhen. Herausforderungen stellen dabei insbesondere Legacysysteme und die Komplexität moderner Wertschöpfungsnetzwerke dar. Darüber hinaus ist das ökonomische Potenzial bisweilen nicht umfänglich quantifizierbar, bevor man den Datenaustausch erprobt hat und beispielsweise die Qualität von Machine-Learning-Ansätzen auf geteilten Daten demonstrieren kann. Eine integrierte techno-ökonomische Abwägung der Potenziale des unternehmensübergreifenden Datenaustauschs und der damit verbundenen Risiken setzt weitere Untersuchungen von Konzepten und Methoden voraus, die in weiteren Arbeiten angegangen werden sollten.

In Zukunft wird die Nachfrage nach dem Austausch von Daten entlang der Wertschöpfungsketten und die Vernetzung dieser miteinander weiter zunehmen. Dabei sollten Unternehmen nicht grundsätzlich eine protektionistische Haltung einnehmen und dem Austausch von Unternehmensdaten per se absagen, da der Austausch von Daten Wertschöpfungspotenziale verspricht. Hierbei ist darauf zu achten, sich einen Teil des Werts der eigenen Daten zu sichern und nicht unbedarft geschäftskritisches Wissen preiszugeben.

Zur einfacheren Lesbarkeit wurden die Quellenverweise entfernt.

Adler, L., Frank, A., Gimpel, H. et al.; Auf dem Weg zum vertrauensvollen, unternehmensübergreifenden automatisierten Datenaustausch von Maschinen – Identifikation von schützenswertem Wissen im Zeitalter von Industrie 4.0. HMD; 2021

https://link.springer.com/article/10.1365/s40702-020-00704-w

http://creativecommons.org/licenses/by/4.0/deed.de

Eine Analyse aus Sicht des Datenschutzes

1 Hintergrund

1.1 Problemstellung

Ein Konfliktpunkt in der Softwareentwicklung in Bezug auf den Datenschutz ist die Nutzung von personenbezogenen Originaldaten (Echtdaten) für den Softwaretest. Die Herausforderung dabei besteht darin, dass die Originaldaten üblicherweise für die relevanten Geschäftsprozesse, aber nicht für den Test erhoben wurden, und auch die Information der Betroffenen oder ggf. deren Einwilligung die Nutzung der Daten für den Test von Software normalerweise nicht ausdrücklich einschließen.

Bei einem gewünschten Softwaretest mit Originaldaten sind daher folgende Fragen zu klären:

• Ist die Nutzung personenbezogener Daten für den Softwaretest erlaubt? Auf welcher Rechtsgrundlage und unter welchen Rahmenbedingungen?
• Inwieweit müssen die Betroffenen über die Nutzung ihrer Daten für den Softwaretest informiert werden?

Diese Fragen sollten in diesem Beitrag analysiert und beantwortet werden.

Zusätzlich handelt es sich bei der Softwareentwicklung oft um eine Form der Auftragsverarbeitung, sodass die dafür üblichen Anforderungen, insbesondere der Abschluss einer entsprechenden Vereinbarung zwischen dem Verantwortlichen und der Softwareentwicklungsorganisation, erfüllt werden müssen. Hier gibt es aber keine Besonderheiten in Bezug auf den Softwaretest, so dass auf diesen Aspekt nicht weiter eingegangen werden soll.

1.2 Warum Testen mit Originaldaten?

Bevor wir die genannten Fragen beantworten können, stellt sich zuerst einmal die Frage nach dem Zweck des Tests mit Originaldaten. Für die folgende Diskussion gehen wir von einem typischen einfachen Testablauf mit den Stufen Modultest (Unittest), Integrationstest und Systemtest aus.

Für die ersten beiden Teststufen ist ein Test auf Basis von Originaldaten nicht geeignet, da hier normalerweise keine Soll-Ergebnisse für einen Soll-Ist-Vergleich vorliegen, der aber einen Kernbestandteil der meisten Testformen bildet. Erst wenn die einzelnen Module (Modultest), deren Zusammenwirken (Integrationstest) sowie das gesamte zu entwickelnde System (erster Teil des Systemtests) gründlich mit künstlichen Testdaten getestet wurden und kaum noch Fehler aufweisen, kommt schon aus Sicht der Testmethodik ein Test mit Originaldaten in Frage. Bei diesem letzten Teil des Systemtests geht es um die Prüfung, ob alle real auftretenden Sonderfälle auch von der entwickelten Software berücksichtigt werden. Dabei wird in der Praxis meist nur geprüft, dass die Software die Daten ohne Fehlermeldungen durchläuft, da aufgrund fehlender überprüfter Soll-Ergebnisse eine Prüfung der funktionalen Korrektheit der Ergebnisse meist nicht möglich ist.

Gemäß dem Grundsatz der Datenminimierung sollte auch dieser Teil des Systemtestes nach Möglichkeit mit anonymisierten Daten durchgeführt werden, aber je nach Rahmenbedingungen und Art des Systems reicht ein solcher Test nicht immer aus. Ein Bedarf an einem Test mit Originaldaten besteht beispielsweise bei einer Datenmigration in ein neues Kernsystem einer Versicherung. Hier bestehen einerseits hohe Anforderungen an die Korrektheit bzw. die systematische Prüfung des neuen Systems, die ggf. sogar gegenüber der zuständigen Aufsichtsbehörde nachzuweisen ist, andererseits viele über Jahre entstandene Sonderfälle, die in der Entwicklung möglicherweise nicht alle bekannt sind.

Auch bei einer Entscheidung für eine Anonymisierung der Originaldaten ist zu berücksichtigen, dass durch die bei der Anonymisierung verursachte Veränderung der Daten möglicherweise der Testzweck nicht mehr erreicht wird, weil beispielsweise bestimmte Abhängigkeiten oder unerwartete Konstellationen in den anonymisierten Daten nicht mehr vorhanden sind.

Eine Pseudonymisierung der Daten ist in diesem Kontext dagegen nicht relevant, da die Möglichkeit einer späteren Zuordnung der Daten zur Person für den betrachteten Zweck des Testens keinen Nutzen bringt. Wenn ein Test mit pseudonymisierten Daten möglich ist, dann ist er ohne weitere Einschränkung auch mit anonymisierten Daten möglich, und daher sollte immer diese stärkere Schutzmaßnahme angewendet werden. Daneben werden Originaldaten auch für die Analyse von Fehlermeldungen und den Test der Fehlerkorrektur genutzt, wenn ein Fehler sonst nicht nachzuvollziehen ist.

Ein weiterer Anwendungsbereich des Tests mit Originaldaten betrifft den Performanztest, hier wie üblich als Bestandteil des Systemtests betrachtet, bei dem es in erster Linie um die Geschwindigkeit geht, mit der eine große Menge von Daten bearbeitet wird. Hier ist es grundsätzlich möglich, aber ggf. sehr schwierig, eine angemessene Menge von Testdaten einschließlich der benötigten Sonderfälle künstlich zu erzeugen, sodass auch hier oft der Wunsch nach der Nutzung von Originaldaten für den Test besteht.

Bisher ging die Betrachtung davon aus, dass der Test in einer separaten Testumgebung durchgeführt wird und nicht in der Produktivumgebung. Dies ist normalerweise schon aus testfachlicher Sicht erforderlich, aber es gibt Ausnahmen, insbesondere beim Test von Fehlerkorrekturen, in denen das nicht sinnvoll möglich ist, so dass in Einzelfällen auch ein Test in der Produktivumgebung erforderlich sein kann.

1.3 Warum kein Testen mit Originaldaten?

Gegen das Testen mit Originaldaten spricht, dass im Allgemeinen wesentlich mehr Personen Zugriff auf Testsysteme haben als das bei Produktivsystemen der Fall ist. Auch werden die Testergebnisse oft weitergegeben, ohne dass geprüft wird, ob sie personenbezogene Daten enthalten. Darüber hinaus wird durch eine solche Verarbeitung die Gefahr von Datenpannen vergrößert, da die Daten auf zusätzlichen und noch nicht abschließend entwickelten und daher fehleranfälligen Systemen eingesetzt werden.

Das gilt insbesondere, wenn der Test nicht in einer separaten Testumgebung, sondern in der Produktivumgebung durchgeführt wird. Darüber hinaus ist zu berücksichtigen, dass Testdatenhäufig nicht die gleiche Sorgfalt entgegengebracht wird wie das für personenbezogene Daten im Produktivbetrieb gefordert und üblich ist.

1.4 Grundlegende Voraussetzungen

Aufgrund der vorgenannten Risiken sowie des Grundsatzes der Datenminimierung sollte zwingend geprüft werden, ob (a) fiktive Testdaten generiert oder (b) die Originaldaten anonymisiert werden können. Die weitere Diskussion in diesem Beitrag geht davon aus, dass diese Prüfung stattgefunden hat mit dem Ergebnis, dass der Testzweck mit fiktiven Testdaten oder anonymisierten Originaldaten nicht oder nicht angemessen erreicht werden kann.

Darüber hinaus ist es wichtig, eine angemessene und dem Produktivbetrieb vergleichbare Sicherheit der Daten bei der Nutzung von Originaldaten für den Softwaretest sicherzustellen, denn für die geforderte Datensicherheit macht es keinen Unterschied, ob Daten zu Produktiv- oder zu Testzwecken verwendet werden. Beispielsweise muss der Zugriff auf die im Test verwendeten Originaldaten restriktiv gehandhabt werden und darf nur einer möglichst kleinen Gruppe von Testern und Entwicklern erlaubt werden. Nach Bedarf ist dies durch eine Datenschutz-Folgenabschätzung oder eine Abstimmung mit der jeweils zuständigen Datenschutzbehörde abzuklären.

2 Unterschiedliche Ausgangssituationen

im Rahmen von Softwaretests

2.1 Beziehung zwischen ursprünglichem Zweck und Zweck des Tests

Für die Beantwortung der vorgenannten Ausgangsfragen müssen aus Sicht des Datenschutzes folgende Ausgangssituationen und Rahmenbedingungen unterschieden werden:

1. Die ursprüngliche Verarbeitung basiert auf einer Einwilligung als Rechtsgrundlage.

2. Die ursprüngliche Verarbeitung beruht nicht auf einer Einwilligung; der Test mit Originaldaten ist Bestandteil des ursprünglich definierten Zwecks.

3. Die ursprüngliche Verarbeitung beruht nicht auf einer Einwilligung; der Test mit Originaldaten ist vereinbar (kompatibel) mit dem ursprünglich definierten Zweck.

4. Die ursprüngliche Verarbeitung beruht nicht auf einer Einwilligung; der Test mit Originaldaten ist nicht vereinbar mit dem ursprünglich definierten Zweck.

Aus der Entscheidung, welcher dieser Fälle vorliegt, ergeben sich nach der DSGVO eine Reihe von sehr unterschiedlichen Konsequenzen für die betrachtete Problemstellung, die im Folgenden ab Abschnitt 3 analysiert werden. Zuerst ist aber eine genauere Unterscheidung erforderlich, wann welcher der genannten Fälle gegeben ist.

2.2 Ursprüngliche Verarbeitung auf Grundlage einer Einwilligung

Diese Fallgruppe ist separat zu betrachten, denn eine wesentliche Eigenschaft einer gültigen Einwilligung ist ihre Bestimmtheit, d. h., wenn Betroffene in eine bestimmte Verarbeitung einwilligen, dann sind diese Verarbeitung und ihr Zweck relativ restriktiv zu interpretieren. Daher ist dieser Fall bei der Definition einer kompatiblen Zweckänderung in Art. 6 Abs. 4 DSGVO ausdrücklich ausgeschlossen. Die Konsequenzen, die sich daraus ergeben, werden in Abschnitt 3 näher betrachtet.

2.3 Test als Bestandteil des ursprünglichen Zwecks

Die für den Softwaretest herangezogenen personenbezogenen Daten werden üblicherweise für einen bestimmten Verarbeitungszweck erhoben, bei dem der Test nicht ausdrücklich enthalten ist. Auch dabei stellt sich aber die Frage, ob es sich bei der Nutzung der Daten für den Softwaretest in jedem Fall um eine Zweckänderung handelt: Unabhängig davon, ob die Verarbeitung auf einer Einwilligung (hier nicht betrachtet) oder einer anderen Rechtsgrundlage beruht, haben die Betroffenen ihre Daten ausdrücklich oder implizit für eine bestimmte Verarbeitung bereitgestellt, und um diese Verarbeitung durchführen zu können, benötigt der Verantwortliche angemessen entwickelte und getestete IT-Systeme.

Daraus lässt sich folgern, dass der Test mit Originaldaten in diesem Fall dem ursprünglich definierten Zweck der Verarbeitung dient, es sich also um keine Zweckänderung handelt. Für die sehr ähnliche Verarbeitung zur „Wahrnehmung von Aufsichts- und Kontrollbefugnissen“ wurde in § 14 Abs. 3 BDSG a. F. explizit formuliert, dass es sich hierbei nicht um eine Zweckänderung handelt. Voraussetzung dafür ist, dass das zu testende System wirklich dem Zweck der ursprünglichen Verarbeitung dient, es sich also um eine Weiterentwicklung, Fehlerkorrektur oder Migration auf eine neue technische Basis handelt und nicht um eine komplett neue Funktionalität. Außerdem haben wir den oben behandelten Fall einer Verarbeitung auf Basis einer Einwilligung hier ausgeschlossen. Ob diese Folgerung wirklich zulässig ist, ist umstritten, aber nach Einschätzung der Autoren gibt es gute Argumente diese Ansicht zu vertreten.

2.4 Vereinbarkeit des Testens mit dem ursprünglichen Verarbeitungszweck

2.4.1 Vereinbarkeitsprüfung

Wenn der Test nicht Bestandteil des ursprünglich definierten Zwecks ist, erlaubt der Grundsatz der Zweckbindung (Art. 5 Abs. 1 lit b) i.V.m. Art. 6 Abs. 4 DSGVO eine Zweckänderung, wenn der neue Zweck mit dem ursprünglichen Zweck vereinbar ist. Der Grundsatz der Zweckbindung ist daher nicht ganz korrekt benannt, da er nicht wirklich eine Zweckbindung fordert, sondern eine Zweckvereinbarkeit.

Um zwischen den oben eingeführten Fällen 3 und 4 und den daraus folgenden Konsequenzen zu unterscheiden, ist also eine Prüfung erforderlich, ob der neue Zweck des Testens mit dem ursprünglich definierten Zweck der Verarbeitung vereinbar ist. Die dafür anzuwendenden Kriterien sind in Art. 6 Abs. 4 DSGVO wie folgt definiert: Zur Feststellung, ob der neue Verarbeitungszweck mit dem ursprünglichen vereinbar ist, berücksichtigt der Verantwortliche
„unter anderem a) jede Verbindung zwischen den Zwecken, für die die personenbezogenen Daten erhoben wurden, und den Zwecken der beabsichtigten Weiterverarbeitung, b) den Zusammenhang, in dem die personenbezogenen Daten erhoben wurden, insbesondere hinsichtlich des Verhältnisses zwischen den betroffenen Personen und dem Verantwortlichen, c) die Art der personenbezogenen Daten, insbesondere ob besondere Kategorien  personenbezogener Daten gemäß Artikel 9 verarbeitet werden oder ob personenbezogene Daten über strafrechtliche Verurteilungen und Straftaten gemäß Artikel 10 verarbeitet werden, d) die möglichen Folgen der beabsichtigten Weiterverarbeitung für die betroffenen Personen, e) das Vorhandensein geeigneter Garantien, wozu Verschlüsselung oder Pseudonymisierung gehören kann.“

Zu beachten ist, dass diese Kriterienliste nicht abschließend ist und außerdem die Kriterien erheblichen Interpretationsspielraum erlauben. Im Folgenden soll daher die genannten Kriterien im Kontext des Softwaretests mit Originaldaten näher untersucht werden.

2.4.2 Bedeutung der Kriterien beim Softwaretest

Kriterium a) betrachtet die Verbindung zwischen den ursprünglichen Zwecken der Datenerhebung und den Zwecken der Weiterverarbeitung, hier also des Testens. Eine enge Verbindung besteht, wenn das zu testende System dem gleichen Zweck wie die ursprüngliche Verarbeitung dient, es sich also um eine Weiterentwicklung, Fehlerkorrektur oder Migration auf eine neue technische Basis handelt.

Handelt es sich dagegen um eine Entwicklung komplett neuer Funktionalität, so ist die Verbindung entsprechend geringer. Kriterium b) betrachtet den Kontext, in dem die Originaldaten erhoben wurden, und die Frage, ob es den vernünftigen Erwartungen der Betroffenen entspricht, die erhobenen Daten auch für den Test zu verwenden. Wenn beispielsweise bei den Informationen gemäß Art. 13 bzw. 14 DSGVO eine sehr restriktive Zweckbindung beschrieben wurde, wird eine Nutzung für den Test den vernünftigen Erwartungen eher widersprechen. Soweit das nicht der Fall ist, wird zwar kaum ein Betroffener bei der Information über die ursprüngliche Verarbeitung daran denken, dass auch ein IT-System entwickelt und getestet werden muss, um diese Verarbeitung durchzuführen, aber es wird i. A. auch nicht im Widerspruch zu seinen Erwartungen stehen.

In Kriterium c) ist die Art der personenbezogenen Daten zu berücksichtigen. Handelt es sich bei den für den Test zu nutzenden Originaldaten um personenbezogene Daten besonderer Kategorien, um Daten über strafrechtliche Verurteilungen oder um Daten von Kindern, dann ist eine Vereinbarkeit des Testens in der Regel zu verneinen. Speziell für den Fall der personenbezogenen Daten besonderer Kategorien kommt dazu, dass hier die ursprüngliche Verarbeitung gemäß Art. 9 DSGVO oft auf einer Einwilligung basiert, und in diesem Fall sind die Vereinbarkeitskriterien nicht anwendbar.

Für das oben eingeführte Beispiel des Tests einer Datenmigration in ein neues Kernsystem einer Versicherung bedeutet das, dass der Test mit Originaldaten in der Regel nicht mit dem ursprünglichen Zweck vereinbar ist.

Kriterium d) betrachtet die Folgen der Nutzung von Originaldaten beim Testen für die Betroffenen. Negative Folgen können weitgehend minimiert werden, sofern sichergestellt wird, dass der Zugriff auf die im Test verwendeten Originaldaten angemessen restriktiv gehandhabt und die Daten vor unberechtigtem Zugriff geschützt sind. Umgekehrt hat ein gründlicher Test sogar positive Auswirkungen auf die Betroffenen, da damit die Wahrscheinlichkeit einer Fehlfunktion des Systems und damit von Fehlern bei der Verarbeitung ihrer Daten reduziert wird.

Schließlich fordert Kriterium e) die Berücksichtigung geeigneter Garantien, wozu in diesem Fall insbesondere restriktive Zugangskontrollen gehören. Dagegen sind die beispielhaft genannten Garantien einer Verschlüsselung oder Pseudonymisierung hier nicht geeignet. Eine Verschlüsselung würde die Nutzung der Daten für den Test verhindern, während eine Pseudonymisierung, wie oben erläutert, beim Test immer durch eine Anonymisierung ersetzt werden sollte.

2.4.3 Sonderfall: Verarbeitung zu Archiv-, Forschungs- oder statistischen Zwecken

Neben einer Verarbeitung personenbezogener Daten zu einem anderen Zweck als dem ursprünglich vorgesehenen nach Art. 6 Abs. 4 DSGVO, bietet Art. 5 Abs. 1 lit. b i. V. m. Art. 89 Abs. 1 DSGVO eine zusätzliche Rechtsgrundlage für Weiterverarbeitungen für Archiv- oder Forschungszwecke:

„… eine Weiterverarbeitung für im öffentlichen Interesse liegende Archivzwecke, für wissenschaftliche oder historische Forschungszwecke oder für statistische Zwecke gilt gemäß Artikel 89 Absatz 1 nicht als unvereinbar mit den ursprünglichen Zwecken („Zweckbindung“);“

Einer gesonderten Kompatibilitätsprüfung bedarf es in diesen Fällen nicht, allerdings ist dieser Sonderfall für den hier betrachteten Softwaretest kaum relevant.

3 Ursprüngliche Verarbeitung auf Basis einer Einwilligung

Sofern die ursprüngliche Verarbeitung auf der Rechtsgrundlage einer Einwilligung stattfindet, die u. a. durch ihre Bestimmtheit gekennzeichnet ist, kann die Nutzung der personenbezogenen Daten für den Test nur dann Bestandteil des ursprünglichen Verarbeitungszwecks sein, wenn diese Nutzung explizit in der Einwilligung benannt ist – eine Konstellation, die praktisch wohl nur in Ausnahmefällen vorkommen wird. Ist das aber der Fall, dann ist auch eine Rechtsgrundlage für den Test vorhanden und eine zusätzliche Information der Betroffenen nicht erforderlich, da sie schon beim Einholen der Einwilligung erfolgt sein muss. Bis auf den genannten Ausnahmefall ist die Nutzung der Originaldaten für den Test aber nicht möglich bzw. benötigt sie eine neue, eigene Einwilligung. Da aber viele Betroffene eine solche Einwilligung nicht erteilen werden, kommt eine Nutzung der Originaldaten in diesem Fall nicht in Frage, zumal dabei noch berücksichtigt werden müsste, dass eine erteilte Einwilligung möglicherweise wieder zurückgezogen wird.

4 Test als Bestandteil des ursprünglichen Zwecks

Der Test als Bestandteil des ursprünglich definierten Zwecks ist aus Datenschutzsicht am einfachsten zu behandeln. In diesem Fall ist die Rechtsgrundlage für die Nutzung der Originaldaten für den Test bereits vorhanden, und auch eine separate Information der Betroffenen ist nicht erforderlich. Ist man sich daher von Anfang an bewusst, dass die Daten auch für Tests eingesetzt werden sollen, sollte man dies bereits zu Beginn bei der Information der Betroffenen berücksichtigen, und die Nutzung zum Test ist damit unproblematisch.

5 Test als mit dem ursprünglichen Zweck vereinbare Verarbeitung

5.1 Notwendigkeit einer Rechtsgrundlage bei einer kompatiblen Zweckänderung

Umstritten ist, ob neben dem beschriebenen Kompatibilitätstest bei einer kompatiblen Zweckänderung noch weitere Voraussetzungen zu erfüllen sind. Verlangt wird teilweise, dass zusätzlich zu den Kriterien nach Art. 6 Abs. 4 DSGVO auch die allgemeinen Voraussetzungen der Verarbeitung personenbezogener Daten nach Art. 6 Abs. 1 DSGVO zu erfüllen sind, da jede Verarbeitung nach Art. 5 Abs. 1 DSGVO rechtmäßig sein muss. Dies steht jedoch im Widerspruch zu den Vorgaben der DSGVO in Erwägungsgrund 50 S. 2, der besagt, dass gerade „keine andere gesonderte Rechtsgrundlage erforderlich ist als diejenige für die Erhebung der personenbezogenen Daten“.

Gegen die Forderung nach einer eigenen Rechtsgrundlage für die kompatible Weiterverarbeitung spricht, dass sie im Fall einer Zweckänderung zu höheren rechtlichen Anforderungen führt als bei der ursprünglichen Verarbeitung, nämlich sowohl der Zweckvereinbarkeit als auch einer Rechtsgrundlage gemäß Art. 6 Abs. 1 DSGVO.

Da derzeit unklar ist, welche rechtliche Meinung sich durchsetzen wird, gehen wir im Folgenden davon aus, dass eine zusätzliche Rechtsgrundlage erforderlich ist. Sollte das nicht der Fall sein, entfällt die in Abschnitt 5.2 beschriebene Prüfung der Rechtmäßigkeit.

5.2 Rechtsgrundlage

Als Rechtsgrundlage für den Softwaretest mit Originaldaten kommt, bis auf seltene Sonderfälle, praktisch nur das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DSGVO in Frage. Um die Rechtsgrundlage des berechtigten Interesses anwenden zu dürfen, müssen folgende Checkpunkte überprüft werden:

• Berechtigtes Interesse: Hat der Verantwortliche ein berechtigtes Interesse an der Nutzung der Originaldaten für den Test?
• Erforderlichkeit: Ist die Nutzung der Daten erforderlich (und nicht nur nützlich) für den angestrebten Zweck der Verarbeitung?
• Interessenabwägung: Überwiegen die Interessen des Verantwortlichen auf Nutzung der Originaldaten für den Test die Interessen der Betroffenen, dass ihre Daten nicht für diesen Zweck eingesetzt werden?

5.2.1 Berechtigtes Interesse

Ein berechtigtes Interesse des Verantwortlichen, die Software gründlich zu prüfen, liegt offensichtlich vor.

5.2.2 Erforderlichkeit

Um sich auf die wirklich erforderliche Verarbeitung zu beschränken, den Grundsatz der Datenminimierung umzusetzen und die Auswirkungen möglichst gering zu halten, muss der Zugriff auf die Testdaten sehr restriktiv gehandhabt werden, und es müssen geeignete technische und organisatorische Maßnahmen umge- setzt werden, so dass nur diejenigen Personen Zugriff auf die Testdaten bekommen, die diesen wirklich benötigen.

In einigen Fällen ist sogar ein externer Nachweis des gründlichen Tests der Software, evtl. gegenüber einer Aufsichtsbehörde, gefordert. Dies gilt beispielsweise bei der bereits angesprochenen Datenmigration in ein neues Kernsystem einer Versicherung, und in einem solchen Fall liegt ein hoher Grad der Erforderlichkeit eines Tests mit Originaldaten vor.

5.2.3 Interessenabwägung

Soweit die genannten Maßnahmen zur Minimierung der Auswirkungen umgesetzt sind, wird es meist aus Sicht der Betroffenen keine gravierenden Gründe geben, die gegen eine solche Nutzung sprechen, auch wenn Ausnahmen und Sonderfälle natürlich immer möglich sind. Im Gegenteil ist es ja sogar meist im Interesse der Betroffenen, dass das System, mit dem ihre Daten verarbeitet werden, gründlich getestet wird und später korrekt funktioniert.

5.2.4 Zusammenfassung

Wenn der hier betrachtete Fall vorliegt und der Test mit Originaldaten eine mit dem ursprünglichen Zweck vereinbare Verarbeitung darstellt, dann ist die Erforderlichkeit dieser Tests sicherzustellen, was im Wesentlichen aber bereits bei der Prüfung der Zweckvereinbarkeit überprüft wurde. Ergänzend dazu muss die IT-Sicherheit der Daten durch geeignete technische und organisatorische Maßnahmen, insbesondere Zugriffsbeschränkungen, sichergestellt werden.

5.3 Informationspflicht

Gemäß Art. 13 Abs. 3 DSGVO bzw. Art. 14 Abs. 4 DSGVO besteht eine Informationspflicht des Verantwortlichen gegenüber den Betroffenen bei einer (erlaubten) Zweckänderung. Im konkreten Fall bedeutet das, dass der Verantwortliche den Betroffenen Informationen über die geplante Nutzung ihrer Daten für den Test zur Verfügung stellen muss, zusätzlich zur ursprünglichen Information über die ursprünglich geplante Verarbeitung dieser Daten.

Diese Forderung gilt unabhängig davon, ob für den Test eine eigene Rechtsgrundlage erforderlich ist oder nicht. Das stellt in der Praxis eine erhebliche Herausforderung dar, denn es handelt sich typischerweise um eine Vielzahl von Betroffenen, und nicht immer liegen entsprechende Kontaktdaten vollständig vor.

6 Test als nicht mit dem ursprünglichen Zweck vereinbare Verarbeitung

Wenn der Test mit Originaldaten nicht mit dem ursprünglichen Zweck vereinbar ist, dann ist dafür sicher eine eigene Rechtsgrundlage erforderlich, bei der es sich aber, analog Abschnitt 5.2, um das berechtigte Interesse handeln könnte.

Unklar ist, ob dafür eine neue Erhebung der Daten erforderlich ist, was diesen Test in den meisten Fällen praktisch unmöglich machen würde. Das führt zurück zu der in Abschnitt 5.1 diskutierten Notwendigkeit einer eigenen Rechtsgrundlage für eine kompatible Verarbeitung.

• Angenommen es ist eine eigene Rechtsgrundlage für eine kompatible Verarbeitung erforderlich. Dann kann alleine eine neue Rechtsgrundlage für die nicht kompatible Verarbeitung nicht ausreichen, da sonst die Vereinbarkeitsprüfung überflüssig wäre. Hier ist also davon auszugehen, dass eine Verarbeitung der bestehenden Daten trotz der neuen Rechtsgrundlage nicht erlaubt wäre, sondern die Daten neu erhoben werden müssen.
• Ist dagegen für eine kompatible Verarbeitung keine eigene Rechtsgrundlage erforderlich, so führt die fehlende Vereinbarkeit dazu, dass eine Rechtsgrundlage für den neuen Zweck, hier also den Test mit Originaldaten, erforderlich wird. In diesem Fall ist davon auszugehen, dass die Vereinbarkeitsprüfung genau für diese Unterscheidung gedacht ist und bei einer vorhandenen neuen Rechtsgrundlage die Originaldaten ohne Neuerfassung genutzt werden dürfen.

7 Zusammenfassung

Ein Test mit Originaldaten ist unter sehr restriktiven Voraussetzungen und Rahmenbedingungen möglich, auch wenn er gemäß dem Grundsatz der Datenminimierung nach Möglichkeit vermieden werden sollte. Wichtigste Voraussetzungen sind, dass der Testzweck nicht mit fiktiven oder anonymisierten Daten erreichbar ist, dass die ursprüngliche Verarbeitung auf einer anderen Rechtsgrundlage als einer Einwilligung basiert und dass der Test sehr direkt diese ursprüngliche Verarbeitung unterstützt, idealerweise einen Bestandteil des ursprünglichen Verarbeitungszwecks bildet, sowie die zusätzlichen Risiken für die Betroffenen möglichst gering gehalten werden, insbesondere durch geeignete technische und organisatorische Maßnahmen zur IT-Sicherheit und restriktive Zugriffsbeschränkungen.

Ralf Kneuper, Sven Jacobs; Datenschutz und Datenrecht DuD; 03.2021

https://link.springer.com/article/10.1007/s11623-021-1411-8

http://creativecommons.org/licenses/by/4.0/deed.de