KI-ULTRA
Leitfäden
Hier finden Sie die beiden KI-ULTRA Leitfäden. Sie umfassen Handlungsempfehlungen und Referenzwerkzeuge wie z. B. Arbeitsvorlagen für beteiligte Personen im Rahmen der KI-Einführung.
Werfen Sie jetzt einen Blick in die Leitfäden
Leitfaden zu Strategie und Wandel für KI-Einsatz
Leitfaden lesen
Leitfaden zur Durchführung
von KI-Projekten
Leitfaden lesen
Leitfaden zur Durchführung von KI-Projekten
Menschenzentrierung von der Idee bis zur Anwendung
Einleitung
So unterschiedlich Anwendungen der Künstlichen Intelligenz (KI) sind, so umfangreich sind ihre betrieblichen Erfolgspotenziale. KI-Anwendungen können z. B. dazu beitragen, neue Geschäftsfelder zu erschließen, effizienter zu arbeiten, die Produktqualität zu verbessern, die Kundenbindung zu stärken und die menschliche Arbeit gesünder und sicherer zu gestalten. Dies fördert eine nachhaltige Entwicklung der Organisation.
Der damit einhergehende technologische, organisationale, soziale und kulturelle Wandel stellt eine umfassende Gestaltungsaufgabe dar, die von allen beteiligten Personen in Unternehmen, Verbänden, Gewerkschaften, Politik und Bildungseinrichtungen erhebliche Anstrengungen erfordert. Wenn Organisationen, Beschäftigte und deren Vertretungen den Wandel gemeinschaftlich gestalten, werden im Einzelfall unerwünschte Auswirkungen vermieden und insgesamt trägt dies auch zur Stärkung der sozialen Marktwirtschaft bei.
Die KI-ULTRA Leitfäden
Im Rahmen des vom Bundesministerium für Arbeit und Soziales (BMAS) geförderten Projekts KI-ULTRA (»Unternehmenslabore für Transformation und Change im Zusammenhang mit Künstlicher Intelligenz in der Arbeitswelt«) wurden zusammen mit den partizipierenden Unternehmen, Verwaltungen und Organisationen zwei Leitfäden entwickelt: Der vorliegende Leitfaden zu Strategie und Wandel für den KI-Einsatz und ein weiterer Leitfaden zur Durchführung von KI-Projekten:
1. Leitfaden zur Durchführung von KI-Projekten:
Dieser Leitfaden enthält ein Vorgehensmodell, mit dessen Hilfe Projekte zur Einführung von KI-Anwendungen im Arbeitsumfeld geplant und durchgeführt werden können. Lesen Sie diesen Leitfaden, wenn Sie planen, ein konkretes KI-Entwicklungs- oder Einführungsprojekt umzusetzen.
2. Leitfaden zu Strategie und Wandel für den KI-Einsatz:
Dieser Leitfaden unterstützt dabei, günstige Rahmenbedingungen für den KI-Einsatz über ein (pilothaftes) Einzelprojekt hinaus zu schaffen. Lesen Sie diesen Leitfaden, wenn Sie Ihre Organisation grundsätzlich fit für den Einsatz von KI machen möchten, und Sie KI als betriebliche Querschnittstechnologie etablieren wollen.
Die Trennung zwischen der operativen Durchführung des KI-Einführungsprojekts (»Wie?«) und dem strategisch angelegten Wandel (»Auf welcher Basis? In welchem Kontext?«) erhöht die bersichtlichkeit der Darstellungen. Tatsächlich aber hängen beide Ebenen stark miteinander zusammen: Die übergeordnete Strategie (z. B. ethische Richtlinien) beeinflusst die Aktivitäten in konkreten Projekten.
Aspekte der übergeordneten Strategie, wie ethische Richtlinien, können die Aktivitäten in konkreten Projekten beeinflussen. Umgekehrt können die Ergebnisse konkreter Projekte, wie die etablierte Funktionsteilung zwischen Mensch und Technik, Aspekte auf strategischer Ebene wie die Organisationskultur beeinflussen.
In den KI-ULTRA Leitfäden skizzieren wir auch allgemeine rechtliche Aspekte, die beim Einsatz von KI-Lösungen beachtet werden müssen. Bitte beachten Sie, dass Rechtsfragen nur überblicksartig in den Leitfäden dargestellt werden können.
Die Ausführungen stellen keine Rechtsberatung dar und können eine rechtliche Beratung im Einzelfall nicht ersetzen.
About this guide
This guide provides a process model for the introduction of AI in companies. This model is intended to serve as an orientation aid. It highlights relevant steps and issues, from the project idea right through to the introduction and use of AI in the company. It focuses in particular on the following aspects:-
- An integrated view of humans, technology and organization – this is the only way to ensure that all requirements for introducing the AI application, including knowledge of the human-centric work format and how AI will affect work processes and workflows, are taken into account by involving employee representation.
- In the model, consistency refers to an analysis that extends from the project idea to productive operation, supported on the methodological side by questions and tools.
- Neutrality regarding providers. The model does not recommend any solutions that are clearly associated with specific commercial offers.
- It uses simple language, relevant questions, tool recommendations and a consistent, practical example to ensure that the Process Model is simple to apply.
The process model that builds on these criteria is divided into four phases, which are further subdivided into individual steps (see Figure 2). Because with data-based projects it is often unclear at the start whether it is possible to achieve the objective, it is important to return to previous steps if necessary, reviewing in particular whether there is any sense in continuing. This is why setbacks are included in all steps towards the final evaluation of the solution. The phases portray the progress of a project. In practice, it is often advisable to carry out a feasibility assessment to avoid uncertainty in how much relevant information is contained within the data. This involves implementing a bare-bones version of the project which is more focused on data than on other aspects. This then indicates how much project-relevant information the data contains.
The four phases are presented briefly below:
-
- Objectives and requirements: In this phase, you should detail the planned project idea in terms of its content requirements from a corporate perspective. This should include all organizational, procedural and technical requirements for the project as well as considering general, legal and all specified requirements and conditions with regard to economic viability.
- Project start: This phase is for setting up the structure of the project scope. The project management process is clarified, as well as the composition of the project team, how data will be delivered and which technologies are to be chosen.
- Concepts and development: This phase involves the development of the AI application and the conceptual planning of the relevant software development and connection. The data is examined and prepared. The AI models are set up, trained and evaluated. In addition, system and data architecture concepts are created or expanded on the basis of existing systems. The resulting solution is then assessed with the outcome of either applying it, returning to a previous step of the model or even abandoning the project, should the objective or economic viability not be achieved.
- Utilization of results: The purpose of the last phase is to combine all elements and put the newly developed AI application into operation. This means integrating it into the process and the operating landscape, as well as ensuring employees are qualified to use the application and appropriate staff are appointed.
It is not essential to adhere strictly to the classification of project phases and steps in the projects. In practice, it may be a good idea for later steps to be planned and prepared at an earlier stage. For example, employee training is in the fourth phase, but it should be prepared at an early stage. It may also be a good idea for some steps to run simultaneously or to be omitted entirely if they are not relevant to the current project. If you are purchasing a solution, for example, this means that many technical aspects from the third phase – such as model selection and building – do not need to be included in the project. An external provider can take on such steps during implementation. In this case, the steps themselves do not need to be worked on, however they should at least be planned and supported by project management.
Finally, please note that the process model should not be regarded as a rigid model. This does not relieve project management of the responsibility of sorting, prioritizing and organizing the work to be done. The model should be seen more as a reference material that can be used as a checklist to avoid missing important points and to clarify common interdependencies and connections between the activities to be carried out. It is a substantive process model; it does not dictate workplace organization in the form of a specific agile or iterative working method.
Target audience
The guide is aimed at private companies, non-governmental organizations (NGOs) and public administration that would like to develop or introduce AI applications. The guide does not cover the legal requirements for public clients procuring AI applications. The main target audience is comprised of decision-makers at the level of management, project management and specialist departments. If projects involve handling the personal data of your own staff, employee representatives are, alongside data protection specialists, another important target audience and should be involved in the process at an early stage. In addition, the guide is aimed at all interested parties who work on the development and application of AI in the work environment. In addition to the description of the target audience of the guide given above, we have used the aforementioned abbreviations to indicate the specific groups of people that typically play an active role in each step. To avoid tying up resources unnecessarily, it is important to be aware that not everyone in the target audience takes an active role in every project step; instead, their deployment should be based on where they are able to make a contribution. However, it is normally a good idea for the entire team to be informed on a regular basis of the latest developments in the project.Example: Coffee machine by machine manufacturer Barista
In order to provide demonstrative examples for this guide, we have created the fictional company “Barista Mechanical Engineering” along with its key company data and application scenario.The company
Barista Mechanical Engineering produces high-quality coffee machines and is a medium-sized company with 200 employees. Its production site is located in Germany. Its main clients are bars, hotels and discerning coffee connoisseurs in both a private and corporate setting. The company has decided that it wants to further develop its coffee machines into smart devices. At the moment, Barista has five employees in its IT department, who look after the internal IT infrastructure including Office, ERP (enterprise resource planning), CRM (customer relationship management) and operating systems. They also employ a software development specialist who works on developing the user interface for coffee machine displays.The application scenario
At the moment, when the machine is out of coffee beans, the users themselves have to react and alert the coffee machine installer if they are unable to refill the machine themselves. This has led to frequent customer dissatisfaction. For this reason, the company plans to introduce a consumption forecasting service, which uses AI to forecast when the coffee bean container is likely to be empty and triggers the refill process. The implementation of this service is the company’s first AI project. It intends to explore the topic of AI by learning through practice and reinforcing this over time by building up its skills.Über diesen Leitfaden
Dieser Leitfaden bietet Ihnen ein Vorgehensmodell zur Einführung von KI in Unternehmen an, welches als Orientierungshilfe dienen soll. Dabei werden relevante Schritte und Fragestellungen von der Projektidee bis hin zur Einführung und Nutzung im Unternehmen aufgezeigt. Besonderer Wert wird hierbei auf die folgenden Aspekte gelegt:
- Die integrierte Betrachtung von Mensch, Technik und Organisation, denn nur so kann gewährleistet werden, dass alle Anforderungen an die einzuführende KI-Anwendung einschließlich des Wissens über die menschenzentrierte Gestaltung der Arbeit und die Auswirkungen von KI auf Arbeitsverfahren und Arbeitsabläufe unter Beteiligung der Mitarbeitendenvertretung berücksichtigt werden.
- Durchgängigkeit steht in dem Modell dafür, dass die Betrachtung von der Projektidee bis hin zum produktiven Einsatz methodisch mit Fragestellungen und Werkzeugen unterstützt wird.
- Neutralität bezüglich Anbieterunternehmen. Das Modell nimmt Abstand von Lösungsempfehlungen, die klar festen kommerziellen Angeboten zuzuordnen sind.
- Mittels einfacher Sprache, relevanter Fragestellungen, der Bereitstellung von Werkzeugempfehlungen sowie einem durchgängigen, praxisnahen Beispiel soll Einfachheit in der Anwendung des Vorgehensmodells erreicht werden.
Das auf diesen Kriterien aufbauende Vorgehensmodell ist in vier Phasen gegliedert, welche sich in einzelne Schritte unterteilen, siehe Abbildung 2. Da bei datenbasierten Projekten oft nicht von Beginn an klar ist, ob sich die Ziele gut erreichen lassen, ist es bei solchen Projekten üblich, Rückschritte zu machen und besonders kritisch zu hinterfragen, ob eine Weiterführung Sinn ergibt. Aus diesem Grund sind die Rückschritte bis zur finalen Evaluation der Lösung dargestellt. Die Phasen stellen ein durchgängiges Projekt dar. In der Praxis ist es häufig empfehlenswert, wegen der Unsicherheit bzgl. der relevanten Informationen in den Daten, eine sogenannte Machbarkeitsstudie durchzuführen. Dabei wird ein stark reduziertes Projekt durchgeführt, welches auf die Daten fokussiert ist und andere Aspekte ausblendet. So kann eingeschätzt werden, wie viele projektrelevante Informationen in den Daten stecken.
Nachfolgend werden die vier Phasen kurz vorgestellt:
- Ziele und Anforderungen: In dieser Phase sollten Sie aus unternehmerischer Perspektive die geplante Projektidee auf ihre inhaltlichen Anforderungen und Voraussetzungen detaillieren. Dabei geht es darum, alle organisatorischen, prozessbezogenen und technischen Anforderungen und Bedarfe an das Projekt aufzunehmen sowie rechtliche Anforderungen zu prüfen und alle genannten Anforderungen und Voraussetzungen in Bezug auf die Wirtschaftlichkeit sowie generellen Anforderungen zu betrachten.
- Projektstart: Die Phase dient dem strukturierten Aufsetzen des Projektrahmens. Es wird geklärt, wie das Projektmanagement erfolgen soll, wie sich das Projektteam zusammensetzt, wie die Datenbereitstellung erfolgt und welche Technologien auszuwählen sind.
- Konzepte und Entwicklung: Diese Phase dient der Entwicklung der KI-Anwendung sowie der konzeptionellen Planung zugehöriger Softwareentwicklung und -anbindung. Die Daten werden gesichtet und aufbereitet. Die KI-Modelle werden aufgesetzt, trainiert und evaluiert. Außerdem werden System- und Datenarchitektur konzeptionell erstellt bzw. auf Basis der existierenden Systeme erweitert. Die entstandene Lösung wird abschließend evaluiert mit der Folge, sie in die Nutzbarmachung zu überführen oder einen Rückschritt in das Modell oder gar einen Projektabbruch durchzuführen, sollte das Ziel nicht erreicht worden oder die Wirtschaftlichkeit nicht gegeben sein.
- Nutzbarmachung der Ergebnisse:In der letzten Phase geht es darum, alle Elemente zusammenzufügen und die neu entwickelte KI-Anwendung in den Betrieb zu überführen. Das bedeutet, diese in den Prozess und in die Betriebslandschaft einzubinden sowie die Mitarbeitenden für die KI-Anwendung zu qualifizieren bzw. Personal einzustellen.
Die Einordnung von Projektphasen und Schritten in den Projekten muss nicht zwingend eingehalten werden. In der Praxis kann es sich anbieten, spätere Schritte bereits frühzeitig zu planen und vorzubereiten. Beispielsweise wird die Fortbildung von Mitarbeitenden in der vierten Phase angesiedelt, sollte aber frühzeitig vorbereitet werden. Es kann ebenfalls sinnvoll sein, Schritte gleichzeitig oder gar nicht zu bearbeiten, wenn sie für das aktuelle Projekt nicht relevant sind. Das bedeutet für Sie z. B., dass beim Zukauf einer Lösung viele technische Aspekte aus der dritten Phase wie Modellauswahl und Modellbau nicht im Projekt bearbeitet werden müssen. Bei einer Umsetzung kann ein externer Dienstleister solche Schritte übernehmen. In diesem Fall müssen die Schritte nicht selbst bearbeitet werden, sollten aber zumindest von der Projektleitung geplant und begleitet werden.
Abschließend weisen wir darauf hin, dass das Vorgehensmodell nicht als starres Modell zu verstehen ist. Dem Projektmanagement nimmt es nicht die Verantwortung, eine eigene Sortierung, Priorisierung und Ordnung der zu erledigenden Arbeiten aufzustellen. Vielmehr versteht sich das Modell als Referenzmodell, welches insbesondere als Checkliste verwendet werden kann, um das Vergessen wichtiger Inhalte zu vermeiden und häufige Abhängigkeiten und Zusammenhänge der zu erledigenden Tätigkeiten zu verstehen. Es versteht sich als inhaltliches Vorgehensmodell, trifft also keine Aussage über die Arbeitsorganisation in Form einer speziellen agilen oder iterativen Arbeitsweise.
Adressat*innen
Der Leitfaden richtet sich an privatwirtschaftliche Unternehmen, Nichtregierungsorganisationen (NGOs) und öffentliche Verwaltungen, welche KI-Anwendungen entwickeln oder einführen möchten. Die vergaberechtlichen Anforderungen bei der Beschaffung von KI-Anwendungen durch öffentliche Auftraggeber sind nicht Gegenstand des Leitfadens.
Hauptadressaten sind betriebliche Entscheidende auf der Ebene des Managements, Projektleitende und Fachabteilungen. Bei Projekten mit personenbezogenen Daten der eigenen Belegschaft ist – neben der Fachkraft für Datenschutz – ebenfalls die betriebliche Interessensvertretung der Mitarbeitenden ein wichtiger Adressat und sollte frühzeitig im Prozess mit eingebunden werden. Darüber hinaus werden alle Interessenten angesprochen, die sich mit der Entwicklung und Anwendung von KI im Arbeitsumfeld beschäftigen.
Zusätzlich zu den Adressaten des Leitfadens haben wir mithilfe der o. a. Icons jene Personengruppen gekennzeichnet, die in den inhaltlichen Schritten typischerweise eine aktive Rolle übernehmen.
Um Ressourcen nicht unnötig zu binden, ist es wichtig zu wissen, dass nicht immer alle Adressaten in jedem Projektschritt eine aktive Rolle übernehmen, sondern gezielt nur herangezogen werden sollten, wenn sie auch einen Beitrag leisten können. Eine regelmäßige Informationsweitergabe über die aktuellen Entwicklungen an das gesamte Team im Projekt ist stets empfohlen.
Beispiel: Kaffeemaschine der Maschinenbaumanufaktur Barista
Um diesen Leitfaden durchgängig mit Beispielen veranschaulichen zu können, führen wir an dieser Stelle das fiktive Unternehmen »Maschinenbaumanufaktur Barista« mit den nachfolgenden Unternehmenseckdaten sowie deren Anwendungsfall ein.
Das Unternehmen
Die Maschinenbaumanufaktur Barista stellt hochwertige Kaffeevollautomaten her und ist ein mittelständisches Unternehmen mit 200 Mitarbeitenden und einer Produktion in Deutschland. Ihr Hauptklientel sind Bars, Hotels sowie anspruchsvolle Kaffeegenießende im Privat- und Unternehmensbereich. Das Unternehmen hat sich zum Ziel gesetzt, ihre Kaffeemaschinen zu smarten Produkten weiterzuentwickeln.
Goals and requirements
When deciding on the content of an Al project, it is important to clearly formulate the project idea, to assess the prerequisites and derive the relevant requirements. At this stage, it is necessary to ask whether the project makes sense as an Al project and, if so, how it can be implemented successfully. For this reason, you should clarify the following issues early in the process:
- If possible, the project should be in line with the organization’s overall strategy and should not be launched as a lone satellite.
- All stakeholders are involved when defining activities and requirements, e.g., specialist department, works council/staff council, data protection specialist, etc.
- Affected processes are considered in the overall context, not in isolation.
Goals and profitability
Just like in classic projects, objectives have to be defined right at the start of an Al project. Usually, to turn these objectives into a project, the potential benefits and required costs have to be presented. While this is already quite difficult for traditional projects, it is much more so for Al projects: The uncertainty of what the data really contains and whether the available data is actually sufficient, makes this assessment particularly challenging. Because of this uncertainty, it is best to plan for the possibility of setbacks or project abandonment from the outset. The evaluation should not be based on intuition or influenced by others. Ideally, it should be treated with the same principles as all other business decisions. This involves gaining an overview and checking, for example, whether the project fits with the overarching organizational strategy and whether the stakeholders are sufficiently involved in the process.
Guiding questions
- Which internal and external objectives does the project work toward?
- What resources are required for the project?
- What is the project expected to achieve?
- What return on investment can be expected?
- How do the individual project objectives fit with the corporate strategy?
If the project idea was developed in the specialist department, check whether the idea is in line with the company’s Al strategy. For more information, we recommend the chapter “Action area: operational Al strategy” in the Guide to strategy and change.
Measures and tools
- P – Business Model Canvas for defining objectives and requirements and assessing the project idea (Example 1)
- IM – Risk assessment for target achievement based on the individual application case
- P – Cost-benefit analysis for assessing potential benefits
Requirements
The requirements of Al projects are quite similar to those of traditional projects. Here we have collated the key aspects of a project. Requirements stemming from stakeholder needs, core activities and aspects of the relevant processes are particularly important. If the surveyed stakeholders have expressed requirements regarding the Al application, e.g., they wish to understand how it will work, this fact needs to be taken into account during the creation process. There are, of course, additional basic requirements stemming, for example, from general business concerns such as ethics, risk management and usability. The interaction concept refers to the design of human-machine interfaces, and ensuring that they are simple and understandable for users.
It is important to systematically take into account the project requirements at each subsequent step of the guide and not to act before the problem is fully understood. This also creates a common understanding of the project, which further helps in assessing the feasibility of activities to be carried out as well as to classify and structure them in order to then prioritize and review them prior to implementation.
Guiding questions
- What requirements do stakeholders have for the project?
- What are the Al-specific requirements (e.g., explainability of results)?
- What should the process look like in the future?
- What requirements are derived from the key activities?
- What legal requirements must be met?
- How can Al be applied to create a positive user experience?
- What usability requirements have been identified?
- Are there any other requirements, e.g., for the company as a whole?
- Does the project alter the work in a way that makes it subject to co-determination?
Measures and tools
- P – Requirements engineering
- P – Creating mock-ups with paper or click prototypes
- P – User-centered design process: Iterative process of designing appropriate interactive systems that involves users in all phases1
Needs from a stakeholder perspective
Stakeholders are generally people or organizations that influence project requirements or may be influenced by them in the future. Because of this, they significantly influence objectives as well as requirements. Al sometimes appears as an invisible “black box,” in which its internal logic is concealed from users. Because of this, it is important to ensure early on that stakeholders do not resent Al or are lacking any important knowledge. For this reason, employee representation should be incorporated as soon as possible.
Guiding questions
- Which stakeholders should be approached?
- Are there any passive stakeholders (e.g., works councils) involved in the project who should therefore be approached?
- What interests do the relevant stakeholders have?
- Are there supporting stakeholders that do not have to be involved in the project, but would add synergy with other projects?
- Could conflict situations arise due to stakeholders having different views?
- Do the stakeholders have basic knowledge of Al or is action required in order to improve acceptance of the project?
- What requirements do stakeholders have in terms of application usability?
Measures and tools
- P – Stakeholder analysis to identify relevant stakeholders
- P – Acceptance analysis and modeling to evaluate technology acceptance among stakeholders
- P – Persona method for mapping out and communicating needs
Affected processes
Processes are made up of activities, which comprise work steps. Processes can have a specific structure and form, or they might have grown organically. To ensure successful transition from a (partially) manual activity to an assisted or even automated activity, it is important to know and understand the specific work processes involved. It is also advisable to define both the current process and the target process for the affected processes when setting objectives. This way, the affected employees and any changing human-technology interfaces can be identified and taken into account. Another key factor is the suitability of the processes as a basis for the work, because even a poor process that is supported by Al is still a poor process.
Guiding questions
- Which processes are affected by the implementation of the project, and are these already clearly set out or does the ACTUAL process still need to be defined?
- Is the process internal (within the company) or collaborative (with partners or service providers)?
- Who is responsible for the process (the company itself or an external partner)?
- Which employees are affected by the process and what do they expect from it?
- Are the interfaces for transfer of resources, information and responsibilities already digitalized or will there be media discontinuities in the process?
- How will tasks be divided between humans and technology in the future?
Measures and tools
- P – Process modeling tools for data recording, modeling, storage and sorting, as well as for cross-functional and cross-organizational communication. In its simplest form, this can be a presentation application as included in any office software package.
- P – Process modeling languages like UML (Unified Modeling Language) or BPMN (Business Process Model and Notation)
- P – Supporting, structured analyses for a general process overview: Process mapping and Makigami
- IAO – Activity diagrams from UML highlighting human-machine interfaces (Example 2)
Key activities
Key activities are the fundamental steps in affected processes that add value to the project. In the separation of roles between humans and technology, it is important to understand which activities can be automated or supported and to what extent, so that the necessary skills can be understood with regard to the potential new application. This also comprises an analysis of those core activities of users, including the required skills, which may encompass human, technical and organizational factors. In research, the term automation of activities is closely connected with the term routine. In this context, it must be possible to estimate the routine portion of a task. To this end, the knowledge and interaction required to complete the task should be assessed. This is important, as the routine portion tends be better suited to automation than highly individualized activities.
Guiding questions
- What activities are currently carried out by users?
- What requirements do users have for their future activities (project objective)?
- How have the activities been classified into routine and non-routine?
- What proportion of all activities that are part of carrying out a key activity is homogenous?
- How can the knowledge of human-centered work design be incorporated into the planning of work procedures and processes?
- Does sensitive data, for example video recordings of current work, need to be processed in order to meet the requirements?
Measures and tools
- IAO – Processing matrix for the classification of routine and non-routine tasks (Example 3)
- P – Shadowing method for user and target group analysis, i.e., where the person performing the tasks is observed without influencing or disturbing them.
- P – Complete a work analysis in which users are asked about their activities.
Legal aspects
General legal aspects
EU AI Act
According to the proposal for an EU act that sets harmonized provisions for artificial intelligence (dated April 21, 2021), only certain Al systems will be allowed on the basis of individual risk assessment. Certain Al practices will be forbidden and high-risk Al systems will be subject to strict requirements.
Labor law
Al systems can trigger employee representative (works council/ staff council) co-determination rights. In an employee context, software is often a technical tool that can be used to monitor the behavior or performance of employees, which is why the works council must co-determine its introduction and use. If Al leads to a fundamental alteration of work organization, this constitutes a work alteration that requires co-determination. There must be an effort to harmonize interests and a social compensation plan may need to be made. Even at the planning stage for applying Al to work procedures and processes, the works council must be consulted and its recommendations and concerns taken into account. If the work situation for employees is significantly altered, this may constitute transfers that must be approved by the works council. If Al is applied in the creation of regulations for employee selection in recruitment, transfers, pay group reassignment or even termination, the works council must be involved. Employees must not be discriminated against. It is therefore essential to ensure that decisions regarding recruitment, transfers, terminations, working hours and other aspects involving employees are not influenced by the employee’s ethnic background, gender, disability or any other grounds as defined by the German General Act on Equal Treatment.
Data protection legislation
The General Data Protection Regulation (GDPR) is particularly relevant for processing personal data. Data that appears non-critical (e.g., machine data recorded by sensors on the production line) can allow persons to be identified (such as employees, customers, suppliers, etc.), meaning that there must be specific legal data protection grounds for processing this data.
Information about legal aspects and how they affect organization strategy can be found in the “Minimizing legal risks” chapter in the Guide to strategy and change.
Another of the principles of the EU GDPR is that of purpose limitation, which states that personal data may only be used for specified purposes and must not be further processed in a manner that is incompatible with these purposes. When implementing an Al project with existing datasets containing data that is traceable to employees, the purpose for collecting the data originally and reasons for further processing must therefore be checked.
Because the GDPR treats Al solutions as a risk, a data protection impact assessment must also be carried out. Among other aspects, this must include a systematic description of the processing procedure as well as assessments of the processing purposes and risks. The data protection impact assessment must be concluded and documented before any personal data is processed within an Al project (including during any training phase).
It is also important to establish in advance how data subject rights (including right to information, right to deletion, withdrawal of consent, etc.) can be maintained when an Al system is introduced. Particularly strict requirements apply to using Al solutions in making decisions that have legal effect (for example, recruiting or evaluating employees); the use of Al solutions is usually not permitted in employee contexts such as these.
If only data that cannot be attributed to individual employees or other persons is used (e.g., purely business-related or aggregated datasets), consent is not required in accordance with data protection law. It can therefore be useful to limit the use of Al solutions from the outset to aggregated, non-personally identifiable data or to anonymize data before use. In some cases, this may be legally required. According to the principles of data minimization, the processing of personal data must always be limited to what is necessary. If the objectives pursued using Al can also be achieved without personal data or with a smaller data set (for example, by using pseudonyms instead of clear names), this more data-efficient approach must be taken.
It is therefore essential to involve data protection experts and specialist advisors in the project as soon as possible while defining objectives and requirements so that any legal matters arising from the specific situation can be assessed.
Further aspects of intellectual property rights
Depending on the type and content of the training data, it may be necessary to evaluate the training data before collecting it. Training data may be legally protected from various legal standpoints (e.g., copyright protection for text, photos or sounds, data protection and right of personality protection for images of people, or trademark protection for images of competition) or even constitute a trade secret. There is also the possibility that the databases from which the training data originates are themselves subject to copyright or copyright-related protection.
German law offers effective exceptions to basic protection, for example in copyright law through the fundamental permission of text and data mining (section 44b German Act on Copyright and Related Rights (Urheberrechtsgesetz, UrhG)). If the holder does not explicitly prohibit it — which is not always easy to confirm — “text and data mining” of published copyrightable data is certainly permitted.
In doing so, it is important to keep in mind that training data is by nature very complex. Depending on the type or content of the data, it may be protected by any number of intellectual property rights (copyright, trademark law, trade secrets, etc.) and thus be subject to various exceptions depending on the type of intellectual property rights that apply. The type and contents of the data in each training dataset must therefore be determined in each case. For copyrighted data, the (copyright) exception for text- and data mining may apply. For trademarked data or trade secrets, other regulation exceptions may apply.
Furthermore, it should be noted that lawful text and data mining requires that data is extracted in order to “gain information (…) from it,” i.e., specifically to attain information about the patterns within the datasets analyzed. With this in mind, text and data mining can be illegal if data is extracted to, for example, train an artificial neural network that does not analyze the data itself, instead automatically compiling other information from it.
In relation to this, it is also relevant whether or not the training data is a trade secret of the company or a third party within the meaning of the German Trade Secrets Act. If the company’s own trade secrets are used, it should always be determined whether or not this will result in the disclosure of the respective data, which may nullify its trade secret protection (for more information, see “Legal aspects regarding the results of the Al service”).
Data licensing
If data from publicly available sources or data suppliers is used, data licensing regulations must generally be adhered to, particularly those that may oppose use of the datasets in question in Al systems or require additional license fees to do so. To avoid these, it is important to check whether data that isn’t collected by the company itself is subject to this type of restriction.
Guiding questions
- Is the data undergoing processing directly (person is known) or indirectly personal (by evaluating the data, it is possible to draw conclusions about a specific person since the number of cases is too low or the characteristics are too clearly indicative of a person)?
- Has the available data been collected for a specified and explicit purpose?
- Are the project objectives compatible with permitted data processing purposes?
- On what legal grounds will the data be used, and to what extent?
- Does the data need to be anonymized or pseudonymized before use?
- Are any contractual stipulations, consents and/or revised data protection information regarding the collection and use of data required?
- Do the risks to personal data need to be evaluated and documented in advance by means of a data protection impact assessment? Who will complete the assessment?
- Is it ensured that no unauthorized automated decisions will be made by Al?
- Does the company have a storage and deletion concept? Do these need to be created or adapted?
- Does the application scenario involve any additional legal requirements?
Guiding questions
- What employee representative co-determination rights must be taken into account and when must they be incorporated?
- Which of the risk groups as defined by the EU AI Act are relevant to the application scenario and what are the resulting requirements?
- Does Al alter work procedures and processes in a way that means a works council must be consulted at the planning stage?
- Do company agreements have to be concluded due to the required software also being suitable for monitoring employee behavior and performance?
- Does introducing Al mean that employee transfers approved by co-determination are required?
- Does Al lead to a fundamental alteration of work organization and thereby to a work alteration that requires co-determination?
- Will Al be applied to recruitment decisions and is there a risk that that prohibited characteristics will be included in the decision?
Legal aspects regarding the results of the Al service
More information about data licensing can be found in the “Action area: data strategy” chapter of the Guide to strategy and change.
Trade secret protection
Businesses naturally take great interest in their results. With this in mind, results produced by Al systems can be viewed as trade secrets. In order for a trade secret to enjoy legal protection as such, the following conditions must be met: It must be a piece of information that:
- is neither generally known nor readily accessible either as a whole or in its precise arrangement and composition
- is of economic value;
- is subjected to confidentiality measures appropriate to the circumstances by its rightful owner; and
- for which there is a legitimate interest in confidentiality.
With this in mind, it is particularly important that appropriate confidentiality measures are taken with regard to the results. Because the German Trade Secrets Act is designed to apply to all technologies, there is no legal requirement for implementing specific confidentiality measures. It is therefore not possible to make a general statement as to which confidentiality measure is appropriate in individual cases based on the need to protect the specific trade secret. A common example, however, would be a special non-disclosure agreement that employees working with the Al system must sign. Others measures often used include technical access barriers such as encrypted saving or creating an authentication concept for access to the results.
Copyright law and patent protection
Under certain circumstances, Al results can be protected under copyright law. This depends on the type of result. As a rule, however, the results are not copyrightable. Copyright can only be applied to something created by a natural person — a human. This also applies to “inventions” that, when patented, are protected by the German Patent Act. However, an Al system can be neither the inventor nor the creator of its results. As neither the provider nor the programmer of the Al system is viewed as the creator, these parties cannot generally be viewed as the originator of the results, either. An exception to this is if the Al system itself is only used as a tool within the scope of the creation or invention process. In these cases, the user can be viewed as the creator or inventor. An important ground rule is that the creation embodied in the result must be the outcome of a user’s unique mental process. This can usually be negated if, for example, an image or text that appears creative is produced by the Al system on the basis of simple commands describing the image or text to be created by the Al system with the sole purpose of producing the image or text in an easier way. Ancillary copyright protection of images is also usually invalid for images produced by Al, since such images are created through pixel information calculations. However, a database construct created by an Al system could be considered to receive copyright-like protection as a database (section 87a, German Act on Copyright and Related Rights (Urheberrechtsgesetz, UrhG)) if the data or elements contained therein are “systematically or methodically arranged and individually accessible by electronic or other means” and “the procurement, verification or presentation thereof requires substantial investment according to the nature or scope.” The holder of this type of ancillary copyright is the party making the investment. This is usually the company, which, as a legal entity, can also be the beneficiary of ancillary copyright.
Utilization of Al results on the basis of contractual data licensing
Because the results generated with the help of Al systems are generally not protected by copyright law but can infringe upon the rights of third parties (see “Minimizing legal risks” in the Guide to strategy and change), it is important in every application scenario to establish how the results obtained with the Al systems will be used. As Al results fundamentally lack copyright protection, if they will be available to third parties, it is important to establish whether transferal to third parties will occur under a licensing agreement and what rights and obligations the parties are subject to.
Guiding questions (Results)
- Could the results of the Al service have a unique importance to the business and must this data, because of its value as a trade secret, be subject to special protective measures?
- Are the users of the Al results subject to non-disclosure agreements?
- Depending on the nature and content of the Al results, is specific legal protection (for example, ancillary copyright for databases produced using an Al system) taken into account?
- Should Al results be assessed and has data licensing been considered if the Al results themselves are not already protected by law?
Measures and tools
- IM – Involvement of legal experts, specializing in the affected area, if necessary. Understanding and formulating legal text is best done by legal experts with the appropriate legal knowledge. Laws can also differ depending on the area of application (region or discipline) and change over time. It is therefore advisable to consult a legal expert in case of doubt.
- IAO – This guide and the Guide to strategy and change.
Project start
In the project start phase, you should think about how you can implement the planned Al application most effectively. For each of the following steps, it is therefore necessary to clarify what is already available and what services may need to be purchased from external providers. The following questions are important for this:
- Is the data for the application scenario actually and legitimately available and is it in a usable state? Does external data need to be purchased?
- Are employees with appropriate knowledge available? Do the employees with the knowledge have the capacity to assist with the new project or is external support needed?
- Is a ready-made solution for the intended idea already available to buy on the market? Can potential service providers be trusted with regard to the datasets being used? If a suitable solution already exists, it is likely that the data required and the project-related expenses will reduce dramatically. In this case, an implementation project would be turned into an introduction project, meaning the third phase would be significantly scaled back.
In this phase, take the time to consider which route makes the most sense for you.
Data access
Al projects live and die by the availability of data. Because of this, before the start of a project, it must be determined whether there is guaranteed access to training data in both a real and a legal sense. Access can take a variety of forms: Customers or partners can supply data, which requires their willingness to do so. In our coffee example, customers such as bars, hotels, etc. could provide data. This would have the potential to significantly improve the results for predictions of refilling and reordering when it is necessary. There must be legal grounds for processing personal data (in accordance with Article 6 GDPR and section 26 German Federal Data Protection Act (Bundesdatenschutzgesetz, BDSG)). In terms of the use of personal data being supported by consent, please note that this must be the consent of each individual whose data will be transferred. Effective consent must be given voluntarily and on an informed basis. In the case of employees’ personal data, this is generally not “voluntary”, as there is a relationship of dependency between employer and employee. One solution may be to anonymize data immediately, i. e., to make it impossible to identify individuals retrospectively.
The data that is generated and used should always be documented and any use limitations complied with. For more information, please refer to “Action area: data strategy and technology transfer” chapter of the Guide to strategy and change.
Data may also be available in a company’s own systems. However, for some organizations, this does not automatically mean that it is immediately accessible because it may:
- not be saved in formats that can be used by the systems,
- be incomplete or
- be subject to special legal protection (e.g., the data is subject to copyright protection, is a trade secret of the company or a third party, is protected by a non-disclosure agreement, is the subject of data licensing or is personal data.)
This then requires data preparation and, if relevant, rights clearance. To this end, it must be ensured that existing data can be used for the intended processing purposes in accordance with the law. Of course, data can also be generated by the organization itself. In the end, it not only comes down to general access to data but also whether there is a large enough volume of data. If possible, this also includes having examples for all relevant events that are reflected in the data. If cases are too rare or not represented in the data, it is difficult or impossible for Al models to learn them. The size of the data volume depends on the actual application scenario.
Guiding questions
- Is enough data available for the application scenario?
- Does the data cover all relevant aspects of the application?
- Is the data easy to access or is access complex, e.g., requires technical solutions for access?
- Are partners, customers or other suppliers prepared to provide access to data?
- Should data that may be subject to legal protection be used, and has sufficient rights clearance been obtained?
- Are the data sets obtained able to be used in a way that conforms to data protection regulations?
Measures and tools
- IM – Trial access to all relevant data sources for technical and organizational review
- IAO – This guide and the Guide to strategy and change.
Project management
Project management has to address the question of how the project is organized and which structures and methods will be used. Al projects are subject to additional factors when compared with standard project management, such as uncertainty caused by the use of data and an unusually high level of interdisciplinary collaboration, as demanded by new tasks. This results in a greater need for communication and coordination within the project team as well as with eventual users. In general, this means that a static approach to defining objectives and requirements and developing them in clear processes is not effective. In Al projects, it is usually important to test a wide range of models and algorithms in order to arrive at a very good solution, as the significance of the data and the best way to extract information from it is not often clear from the outset. To do so, it may be necessary to repeat previous project steps. It is therefore generally advisable to implement an iterative or even agile form of project management, e.g., Scrum or Kanban. To support project management, process models such as CRISP-DM (CRoss-Industry Standard Process for Data Mining) or this guide can also be used as a starting point for content structure and methods. Particularly for organizations outside the IT industry, which generally have little to no experience with Al projects, this support is advisable as it will provide them with guidance throughout the process.
Guiding questions
- What type of project management best suits the requirements of the objective and the team?
- Should a process model such as CRISP-DM or this guide be used and, if so, in what context?
Measures and tools
- P – Agile project management, e.g., Scrum or its variants
- IAO – This guide
- P – RACI-Matrix (responsibility assignment matrix) for planning tasks and the associated responsibilities
Technology selection
The chosen technology (programming languages, libraries and software systems) may differ from project to operation. Its individual suitability may also vary, which is why coordination in the individual phases can improve efficiency overall. In particular, it is best at this point to make conscious decisions about technologies used within the company for the solution. Al is not always the answer to every problem. In some cases, a simple rule system that is programmed and does not learn from data may be the suitable result. However, if Al is the chosen solution, strategic questions also play a role here, such as what expertise is already available and which portion should be implemented and operated in-house and which portion should be outsourced. The technology and the chosen model (algorithms or Al methods) are also sometimes interrelated. For example, if methods that are rarely used or newly developed are required, this can limit the technologies that can be chosen. With third-party technologies, it is important to ensure that data processing complies with both individual requirements and legal regulations. At this point, it is particularly meaningful to consider whether data that is subject to intellectual property rights (data protection, copyright, etc.) can be processed or viewed by an external provider beyond the purpose of the individual application scenario. Restrictions may apply as a result, for example licensing requirements.
Guiding questions
- Is Al the solution to the problem or can the project goals be achieved through simple rules?
- For which technologies are skills already available or expected to be available in the company in future?
- Which portion of the solution should be developed and operated in-house?
- What are the potential limitations caused by existing systems or designated providers?
- Are the providers of (Al) systems gaining unwanted access to the data used or generated?
Measures and tools
- IM – Create an overview of the available expertise of your own employees for programming languages, libraries and application software
- P – Compare with existing and planned providers and systems to determine the compatibility requirements
- IM – Check the product description and licensing for the chosen technology for unwanted access to used and generated data
Project team and stakeholders
Al projects are becoming ever more interdisciplinary and require close coordination of technical expertise, IT knowledge and mathematical abilities. It can be a good idea to check which skills your own employees will bring to the project. You will need to consider which skills can be taught via training and which need to be purchased externally for the project. Remember that once the solution is to be transferred into a production environment as part of a system, additional skills may be required. Structured planning that involves checking the required roles and filling the positions is therefore an important step for successful project completion. Depending on the complexity of the project and the application area, individuals can take on several roles, or several people might share individual roles. Apart from the active roles in the project, passive roles also have to be identified, i.e., the relevant stakeholders for implementation. Both internal stakeholders, such as members of the works council and data protection specialists, and external stakeholders, such as end users, may become relevant and play a decisive role in the success of the project.
Guiding questions
- Which roles are relevant for the planned project?
- Which persons will fill which roles?
- Are there any skills missing for the planned project?
- Which stakeholders should be involved in the project, and when and how should they become involved?
- Do skills need to be procured from external service providers because they are not available in-house?
- If employees are lacking skills, can they be trained?
Measures and tools
- IAO – Allocate and describe roles and stakeholders (Example 4)
![The image shows a grid of cards, each representing a role or a stakeholder group. It is divided into a left side for “roles in the project”, and “stakeholders” on the right side. Each card has a title at the top, and some additional text on the card, either the name of the person occupying the role, or clarifications and activities related to the respective role or group. The roles in the project are: Specialist expertise (Anna Gramm), Specialist data expertise (Anna Gramm), Project management (Wilma Ruhe), AI operators (Department C3), Software development (To be clarified! Potentially Department C4; check if ready and available!), Data scientist (Qwertz Data Consulting LLC). The stakeholders are: Quality management (Ernst Haft), Users (Were asked about their requirements […]), Works council (Consent obtained. Works council requests information at milestones), Decision-makers (Team leader Chris P. Bacon has doubts about the project and wants to see convincing figures before giving his approval).](https://websites.fraunhofer.de/ergebnisse-ki-ultra/wp-content/uploads/2025/06/E4.png)
Concepts and development
Data preparation
Before the actual work with the data begins, and once the legal status of the data has been determined, it should be checked that it is in the required form and of sufficient quality. It may become necessary to recollect some data, establish new mechanisms for quality assurance and make decisions on how to deal with flaws in data. In some cases, for example, it may be possible to interpolate gaps in data. In other cases, parts of the data may have to be discarded. Outliers may also have to be dealt with, unless these values should remain in the data as naturally occurring events. In addition to ensuring the quality of the data, it may also be necessary to merge data from different sources while guaranteeing the same quality and (temporal) resolution.
More information about the data strategy and how it should be handled in the context of the organizational strategy can be found in the chapter “Action area: data strategy” in the guide for strategy and change.
Guiding questions
- Is the available data complete and, if not, how are gaps dealt with?
- Is the data of sufficient quality and, if not, how can quality be ensured?
- How is data from different systems and in different resolutions merged?
Measures and tools
- IM – Conduct a structured check of the data using technical support
- P – Office spreadsheet application, e.g., data series functions
- P – Programming language for data experts, e.g., Python or R
Understanding and exploring data
If data is available in (probably) sufficient quality and quantity, data exploration can begin. A good understanding of the data is built up through a combination of statistical analyses, specialist knowledge and visualization from different perspectives. This can be used to fine-tune the further selection of models and lead to a more detailed assessment or even adjustment of the set targets. This process is the basis for so-called feature engineering, i.e., the selection and forming of data to be processed in model building.
Guiding questions
- Based on the understanding of the data, do the project goals and the requirements seem realistic?
- Has the data led to new findings that open up new potential?
- Which combinations and forms of data are promising in terms of further processing in the models?
Measures and tools
- P – Statistical analyses. Most graphics tools offer the required functionalities. Free frameworks also offer the necessary options, e.g., Pandas Profiling for the Python programming language provides comprehensive functions that are available with just a few lines of code.
- IM – Different visual perspectives (diagram types) to examine the data.
Model selection
Selecting appropriate Al models is an iterative process. It is normal for this selection to change before the final evaluation. The selection of Al models influences feature engineering, since different models can work (more effectively) with different data types and formats. In especially innovative or complex application cases, the selected model can also influence technology selection due to its rarely used or particularly new algorithms. This should be considered during initial technology selection. Due to the uncertainty regarding the nature and degree of information contained in the data, it is useful to start with relatively simple models. This will reveal whether the data actually contains any relevant information and offers a baseline that more complex models can be measured against. When selecting complex models, it is advisable to access documented and published best practices to keep costs at a manageable level.
Guiding questions
- How does the model selection influence technology selection?
- What is the simplest model that could be used for an initial test and as a baseline?
- Which models seem appropriate based on best practices and available expertise?
- Which models are feasible? Are there any rarely used, particularly complex or very new models under consideration?
Measures and tools
- P – scikit-learn algorithm cheat sheet for selecting the baseline process2
- IM – Best practice research
Data architecture
The more data is included, the more useful it is to define a suitable data architecture, especially for subsequent live systems. Data must be collected and merged from various sources. At an organizational level, it may be necessary to decide whether a standard data strategy and administration process are required. If these decisions are made locally in the project, this increases the likelihood that different data sources will need to be integrated in future. If the issue of data architecture is neglected, there is a risk in the medium and long term that a silo landscape of different databases and source systems will become established over multiple projects. The consequences of such a construct are technical and organizational debts that lead to significant extra costs in operations and future projects.
Guiding questions
- Which source systems are available and how accessible are they?
- What is the strategy on data management?
Measures and tools
- IM – Comparison with the organizational strategy on data architecture from the Guide to strategy and change
- P – Assess the economic viability and carry out a risk analysis comparing the cost of integration to a fragmented silo structure
System architecture
If, in practice, models will be used regularly after the project, it is sensible to embed them in the organizational system. This can be planned using a system architecture. Here, the question of which components and integration points are part of the solution have particular relevance. It is especially important to consider which existing elements will be used and which new elements will have to be created. If the design also involves devices and sensor systems, this can result in complex IoT architectures. In addition to central devices, as well as application and data management components, such architectures can also comprise further elements, such as those of an administrative nature or device management. The processed data volume also affects the architecture. If the data volumes are so great that they cannot be processed using individual (high-performance) computers, this is termed as “Big Data”. Many conventional software systems are not able to process these data volumes, so special Big Data technologies need to be used instead. In this context, it may also be worth considering using cloud solutions. When cloud systems are used, control is exchanged for ease of operation. Depending on the existing expertise, the application scenario and requirements, this may be a sensible choice.
Guiding questions
- What components will make up the eventual overall system? Which are already available and which need to be added?
- When creating the new or expanded overall system, where are the integration points that have to be implemented for productive use?
- Is there a need for a big data architecture?
- Should cloud solutions be used?
Measures and tools
- IAO – IoT architecture sheet for creating a reference architecture. This is used to visualize components and interfaces so that the entire project team can see which components already exist and which need to be implemented (example 5).
Model building
The actual Al mostly consists of configuring models and processing data through training. The requirements for data preparation vary depending on the model: Some models cannot cope with missing or only numerical data, for example. As well as selection and training, models also need to be configured. Hyperparameters have to be selected and optimized; these differ greatly from model to model. Analyses then show how suitable the combination of the selected model and hyperparameters is, which often leads to new configurations or even other models. The data may also vary depending on the model: so-called feature engineering is used to select the data for the respective model and how it is presented. It may be useful, for example, to transfer the data to the models either individually or in an aggregated form. Model building usually involves a combination of existing experience, proven processes and trial and error.
Guiding questions
- Do data adjustments have to be made to the models?
- What are the hyperparameters for the chosen models, what are their standard values and to what degree does it make sense to deviate from them?
- Which data is fed to the models for training and in which form?
Measures and tools
- IM – Programming: Skilled workers use programming to create the Al models with maximum flexibility.
- P – Graphical software tools: Skilled workers use graphical tools to create Al models that are pre-implemented in a configurable manner. They can be combined and configured with graphical interface elements.
- IM – Automated machine learning (AutoML) automates the search for appropriate solutions by trying out many different models and configurations.
Robustness and Al security
As well as the underlying IT security, the level of robustness and Al security also needs to be defined for Al systems. The level of “robustness” indicates how effectively a system can handle deviations in the data. The level of “Al security” refers to the level of robustness with regard to targeted data manipulation. Attacks on Al systems can involve manipulating data to worsen results or falsify them in a targeted way.
Guiding questions
- Is the data that is relevant to the application scenario adequately represented in the data used to create the Al models? If not, robustness can be dramatically reduced in the practical application.
- Could potential attackers be interested in the application case? If not, this should be documented. Otherwise, the Al experts must improve robustness through individual measures.
- What are countermeasures for likely attack scenarios? These measures depend on the application scenario and the data, but established methods also exist, such as applying noise filters to audio data to increase the robustness of Al models.
Measures and tools
- IM – Targeted building and testing of edge cases
- IM – Data-driven penetration test: Testers with technical Al expertise attempt to fool Al models or achieve poor results.
Final evaluation
The final evaluation is particularly significant in Al projects as it also has to be considered that it might not have been possible to meet the original objective. Iterations and changes in the plan — or even abandonment of the project — are possible at many steps in Al projects, particularly in the “data access,’ “data preparation,” “understanding and exploring data” and “model building” stages. This is due to the fact that it is not always possible to clearly predict if the desired information is adequately reflected in the data. While it is possible in theory for these steps to be expanded as necessary in order to optimize data understanding and Al models, the final evaluation represents the end of these iteration possibilities and determines whether the project results will be applied in practice. In this step, the objectives and requirements are checked, and cost-effectiveness is scrutinized based on the knowledge obtained (e.g., complexity of Al models and expected cost of maintenance and further development).
Guiding questions
- Has it been possible to achieve the original objective (to a sufficient degree)?
- Is it economically viable to transition to live operation?
- Have the specified requirements been met to a sufficient degree?
- What further data potentials have arisen during the project period to date?
Measures and tools
- IM – Assess the economic viability of prototypes and system concepts
- IM – Step-by-step review of requirements from phase 1
Imprint
Fraunhofer Institute for Industrial Engineering IAO
Nobelstraße 12
70569 Stuttgart
Germany
www.iao.fraunhofer.de
Authors
Damian Kutzias, Claudia Dukino, Jan-Paul Leuteritz
Editors
Oliver Riedel, Katharina Hölzle, Wilhelm Bauer, Matthias Peissner
Contact
Press and Public Relations
Fraunhofer IAO
Nobelstraße 12
70569 Stuttgart
Germany
presse@iao.fraunhofer.de
Fraunhofer Publica
http://dx.doi.org/10.24406/publica-4420
© Fraunhofer IAO, 2025
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License: https://creativecommons.org/licenses/by-sa/4.0/legalcode.en
The legal expertise was provided by the law firms BHO Legal and Oppenländer.
Contact (Authors)
Damian Kutzias
damian.kutzias@mail.de
Claudia Dukino
Digital Business
claudia.dukino@iao.fraunhofer.de
Dr. Jan-Paul Leuteritz
Ergonomics and Vehicle Interaction
jan-paul.leuteritz@iao.fraunhofer.de
Ziele und Anforderungen
Bei der inhaltlichen Ausrichtung geht es darum, die Projektidee sauber auszugestalten, die Voraussetzungen zu prüfen und Anforderungen abzuleiten. Hierbei gilt es, bereits die Frage zu stellen, ob das Projekt als KI-Projekt sinnvoll ist und falls ja, wie es erfolgreich umgesetzt werden kann.
Deshalb sollten Sie sich beispielsweise frühzeitig mit den folgenden Sachverhalten auseinandersetzen:
- Das Projekt sollte – falls möglich – zur Gesamtstrategie der Organisation passen und nicht als losgelöster Satellit starten.
- Alle Akteure werden bei der Aufnahme der Aktivitäten und Anforderungen mitgenommen, z. B. Fachabteilung, Betriebsrat/Personalrat, Fachperson für Datenschutz etc.
- Betroffene Prozesse werden nicht losgelöst, sondern im Gesamtkontext betrachtet.
Ziel und Wirtschaftlichkeit
Wie bei klassischen Projekten steht bei KI-Projekten am Anfang das Festlegen von Zielen. Um auf diesen Zielen auch ein Projekt aufzusetzen, ist in der Regel eine Vorstellung vom Nutzen und den notwendigen Aufwänden erforderlich.
Was bei klassischen Projekten schon schwer sein kann, ist bei KI-Projekten ungleich schwerer: Die Unsicherheit, was wirklich in den Daten steckt und ob die vorhandenen Daten auch ausreichen, macht diese Abschätzung zu einer besonderen Herausforderung. Durch diese Unsicherheit empfiehlt es sich, die Möglichkeit für Rückschritte und Projektabbruch von Anfang an einzuplanen.
Die Bewertung sollte nicht intuitiv oder durch Einflüsse von außen getroffen werden. Besser ist es, nach den gleichen Grundsätzen zu handeln, die auch für alle anderen Anlageentscheidungen gelten. Das bedeutet, sich einen Überblick zu verschaffen und beispielsweise zu prüfen, ob das Projekt in die Gesamtorganisationsstrategie passt und die Stakeholder im Prozess ausreichend mitgenommen werden.
Leitfragen
- Welche internen bzw. externen Ziele verfolgt das Projekt?
- Welche Ressourcen werden für das Projekt benötigt?
- Welcher Nutzen ist durch das Projekt zu erwarten?
- Wie ist der Return on Investment einzuschätzen?
- Wie passen die individuellen Ziele des Projekts zur Unternehmensstrategie?
Falls die Projektidee innerhalb der Fachabteilung entwickelt wurde, sollte geprüft werden, ob die Idee zur KI-Strategie des Unternehmens passt. Für weiterführende Informationen empfehlen wir das Kapitel »Handlungsfeld: Betriebliche KI-Strategie« im Leitfaden zu Strategie und Wandel.
Maßnahmen und Werkzeuge
- Ö – Business Model Canvas zur Festlegung von Zielen und Anforderungen sowie Prüfen der Projektidee (Beispiel 1)
- IM – Anwendungsfallorientierte Risikoabschätzung zur Zielerreichung
- Ö – Nutzwertanalyse zur Bewertung von Nutzenargumenten
Anforderungen
In Bezug auf Anforderungen haben KI-Projekte viele Parallelen zu klassischen Projekten. Hier sammeln sich die gesamten Aspekte zum Projekt. Hervorzuheben sind jene Anforderungen, die sich aus den Bedarfen der Stakeholder, den Schlüsselaktivitäten und den Aspekten der betrachteten Prozesse ergeben.
Wenn die befragten Stakeholder Anforderungen an die KI-Anwendung geäußert haben, z. B., dass sie verstehen möchten, wie diese funktionieren wird, muss dies bei der Erstellung berücksichtigt werden.
Es gibt allerdings auch noch grundsätzliche Anforderungen, welche z. B. übergeordnet aus dem Unternehmen kommen wie der Umgang mit Ethik, Risikomanagement oder aber auch dem Interaktionskonzept (Usability). Mit dem Interaktionskonzept ist die Gestaltung der Mensch-Maschine- Schnittstellen gemeint, sodass sie für die Nutzenden einfach und verständlich ist.
Wichtig ist es, die an das Projekt gestellten Anforderungen systematisch in den nachfolgenden Schritten des Leitfadens aufzunehmen und nicht schon zu handeln, bevor das Problem überhaupt richtig verstanden wurde. Somit wird auch ein gemeinsames Verständnis für das Projekt geschaffen, was auch dabei hilft die anstehenden Aktivitäten auf ihre Machbarkeit zu überprüfen, zu klassifizieren und zu strukturieren, um sie abschließend priorisieren und für die anstehende Umsetzung überprüfen zu können.
Leitfragen
- Welche Anforderungen stellen die Stakeholder an das Projekt?
- Welche KI-spezifischen Anforderungen gibt es (bspw. Erklärbarkeit der Ergebnisse)?
- Wie soll der zukünftige Prozess aussehen?
- Welche Anforderungen ergeben sich aus den Schlüsselaktivitäten?
- Welche rechtlichen Rahmenbedingungen sind einzuhalten?
- Wie kann KI genutzt werden, um ein positives Benutzungserlebnis zu gestalten?
- Was für Anforderungen ergeben sich bzgl. Usability?
- Gibt es sonstige Anforderungen z. B. übergreifend aus dem Unternehmen?
- Ändert sich die Arbeit durch das Projekt auf eine Art, die mitbestimmungspflichtig ist?
Maßnahmen und Werkzeuge
- Ö – Requirements Engineering (Anforderungsanalyse)
- Ö – Erstellung von Mockups mit Papier- oder Klick-Prototypen
- Ö – Nutzendenzentrierter Gestaltungsprozess: Iterativer Prozess zur Gestaltung gebrauchstauglicher, interaktiver Systeme, die die Nutzenden in allen Phasen einbeziehen1
Bedarfe aus der Stakeholderperspektive
Stakeholder sind allgemein Personen oder Organisationen, die die Anforderungen an das Projekt beeinflussen oder von ihm zukünftig beeinflusst werden können. Sie tragen somit maßgeblich zur Ableitung von Zielen, aber auch Anforderungen bei.
Insbesondere bei KI, welche bisweilen als undurchschaubare »Black Box« auftreten kann, indem sie ihre interne Logik vor dem Nutzenden verbirgt, ist es notwendig, frühzeitig sicherzustellen, dass es keine grundsätzliche Abneigung oder fehlende notwendige Kompetenzen bei den Stakeholdern gibt. Deshalb sollte die Vertretung der Mitarbeitenden frühzeitig einbezogen werden.
Leitfragen
- Welche Stakeholder sollten befragt werden?
- Gibt es passive Stakeholder (z. B. Betriebsrat), die sich in das Projekt einbringen und aus diesem Grund auch befragt werden sollten?
- Welche Interessen verfolgen die betroffenen Stakeholder?
- Gibt es unterstützende Stakeholder, die nicht zwangsläufig im Projekt involviert sind, aber Synergien aus anderen Vorhaben einbringen könnten?
- Können sich Konfliktsituationen durch unterschiedliche Ansichten der Stakeholder ergeben?
- Ist grundlegendes Wissen bei den Stakeholdern zu KI vorhanden oder gibt es hier Handlungsbedarf, um die Akzeptanz gegenüber dem Projekt zu stärken?
- Welche Anforderungen stellen die Stakeholder an die Usability der Anwendung?
Maßnahmen und Werkzeuge
- Ö – Stakeholder-Analyse zur Identifizierung relevanter Stakeholder
- Ö – Akzeptanzanalysen und -modelle zur Bewertung der Technologieakzeptanz der Stakeholder
- Ö – Persona-Methode zur Darstellung und Kommunikation von Bedürfnissen
Betroffene Prozesse
Tätigkeiten und somit Arbeitsschritte finden innerhalb von Wesentlicher Faktor ist auch die Tauglichkeit der Prozesse als Grundlage der Arbeit, denn auch ein KI-gestützter schlechter Prozess ist immer noch ein schlechter Prozess.
Leitfragen
- Welche Prozesse sind im Rahmen der Projektumsetzung betroffen und sind diese bereits transparent aufbereitet oder ist der IST-Prozess noch zu erfassen?
- Ist der Prozess ein inner- (im Unternehmen) oder zwischenbetrieblicher Prozess (mit Partnern oder Dienstleistern)?
- Wer ist verantwortlich für den Prozess (das Unternehmen selbst oder ein externer Partner)?
- Welche Mitarbeitenden sind von dem Prozess betroffen und welche Erwartungen stellen diese an den Prozess?
- Sind die Schnittstellen, an denen es zur Übergabe von Ressourcen, Informationen und Verantwortungen kommt, bereits digitalisiert oder kommt es zu Medienbrüchen im Ablauf?
- Wie soll die zukünftige Aufgabenverteilung zwischen Mensch und Technik aussehen?
Maßnahmen und Werkzeuge
- Ö – Prozessmodellierungswerkzeuge zur Datenaufnahme, Modellierung, Speicherung und Einsortierung sowie zur funktions- und organisationsübergreifenden Kommunikation. Im einfachsten Fall kann das eine Präsentationssoftware aus einem Office-Produkt sein.
- Ö – Prozessmodellierungssprachen wie UML (Unified Modeling Language) oder BPMN (Business Process Model and Notation)
- Ö – Unterstützende strukturierte Analysen für eine grobe Prozessübersicht: Prozessmapping und Makigami
- IAO – Aktivitätsdiagramme aus UML mit Hervorhebung der Mensch-Technik-Schnittstellen (Beispiel 2)
Schlüsselaktivitäten
Unter Schlüsselaktivitäten werden wesentliche Arbeitsschritte in betroffenen Prozessen verstanden, welche einen wertschöpfenden Beitrag im Projekt liefern. Es ist wichtig zu verstehen, welche Aktivitäten in der Funktionsteilung zwischen Mensch und Technik in welchem Umfang automatisiert bzw. unterstützt werden können, um die erforderlichen Kompetenzen im Hinblick auf die mögliche neue Anwendung zu verstehen.
Dazu ist es notwendig, die Kerntätigkeiten der Anwendenden und deren benötigten Kompetenzen zu analysieren, die menschliche, technische und organisatorische Aspekte umfassen können.
In der Forschung ist der Begriff der Automatisierung von Tätigkeiten eng mit dem Begriff der Routine verbunden. Dafür ist es notwendig, den Routine- Anteil einer Aufgabe einschätzen zu können. Dafür sollten die Anforderungen an Wissen und Interaktion, welche zum Ausführen der Tätigkeit notwendig sind, eingeschätzt werden. Dies ist wichtig, weil sich der Routine-Anteil tendenziell besser für eine mögliche Automatisierung eignet als hochindividualisierte Tätigkeiten.
Leitfragen
- Welche Aktivitäten werden durch die Nutzenden Stand heute ausgeführt?
- Welche Anforderungen stellen die Nutzenden an ihre zukünftigen Aktivitäten (Ziel des Projekts)?
- Wie sieht die Einordnung der Aktivitäten in Routine und Nicht-Routine-Tätigkeiten aus?
- Wie hoch ist der Homogenitätsanteil aller Aufgaben, die zur Durchführung einer Schlüsselaktivität gehören?
- Wie kann das Wissen über menschengerechte Gestaltung der Arbeit bei der Planung von Arbeitsverfahren und Arbeitsabläufen berücksichtigt werden?
- Müssen zur Erhebung der Anforderungen schützenswerte Daten, bspw. durch Videoaufnahmen der aktuellen Arbeit, verarbeitet werden?
Maßnahmen und Werkzeuge
- IAO – Bearbeitungsmatrix zur Einordnung von Routine und Nicht-Routine-Tätigkeiten (Beispiel 3)
- Ö – Shadowing-Methode zur Nutzenden- und Zielgruppenanalyse, d. h., dass die ausführenden Personen bei ihren Tätigkeiten beobachtend begleitet werden, ohne sie zu beeinflussen oder gar zu stören.
- Ö – Arbeitsanalysen durchführen, indem Nutzende zu ihren Tätigkeiten befragt werden.
Rechtliche Aspekte
Allgemeine rechtliche Aspekte EU-Verordnung zu KI
Arbeitsrecht
KI-Systeme können Mitbestimmungsrechte von Vertretungen der Mitarbeitenden (Betriebsrat/Personalrat) auslösen. Software im Beschäftigtenkontext ist regelmäßig eine technische Einrichtung, mit der sich das Verhalten oder die Leistung der Mitarbeitenden überwachen lässt, weshalb über die Einführung und Anwendung der Betriebsrat mitzubestimmen hat.
Führt KI zu einer grundlegenden Änderung der Betriebsorganisation, liegt eine mitbestimmungspflichtige Betriebsänderung vor. Dann müssen ein Interessenausgleich versucht und möglicherweise sogar ein Sozialplan aufgestellt werden.
Schon bei der Planung von Arbeitsverfahren und Arbeitsabläufen unter Einsatz von KI ist der Betriebsrat zu unterrichten und sind seine Vorschläge und Bedenken zu berücksichtigen.
Ändern sich für Mitarbeitende die Arbeitsumstände erheblich, kann eine Versetzung vorliegen, die der Zustimmung des Betriebsrats bedarf.
Wird KI zur Aufstellung von Richtlinien über personelle Auswahl bei Einstellungen, Versetzungen, Umgruppierungen oder gar Kündigungen eingesetzt, muss der Betriebsrat zwingend beteiligt werden.
Mitarbeitende dürfen nicht diskriminiert werden. Es muss deshalb sichergestellt werden…
Datenschutzrecht
Bei der Verarbeitung personenbezogener Daten ist besonders die Datenschutzgrundverordnung (DSGVO) relevant. Vermeintlich unkritische Daten (z. B. Maschinendaten, welche durch Sensoren am Fließband aufgenommen werden) können Rückschlüsse auf Personen (wie Mitarbeitende, Kund*innen, Lieferanten etc.) zulassen, sodass für die Verarbeitung dieser Daten eine spezifische datenschutzrechtliche Rechtsgrundlage vorliegen muss.
Informationen zu rechtlichen Themen und deren Umgang im Rahmen der Organisationsstrategie können im Kapitel »Rechtliche Risiken minimieren« im Leitfaden zu Strategie und Wandel nachgelesen werden.
Ein weiterer Grundsatz der DSGVO ist die Zweckbindung, welche besagt, dass personenbezogene Daten nur für festgelegte Zwecke verwendet und nicht in einer Weise weiterverarbeitet werden dürfen, die mit diesen Zwecken nicht zu vereinbaren ist.
Soweit für die Umsetzung eines KI-Projektes auf bestehende Datensätze mit Personenbezug zurückgegriffen werden soll, muss daher zunächst geprüft werden, zu welchen Zwecken die Daten ursprünglich erhoben wurden und auf welcher Grundlage die Daten weiterverarbeitet werden können.
Da die DSGVO KI-Lösungen per se als risikobehaftet ansieht, muss daneben im Regelfall eine sog. »Datenschutz-Folgenabschätzung« durchgeführt werden. In dieser müssen u. a. die Verarbeitungsvorgänge systematisch beschrieben und die Verarbeitungszwecke und Risiken bewertet werden.
Die Datenschutz-Folgenabschätzung muss abgeschlossen und dokumentiert sein, bevor personenbezogene Daten innerhalb des KI-Projekts (einschließlich einer etwaigen Trainingsphase) verarbeitet werden. Zudem sollte vorab geprüft werden, wie Betroffenenrechte (etwa Auskunftsansprüche, Löschbegehren, Widerruf von Einwilligungen etc.) im Zusammenhang mit dem Einsatz von KI-Systemen erfüllt werden können.
Sollen KI-Lösungen auch zur Vorbereitung von Entscheidungen genutzt werden, die rechtliche Wirkung entfalten (etwa im Recruiting oder bei der Bewertung von Mitarbeitenden), gelten besonders strenge Anforderungen; eine Nutzung von KI-Lösungen ist hier im Beschäftigtenkontext meist unzulässig.
Soweit nur mit Daten gearbeitet wird, die sich keinem individuellen Mitarbeitenden oder sonstigen Personen zuordnen lassen (etwa rein betriebsbezogene oder aggregierte Datensätze), greift der datenschutzrechtliche Erlaubnisvorbehalt nicht. Daher kann es sinnvoll sein, den Einsatz von KI-Lösungen von Anfang an auf aggregierte Daten ohne Personenbezug zu beschränken oder Daten vor der Nutzung zu anonymisieren.
Im Einzelfall kann dies sogar rechtlich erforderlich sein. Nach dem Grundsatz der Datenminimierung muss die Verarbeitung personenbezogener Daten grundsätzlich auf ein notwendiges Maß beschränkt werden. Soweit sich die Ziele, die mit dem KI-Einsatz verfolgt werden, auch ohne personenbezogene Daten oder mit einem geringeren Datensatz erreichen lassen (etwa der Verwendung von Pseudonymen statt Klarnamen), muss dieser datensparsamere Weg gewählt werden.
Für die Definition der Ziele und Anforderungen ist es daher unerlässlich, möglichst frühzeitig die Fachkraft für Datenschutz bzw. fachkundige Beratende in das Projekt einzubeziehen, um die aufgeworfenen Rechtsfragen im Einzelfall zu bewerten.
Weitere gesetzliche Schutzrechts-Aspekte
Je nach Art und Inhalt der Trainingsdaten wird eine Evaluation der Trainingsdaten erforderlich, bevor mit deren Sammlung begonnen werden kann. Trainingsdaten können unter verschiedenen rechtlichen Gesichtspunkten ihrerseits gesetzlichen Schutz beanspruchen (z. B. urheberrechtlicher Schutz für Texte, Fotos oder Klänge; datenschutz- und persönlichkeitsrechtlicher Schutz für Bildnisse von Personen oder markenrechtlicher Schutz bei Bildnissen von Gegenständen) oder gar ein Geschäftsgeheimnis verkörpern.
Daneben besteht auch die Möglichkeit, dass Datenbanken, aus denen Trainingsdaten stammen, selbst urheberrechtlich oder urheberrechtsähnlich schutzfähig sind.
Das deutsche Recht bietet wirksame Ausnahmen vom grundsätzlichen Schutz z. B. im Urheberrecht durch die grundsätzliche Erlaubnis eines Text- und Data Minings (§ 44b UrhG).
Wenn der Rechteinhaber es nicht ausdrücklich verbietet – was nicht immer leicht zu identifizieren ist – darf ein »Text- und Data Mining« von veröffentlichten urheberrechtsfähigen Daten durchaus erfolgen.
Dabei ist jedoch stets zu beachten, dass Trainingsdaten naturgemäß sehr komplex sind. Je nach Art oder Inhalt der Daten können diese durch verschiedene Schutzrechte (Urheberrecht, Markenrecht, Geschäftsgeheimnisse etc.) geschützt sein, und daher auch je nach dem Schutzrecht verschiedene Ausnahmeregelungen gelten.
Daher ist im Einzelfall zu prüfen, welche Arten von Daten bzw. Inhalte im Trainingsdatensatz vorliegen. Bei urheberrechtlich geschützten Daten kann die (urheberrechtliche) Ausnahme des »Text und Data Minings« anwendbar sein. Bei markenrechtlich geschützten Daten oder beim Vorliegen von Geschäftsgeheimnissen können andere Ausnahmeregelungen gelten.
Ferner ist zu berücksichtigen, dass ein rechtmäßiges Text- und Data Mining voraussetzt, dass Extrahierung der Daten erfolgen muss, um »daraus Informationen (…) zu gewinnen«, also insbesondere, um Informationen über die in den analysierten Datensätzen verborgenen Mustern auszugeben.
An diesem Zweck kann ein rechtmäßiges Text- und Data Mining scheitern, wenn die Extrahierung der Daten z. B. dem Training eines künstlichen neuronalen Netzwerks dient, das die Informationen selbst nicht analysiert, sondern daraus andere Informationen automatisiert zusammenstellt.
In diesem Zusammenhang ist ferner relevant, ob die Trainingsdaten ihrerseits Geschäftsgeheimnisse des Unternehmens oder gar Dritter im Sinne des Geschäftsgeheimnisschutzgesetzes verkörpern.
Werden eigene Geschäftsgeheimnisse genutzt, sollte in jedem Fall geklärt werden, ob dadurch eine Offenbarung der jeweiligen Daten erfolgt, die ggfs. dazu führen kann, dass der Geschäftsgeheimnisschutz erlischt (siehe dazu auch im Kapitel »Rechtliche Aspekte betreffend die Ergebnisse der KI-Leistung«).
Datenlizenzen
Wenn Daten aus öffentlich verfügbaren Quellen oder aber von Datenanbietern beschafft werden, sind ggf. Regelungen in Datenlizenzen zu beachten, die einer Nutzung der entsprechenden Datensätze in KI-Systemen entgegenstehen könnten oder aber zusätzliche Lizenzgebühren auslösen. Um dies zu vermeiden, ist zu prüfen, ob Daten, die nicht selbst erhoben werden, entsprechenden Einschränkungen unterliegen.
Leitfragen (Datenschutz & Schutzrechte)
- Sind die zu verarbeitenden Daten direkt (Person ist bekannt) oder indirekt personenbezogen (es können durch die durchgeführten Auswertungen Rückschlüsse auf eine bestimmte Person gezogen werden, da die Fallzahl zu niedrig ist oder die Merkmale zu eindeutig auf eine Person hindeuten)?
- Sind die vorliegenden Daten zweckgebunden erhoben worden?
- Sind die Projektziele mit den Zwecken kompatibel, für die eine Datenverarbeitung erlaubt ist?
- Auf welcher Rechtsgrundlage und in welchem Umfang dürfen die Daten eingesetzt werden?
- Ist es notwendig, die Daten vor Nutzung zu anonymisieren oder zu pseudonymisieren?
- Bedarf es vertraglicher Regelungen, Einwilligungen und/ oder überarbeitete Datenschutzinformationen zur Erhebung und Nutzung von Daten?
- Müssen die Risiken für personenbezogene Daten vorab in einer Datenschutz-Folgenabstimmung geprüft und dokumentiert werden? Wer führt diese durch?
- Ist sichergestellt, dass keine unzulässigen automatisierten Entscheidungen durch die KI getroffen werden?
- Gibt es im Unternehmen Aufbewahrungs- und Löschkonzepte? Müssen diese ggf. erstellt oder angepasst werden?
- Ergeben sich aus dem Anwendungsfall heraus weitere rechtliche Anforderungen?
Leitfragen (Arbeitsrecht & EU-VO)
- Welche Mitbestimmungsrechte der Vertretung der Mitarbeitenden müssen berücksichtigt werden und wann ist diese zu beteiligen?
- Welche der vorgesehenen Risikogruppen der geplanten KI-Verordnung der EU ist der Anwendungsfall zuzuordnen und welche Anforderungen ergeben sich daraus?
- Verändert KI Arbeitsverfahren und Arbeitsabläufe, sodass ein Betriebsrat schon bei der Planung einbezogen werden muss?
- Müssen Betriebsvereinbarungen abgeschlossen werden, weil die erforderliche Software auch geeignet ist, das Verhalten und die Leistung der Mitarbeitenden zu überwachen?
- Macht der Einsatz von KI mitbestimmungspflichtige Versetzungen von Mitarbeitenden erforderlich?
- Führt KI zu einer grundlegenden Änderung der Betriebsorganisation und damit zu einer mitbestimmungspflichtigen Betriebsänderung?
- Wird KI zur Entscheidung über eine personelle Auswahl eingesetzt und besteht die Gefahr, dass verbotene Merkmale in die Entscheidung einfließen?
Rechtliche Aspekte betreffend die Ergebnisse der KI-Leistung
Zum vertiefenden Umgang mit Datenlizenzen empfehlen wir das Kapitel »Handlungsfeld: Datenstrategie« im Leitfaden zu Strategie und Wandel.
Geschäftsgeheimnisschutz
Ein besonderes Interesse des Unternehmens an den Ergebnissen dürfte selbsterklärend sein. Insoweit kommt insbesondere in Betracht, Ergebnisse von KI-Systemen als Geschäftsgeheimnisse anzusehen.
Damit ein Geschäftsgeheimnis als solches gesetzlichen Schutz genießen kann, müssen folgende Voraussetzungen zutreffen:
- Es muss sich um eine Information handeln, die
- weder insgesamt noch in der genauen Anordnung und Zusammensetzung allgemein bekannt oder ohne Weiteres zugänglich ist
- und von wirtschaftlichem Wert ist und
- Gegenstand von den Umständen nach angemessenen Geheimhaltungsmaßnahmen durch ihren rechtmäßigen Inhaber ist und
- bei der ein berechtigtes Interesse an der Geheimhaltung besteht.
- Es muss sich um eine Information handeln, die
Vor diesem Hintergrund ist insbesondere wichtig, dass angemessene Geheimhaltungsmaßnahmen betreffend die Ergebnisse ergriffen werden. Weil das Geschäftsgeheimnisgesetz technologieoffen gestaltet ist, besteht keine gesetzliche Pflicht für den Einsatz bestimmter Geheimhaltungsmaßnahmen.
Welche Geheimhaltungsmaßnahme im Einzelfall gemessen an der Schutzbedürftigkeit des konkreten Geschäftsgeheimnisses angemessen ist, lässt sich daher allgemeingültig nicht aussagen. Ein prominentes Beispiel kann aber eine besondere vertragliche Verschwiegenheitsverpflichtung der an den KI-Systemen arbeitenden Mitarbeitenden sein. Darüber hinaus sind technische Zugangshürden, wie z. B. die verschlüsselte Speicherung oder die Erarbeitung eines Berechtigungskonzepts für den Zugang zu den Ergebnissen, häufig vorzufindende Maßnahmen.
Urheberrechts- und Patentschutz
Unter Umständen können Ergebnisse einer KI urheberrechtlich schützbar sein. Das hängt von der Art des Ergebnisses ab. Im Regelfall sind die Ergebnisse jedoch nicht urheberrechtsfähig. Ein urheberrechtlicher Schutz kann nur für persönliche geistige Schöpfungen einer natürlicher Person – also eines Menschen – entstehen.
Dasselbe gilt für die »Erfindung«, die, als Patent eingetragen, ebenfalls gesetzlichen Schutz nach dem PatentG genießen kann. Ein KI-System kann aber nie Erfinder oder Urheber des jeweiligen Ergebnisses sein.
Auch ist weder der Betreiber noch der Programmierer des KI-Systems als Urheber anzusehen, denn von diesen Personen kann in der Regel keiner als Schöpfer des Ergebnisses selbst angesehen werden. Eine Ausnahme kann etwa dann gelten, wenn das KI-System selbst nur als Werkzeug im Rahmen des Schaffensprozesses oder für die Erfindung genutzt wird. Dann kann ausnahmsweise der Anwendende als Urheber oder Erfinder gelten.
Als wichtigste Grundregel gilt dabei, dass die im Ergebnis verkörperte Schöpfung aber das Ergebnis eines geistig individuellen Schaffensprozesses des Anwendenden ist. Dies lässt sich in aller Regel verneinen, wenn z. B. ein künstlerisch anmutendes Bild oder ein Text allein aufgrund von einfachen, das vom KI-System zu erstellende Bild bzw. den Text beschreibenden Befehlen durch das KI-System geschaffen wird. Auch ein Leistungsschutz an Bildern wird in der Regel zu verneinen sein, da durch KI geschaffene Bilder durch die Berechnung von Pixelinformationen entstehen.
Es käme allerdings in Betracht, dass ein durch ein KI-System geschaffenes Datenbankkonstrukt urheberrechtsähnlichen Leistungsschutz als Datenbank (§ 87a UrhG) genießt, wenn die darin enthaltenen Daten bzw. Elemente »systematisch oder methodisch angeordnet und einzeln mithilfe elektronischer Mittel oder auf andere Weise zugänglich sind« und wenn zugleich »deren Beschaffung, Überprüfung oder Darstellung eine nach Art oder Umfang wesentliche Investition erfordert«.
Rechteinhaber eines solchen Leistungsschutzrechts ist derjenige, der die Investition tätigt, also in der Regel das Unternehmen, das auch als juristische Person Leistungsschutzberechtigter sein kann.
Verwertung von KI-Ergebnissen auf Grundlage von vertraglichen Datenlizenzen
Da die mithilfe von KI-Systemen generierten Ergebnisse in der Regel nicht urheberrechtlich geschützt sind, jedoch Rechte Dritter verletzen können (siehe »Rechtliche Risiken minimieren« im Leitfaden zu Strategie und Wandel), ist je Anwendungsfall festzulegen, wie die mit den KI-Systemen erzielten Ergebnisse genutzt werden.
Sollen KI-generierte Ergebnisse Dritten zur Verfügung gestellt werden, ist im Hinblick auf den grundsätzlich fehlenden urheberrechtlichen Schutz KI-generierter Ergebnisse zu prüfen, ob eine Weitergabe an Dritte unter Zugrundelegung einer Lizenzvereinbarung erfolgt, welche die Rechte und Pflichten der Parteien festlegt.
Leitfragen (Ergebnisse)
- Können die Ergebnisse der KI-Leistung eine eigenständige wirtschaftliche Bedeutung haben und müssen diese Daten wegen ihrer Geheimhaltungsbedürftigkeit besonderen Schutzmaßnahmen unterworfen werden?
- Sind die Anwendenden auf die Geheimhaltung von KI-Ergebnissen verpflichtet?
- Kommt angesichts von Art und Inhalt der KI-Ergebnisse ein spezifischer gesetzlicher Schutz (etwa ein Leistungsschutzrecht an Datenbanken, die durch ein KI-System erschaffenen wurden) in Betracht?
- Sollen KI-Ergebnisse verwertet werden und kommen Datenlizenzen in Betracht, wenn die KI-Ergebnisse selbst nicht schon per Gesetz geschützt sind?
Maßnahmen und Werkzeuge
- IM – Einbeziehen von Rechtsexpertise, ggf. mit Spezialisierung auf den betroffenen Bereich. Das Verständnis von Rechtssprache sowie deren Auslegung ist von juristischen Fachleuten ausgeprägter verglichen mit dem Rechtsverständnis von fachfremden Menschen. Zudem können sich Gesetze je nach Anwendungsbereich regional und fachlich unterscheiden sowie auch mit der Zeit ändern, wodurch im Zweifelsfall die Konsultation von Rechtsexperten zu empfehlen ist.
- IAO – Dieser Leitfaden und der Leitfaden zu Strategie und Wandel
Projektstart
In der Phase des Projektstarts sollten Sie sich überlegen, wie Sie die geplante KI-Anwendung optimal umsetzen können. Deshalb gilt es für jeden der nachfolgenden Schritte zu klären, was bereits zur Verfügung steht und welche Dienstleistungen ggf. eingekauft werden müssen. Die folgenden Fragen sind dabei von zentraler Bedeutung:
- Sind Daten für den Anwendungsfall tatsächlich und rechtlich verfügbar und befinden sich diese in nutzbarem Zustand?
- Müssen externe Daten zugekauft werden?
- Stehen Mitarbeitende mit entsprechendem Wissen zur Verfügung?
- Verfügen die internen Wissentragenden über Kapazitäten, um das neue Projekt zu unterstützen, oder braucht man hierfür externe Unterstützung?
- Gibt es zu der Idee, die man verfolgt, bereits eine fertige Lösung am Markt, die man kaufen kann?
- Sind die in Frage kommenden Dienstleister vertrauenswürdig, auch mit Blick auf die verwendeten Datensätze?
Eventuell reduzieren sich die benötigten Daten sowie projektbezogene Aufwände drastisch, falls eine passende Lösung bereits existiert. So würde sich ein Implementierungsprojekt zu einem Einführungsprojekt ändern, wodurch die dritte Phase sich stark reduzieren würde.
Nehmen Sie sich gerade in dieser Phase die Zeit, um abzuwägen, welcher Weg der für Sie sinnvollste ist.
PE PL Fach SE KI IT BR
Datenzugriff
Mit der Verfügbarkeit von Daten stehen und fallen KI-Projekte. Daher sollte vor dem Projektstart bereits geprüft werden, ob der Datenzugriff auf die Trainingsdaten sowohl in tatsächlicher als auch in rechtlicher Hinsicht gewährleistet ist.
Es sollte immer eine Dokumentation zu den genutzten und generierten Daten mitsamt möglichen Nutzungsbeschränkungen geführt werden, dazu empfehlen wir das Kapitel »Handlungsfeld: Datenstrategie« im Leitfaden zu Strategie und Wandel.
Der Zugriff kann sich dabei sehr vielseitig gestalten: Kund*innen oder Partner können Daten liefern, was ihre Bereitschaft zur Herausgabe der Daten voraussetzt. In unserem Kaffeebeispiel könnten Kunden wie Bars, Hotels etc. Daten zur Verfügung stellen. Dadurch könnten die Prognoseergebnisse, wann das Auffüllen und Nachbestellen notwendig sein wird, voraussichtlich deutlich verbessert werden.
Sofern personenbezogene Daten genutzt werden sollen, muss eine rechtliche Verarbeitungsgrundlage bestehen (z. B. nach Art. 6 DSGVO oder § 26 BDSG). Soweit die Nutzung personenbezogener Daten auf eine Einwilligung gestützt werden soll, muss hierbei beachtet werden, dass es auf die Einwilligung derjenigen Personen ankommt, deren Daten übermittelt werden sollen.
Eine wirksame Einwilligung muss freiwillig und informiert abgegeben werden. Bei personenbezogenen Daten von Beschäftigten ist die Freiwilligkeit regelmäßig nicht gegeben, da ein Abhängigkeitsverhältnis zwischen Arbeitgeber und Arbeitnehmer besteht. Eine Lösung kann darin bestehen, Daten sofort zu anonymisieren, d. h., dass die nachträgliche Identifizierung von Personen unmöglich wird.
Ebenso können Daten in eigenen Systemen liegen, was je nach Organisation nicht automatisch heißt, dass diese auch unmittelbar verfügbar sind, da sie
- nicht in den für die Systeme nutzbaren Formaten gespeichert sind,
- lückenhaft sind oder
- unter besonderem rechtlichen Schutz stehen.
Die Daten liegen z. B. unter urheberrechtlichem Schutz oder sie sind Geschäftsgeheimnisse des Unternehmens oder Dritter oder sie unterliegen einer Vertraulichkeitsvereinbarung oder sie sind Gegenstand einer Datenlizenz oder sie gehören zu personenbezogenen Daten. Hier bedarf es zunächst einer Datenaufbereitung und ggfs. einer Rechteklärung.
Dafür muss sichergestellt sein, dass vorhandene Daten für die angestrebten Verarbeitungszwecke rechtskonform genutzt werden dürfen.
Letztendlich können Daten auch selbst generiert werden. Es zählt nicht nur der generelle Zugriff auf die Daten, sondern auch, ob Daten in hinreichender Menge zur Verfügung stehen. Dazu gehört auch, Beispiele zu möglichst allen relevanten Vorkommnissen zu haben, die sich in den Daten widerspiegeln.
Sind Fälle zu selten oder gar nicht in den Daten vertreten, können KI-Modelle diese schlecht oder gar nicht lernen. Wie groß die Datenmenge sein sollte, hängt tatsächlich vom Anwendungsfall ab. Möchte unser Kaffeemaschinenhersteller z. B. seine Rechnungen automatisch prüfen und es stellt sich heraus, dass er vornehmlich seine Waren über die gleichen Firmen bezieht, wird er deutlich weniger Rechnungen als Trainingsdaten benötigen, als wenn er divers einkauft und sich die Rechnungen dadurch unterscheiden.
Leitfragen
- Liegen Daten in hinreichender Menge vor, sodass sie dem Anwendungsfall genügen?
- Decken die Daten die relevanten Ausprägungen der Anwendung ab?
- Sind die Daten leicht verfügbar, oder benötigt es komplexe Zugänge oder technische Lösungen für den Zugriff?
- Sind Partner, Kunden oder sonstige Lieferanten bereit, Datenzugriff zu gewähren?
- Sollen Daten verarbeitet werden, die möglicherweise unter rechtlichem Schutz stehen und ist eine hinreichende Rechteklärung erfolgt?
- Sind die erlangten Datensätze auch datenschutzkonform nutzbar?
Maßnahmen und Werkzeuge
- IM – Probezugriff auf alle relevanten Datenquellen zur technischen und organisatorischen Prüfung
- IAO – Dieser Leitfaden und der Leitfaden zu Strategie und Wandel
Projektmanagement
Unter dem Aspekt des Projektmanagements stellt sich die Frage, wie das Projekt organisiert wird und welche Strukturen und Methoden zum Einsatz kommen. Bei KI-Projekten kommen zusätzliche Faktoren wie Unsicherheiten durch die Nutzung von Daten und eine überdurchschnittlich hohe Interdisziplinarität, gefordert durch neue Aufgaben, zum Standardprojektmanagement hinzu.
Dadurch entsteht ein höherer Kommunikations- und Abstimmungsbedarf innerhalb des Projektteams und mit den späteren Nutzenden. Dies hat in der Regel zur Folge, dass ein statisches Vorgehen, Ziele und Anforderungen zu definieren und in klaren Abläufen zu erarbeiten, nicht gut funktioniert.
Bei KI-Projekten ist es normalerweise notwendig, diverse Modelle und Algorithmen auszuprobieren, um eine optimierte Lösung zu erhalten, denn die Aussagekraft der Daten sowie die guten Wege zur Informationsextraktion sind oft nicht von Anfang an klar. Dafür kann es auch notwendig sein, (frühere) Projektschritte zu wiederholen.
Deshalb ist es üblicherweise ratsam, eine iterative oder gar agile Form des Projektmanagements zu wählen, z. B. Scrum oder Kanban. Zusätzlich können zur Unterstützung des Projektmanagements Vorgehensmodelle wie der CRISP-DM (CRoss-Industry Standard Process for Data Mining) oder dieser Leitfaden genutzt werden, um inhaltlich die Struktur und Methoden herauszuarbeiten.
Insbesondere für IT-fremde Organisationen, welche in der Regel wenig bis keine Erfahrungen bezüglich KI-Projekten besitzen, empfiehlt sich diese Ergänzung, da sie damit unterstützt durch den Prozess geführt werden.
Leitfragen
- Welche Art des Projektmanagements deckt die Anforderungen des Ziels und des Teams am besten ab?
- Soll ein Vorgehensmodell wie CRISP-DM oder dieser Leitfaden angewendet werden und falls ja, in welchem Umfang?
Maßnahmen und Werkzeuge
- Ö – Agiles Projektmanagement, bspw. Scrum oder Varianten davon
- IAO – Dieser Leitfaden
- Ö – RACI-Matrix (Verantwortlichkeitsmatrix oder Responsibility Assignment Matrix) zur Planung der Aufgaben und deren Verantwortlichkeiten
Technologieauswahl
Die Wahl der Technologie (Programmiersprachen, -bibliotheken und Softwaresysteme) mag sich vom Projekt zum Betrieb unterscheiden und auch unterschiedliche Tauglichkeit haben, weshalb in Summe eine Abstimmung in den einzelnen Phasen effizienzsteigernd sein kann. Insbesondere empfiehlt es sich, an dieser Stelle bewusst Entscheidungen über verwendete Technologien für die Lösung im Betrieb zu treffen.
Nicht immer ist KI die Lösung für alle Probleme. An mancher Stelle kann das Ergebnis auch ein einfaches Regelsystem sein, das programmiert wird und nicht aus Daten lernt.
Hat man sich jedoch für KI entschieden, stellt sich die strategische Fragestellung, welche Kompetenzen bereits vorhanden sind und welche Anteile selbst umgesetzt und betrieben und welche dagegen extern bezogen werden sollen.
Teilweise sind Technologie und Modellauswahl (Algorithmen bzw. KI-Verfahren) auch verzahnt. Werden z. B. selten verwendete oder neu entwickelte Verfahren benötigt, kann das die Technologieauswahl einschränken.
Bei Technologie Dritter sollte sichergestellt werden, dass die Verarbeitung der Daten sowohl eigenen Anforderungen als auch rechtlichen Rahmenbedingungen entspricht. Besonders relevant ist hierbei oft die Frage, ob Daten, die einem Schutzrecht (Datenschutz, Urheberrecht etc.) unterliegen, von Fremdanbieterunternehmen über den eigenen Anwendungsfall hinaus verarbeitet oder eingesehen werden können. Entsprechende Regelungen können z. B. in Lizenzbedingungen enthalten sein.
Leitfragen
- Ist KI die Lösung für das Problem oder genügen einfache Regeln, um die Projektziele zu erreichen?
- Für welche Technologien sind bereits Kompetenzen vorhanden oder sollen zukünftig im Unternehmen sein?
- Welche Anteile der Lösung sollen selbst entwickelt und betrieben werden?
- Welche Einschränkungen ergeben sich durch ggf. existierende Systeme oder festgelegte Anbieterunternehmen?
- Verschaffen sich die Anbieter von (KI-)Systemen unerwünschten Zugriff zu den verwendeten oder generierten Daten?
Maßnahmen und Werkzeuge
- IM – Aufstellung einer Kompetenzübersicht der eigenen Mitarbeitenden für Programmiersprachen, -bibliotheken und Anwendungssoftware
- Ö – Abgleich mit bestehenden und geplanten Dienstleistenden und Systemen zur Feststellung von Kompatibilitätsanforderungen
- IM – Prüfung der Produktbeschreibungen und Lizenzen ausgewählter Technologie im Hinblick auf unerwünschte Zugriffe auf genutzte und generierte Daten
Projektteam und Stakeholder
KI-Projekte sind zunehmend interdisziplinär und erfordern die enge Koordination von Fachexpertise, IT-Wissen und mathematischen Fähigkeiten. Hier bietet es sich an, zu schauen, welche Fähigkeiten die eigenen Mitarbeitenden bereits mit sich bringen.
Es stellt sich die Frage, was geschult werden kann und welche Fähigkeiten für das Projekt zugekauft werden müssen. Dabei ist zu beachten, dass, sobald die Lösung in eine produktive Umgebung als Teil eines Systems überführt werden soll, weitere notwendige Fähigkeiten hinzukommen können.
Dementsprechend ist die strukturierte Planung durch Prüfung der notwendigen Rollen sowie deren Besetzung ein wichtiger Schritt für die erfolgreiche Projektdurchführung. Je nach Komplexität des Projekts und dessen Einsatzbereich können einzelne Personen mehrere Rollen einnehmen und auch einzelne Rollen auf mehrere Personen verteilt werden.
Neben den aktiven Rollen im Projekt stellt sich auch die Frage der passiven Rollen, also der relevanten Stakeholder für die Durchführung. Dabei können sowohl interne Stakeholder, z. B. Angehörige des Betriebsrats, die Fachkraft für Datenschutz als auch externe Stakeholder, wie Endnutzende, relevant werden und entscheidende Rollen für den Projekterfolg übernehmen.
Leitfragen
- Welche Rollen sind für das anstehende Projekt relevant?
- Welche Personen besetzen welche Rollen?
- Fehlen Kompetenzen für das anstehende Projekt?
- Welche Stakeholder sollten wann und wie in das Projekt involviert werden?
- Müssen wegen fehlender Kompetenzen externe Dienstleistende hinzugezogen werden?
- Können fehlende Fähigkeiten der Mitarbeitenden geschult werden?
Maßnahmen und Werkzeuge
- IAO – Zuordnung und Beschreibung von Rollen und Stakeholdern (Beispiel 4)
![Das Bild zeigt ein Raster von Karten, die jeweils eine Rolle oder eine Stakeholder-Gruppe darstellen. Es ist unterteilt in eine linke Seite für „Rollen im Projekt“ und „Stakeholder“ auf der rechten Seite. Jede Karte hat einen Titel am oberen Rand und einen zusätzlichen Text auf der Karte, entweder den Namen der Person, die die Rolle innehat, oder Erläuterungen und Aktivitäten im Zusammenhang mit der jeweiligen Rolle oder Gruppe. Die Rollen im Projekt sind: Fachexpertise (Anna Gramm), Fachdatenexpertise (Anna Gramm), Projektmanagement (Wilma Ruhe), KI-Operatoren (Abteilung C3), Softwareentwicklung (Noch zu klären! Evtl. Abteilung C4; prüfen, ob bereit und verfügbar!), Datenwissenschaftler (Qwertz Data Consulting LLC). Die Stakeholder sind: Qualitätsmanagement (Ernst Haft), Nutzer (Wurden nach ihren Anforderungen befragt [...]), Betriebsrat (Zustimmung eingeholt. Betriebsrat verlangt Informationen zu Meilensteinen), Entscheidungsträger (Teamleiter Chris P. Bacon hat Zweifel am Projekt und will überzeugende Zahlen sehen, bevor er seine Zustimmung gibt).](https://websites.fraunhofer.de/ergebnisse-ki-ultra/wp-content/uploads/2025/04/2025-04-29-16_56_58-Leitfaden_Durchfuerhrung.docx-Kompatibilitatsmodus-Word.png)
Konzepte und Entwicklung
Datenaufbereitung
Bevor in die eigentliche Arbeit mit den Daten eingestiegen werden kann und nachdem der rechtliche Status der Daten geklärt ist, sollten diese auf eine passende Form sowie hinreichende Qualität geprüft werden.
Dabei kann es erforderlich werden, manche Daten neu zu erheben, neue Mechanismen zur Qualitätssicherung zu etablieren oder Entscheidungen zum Umgang mit Mängeln in den Daten zu treffen. Beispielsweise können Lücken in Daten in einigen Fällen interpoliert werden, in anderen Fällen müssen Teile verworfen werden.
Auch Ausreißer in den Werten müssen eventuell behandelt werden, sofern diese nicht als natürlich auftretende Vorkommnisse in den Daten verbleiben sollen. Neben der Qualität der Daten kann es auch notwendig sein, Daten aus verschiedenen Quellen zusammenzuführen und dabei gleiche Qualität und (zeitliche) Auflösung zu garantieren.
Informationen zur Datenstrategie und deren Umgang im Rahmen der Organisationsstrategie können im Kapitel »Handlungsfeld: Daten-Strategie« im Leitfaden zu Strategie und Wandel nachgelesen werden.
Leitfragen
- Sind die vorliegenden Daten vollständig und falls nicht, wie wird mit Lücken umgegangen?
- Ist die Qualität der Daten hinreichend und falls nicht, wie kann diese sichergestellt werden?
- Wie werden Daten aus verschiedenen Systemen und in verschiedenen Auflösungen zusammengeführt?
Maßnahmen und Werkzeuge
- IM – Strukturiertes Prüfen der Daten mit fachlicher Unterstützung
- Ö – Office-Tabellenprogramm, z. B. Datenreihen-Funktionen
- Ö – Datenaffine Programmiersprache, z. B. Python oder R
Daten verstehen und explorieren
Liegen Daten in (vermutlich) hinreichender Menge und Qualität vor, kann die Exploration der Daten beginnen. Dabei wird durch eine Kombination von statistischen Analysen, Fachwissen und Visualisierung aus verschiedenen Perspektiven ein gutes Verständnis für die Daten aufgebaut.
Damit kann sowohl die weitere Auswahl von Modellen verfeinert als auch eine vertiefte Einschätzung oder sogar Anpassung der Zielsetzung vorgenommen werden.
Auf dieser Basis kann das sog. »Feature Engineering« betrieben werden, also das Auswählen und Formen der Daten für die Verarbeitung in der Modellbildung.
Leitfragen
- Scheint das Erreichen der Projektziele und das Erfüllen der Anforderungen realistisch auf Basis des Datenverständnisses?
- Gibt es neue Erkenntnisse aus den Daten, die weitere Potenziale eröffnen?
- Welche Kombinationen und Formen der Daten sind für die Weiterverarbeitung in den Modellen vielversprechend?
Maßnahmen und Werkzeuge
- Ö – Statistische Analysen. Die meisten grafischen Werkzeuge bieten entsprechende Funktionalitäten. Auch auf der Ebene freier Frameworks gibt es entsprechende Möglichkeiten, bspw. bietet »ydata-profiling« für die Programmiersprache Python sehr umfangreiche Mittel, die mit wenigen Zeilen Code zur Verfügung stehen.
- IM – Betrachtung der Daten aus verschiedenen visuellen Perspektiven (Diagrammtypen)
Modellauswahl
Die Auswahl von geeigneten KI-Modellen ist ein iterativer Prozess. Bis zur abschließenden Evaluierung ist es normal, dass sich diese Auswahl verändert.
Die Auswahl von KI-Modellen beeinflusst das Feature Engineering, da unterschiedliche Modelle mit unterschiedlichen Arten und Formaten von Daten (besser) arbeiten können.
Bei besonders innovativen oder komplexen Anwendungsfällen kann die Modellauswahl durch selten verwendete oder besonders neue Verfahren Einfluss auf die Technologieauswahl haben und sollte aus dieser Perspektive bereits während der Technologieauswahl erstmals angedacht werden.
Aufgrund der Unsicherheit, welche Informationen zu welchem Grad in den Daten stecken, bietet es sich an, mit möglichst einfachen Modellen zu beginnen, um somit in Erfahrung zu bringen, ob nennenswerte Informationen in den Daten stecken, und eine Messlatte für komplexere Verfahren zu bieten.
Für die Auswahl von komplexen Verfahren kann auf dokumentierte und veröffentlichte Best Practices zurückgegriffen werden, um den Aufwand überschaubar zu halten.
Leitfragen
- Welchen Einfluss hat die Modellauswahl auf die Technologieauswahl?
- Welches ist das einfachste Verfahren, welches für einen initialen Test sowie als Messlatte verwendet werden kann?
- Welche Verfahren bieten sich aus bestehenden Best Practices sowie vorhandenen Kompetenzen heraus an?
- Welche Verfahren sind denkbar?
- Kommen selten verwendete, besonders komplexe oder sehr neue Verfahren in Betracht?
Maßnahmen und Werkzeuge
- Ö – Scikit-Learn Algorithm Cheat-Sheet für die Auswahl des Baseline-Verfahrens2
- IM – Best Practice-Recherche
Datenarchitektur
Je mehr Daten einbezogen werden, desto mehr wird eine angemessene Datenarchitektur sinnvoll, insbesondere wenn es um spätere Produktivsysteme geht. Daten müssen aus verschiedenen Quellen gesammelt und zusammengeführt werden. Ggf. stellt sich auf Organisationsebene die Frage nach einer einheitlichen Datenstrategie und -verwaltung.
Trifft man solche Entscheidungen lokal im Projekt, erhöht das die Wahrscheinlichkeit für zukünftigen Bedarf an Integrationen verschiedener Datenquellen. Vernachlässigt man das Thema Datenarchitektur, besteht mittel- und langfristig gesehen über mehrere Projekte hinweg das Risiko einer Silolandschaft verschiedener Datenbanken und Quellsysteme.
Die Konsequenzen sind technische und organisatorische Schulden, die sich in deutlichen Mehraufwänden in Betrieb und zukünftigen Projekten äußern.
Leitfragen
- Welche Quellsysteme gibt es und wie zugänglich sind diese?
- Was ist die Strategie zur Datenhaltung?
Maßnahmen und Werkzeuge
- IM – Abgleich mit der Organisationsstrategie zum Thema Datenarchitektur aus dem Leitfaden zu Strategie und Wandel
- Ö – Wirtschaftlichkeitsbetrachtung und Risikoanalyse bzgl. Integrationsaufwand vs. entstehender Silos
Systemarchitektur
Sollen Modelle nach dem Projekt in der Praxis regelmäßig angewendet werden, so ist eine Einbettung in die Systeme der Organisation sinnvoll. Diese kann mithilfe einer Systemarchitektur geplant werden. Dabei ist insbesondere relevant, welche Komponenten und Integrationspunkte Bestandteil der Lösung sind.
Damit ist zu beachten, welche bestehenden Elemente genutzt und welche neu geschaffen werden müssen.
Sind Geräte und Sensorik beteiligt, können sich komplexe IoT-Architekturen ergeben, welche neben den zentralen Geräten, Anwendungs- und Datenhaltungskomponenten weitere Elemente enthalten können wie administrative Elemente oder Geräteverwaltung.
Auch die zu verarbeitende Datenmenge hat Einfluss auf die Architektur. Werden die Datenmengen so groß, dass sie nicht mehr auf einzelnen (Hochleistungs-)Computern verarbeitet werden können, so spricht man von »Big Data«. Für die Verarbeitung solcher Datenmengen funktionieren viele herkömmliche Softwaresysteme nicht mehr, daher müssen spezielle Big Data- Technologien zum Einsatz gebracht werden.
In diesem Kontext kann sich auch die Frage nach der Nutzung von Cloud-Lösungen stellen. Bei der Verwendung von Cloud- Lösungen wird Kontrolle gegen Vereinfachung des Betriebs eingetauscht, was, je nach vorhandenen Kompetenzen, Anwendungsfall und Anforderungen, sinnvoll sein kann.
Leitfragen
- Aus welchen Komponenten besteht das spätere Gesamtsystem?
- Welche davon gibt es bereits und welche müssen neu hinzugefügt werden?
- Wo sind bei der Entstehung des neuen bzw. erweiterten Gesamtsystems Integrationspunkte, die für die Produktivität implementiert werden müssen?
- Wird eine Big Data-Architektur benötigt?
- Sollen Cloud-Lösungen verwendet werden?
Maßnahmen und Werkzeuge
- IAO – IoT-Architektursheet zur Erstellung einer Referenzarchitektur. Dabei werden Komponenten und Schnittstellen visualisiert, sodass für das gesamte Projektteam aufgezeigt wird, welche Bestandteile existent sind und welche implementiert werden müssen (Beispiel 5).
Modellbau
Die »eigentliche KI« besteht zumeist aus dem Konfigurieren von Modellen und der Verarbeitung der Daten durch Training. Je nach Modell gibt es verschiedene Anforderungen an die Aufbereitung der Daten: Bspw. können manche Modelle nicht mit fehlenden oder nur mit numerischen Daten umgehen. Neben der Auswahl und dem Training müssen Modelle auch konfiguriert werden. Sogenannte Hyperparameter müssen gewählt und optimiert werden, was sich von Modell zu Modell stark unterscheiden kann. Im Prozess der Analysen zeigt sich die Eignung der Kombination aus Modell- und Hyperparameterwahl, was oft neue Konfigurationen oder auch andere Modelle erforderlich macht. Auch die Daten müssen nicht für jedes Modell gleich sein: Im sog. »Feature Engineering« wird die Auswahl der Daten für das jeweilige Modell getroffen und ebenso die Darstellungsform. Es kann bspw. sinnvoll sein, den Modellen die Daten einzeln oder in aggregierter Form zu übergeben. Der Modellbau besteht meistens aus einer Kombination von eigener Erfahrung, bewährten Verfahren sowie Ausprobieren.
Leitfragen
- Müssen Anpassungen der Daten auf die Modelle stattfinden?
- Welche Hyperparameter gibt es für die gewählten Modelle, welche Standardwerte haben diese und in welchem Umfang kann davon sinnvoll abgewichen werden?
- Welche Daten werden den Modellen zum Trainieren gegeben und in welcher Form?
Maßnahmen und Werkzeuge
- IM – Programmierung: Fachkräfte erstellen mit maximaler Flexibilität die KI-Modelle durch Programmierung.
- Ö – Grafische Softwarewerkzeuge: Fachkräfte erstellen mit grafischen Werkzeugen KI-Modelle, welche konfigurierbar vorimplementiert sind und durch grafische Oberflächenelemente kombiniert und konfiguriert werden können.
- IM – Automatisiertes Maschinelles Lernen (AutoML) automatisiert durch Ausprobieren vieler verschiedener Modelle und Konfigurationen die Suche nach geeigneten Lösungen.
Robustheit und KI-Sicherheit
Neben der grundlegenden IT-Sicherheit stellt sich bei KI-Systemen die Frage nach Robustheit und KI-Sicherheit. Der Grad der »Robustheit« bezeichnet dabei, wie gut ein System mit Abweichungen in den Daten klarkommt. Der Grad der »KI-Sicherheit« bezieht sich auf den Grad der Robustheit hinsichtlich gezielter Manipulationen von Daten.
Angriffe auf KI-Systeme können Daten manipulieren, um die Ergebnisse zu verschlechtern oder gezielt zu verfälschen.
Leitfragen
- Sind die für den Anwendungsfall relevanten Daten hinreichend gut in den Daten vertreten, mit denen die KI-Modelle erstellt werden? Falls nicht, kann sich in der praktischen Anwendung die Robustheit drastisch verringern.
- Ist der Anwendungsfall für potenzielle Angreifer interessant? Falls nicht, sollte das dokumentiert werden. Andernfalls sollte die Robustheit von den KI-Expert*innen durch individuelle Maßnahmen erhöht werden.
- Was sind Gegenmaßnahmen für wahrscheinliche Angriffsszenarien? Solche Maßnahmen hängen vom Anwendungsfall und den Daten ab, doch gibt es auch etablierte Verfahren wie das Anwenden von Rauschfiltern bei Audiodaten zur Erhöhung der Robustheit von KI-Modellen.
Maßnahmen und Werkzeuge
- IM – Gezieltes Konstruieren von Randfällen und Testen derselben
- IM – Datenbezogener Penetrationstest: Man lässt Testpersonen mit technischer KI-Expertise gezielt versuchen, KI-Modelle zu täuschen oder zu schlechten Ergebnissen zu führen.
Abschließende Evaluierung
Die abschließende Evaluierung nimmt bei KI-Projekten einen besonderen Stellenwert ein, da auch in Betracht gezogen werden muss, dass das ursprüngliche Ziel möglicherweise nicht erreicht werden konnte.
Iterationen und Plananpassungen bis hin zum Projektabbruch sind in KI-Projekten an vielen Stellen möglich, besonders bei den Schritten »Datenzugriff«, »Datenaufbereitung«, »Daten verstehen und explorieren« sowie »Modellbau«. Der Grund dafür ist, dass nicht immer klar vorhergesagt werden kann, ob die gewünschten Informationen auch hinreichend gut in den Daten abgebildet sind.
Während diese Schritte zur Optimierung von Datenverständnis und KI-Modellen theoretisch beliebig vertieft werden können, stellt die abschließende Evaluierung das klare Ende dieser Iterationsmöglichkeiten dar und entscheidet darüber, ob die Projektergebnisse ihren Weg in die Praxis finden.
Dabei werden sowohl Zielsetzungen und Anforderungen geprüft als auch die Wirtschaftlichkeit auf Basis der gewonnenen Erkenntnisse (z. B. Komplexität der KI-Modelle und erwartete Aufwände zur Pflege und Weiterentwicklung) hinterfragt.
Leitfragen
- Konnte das ursprüngliche Ziel (hinreichend gut) erreicht werden?
- Ist die Überführung in den Betrieb wirtschaftlich?
- Wurden die aufgestellten Anforderungen hinreichend gut erfüllt?
- Welche weiteren Datenpotenziale haben sich während der bisherigen Projektlaufzeit ergeben?
Maßnahmen und Werkzeuge
- IM – Wirtschaftlichkeitsbetrachtung von Prototyp und Systemkonzepten
- IM – Sukzessives Prüfen der Anforderungen aus Phase 1
Impressum
Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO
Nobelstraße 12
70569 Stuttgart
www.iao.fraunhofer.de
Autorenschaft
Damian Kutzias, Claudia Dukino, Jan-Paul Leuteritz
Herausgeberschaft
Oliver Riedel, Katharina Hölzle, Wilhelm Bauer, Matthias Peissner
Kontakt (Presse)
Presse und Öffentlichkeitsarbeit Fraunhofer IAO
Nobelstraße 12
70569 Stuttgart
presse@iao.fraunhofer.de
Fraunhofer Publica
http://dx.doi.org/10.24406/publica-1637
Fraunhofer IAO, 2023
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz: https://creativecommons.org/licenses/by-sa/4.0/legalcode.de
Die Inhalte zur rechtlichen Expertise wurden von den Rechtsanwaltskanzleien BHO Legal und Oppenländer geliefert.
Kontakt (Autoren)
Damian Kutzias
Digital Business Services
damian.kutzias@iao.fraunhofer.de
Claudia Dukino
Digital Business
claudia.dukino@iao.fraunhofer.de
Dr. Jan-Paul Leuteritz
Ergonomics and Vehicle Interaction
jan-paul.leuteritz@iao.fraunhofer.de
