Inhalt und Aufbau des Artikels

In diesem Artikel möchte ich auf folgende Punkte eingehen:

1. Für wen und welche Anwendungsfälle ist dieser Leitfaden gedacht?
2. Warum braucht es eine IST-Analyse für Data Science oder KI-Projekte?
3. Vorlage — Was sollte in einer IST-Analyse für Data Science oder KI-Projekte abgefragt werden und warum?
4. Wie lässt sich eine IST-Analyse in der Praxis durchführen
5. Abschließende Gedanken zur Notwendigkeit einer IST-Analyse

Für wen und welche Anwendungsfälle ist dieser Leitfaden gedacht?

Diese Vorlage ist insbesondere für Consultants, KI-Beauftragte im Unternehmen oder Projektmanager gedacht, welche mit der Planung, Durchführung und Einführung von KI-Projekten betraut wurden und eine kompakten (Praxis-) Vorlage in Form einer Checkliste zur IST-Analyse suchen. Diese kann später in Verbindung mit einer Anforderungsanalyse z. B. als Teil eines Lastenhefts zur Ausschreibung, Planung oder Konzeption von Lösungskonzepten für Data Science oder KI-Projekte genutzt werden.

Da es bei den Fragen der IST-Analyse sehr viele inhaltliche Überschneidungen mit anderen Anwendungsfällen gibt, eignet sich die Checkliste ebenfalls sehr gut als Grundlage für folgende Punkte:

• die Entwicklung einer KI-Strategie.

• die Bewertung und Einordnung anhand eines KI-Reifegradmodells.

• für das Risikomanagement (eine genaue IST-Analyse reduziert viele Risiken im Projekt).

• die Identifizierung und mögliche Bewertung von Use- und Business Cases.

• klassische Projektplanungen (z. B. die Initialisierungsphase nach PRINCE2).

• einen Projektsteckbrief oder eine Produkt-Vision.

• das Business Understanding nach einem KI-Lifecylce Modell (z. B. CRISP-ML(Q)).

• …

INFO

Diese Vorlage ist primär für Projekte kleiner bis mittlerer Ordnung gedacht, bei welchen die Kosten für die Vorbereitung und Planung möglichst niedrig gehalten werden sollen und ein schneller Überblick für die Planung und Lösungskonzeption geschaffen werden soll (z. B. im Rahmen von PoCs, MVPs, Pre-Projects etc.).

Bei größeren Projekten (>100k) sollte die Vorlage und die darin enthaltenden Fragestellungen ggf. eher als “Einstieg” gesehen werden, welche als Grundlage oder Ergänzung für z. B. die Vorbereitungsphase in anderen Projektmanagementformen (z. B. PRINCE2) dient.

Warum braucht es eine IST-Analyse für KI oder Data Science Projekte?

Was sollte in einer IST-Analyse für KI oder Data Science Projekte abgefragt werden und warum?

1. To-do: Hintergrund ermitteln

Was und Warum

Bei der Ermittlung des Hintergrunds geht es darum zu verstehen, in welchem Umfeld oder Branche die Firma tätig ist, um typische Problemstellungen, Besonderheiten oder auch Regularien und Auflagen erkennen zu können, welche später bei der Lösungskonzeption berücksichtigt werden müssen.

Ziele

Ziel dieses To-dos sind Antworten auf folgende Fragen:

1.1 — Wer ist die Firma und was macht diese?

Die Frage ist in der Regel der Einstieg, um ein Gefühl dafür zu bekommen, wer der Kunde ist, welche Schwerpunkte dieser hat und was (erst mal oberflächlich) die Geschäftsmodelle sind und Hintergründe sind. Die Information dient als Grundlage für weitere Recherchen.

1.2 — In welcher Branche ist die Firma?

Zu wissen und zu verstehen, in welcher Branche eine Firma aktiv ist, hilft einen Überblick oder Gefühl dafür zu bekommen, welche branchenspezifischen Besonderheiten oder Eigenschaften berücksichtigt werden müssen. Dies betrifft sowohl Regularien als auch mögliche branchenspezifische Lösungen, welche bei der Entwicklung eines Lösungskonzepts ggf. berücksichtigt werden können oder müssen. Häufig kommt es vor, dass es für Problemstellungen bereits Best Practices oder Branchenstandards gibt, welche der Firma nicht bekannt sind. So kann es im Rahmen des Lösungskonzepts und der Business Case Bewertung vorkommen, dass eine Branchenlösung ggf. die wirtschaftlichere oder bessere Lösung ist. Aufgabe des Consultants ist dann die Recherche oder Berücksichtigung dieser.

INFO — Dieser Punkt ist darüber hinaus sehr hilfreich, um bereits abschätzen zu können, um welche Risikoklasse es sich bei einem möglichen KI-System nach EU-AI-Act handelt. Der AI-Act definiert bestimmte Risikokategorien, welche sich unter anderem nach der Branche und dem Anwendungszweck richten.

1.3 — Welche regulatorischen Bestimmungen oder Anforderungen gelten für die Firma oder unterliegt diese?

Für viele Branchen gelten besondere Bestimmungen und Gesetzgebungen. Insbesondere bei KI- und IT-Anwendungen gelten für viele Branchen spezielle Anforderungen und Gesetzgebungen. Z. B. CRITIS, NIS2, VAIT, ITSec, Dora etc. Wenn bekannt ist, in welcher Branche eine Firma ist, kann bereits abgeschätzt werden, welche Anforderungen und Regularien für die Einführung von KI gelten könnten.

Beispiel: Typische branchenspezische Bestimmungen sind zum Beispiel:

• In der Versicherungsbranche: VAIT (Versicherungsaufsichtliche Anforderungen an die IT)

• Banken: DORA (Digital Operational Resilience Act)

• Betreiber kritischer Infrastrukturen: KRITIS, NIS2

1.4 — Was ist das Geschäftsmodell der Firma?

Diese Frage hat große Bedeutung, um ein Gefühl für mögliche Use- und Business Cases für Data Science oder KI zu bekommen. Falls es bei der Kundenanfrage um die Evaluierung möglicher Use Cases oder die Lösung bestehender Probleme geht, kann durch das Wissen um das Kerngeschäft das Risiko minimiert werden, Lösungen oder Produkte zu entwickeln, welche ggf. am eigentlichen Bedarf vorbeigehen.

Beispiel: Wenn der Kunde z. B. ein großer Re-Seller für Maschinen im B2B Bereich ist und das Ziel ist, die Umsätze zu steigern, wäre ein Chatbot zur Beantwortung von Fragen ggf. keine verkaufsfördernde Maßnahme, auch wenn es womöglich die Arbeit der Support-Mitarbeiter verbessert.

1.5 — Wird im Unternehmen bereits KI eingesetzt und welche Erfahrungen wurden damit gemacht?

Falls bereits KI-Systeme im Unternehmen eingesetzt wurden, ist es hilfreich zu erfahren, in welchem Umfang dies geschieht oder geschah und wie die Erfahrungen damit waren. Häufig haben Firmen bereits mit “off the shelf” Lösungen, Erfahrungen gesammelt oder eigene interne Proof of Concepts durchgeführt. Dies ist insbesondere mit Blick auf die Rentabilität (einen Business Case) oder Funktionalität sehr relevant. Falls schlechte Erfahrungen gemacht wurden oder sich kein (finanzieller) Mehrwert eingestellt hat, ist dies für die Planung und Konzeption neuer KI-Systeme sehr relevant. Das gleiche gilt natürlich auch für positive Erfahrungen, da dadurch bereits abgeleitet werden kann, wo die Firma nicht nur Anwendungspotenziale sieht, sondern auch bereits positiv erprobt hat.

INFO — Erfahrungsgemäß sind die häufigsten Gründe für negative Erfahrungen mit KI-Systemen mangelnde oder unzureichende Ergebnisse oder zu hohe Kosten bei zu geringem Mehrwert. Insbesondere mangelnde Ergebnisse sind dabei häufig auf fehlende Anpassungen oder die alleinige Nutzung von “off-the-shelf” Lösungen zurückzuführen.

1.6 — Gibt es eine Daten- oder KI-Strategie im Unternehmen?

Wenn es bereits eine Daten- oder KI-Strategie gibt, muss diese bei der späteren Lösungskonzeption berücksichtigt oder ggf. angepasst werden. So kann eine Strategie bereits die Nutzung bestimmter Frameworks, Infrastrukturen oder Maßnahmen zur Einhaltung von rechtlichen Anforderungen oder dem Risikomanagement ein- oder ausschließen. Falls ein Unternehmen keine Daten- oder KI-Strategie hat, ist es bei der Auswahl und Konzeption einer möglichen Lösung wichtig, dies im Hinterkopf zu behalten bzw. zu empfehlen, im Rahmen des Lösungskonzepts eine zu entwickeln, um eine einheitliche und nachhaltige Architektur und Strategie mit den Lösungen zu verfolgen sowie Compliance-Anforderungen einzuhalten (insbesondere mit Blick auf den AI-Act wichtig!) und ggf. bereits Best Practices für zukünftige Systeme zu etablieren.

1.7 — Ist das Thema Daten- und KI-Strategie für die Geschäftsführung ein aktuelles Thema?

Mit dieser Frage soll abgeschätzt werden, wie groß der Rückhalt in der Unternehmensführung für das Thema KI und datengetriebene Anwendungen ist. Da der Einsatz von KI-Systemen in Unternehmen häufig auch einen großen Change und mitunter größere Aufwände für Governance und Akzeptanz benötigt, ist es zentral, dass die Entscheider solche Vorhaben strategisch unterstützen. Genauso können dadurch der mögliche Umfang und die Tragweite der KI-Lösung besser abgeschätzt werden.

1.8 — Gibt es interne KI-Regelungen, Policies oder Guidelines?

Falls Firmen bereits KI nutzen, ist es gut möglich, dass bereits interne KI-Regelungen, Nutzungshinweise/Einschränkungen oder Best Practices bestehen, welche bei der Konzeption einer Lösung berücksichtigt werden müssen oder können. Insbesondere bei großen Unternehmen sind diese nicht immer allen Verantwortlichen bekannt. Diese werden dann bei der Anforderungserhebung in der Regel noch mal speziell abgefragt.

Beispiel: Typische Artefakte einer KI-Regelung oder Guidelines können z. B. sein:

• Regelungen zur internen Nutzung von KI oder dem Umgang mit Firmendaten im Kontext KI.

• KI-Schulungsunterlagen

• Vorlagen / Templates zur Einreichung eines KI-Lösungskonzepts.

• Frage- oder Anforderungskataloge, welche beantwortet werden müssen.

• Ausschluss bestimmer Use Cases / Risikoeinstufungen etc.

• …

1.9 — Gibt es Ressourcen / Entwickler innerhalb der Firma oder einen Partner, durch welche eigene KI-Anwendungen entwickelt oder betrieben werden können?

Dies ist wieder eine zentrale Frage für die spätere Lösungskonzeption. Wenn es im Unternehmen Entwickler / MA gibt, welche Expertise in der Entwicklung, Wartung und Inbetriebnahme haben, kann das bei der Lösungskonzeption berücksichtigt werden. Wichtig ist, dass möglichst genau beschrieben wird, welche Kompetenzen (z. B. Sprachen, Frameworks, Anbieter etc.) z. B. im Rahmen einer Skill-Matrix bei der Belegschaft vorhanden sind.

INFO — Die Information ist darüber hinaus relevant, um abzustecken, ob und welche Teile ggf. Inhouse entwickelt werden sollen. Dies hat ggf. Einfluss darauf, ob es sich beim Kunden um einen Provider oder Deployer nach EU-AI-Act handelt

2. To-do: Mögliche Stakeholder, Ansprechpartner und Nutzer ermitteln

Was und Warum

Bei der Ermittlung der Stakeholder und Ansprechpartner geht es mir primär darum, einen Überblick über alle an dem Projekt beteiligten Personen und deren Rollen zu bekommen, um zu wissen, wer mit welchem Hintergrund für welche Themen Ansprechpartner ist. Weiterhin versuche ich einen Überblick über die Zielgruppe bzw. den Personenkreis zu bekommen, welcher von der Problemstellung und Lösung überhaupt betroffen ist oder sein wird. Diese sollten immer bestmöglich in die Entwicklung mit einbezogen werden.

Ziele

Ziel dieses To-dos sind Antworten auf folgende Fragen:

2.1 — Wer hat das Projekt initiiert (und warum)?

Diese Frage ist wichtig, um die Motivation und die Interessen des Initiators zu verstehen. Dies kann helfen zu erkennen, ob das Projekt aus persönlichen oder wirtschaftlichen Gründen gestartet wurde, welche Ziele damit verfolgt werden und wer ggf. als zentraler “Fürsprecher” im Projekt auftritt.

2.2 — Wer verwaltet das Budget oder tritt als zentraler Sponsor im Projekt auf?

Der Projektsponsor muss immer in alle Entscheidungen mit eingebunden werden, um zu verstehen, wofür Kosten entstehen und warum. Dies ist wichtig, falls sich währen der Entwicklung Anforderungen oder Umfang ändern und damit auch die Kosten.

2.3 — Wer verwaltet, steuert und betreut das Projekt auf Seite des Kunden?

Der PM (Projektmanager) auf Kundenseite ist der zentrale Ansprechpartner bei Fragen oder Problemen im Projekt. Mit diesem muss auch die Planung abgestimmt werden. Es kann auch durchaus sein, dass Kunden keinen eigenen PM haben und die Projektsteuerung von extern (oder einem selbst) durchgeführt werden soll. Dies kann dann geklärt werden.

2.4 — Welche Bereiche und Abteilungen werden voraussichtlich von dem Projekt betroffen sein?

Hier gilt es bereits herauszufinden, welche Bereiche und Abteilungen bei der Analyse und Umsetzung mit einbezogen werden sollen bzw. wo die Problemstellung aufgehängt ist. Davon abgesehen ist in der Regel immer die IT mit involviert, da diese die Daten bereitstellen muss, genauso wie der Datenschutzbeauftragte und ggf. Betriebsrat.

2.5 — Wer ist der Datenschutzbeauftragte?

Ohne den Datenschutzbeauftragten geht bei KI- und Data Science Projekten nichts.

2.6 — Wer ist der Ansprechpartner für Daten und Datenquellen (Data Steward)?

Da es bei den meisten Data Science und Projekten um die Entwicklung oder Integration von datengetriebenen Anwendungen geht, braucht es einen Ansprechpartner zu Daten und Systemen. Häufig gibt es Ansprechpartner, welche sich explizit um das Data Management kümmern.

2.7 — Wer ist der Ansprechpartner für die IT-Infrastruktur und bestehende KI-Systeme?

Für die Entwicklung und Einführung von Data Science und KI-Systemen sind die bestehende IT-Infrastruktur, Prozesse und Systeme die Ausgangsbasis. Aus diesem Grund sollten solche Projekte immer in direkter Abstimmung mit den jeweiligen IT-Verantwortlichen und Experten des Unternehmens erfolgen.

2.8 — Gibt es einen Ansprechpartner oder Verantwortliche für Risikomanagement?

In manchen Firmen gibt es extra Risikomanager oder Verantwortliche, welche bei der Planung und Konzeption von Anwendungen, Risikoprofile etc. erstellen und bei der Planung dementsprechend berücksichtigt werden müssen.

2.9 — Wer sind (allgemeine) Ansprechpartner und Kontakte?

Zusammenfassung, an wen man sich bei welchen Rückfragen wenden kann und welche weiteren Ansprechpartner womöglich relevant sind.

2.10 – Wer ist Ansprechpartner für KI- und KI-Projekte (falls vorhanden)?

Nicht selten gibt es in Unternehmen einen KI-Beauftragten oder verantwortlichen für KI-Projekte. In der Praxis werden KI-Projekte häufig über die KI gesteuert. Dies sollte jedoch eigentlich nicht der Fall sein bzw. ist nicht optimal, da für KI Projekte ein anderes Hintergrundwissen notwendig ist.

2.11 – Wer ist der Kontakt für den Betriebsrat (falls bereits absehbar ist, dass dieser benötigt wird)?

Falls es sich um KI-Systeme oder Anwendungen handelt, welche MA oder deren Daten betreffen muss immer der Betriebsrat mit eingeschaltet werden. Es ist grundsätzlich immer ratsam den Betriebsrat bei der Planung mit im Boot zu haben bzw. frühzeitig mit einzubeziehen.

(Optional) 3. To-do: Problemstellung oder Use Case ermitteln

Die Dokumentation von Problemstellungen oder KI-Use Cases ist für mich immer ein eigener Schritt auch wenn dieser in der Regel Teil der IST-Analyse ist. Aus diesem Grund führe ich den Schritt an dieser Stille als “optional”. Das gleiche gilt auch für die Punkte 4. und 5.

Ich habe zur Identifizierung und Dokumentation von KI-Use Cases einen eigenen Beitrag erstellt. Die Vorlage kann man unter folgendem Link finden: https://dawidzins-ki.de/vorlage-ki-use-cases-identifizieren-und-dokumentieren/

(Optional) 4. To-do: Aktuelle Lösung(en) ermitteln

Siehe Punkt 3.

(Optional) 5. To-do: Bisherige Lösungsansätze oder Vorschläge ermitteln

Siehe Punkt 3.

6. To-do: Relevante IT-Umgebung und Systeme ermitteln

Was und Warum

Unabhängig von dem Use Case und der späteren Lösungskonzeption ist es wichtig zu wissen, welche technischen Rahmenbedingungen überhaupt gegeben sind. Dies ist insbesondere für die Auswahl der möglichen Technologien und Anbieter, die Konzeption der Lösungsarchitekturen und die Umsetzung des Legal-, Betriebs- und Risikomanagements relevant.

6.1 — Müssen der Datenschutzbeauftragte, Betriebsrat oder andere in die Planung der Problemstellung einbezogen werden?

Insbesondere bei Daten- oder KI-Projekten gibt es viele Risikogebiete und Faktoren, welche das Einbeziehen unterschiedlichster Entscheider oder Beratungsorgane notwendig machen. Da in der Regel solche Projekte häufig in oder mit der IT federführend umgesetzt werden, ist es ratsam direkt zu Beginn die benötigten Organe auf Basis der aktuellen Problemstellung abzufragen. Häufig gibt es auch eigene Prozesse.

6.2 — Welche IT-Infrastruktur, Architektur und Anbieter werden aktuell genutzt?

Die aktuell vorhandene oder zukünftig geplante IT-Infrastruktur oder Architektur ist sehr wichtig für die Auswahl, die Implementierung und den Betrieb von KI-Systemen oder Data Science Anwendungen, da dadurch bestimmt wird, welche Modelle, Anbieter oder Hardware ggf. infrage kommen oder nicht. Genauso ist diese Information für eine spätere Skalierung (Wie weit kann skaliert werden?) und Kosten relevant.

Beispiel: Weit verbreitet sind z. B. On-Premises, Cloud-Ansätze (Public Cloud / Private Cloud) oder Mischformen wie eine Hybrid-Cloud. Dabei wird im Cloud-Bereich häufig auch nach Infrastructure as a Service (IaaS) und Platform as a Service (PaaS) unterschieden. Typische Cloud-Anbieter sind AWS, Azure, GCP oder deutsche Anbieter wie Hetzner oder IONOS.

6.3 — Welche IT-Systeme und Anbieter werden aktuell genutzt?

Die IT-Systeme beschreiben alle in der Nutzung der Firma befindlichen Systeme. Dabei sind insbesondere die Anwendungen, Anbieter und Datenbanken relevant. Die Übersicht ist wichtig, um einen Überblick über die möglichen Anbieter, deren Anwendungen und Schnittstellen zu bekommen, um abschätzen zu können, mit welchen weiteren Systemen eine KI oder Data Science Lösung ggf. kompatibel sein soll. Auf Basis dieser Übersicht frage ich in der Regel auch gezielt, ob ein KI-System eventuell zukünftig mit einem der bestehenden Systeme kompatibel sein soll oder nicht. Darüber hinaus ist es wichtig zu wissen, ob es sich bei den Systemen um Software as a Service (SaaS) oder lokal installierte Software handelt.

6.4 — Welche Schnittstellen zu den relevanten IT-Systemen bestehen / wie kann auf diese zugegriffen werden?

Wenn die Systeme bekannt sind, ist es wichtig zu wissen, wie auf die Systeme zugegriffen werden kann oder welche Schnittstellen zu diesen bestehen. Mögliche Schnittstellen können sein: APIs, Konnektoren, Middleware etc.

Darüber hinaus ist wichtig zu erfahren, wie die Ein- und Ausgabeformate der jeweiligen Schnittstellen aussehen (z. B. JSON, CSV, XML, Objekte etc.).

6.5 — Welcher Technologie-Stack wird innerhalb der Firma genutzt oder bevorzugt?

Die genutzten Systeme und Technologien geben einen Überblick über den innerhalb der IT bzw. Firma verbreiteten Techstack und die Kompetenzen der MA. In der Regel haben Firmen sich auf wenige Programmiersprachen oder einen favorisierten Techstack spezialisiert, mit welchem man sich auskennt. Dies ist sehr relevant für die Implementierung und Wartung von neuen Anwendungen. In der Regel wünscht man sich Anwendungen, welche mit den Fähigkeiten der eigenen IT übereinstimmen, damit diese selbstverwaltet und betreut werden kann (und damit Kosten sparen). Darüber hinaus kann über die bestehenden IT-Systeme abgeschätzt werden, bei welchen Anbietern.

6.6 — Wie werden IT-Systeme und Infrastruktur gegen interne und externe Bedrohungen geschützt?

Für die Planung und Entwicklung von KI-Systemen ist es wichtig zu wissen, wie aktuell die IT-Systeme vor internen und externen Bedrohungen geschützt wird. Dies ist sowohl für Nachweispflichten und das Risikomanagement als auch für Anforderungen an zukünftige KI-Systeme relevant. In der Regel verfügen Firmen auch über Incident- und Monitoring-Prozesse oder Guidelines, welche während einer Entwicklung oder Implementierung berücksichtigt werden müssen.

Typische Anforderungen in disem Kontext können z. B. sein:

• Welche Anforderungen an die externe Entwicklung und Nutzung von Systemen bestehen z. B. Nutzung von Citrix, AVV-Vertrag, Anonymisierung, keine Entwicklung auf Fremd-Systemen etc.?

• Dürfen Anwendungen auf eigenen Systemen und unter Nutzung eigener Anbieter entwickelt werden oder muss die Entwicklung auf Systemen des Kunden erfolgen?

• …

6.7 — Gibt es eine Übersicht oder Dokumentation zur IT-Architektur?

Falls es eine Dokumentation gibt, ist dies für eine anschließende Analyse und Prüfung hilfreich, um die Architektur nachvollziehen zu können. Abhängig von der Firmengröße und Komplexität der IT-Architektur, ist ein volles Verständnis nicht ohne Dokumentation nachvollziehbar. Nicht für jedes Data Science oder KI-Projekt ist jedoch ein volles Verständnis der Architektur notwendig.

6.8 — Wie ist die aktuelle Auslastung der IT?

Grundsätzlich ein internes Thema bzw. Teil des Portfolio-Managements, aber gerne vergessen: Die verfügbaren Ressourcen der IT. Wenn klar ist, dass die IT-Abteilung aktuell und ggf. auch zukünftig unterbesetzt oder bereits voll ausgelastet ist, hat dies einen großen Einfluss darauf, ob neue Data Science oder KI-Systeme entwickelt, implementiert oder auch nur eingeführt werden können.

6.9 — Gelten für die IT bestimmte Compliance oder Governance-Anforderungen?

Nicht immer müssen es gesetzliche Anforderungen oder Auflagen sein, welche eine Firma erfüllen muss. Häufig haben Unternehmen auch eigene Compliance oder Governance-Anforderungen definiert, um bestimmte Qualitäts- und Sicherheitslevel zu erfüllen. Klassiker sind z. B. ISO-Normen, nach welchen ein Unternehmen regelmäßig auditiert wird. Ein Überblick über die gesetzlichen und freiwilligen Rahmenbedingungen ist deshalb unabdingbar.

Typische Anforderungen oder gesetzliche Rahmenbedingungen können z. B. sein:

• ISO 27001, BSI-Grundschutz, NIS-2, DORA, KRITIS, HIPAA, PCI, GDPdl, EU-CSRD, Energieeffizienz-Richtline

6.10 — Gibt es bestimmte Governance, Risikomanagement und Compliance-Prozesse oder Frameworks?

Für den Fall, dass das Unternehmen bestimmten Compliance oder Governance-Anforderungen unterliegt, gibt es in der Regel auch Management-Systeme oder Frameworks, welche bei der Entwicklung ggf. berücksichtigt werden müssen. Zu wissen, welche dies sind, ist deshalb von großer Bedeutung.

Typische Frameworks etc. können z. B. sein:

• COBIT, ITIL, COSO, EU-CSRD, AIMS nach ISO 42001, MS nach ISO 27001, etc.

7. To-do: Relevante KI-Systeme ermitteln (optional)

Was und Warum

Falls im Unternehmen bereits KI-Services oder Systeme genutzt werden oder vorhanden sind, ist das Wissen über deren Entwicklung, Einführung, Betrieb und Erfahrungen sehr wertvoll, da dadurch ggf. viele der Rahmenbedingungen, welche für die Einführung und Entwicklung neuer KI-Systeme benötigt werden, bereits vorhanden sind oder sich daran orientiert werden kann. Dies betrifft insbesondere die Themen Qualitäts- und Risikomanagement, Überwachung sowie technische und regulatorische Anforderungen.

7.1 — Welche KI-Systeme und Anbieter werden aktuell genutzt?

Das Wissen über im Unternehmen bereits bestehende oder genutzte KI-Systeme ist aus mehreren Gründen wichtig und relevant. Dazu folgende Beispiele:

• Mit Blick auf die Problemstellung kann so geprüft werden, ob ggf. bestehende Lösungen / KI-Systeme weiter genutzt oder in zukünftige Lösungskonzepte eingebunden werden können (z. B. durch Anpassung etc.).

• Mit dem Wissen über die aktuellen Anbieter kann geprüft werden, welche weiteren Lösungen oder Produkte von diesem für die weiteren Problemstellungen genutzt werden können oder ob dieser weiterhin infrage kommt. Häufig ist es insbesondere aus Betriebs-, Wartungs- und Risikomanagement-Sicht sinnvoll, nicht zu viele Insellösungen und Anbieter zu haben, da diese alle einzeln verwaltet werden müssen.

• Falls bereits KI-Systeme im produktiven Betrieb sind, kann in der Regel von den Erfahrungen und damit verbundenen Prozessen profitiert werden. Häufig sind dann bereits Risikomanagement- und Sicherungsprozesse eingeführt und Guidelines oder Trainings für die Nutzung (siehe AI-Literacy-Pflicht nach EU-AI-ACT) vorhanden.

• …

7.2 — Für welche Anwendungszwecke bzw. Use Cases werden die bestehenden KI-Systeme im Unternehmen genutzt?

Der Anwendungszweck eines KI-Systems ist besonders relevant für Maßnahmen im Rahmen eines Risikomanagements oder der Risikoanalyse. Nur wenn bekannt ist, für welche Zwecke oder in welcher Umgebung ein KI-System eingesetzt wird, kann abgeleitet werden, welche möglichen Risiken bestehen und welche Sicherungsstandards- und Maßnahmen ergriffen werden müssen oder ob es sich ggf. sogar um illegale Anwendungsfälle nach DSGVO oder EU-AI-Act handelt. Man sollte insbesondere darauf achten, ob es sich bei dem Anwendungszweck ggf. um sicherheitsrelevante Bereiche oder Use Cases handelt, da es sich dann in der Regel direkt um ein Hochrisiko-System handelt.

7.3 — Wie viele Nutzer arbeiten mit den aktuellen KI-Systemen?

Insbesondere bei KI-Systemen oder Data Science Lösungen ist der Punkt der Skalierbarkeit einer, welcher zwingend bereits bei der Auswahl, Planung und Konzeption berücksichtigt werden muss. Darüber werden in der Regel auch die Kosten und der Lösungsansatz bestimmt. Aus diesem Grund ist es wichtig zu wissen, wie viele Nutzer aktuell mit KI-Systemen arbeiten und wie die Erfahrungen mit der Performance und Leistung waren und sind. Darüber hinaus ist die Anzahl der Nutzer auch für die Kalkulation möglicher Lizenzkosten relevant.

7.4 — In welche Risikokategorie nach EU-AI-Act fallen die bestehenden KI-Systeme?

Diese Information ist sehr relevant, um die bereits bestehenden (oder zukünftigen) Sicherheits, Dokumentations- und Qualitätsanforderungen abschätzen bzw. bestehende Dokumente und Prozesse bewerten zu können. Der EU-AI-Act definiert für KI-Systeme unterschiedliche Risikokategorien, welche mit verschiedenen Nachweis-, Dokumentations- und Qualitätskriterien verbunden sind. Die Einhaltung ist ab Zeitpunkt der Umsetzung des AI-Acts verpflichtend und hat großen Einfluss auf die Lösungskonzeption und Einführung von KI-Systemen.

7.5 — Wurden bestehende KI-Systeme manuell angepasst / sind eine Eigenentwicklung oder werden diese als fertige Produkte von extern bezogen?

Diese Frage ist sehr relevant für die Unterscheidung, ob es sich bei dem Unternehmen um einen Betreiber (Deployer) oder Anbieter (Provider) von KI-Systemen nach dem EU-AI-Act handelt. Die Unterscheidung ist von großer Bedeutung, da der EU-AI-Act je nach Typ unterschiedliche Pflichten und Anforderungen definiert, welche für mögliche Lösungen und Konzeptionen relevant sind.

INFO: Viele Anbieter bekannter Software implementieren aktuell zunehmend KI-Funktionen in ihre Anwendungen, wodurch bei Unternehmen auf einmal KI-Funktionen in ihren Bestandssystemen verfügbar werden, auch ohne diese explizit zu beauftragen. Firmen wären dadurch häufig “nur” Deployer und keine Provider (dies ist meine Einschätzung und keine rechtliche Beratung).

7.6 — Werden bzw. wurden personenbezogene Daten von bestehenden KI-Systemen verarbeitet oder für das Training genutzt?

Mit dieser Fragestellung soll im Endeffekt geklärt werden, wie mit den bestehenden KI-Systemen die Einhaltung der DSGVO sichergestellt wird. Wenn KI-Systeme personenbezogene Daten während ihrer Nutzung verarbeiten oder auf diesen (z. B. im Rahmen eines Trainings) basieren, gelten zwingend die Anforderungen und Regeln der DSGVO. So kann anschließend direkt abgefragt werden, welche Maßnahmen zur Einhaltung und Sicherstellung der DSGVO umgesetzt wurden, welche wiederum relevant für die Planung und Konzeption von weiteren Data Science oder KI-Lösungen ist.

Beispiel: Typische Anforderungen, welche im Rahmen der DSGVO geprüft werden müssen sind z. B. folgende:

• Gehen Daten in Drittländer oder werden dort verarbeitet?

• Gibt es eine Einwilligung / Rechtsgrundlage zur Verarbeitung (Zweckbindung)?

• Wie wird der Schutz sichergestellt (Privacy by Design / Default, TOMs)

• Ist eine Datenschutzfolgeabschätzung notwendig?

• Welche Transparenz- und Informatonsvorschriften müssen eingehalten werden?

• Welche Dokumentationspflichten gelten?

• …

INFO: Aktuell (Stand 2024) überschneiden sich einige Anforderungen aus der DSGVO mit Blick auf den Einsatz von KI-Systemen oder Data Science Anwendungen mit den Anforderungen im EU-AI-Act (z. B. Erklärbarkeit von Algorithmen, Einsatzzweck, Risikoklassifizierung und Management etc.). Es ist ratsam, zuerst sicherzustellen, dass auf jeden Fall die Anforderungen der DSGVO erfüllt werden, da diese bereits gültig sind.

7.7 – Werden bzw. wurden nicht-personenbezogene aber schützenswerte Daten von bestehenden KI-Systemen verarbeitet oder für das Training genutzt?

• Öffentliche Daten (Informationen, die ohne Einschränkungen öffentlich zugänglich gemacht werden können.)

• Interne Daten (Informationen, die für die interne Nutzung innerhalb der Organisation bestimmt sind.)

• Vertrauliche Daten (Sensible Geschäftsinformationen, deren unbefugte Offenlegung der Organisation schaden könnte.)

• Streng vertrauliche Daten (Hochsensible Informationen, deren Offenlegung schwerwiegende Schäden verursachen könnte.)

7.8 — Wie werden bestehenden KI-Systeme gegen interne und externe Bedrohungen geschützt?

Über die Sicherungsmaßnahmen kann ermittelt werden, wie das Unternehmen aktuell seine KI-Systeme vor Manipulation, Datendiebstahl, Hacking oder anderen Gefahren schützt. Dies ist aktuell insbesondere für (generative) KI-Systeme relevant, welche möglicherweise Zugriff auf interne oder personenbezogene Daten haben und über das Prompting und die Freitext-Interaktion mit der KI (zusätzlich zu den allgemeinen IT- und Software-Angriffsvektoren) weitere Angriffsmöglichkeiten bieten. In der Regel sind solche Maßnahmen auch Teil eines Risikomanagements (falls vorhanden) und im Rahmend er DSGVO relevant, wenn personenbezogene Daten verarbeitet werden.

Beispiel: Typische Sicherungsmaßnahmen sind zum Beispiel:

• Moderationsfunktionen

• Filter

• Guardrails / System-Prompts

• Logging und Eingabe- Ausgabetracking

• Sicheres Anwendungsdesign

• Automatisierte Prüfung auf personenbezogene Daten in der Ein- oder Ausgabe

• Prüfung auf personenbezogene Daten in den Trainingsdaten

• Anonymisierung / Pseudonymisierung von sensiblen Informationen

• Aufbewahrungs- und Dokumentationsrichtlinien

• Rechte- und Nutzermanagement

• Firewalls

• Verschlüsselung

• Schulungen

• Schnittstellensicherung (z. B. API-Keys)

• Dedizierte Wissensdatenbanken

• Mandantenfähigkeit / Logische Trennungen

• etc.

7.9 — Wie sieht das Risikomanagement für die bestehenden KI-Systeme aus?

Für viele Firmen ist ein Risikomanagement bereits gesetzlich vorgeschrieben und für alle anderen wird dieses mit Blick auf Hochrisikosysteme im Rahmen des AI-Acts (zukünftig) ebenfalls verpflichtend. Doch von gesetzlichen Verpflichtungen abgesehen, sollte eine Risikoanalyse und ein anschließendes Risikomanagement aus meiner Sicht eine Grundvoraussetzung sein, da man sich dadurch automatisch mit möglichen Risiken und deren Vermeidung im Rahmen von Qualitätskriterien und Anforderungen etc. beschäftigt. Falls bereits KI-Systeme im Einsatz sind, lassen sich über eine Analyse des bestehenden Risikomanagements (falls vorhanden) bereits Informationen zu den unternehmensinternen Risiken und Maßnahmen ableiten, welche für die Planung und Konzeption von neuen KI-Systemen relevant sein können, ohne das Rad neu erfinden zu müssen. Umgekehrt können so Ergebnisse einer neuen Risikoanalyse- und deren Maßnahmen auf Bestandssysteme übertragen werden.

INFO: Wenn KI-Systeme personenbezogene Daten verarbeiten, ist eine Risikoanalyse bzw. eine Datenschutzfolgeabschätzung (bei hohem Risiko für die Betroffenen) und ein Risikomanagement in der Regel ebenfalls verpflichtend.

KI bezogene Risiken

• Welche KI-bezogenen Anforderungen / Risiken bestehen und wie werden diese vom KI-System / Lösungskonzept berücksichtigt?

  • Welche Risiken bestehen / sind bekannt oder können sich aus dem Projekt ergeben?

  • Welches Schadenspotenzial können die Risiken haben?

  • Wie hoch wird die Eintrittswahrscheinlichkeit der Risiken geschätzt?

  • Wie wird das Schadenspotenzial der Risiken minimiert?

  • Welche weiteren Maßnahmen sind empfohlen?

Daten- und datenschutzbezogene Risiken

• Welche Daten- und Datenschutzbezogenen Anforderungen / Risiken bestehen und wie werden diese vom KI-System / Lösungskonzept berücksichtigt?

  • Welche Risiken bestehen / sind bekannt oder können sich aus dem Projekt ergeben?

  • Welches Schadenspotenzial können die Risiken haben?

  • Wie hoch wird die Eintrittswahrscheinlichkeit der Risiken geschätzt?

  • Wie wird das Schadenspotenzial der Risiken minimiert?

  • Welche weiteren Maßnahmen sind empfohlen?

Regulatorische und rechtliche Risiken

• Welche Daten- und Datenschutzbezogenen Anforderungen / Risiken bestehen und wie werden diese vom KI-System / Lösungskonzept berücksichtigt?

  • Welche Risiken bestehen / sind bekannt oder können sich aus dem Projekt ergeben?

  • Welches Schadenspotenzial können die Risiken haben?

  • Wie hoch wird die Eintrittswahrscheinlichkeit der Risiken geschätzt?

  • Wie wird das Schadenspotenzial der Risiken minimiert?

  • Welche weiteren Maßnahmen sind empfohlen?

7.10 — Wie sieht das Qualitäts- und Betriebsmanagement für die bestehenden KI-Systeme aus?

Die kontinuierliche Evaluierung bzw. Kontrolle von KI-Systemen ist im Rahmen von ML- oder LLM-Ops ein kritischer Prozess, um die Qualität, Sicherheit und Nachvollziehbarkeit im Betrieb zu gewährleisten. Bedingt dadurch, dass KI-Systeme in der Regel durch historische Daten im Rahmen eines Trainings “lernen”, sind diese sehr anfällig, wenn sich Daten oder Verteilungen in Produktionsdaten, welche zur Eingabe genutzt werden, ändern. Man spricht bei solchen Änderungen von Concept- und Model-Drift, wodurch sich die Performance und Genauigkeit eines KI-Systems nach dem initialen Training bzw. der Entwicklung um Betrieb ändern kann. Um diese zu reduzieren oder frühzeitig zu erkennen, müssen KI-Systeme, deren Eingabedaten- und Ergebnisse kontinuierliche überwacht, geprüft und ggf. angepasst werden. Um diese Problemstellung(en) haben sich viele Anbieter, Tools und Ansätze entwickelt. Für die Planung von neuen KI-Systemen ist es wichtig zu wissen, welche eine Firma ggf. bei ihren Bestandssystemen bereits nutzt oder wie der Betrieb und die Überwachung durchgeführt oder organisiert werden, um eine gleichbleibende Genauigkeit sicherzustellen.

Beispiel: Typische Fragestellungen bzw. Punkte, welche in dem Kontext relevant sein können:

• Wie werden die KI-Systeme im laufenden Betrieb überwacht?

• Werden die Modelle automatisiert / händisch nachtrainiert?

• Wie werden Abweichungen erkannt?

• Welche Systeme / Anbieter kommen zum Einsatz?

• …

7.11 — Welche Daten wurden bzw. werden für das Training, Validierung, Tests und den Betrieb genutzt?

Falls ein KI-System mit individuellen Daten erstellt oder angepasst wurde, ist die Art und Weise, wie dies geschehen ist, eine wichtige Information, um abzuschätzen, wie das Data Management und die Data Governance umgesetzt wurden oder werden.

Beispiel: Typische Fragestellungen bzw. Punkte, welche in dem Kontext relevant sein können:

• Nach welchen Kriterien wurden die Daten ausgewählt?

• Wurden die Daten vorverarbeitet?

• Wurden neue Daten verwendet?

• Wurden externe Daten hinzugezogen?

• Woher stammen die Daten?

• Sind die Daten korrekt/sauber/gleich verteilt?
  wie wurden die Daten vorverarbeitet?

• Wie wurde/wird Data Governance eingehalten?

• Wie werden die Daten verwaltet (Data Management)?

• Welche Metriken wurden für das Training verwendet?

• Welche Trainingsverfahren wurden genutzt?

• Welche Genauigkeit wurde auf den Datensätzen ursprünglich erreicht?

• …

7.12 — Wie wird bei bestehenden KI-Systemen Robustheit, Fairness und Transparenz sichergestellt?

Da viele KI-Systeme in Entscheidungsprozesse involviert werden oder sind, ist es äußerst wichtig sicherzustellen, dass die Ausgaben eines KI-Systems nachvollziehbar und verlässlich (siehe Halluzinationen) sind und keine Entitäten benachteiligen. Die Anforderungen an Fairness und Transparenz steigen mit der Risikoklasse eines KI-Systems und sind stark vom jeweiligen Einsatzzweck abhängig. Dazu kommen bereits Maßnahmen während des Trainings, bei welchen sichergestellt werden muss, dass z. B. kein Data Leakage vorkommt, was zu schlechten Generalisierungseigenschaften führt. In der Regel ist ein Nachweis über eine Analyse der Trainingsdaten möglich, jedoch ist dies bei vielen KI-Systemen, wo kein Zugriff auf die Trainingsdaten und Verfahren besteht, nur sehr eingeschränkt möglich.Dies betrifft aktuell insbesondere viele Closed Source GenAI-Anbieter oder Modelle (Large Language Models). In solchen Fällen bleiben nur manuelle Tests- und Auswertungen übrig. Falls ein Unternehmen bereits ein Test-Framework in Nutzung oder Standards definiert hat, ist deren Analyse für spätere Lösungskonzepte sehr hilfreich.

Beispiel: Typische Fragestellungen sind dabei:

• Wie wird mit Halluzinationen umgegangen?

• Wie wird Bias in den Ausgaben verhindert?

• Wie wird sichergestellt, dass KI-Systeme gut generalisieren (vgl. Bias-Variance Tradeoff)?

• Wie wird sichergestellt, dass Ergebnisse nachvollziehbar sind?

• …

7.13 — Gibt es eine Dokumentation zu den bestehenden KI-Systemen?

Über eine Anwendungsdokumentation lassen sich schnell und tiefergehende Erkenntnisse zu den bestehenden Systemen einsehen. Falls vorhanden und möglich, sollte diese immer eingesehen werden, um Angaben abzuprüfen oder weitere Informationen im Nachgang eigenständig erarbeiten zu können.

INFO: In der Regel gehören Dokumentationen immer zur Auslieferung eines KI-Systems bzw. sind vorhanden. Im Rahmen der DSGVO oder dem AI-Act sind und werden diese je nach Anwendungsfall auch verpflichtend.

7.14 — Wie wurden die bestehenden KI-Systeme in das Unternehmen eingeführt und wie sehen die Schulungen und Trainings dazu aus?

Abseits von vielen Konzepten oder Use Cases liegt der flächendeckende Mehrwert von KI aktuell in der Automatisierung und damit verbundenen Einsparung oder Optimierung von Kosten und Prozessen. Die Einführung von KI-Systemen kann deshalb schnell zu Verunsicherung und Ablehnung bei Mitarbeitern und der Belegschaft führen, welche ggf. ihre Arbeit gefährdet sehen. Genauso wichtig wie die Systeme selbst ist deshalb erfahrungsgemäß auch die Einführung, welche maximal transparent und gut geplant sein sollte. Falls es bereits bestehende KI-Systeme gibt, ist es interessant zu wissen, wie diese eingeführt wurden und wie das Feedback der Nutzer und Mitarbeiter dazu aussahen.

7.15 — Sind/waren externe Firmen in die Beratung, Wartung oder den Betrieb der IT-Infrastruktur oder vorhandener KI-Syteme eingebunden?

Insbesondere bei Cloud-Anwendungen wie Infrastructure As-a-Service (IaaS), Platform-as-a-Serivce (PaaS) oder Software-as-a-Service (z. B. ChatGPT) ist es häufig der Fall, dass die Einführung, Wartung und der Betrieb nicht inhouse durchgeführt wird, sondern von externen Dienstleistern. Diese Informationen sind für spätere Rückfragen und die Planung relevant, da diese Firmen dann ggf. mit involviert werden müssen.

7.16 – Welche Rollen und Verantwortlichkeiten (Prozesse) gibt es?

Wenn KI-Systeme oder Anwendungen bereits genutzt und in Betrieb sind, ist es wichtig zu wissen, wer diese Betreut und für deren Betrieb verantwortlich ist. Diese Information ist insbesondere bei Hochrisiko-Anwendungen wichtig, bei welchen ein AIMS und AIIS Pflicht oder notwendig sind.

8. To-do: Relevante Daten und Datenquellen ermitteln

Was und Warum:

Abhängig von der Problemstellung bzw. dem Use Case spielen Daten und Systeme eine zentrale Rolle bei der Konzeption oder Auswahl von Lösungskonzepten. Aus diesem Grund werden Informationen zu vorhandenen Systemen, Daten und deren Schnittstellen etc. benötigt, welche mit der Problemstellung in Zusammenhang stehen. So kann abgeschätzt werden, ob und welche Lösungsansätze überhaupt infrage kommen könnten, welche Systeme berücksichtigt werden müssen und mit welchem Aufwand für die Datenaufbereitung und Analyse zu rechnen ist.

INFO: Bei der Identifizierung relevanter Daten und Datenquellen geht es noch nicht darum, die Daten zu analysieren oder bis ins Detail zu beschreiben. Dies ist Aufgabe in der späteren Umsetzung bzw. Arbeitspaket im Lösungskonzept (z. B. im Data Understanding nach CRISP-DM). Ziel ist, eine schnelle Übersicht zu bekommen, um eine möglichst genaue Planung des Lösungskonzepts zu ermöglichen.

Ziele

Ziel dieses To-dos sind Antworten auf folgende Fragen:

8.1 — Welche Daten sind vorhanden?

Welche Daten sind mit Blick auf die Problemstellung vorhanden? Dabei geht es darum herauszufinden, welche Entitäten diese Daten abbilden oder beschreiben (z. B. Kundendaten, Produktdaten, Umsatzdaten etc.) und ob es sich um strukturierte oder unstrukturierte Daten (z. B. Bilder, Videos, Audio etc.) handelt. Die Fragen nach den Daten bestimmen sich dabei immer nach der Problemstellung oder dem Use Case.

Beispiel: Wenn z. B. ein Assistenzsystem für den Kundensupport entwickelt werden soll, dann sind Support-Dokumente relevant und es muss geklärt werden, wie diese aussehen und was diese abbilden (sind Tabellen, Bilder etc. in den Dokumenten? Handelt es sich um PDFs, Word-Dokumente etc.?). Wenn der Use Case die Entwicklung eines Nachfrageprognosemodells ist, dann sind z. B. Daten zu Produkten, der Nachfrage, der zeitlichen Dimension und dem Kunden wichtig.

8.2 — Welche Datenquellen sind vorhanden?

Um mit Blick auf die Problemstellung bzw. den Use Case entscheiden zu können, welche Daten genutzt werden können, ist es zunächst hilfreich, einen Überblick über die vorhanden Datenquellen zu bekommen. Dadurch kann häufig bereits abgeleitet werden, um welche Art von Daten es sich handelt und welche Systeme bei der Lösungskonzeption potenziell mit berücksichtigt werden müssen. Hilfreich können Systemdokumentationen oder Architektur-Skizzen sein, auf welchen die einzelnen Komponenten und Systeme dokumentiert sind.

8.3 — In welchem Datenformat stehen die Daten in den Systemen bereit oder können diese abgerufen werden?

Daten können in verschiedenen Formaten wie CSV, JSON, XML, SQL-Datenbanken oder Big Data-Formate wie Apache Parquet oder ORC gespeichert sein. Jedes Format hat seine eigenen Vor- und Nachteile in Bezug auf Speicherplatz, Performance, Flexibilität und Kompatibilität mit verschiedenen Tools und Programmiersprachen. In den meisten Fällen können Daten in beliebige Ausgabeformate transformiert werden, jedoch ist es hilfreich, bereits zu Beginn zu wissen, in welchen Formaten die Daten vorhanden sind, um bei der Lösungskonzeption bereits zu wissen, welche Formate unterstützt werden müssen.

8.4 — Gibt es einen Data Catalog / Data Dictionary bzw. eine Datenbeschreibung?

Um ein Lösungskonzept zu entwickeln oder umzusetzen, ist es unabdingbar, dass man die Kundendaten versteht. Nur so kann entschieden werden, welche Daten für eine Problemstellung / Lösung geeignet sind oder nicht. Das Aufbauen eines Datenverständnisses ist immer ein großer Zeitfaktor und kann durch einen vorhanden Data Cataloq bzw. eine vorhandene Datenbeschreibung deutlich verkürzt werden. Zusätzlich sind so im Vorfeld bereits genauere Abschätzungen möglich.

8.5 — Gibt es eine Nomenklatur und wie müssen die Daten gelesen werden?

Es ist häufig üblich, dass Datenbanksysteme oder Daten eine bestimmte Nomenklatur oder Bezeichnungsschema aufweisen. Falls ein solches besteht (was zu 98 % der Fall ist), kann es in späteren Schritten viel Zeit sparen, wenn dieses im Vorfeld bereits bekannt ist und man einen Blick auf diese werfen kann. Darüber hinaus wird daraus bereits deutlich, wie die Daten strukturiert sind.

8.6 — Wie kann auf die Daten zugegriffen werden / sehen die Schnittstellen zu den Systemen aus?

Sobald die Systeme und Daten bekannt sind, ist es wichtig zu wissen, wie auf die Daten zugegriffen werden kann, da es bei der Planung und Lösungskonzeption einen Unterschied macht, ob man auf eine REST-API zugreift oder direkt auf eine Datenbank gehen muss. Dies hat häufig auch einen Einfluss darauf, ob die Daten von Außerhalb erreichbar sind oder nicht. Daten sind hochsensibel und dürfen in der Regel nicht ohne weiteres Bestandssystem verlassen oder durch Dritte verarbeitet werden. Es muss damit geklärt werden, wie ein sicherer Zugriff auf die Daten hergestellt werden kann (z. B. durch die Bereitstellung von VMs oder Anonymisierung etc.). Außerdem bestimmt sich dadurch auch die eigenen Sicherheitsmaßnahmen und rechtlichen Rahmenbedingungen (wenn Daten rausgegeben werden, wird man zum Datenauftragsverarbeiter und hat seine eigenen Sicherheitsmaßnahmen zu garantieren etc.).

8.7 — Welche Daten dürfen genutzt werden?

Hier muss geklärt werden, welche der vorhanden Daten überhaupt genutzt werden dürfen. So besteht insbesondere bei personenbezogenen oder Kundendaten immer die Rechtsgrundlage für die Verarbeitung im Mittelpunkt. Wenn es keine Einwilligung oder Optionen zur Unkenntlichmachung gibt, dürfen diese nicht verwendet werden (auch nicht im Rahmen von internen PoCs).

INFO: Häufig ist es nützlich zu fragen, ob es in den Tabellen / Datensätzen Marker / Kenner gibt, über welche abgefragt werden kann, ob Daten verarbeitet werden dürfen (Rechtsgrundlage für die Datenverarbeitung gegeben ist).

8.8 — Wie viele Daten stehen zur Verfügung / wie groß sind die (benötigten) Datensätze?

Dies ist eine wichtige Frage, da davon abhängt, ob und wie die Daten überhaupt verarbeitet werden können und welche Technologien zur Verarbeitung und Lösungskonzeption berücksichtigt werden müssen. Bei kleinen Datensätzen (wenige GB) kann z. B. mit der Grundgesamtheit auf einem lokalen System gearbeitet werden. Bei größeren Datenmengen müsste man sich bereits auf eine Stichprobe beschränken oder ein Framework wie Spark zur verteilten Analyse nutzen, was ggf. die Nutzung von Cloud-Dienstleistern erforderlich macht.

8.9 — Wie “sauber” und konsistent sind die Datensätze?

Wenn bereits bekannt ist, dass einzelne Datensysteme nicht sauber oder gepflegt sind, ist dies eine wichtige Information zur Aufwandsschätzung. Hellhörig muss man insbesondere werden, wenn es viele Freitextfelder oder unterschiedliche Bezeichnungen für gleiche Werte gibt.

Beispiel: Typische Probleme bei “unsauberen” oder inkonsistenten Daten könne z. B. sein:

• Dubletten

• Fehlende Einträge

• Unterschiedliche Schreibweisen

• Freitext-Fehler

• …

8.10 — Welche Besonderheiten oder Probleme bei der Interpretation und Nutzung der Daten sind bekannt?

Nicht selten ist es der Fall, dass Datenbanken und Systemen besonders gelesen oder interpretiert werden müssen, da z. B. verschiedene Datensilos in einem Data Warehouse über ETL-Strecken zu verschiedenen Zeitpunkten in der Nacht zusammengeführt werden und dadurch so z. B. ein vollständiger “aktueller” Datensatz nicht vor 6:00 morgens abgerufen werden kann. Es macht Sinn, solche Besonderheiten nach Möglichkeit im Vorfeld bereits abzufragen, um sich (aus eigener Erfahrung) später viel Arbeit zu ersparen.

8.11 — Gibt es Training-, Test- und Validierungsdaten?

Wenn bereits absehbar ist, dass es sich bei der Problemstellung um ein Supervised Learning Problem handelt, lohnt es sich häufig bereits nachzufragen, ob es zur Problemstellung Trainings- bzw. Testdaten gibt, bei welchen die Ausgangsdaten und die gewünschten Informationen / Ergebnisse bereits getrennt aufbereitet sind. Für die meisten Machine-Learning und KI Probleme werden solche Daten benötigt und die Aufbereitung ist eine aufwendige Arbeit.

Beispiel: Ein Beispiel könnte das korrekte Extrahieren von Entitäten (Namen, Adressen, Gehaltsangaben) aus Websites oder Texten sein. Trainings bzw. Testdaten für diese Problemstellung wären dann Beispiele der Originalwebsites oder Texte und gesondert (z. B. in einer Excel) jeweils die gewünschten Informationen, welche aus diesen extrahiert werden sollen. So kann gemessen werden, wie gut bzw. genau die Extraktion funktioniert.

8.12 — Wie dynamisch sind die Daten (wechseln diese häufig)?

Dies ist ein Punkt, welcher meiner Meinung nach häufig vergessen wird, jedoch eine große Bedeutung hat. Mit Blick auf mögliche Lösungskonzepte ist es entscheidend zu wissen, wie häufig z. B. ein Modell oder eine Pipeline ggf. neu trainiert, überprüft oder angepasst werden muss oder wie häufig Empfehlungen und Ergebnisse berechnet werden müssen. Wenn sich Daten z. B. täglich mehrmals ändern, müssen im Falle eines Empfehlungssystems z. B. Empfehlungen ggf. mehrmals täglich neu berechnet werden, was ein Deployment als Batch-Processing Lösung, welche Empfehlungen nachts berechnet, nicht möglich macht und damit ggf. eine aufwendigere Real-Time Lösung notwendig macht.

8.13 — Wie werden Daten und deren Zugriff aktuell geschützt?

Sobald Daten verfügbar sind, ist es für die Durchführung wichtig zu wissen, wie der Zugriff auf die Daten erfolgt und wie diese aktuell geschützt sind. Dies ist aus Governance-Sicht wichtig, um zu verstehen, welche Standards bei der Entwicklung berücksichtigt werden müssen.

8.14 — Wer ist Ansprechpartner / Owner für die jeweiligen Daten beim Kunden?

Egal wie genau man sich die Daten und Quellen im Vorfeld beschreiben lässt oder wie ausführlich Dokumentationen sind. Man wird bei der Planung und Durchführung immer Rückfragen haben und dazu braucht es einen Ansprechpartner.

Wie lässt sich eine IST-Analyse in der Praxis durchführen?

Ich arbeite den Fragenkatalog in der Regel nicht sequenziell ab, sondern orientiere mich bei den jeweiligen Fragen / To-dos immer individuell an den einzelnen Stakeholdern. In der Praxis hat sich für mich jedoch häufig bewährt, zwei getrennte Discovery Workshops (digital oder in Person) durchzuführen. Einen mit den Business-Stakeholdern und einen mit den Verantwortlichen aus der IT und die Fragen bzw. To-dos dahingehend aufzuteilen. Im Anschluss gehe ich, falls notwendig noch mal gezielt in Einzelinterviews. Der Hintergrund ist, dass in der Regel die technischen Hintergründe für das Business und umgekehrt das Business für die Technik weniger relevant/bekannt ist und dadurch in kleineren fachspezifischen Gruppen zielgerichteter diskutiert werden kann.

Beim Workshop mit den Business Stakeholdern würden dann primär folgende To-dos thematisiert:

• 1. To-do: Hintergrund ermitteln

• 2. To-do: Mögliche Stakeholder, Ansprechpartner und Nutzer ermitteln

• 3. To-do: Problemstellung oder Use Case ermitteln

• 4. To-do: Prozessdokumentation zur Problemstellung erstellen

• 5. To-do: Aktuelle Lösung(en) ermitteln

Beim technischen Workshop wären es dementsprechend eher folgende To-dos:

• 6. To-do: Relevante IT-Umgebung und Systeme ermitteln

• 7. To-do: Relevante KI-Systeme ermitteln (optional)

• 8. To-do: Relevante Daten und Datenquellen ermitteln

Abschließende Gedanken zur Notwendigkeit einer IST-Analyse

Wie eingangs bereits erwähnt, ist die IST-Analyse aus meiner Sicht ein essenzieller Bestandteil zur Planung und Durchführung von Data Science oder KI-Projekten und sollte immer an erster Stelle stehen, gefolgt von einer Anforderungsanalyse. In der Praxis habe ich häufig die Erfahrung gemacht, dass insbesondere die IST- und Anforderungsanalyse im Rahmen von „agiler“ Vorgehensweise gerne abgekürzt oder weggelassen wird.

Dies wird häufig damit begründet, dass IST- und Anforderungsanalysen zu aufwendig sind und man während der Entwicklung durch schnelle Ergebnisse in Form von Inkrementen nach jedem Sprint (letztendlich Try and Error) lernt und zusammen mit einem sich kontinuierlich entwickelnden Backlog die anfänglichen Unsicherheiten am Ende ausgleicht. Ich stimme damit persönlich nur teilweise überein.

Insbesondere bei Data Science oder KI Projekten sind meiner Meinung nach die Risiken gegenüber Compliance- oder Datenschutzanforderungen zu verstoßen oder im Meer an möglichen Lösungen den falschen Lösungsansatz zu wählen so hoch, dass es ohne vorherige Analyse sehr wahrscheinlich ist, bereits in der Entwicklung dagegen zu verstoßen. Dies betrifft übrigens bereits die Durchführung von Proof of Concepts. Darüber hinaus bin ich der Überzeugung, dass eine dokumentierte IST- bzw. Anforderungsanalyse für sich bereits einen Wert für eine Firma oder Kunden darstellt.

Womit ich persönlich übereinstimme, ist, dass für viele Vorhaben eine ausgewachsene IST- und Anforderungsanalyse einfach aufwands- und kostentechnisch nicht möglich oder verhältnismäßig ist. Aus diesem Grund nutze ich diese Checkliste zur IST-Analyse als schnellen und standardisierten Kompromiss. Ein Artikel mit einer Checkliste zur Anforderungsanalyse folgt zeitnah.

INFO: Für alle, welche nach agilen Methoden arbeiten, bietet sich z. B. an, die IST-Analyse als Ziel und Inkrement eines ersten Sprints zu nutzen.

Ich hoffe, der Beitrag hilft anderen bei der Planung und Konzeption von eigenen KI-Systemen, und ich freue mich über Feedback, Anregungen und Verbesserungsvorschläge.