Einführung Projektarbeit: Thema & Scope festlegen

Lernziele

Sie kennen den formalen Rahmen der Projektarbeit (Umfang, Struktur, Bewertungskriterien) und können Ihre Arbeit gezielt darauf ausrichten.

Sie sind in der Lage, ein Thema für Ihre Projektarbeit aus Ihrem Berufsalltag zu entwickeln und es in einer präzisen Problemstellung zu formulieren.

Sie können den Scope Ihres Projekts mithilfe einer In/Out-Matrix klar abgrenzen und begründen, was Teil der Arbeit ist und was nicht.

Sie haben ein vollständiges Themenblatt ausgefüllt und erstes schriftliches Trainerfeedback erhalten.

Sie verstehen die Verbindung zwischen den Modulen 1–9 und der Projektarbeit als Transferinstrument.

Sie können typische Scope-Fehler benennen und in Ihrem eigenen Entwurf vermeiden.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

Stellen Sie sich vor, Sie befinden sich nach Wochen intensiver Schulung an einem Wendepunkt. Sie haben gelernt, wie große Sprachmodelle funktionieren, wie man Prompts strukturiert, wie Agenten gebaut werden, welche Datenschutzregeln gelten und wie man KI-Systeme sicher einführt. Das alles ist Wissen — und Wissen allein verändert noch nichts im Arbeitsalltag.

Die Projektarbeit ist der Moment, in dem Wissen zu Können wird. Sie nehmen ein echtes Problem aus Ihrem Arbeitsumfeld — vielleicht die zeitaufwendige Angebotserstellung, vielleicht das Onboarding neuer Mitarbeitender, vielleicht die Auswertung von Anfragen — und entwickeln dafür eine KI-gestützte Lösung. Sie analysieren, konzipieren, bauen einen Prototyp, bewerten Risiken und dokumentieren das alles so, dass andere es verstehen und nachbauen könnten.

Das klingt nach viel. Und das ist es auch — aber nicht, weil es kompliziert wäre, sondern weil es relevant ist. Diese UE gibt Ihnen den strukturellen Rahmen: Was genau wird erwartet? Wie wird bewertet? Und vor allem: Wie grenzen Sie Ihr Thema so ab, dass es in 10–15 Seiten realistisch behandelbar ist? Die wichtigste Entscheidung dieser UE ist die Scope-Abgrenzung. Zu viele Teilnehmende scheitern nicht am Schreiben, sondern daran, dass ihr Thema zu breit ist. Ein gut abgegrenztes Thema ist halb gewonnene Projektarbeit.

Lerntext — Theorie und Konzepte

Was ist die Projektarbeit — und was ist sie nicht?

Die Projektarbeit ist das zentrale Prüfungs- und Transferinstrument der Schulung „KI-Anwender:in im Unternehmen”. Sie verbindet die theoretischen Inhalte aus den Modulen 1–9 mit einem konkreten Praxisfall aus Ihrem Arbeitsumfeld. Das Transferprinzip ist dabei leitend: Gelerntes soll im eigenen Arbeitskontext wirksam werden — nicht nur in der Schulung verstanden worden sein.

Was die Projektarbeit nicht ist: Sie ist kein akademisches Forschungspapier, das vollständige Literaturrecherchen erfordert. Sie ist keine technische Dokumentation, die Programmiercode in extenso enthält. Und sie ist keine interne Strategiepräsentation für die Geschäftsführung. Sie ist ein strukturierter Nachweis, dass Sie einen KI-Use-Case eigenständig von der Problemanalyse bis zur Risikobewertung durchdenken können.

Ein weiteres Prinzip: Die Projektarbeit soll grundsätzlich auf andere Arbeitgeber und Organisationen übertragbar sein. Das bedeutet, dass Sie keine streng vertraulichen Informationen (konkrete Kundennamen, Preiskalkulationen, interne Finanzdaten) ohne Anonymisierung einarbeiten. Der Use-Case stammt aus einem realen Kontext, aber Methodik und Erkenntnisse werden so beschrieben, dass ein fachkundiger Leser ohne Insider-Wissen die Arbeit nachvollziehen kann. Orientierung zu formalen Anforderungen bietet das Schulungsbegleitmaterial sowie die PMBOK-Richtlinien des Project Management Institute.

Merksatz

Die Projektarbeit ist kein Forschungspapier, sondern ein Machbarkeitsnachweis: Sie zeigt, dass Sie einen KI-Use-Case eigenständig analysieren, konzipieren, prototypisieren, rechtlich einordnen und wirtschaftlich bewerten können.

Formale Anforderungen im Detail

Die Projektarbeit wird nach folgenden formalen Vorgaben erstellt:

Umfang: 10–15 Seiten Fließtext (ohne Deckblatt, Inhaltsverzeichnis, Literaturverzeichnis und Anhang)

Sprache: Deutsch; Fachbegriffe auf Englisch sind erlaubt, werden beim ersten Auftreten kurz erklärt

Formatierung: Schriftgröße 12 pt (Fließtext), 11 pt (Tabellen), Zeilenabstand 1,5, Seitenränder 2,5 cm rings

Zitierstandard: APA oder IEEE — konsistent durchhalten

Die Pflichtgliederung lautet: 1. Einleitung und Problemstellung 2. Analyse des Ist-Zustands 3. Use-Case-Konzeption (inkl. KI-Use-Case-Canvas) 4. Technische und rechtliche Betrachtung 5. Prototyp oder Proof-of-Concept 6. Evaluation und Risikobewertung 7. Wirtschaftlichkeitsbetrachtung 8. Fazit und nächste Schritte 9. Quellen und Anhang

Diese Struktur ist nicht zufällig. Sie spiegelt den vollständigen Denk- und Handlungsprozess einer Person in der Rolle eines KI-Projektverantwortlichen wider — von der Problemerkennung über die Konzeption bis zur ehrlichen Evaluation. Wer diese Struktur beherrscht, kann KI-Projekte professionell führen und kommunizieren.

Bewertungskriterien verstehen

Die Projektarbeit wird mit maximal 20 Punkten bewertet und geht mit einer Gewichtung von 33 % in die Gesamtnote ein. Die fünf Bewertungsbereiche sind:

Zwei häufige Missverständnisse bei der Bewertung: Erstens wird nicht die Komplexität des gewählten Use-Cases bewertet, sondern die Tiefe der Auseinandersetzung. Ein einfacher Use-Case kann volle Punktzahl erhalten, wenn er methodisch sauber durchgearbeitet wird. Zweitens wird der Prototyp nicht danach bewertet, ob er produktionsreif ist, sondern ob er die technische Machbarkeit glaubwürdig demonstriert.

Die Scope-Definition — das wichtigste Werkzeug dieser UE

Der häufigste Fehler bei Projektarbeiten ist ein zu breiter Scope. „Ich möchte KI für die gesamte Kundenkommunikation einsetzen” ist kein Thema — es ist ein Unternehmens-Transformationsprojekt. Ein gutes Projektarbeitsthema ist:

Spezifisch: Ein konkreter Prozess, nicht eine ganze Abteilung

Messbar: Es gibt einen definierbaren Ausgangszustand und ein messbares Ziel

Realisierbar: Ein Prototyp kann in ca. 4 Stunden Arbeit erstellt werden

Relevant: Der Use-Case hat echte Bedeutung für Ihre Organisation

Zeitlich eingegrenzt: Es geht um einen klar beschreibbaren Prozessschritt, nicht um eine Daueraufgabe

Die In/Out-Matrix ist das Werkzeug zur Scope-Abgrenzung. Sie listet explizit auf, was zum Thema gehört (In-Scope) und was bewusst ausgeklammert wird (Out-of-Scope). Diese Explizitmachung schützt vor späterem Scope-Creep und zeigt, dass Sie methodisch vorgehen.

Abb. 109.1 — Scope-Definition mittels In/Out-Matrix am Beispiel Angebots-Assistent

Zulässige Use-Case-Kategorien für Ihre Projektarbeit sind exemplarisch: - KI-gestützter Angebots- oder Dokumentenassistent - Recruiting-Screener für eingehende Bewerbungen - Reporting-Automator für Berichte und Statusmeldungen - Wissens-Assistent mit Zugriff auf Projektdokumentation (RAG-Architektur) - KI-gestützte Kundenkommunikation (E-Mail-Entwurf, Ticketbearbeitung) - Internes Onboarding-System für neue Mitarbeitende - Sonstige Use-Cases mit vorheriger Trainer-Genehmigung

Merksatz

Lieber einen kleinen Prozess sehr gründlich analysieren als drei Prozesse oberflächlich beschreiben. Die Tiefe der Auseinandersetzung zählt mehr als die Breite des Themas.

Themenentwicklung: Wie Sie Ihren Use-Case finden

Falls Sie noch kein konkretes Thema haben oder mehrere Ideen in Erwägung ziehen: Die folgenden Leitfragen helfen bei der Entscheidung.

Leitfrage 1 — Was kostet Sie täglich am meisten Zeit? Gehen Sie Ihren typischen Arbeitstag gedanklich durch. Welche Aufgabe wiederholt sich regelmäßig und dauert unverhältnismäßig lang? Wiederholende Textaufgaben (E-Mails schreiben, Protokolle erstellen, Berichte zusammenfassen) sind oft beste KI-Kandidaten.

Leitfrage 2 — Wo passieren regelmäßig Fehler oder Inkonsistenzen? Nicht jede Optimierung ist eine Zeitfrage. Manchmal geht es um Qualität: Angebote, die inkonsistent formuliert sind. Berichte, die wichtige Punkte auslassen. KI kann helfen, Konsistenz zu erhöhen.

Leitfrage 3 — Was würden Ihre Kolleginnen und Kollegen sofort nutzen, wenn es existierte? Ein Use-Case, den niemand außer Ihnen will, ist schwer zu implementieren. Fragen Sie informell: „Wenn ich ein Tool hätte, das X macht — würdest du es nutzen?” Drei positive Antworten sind bereits ein Markttest.

Leitfrage 4 — Was ist technisch machbar in 4–6 Wochen? Die Projektarbeit ist kein 6-Monate-Projekt. Der Prototyp muss in realistischer Zeit entstehen. Wenn Ihr Use-Case eine aufwendige API-Integration oder ein Fine-Tuned Model erfordert, prüfen Sie, ob es eine vereinfachte Version gibt, die denselben Kernbeweis erbringt.

Vertiefung — Die In/Out-Matrix als Denkwerkzeug

Die In/Out-Matrix stammt aus dem Projektmanagement und ist in den PMBOK-Richtlinien des Project Management Institute beschrieben. Für KI-Projektarbeiten hat sie eine besondere Bedeutung: KI-Systeme neigen dazu, schnell erweitert werden zu wollen — ein Assistent für Angebote soll bald auch Verträge prüfen, dann auch Kundenkommunikation übernehmen. Diese Erweiterungsdynamik nennt man Scope Creep.

Die In/Out-Matrix zwingt dazu, zu Beginn explizit zu entscheiden, was nicht Teil der Projektarbeit ist — und diese Entscheidung zu begründen. Das ist keine Einschränkung, sondern eine Qualitätssicherungsmaßnahme: Wer weiß, was er nicht tut und warum, zeigt methodische Reife.

Eine gut ausgefüllte In/Out-Matrix könnte fünf bis sieben Kategorien umfassen: den betroffenen Prozess, die verwendeten Daten, die gewählte Technologie, die Nutzergruppe, die Qualitätssicherungsmaßnahmen, die organisatorische Reichweite und den zeitlichen Rahmen. Für jede Kategorie wird festgehalten, was In-Scope ist (Teil der Arbeit) und was Out-of-Scope ist (bewusst ausgeklammert), jeweils mit einer kurzen Begründung.

Diese Explizitmachung schützt Sie vor Scope Creep und macht für Prüfende transparent, was bewusst ausgeklammert wurde. Eine theoretische Vertiefung zur Scope-Definition im Projektmanagement bietet das PMBOK Guide (Project Management Institute).

Vertiefung — Bewertungskriterien und Gliederungslogik im Detail

Die Projektarbeit wird nach einem verbindlichen Bewertungsraster mit 20 Punkten bewertet. Um dieses Raster optimal zu erfüllen, hilft ein tieferes Verständnis der zugrunde liegenden Bewertungslogik.

Bewertungsbereich 1 — Problemdefinition (4 Punkte): Die Problemdefinition ist das Fundament der gesamten Arbeit. Eine schwache Problemdefinition zieht alle nachfolgenden Kapitel nach unten. Die Kommission prüft: Ist das Problem nachvollziehbar und relevant? Gibt es eine Quantifizierung (Zeitaufwand, Fehlerrate, Kosten)? Ist der Kontext verständlich dargestellt — auch für jemanden, der Ihre Organisation nicht kennt?

Häufiger Fehler: Das Problem wird zu weit gefasst. “Die Digitalisierung in unserem Unternehmen ist unvollständig” ist kein Projektproblem — es ist eine Beobachtung. Ein konkretes Projektproblem lautet: “Die manuelle Verarbeitung von Eingangsrechnungen bindet 6 Stunden pro Woche und führt zu einer Fehlerrate von 8 % in der Buchführung.”

Bewertungsbereich 2 — Use-Case-Analyse (5 Punkte): Der höchste Einzelbereich. Die Kommission prüft, ob der KI-Use-Case systematisch analysiert wurde — mit Canvas, Ist/Soll-Vergleich, Stakeholder-Mapping und begründeter Priorisierung. Besonders geschätzt wird es, wenn Alternativ-Use-Cases benannt und bewusst ausgeschlossen werden, weil das zeigt, dass eine echte Auswahlentscheidung stattgefunden hat.

Bewertungsbereich 3 — Prototyp oder Konzept (5 Punkte): Ebenfalls 5 Punkte. Der Prototyp muss nicht vollständig funktionsfähig sein — aber er muss plausibel, technisch nachvollziehbar und datenschutzkonform beschrieben sein. Ein vollständig beschriebenes Konzept mit Architektur-Skizze ist gleichwertig zu einem einfachen funktionierenden Prototyp.

Bewertungsbereich 4 — Wirtschaftlichkeit und Reflexion (4 Punkte): KPI-Abschätzung, Aufwand/Nutzen und kritische Reflexion der Grenzen. Dieser Bereich wird häufig unterschätzt — wer nur den Nutzen beschreibt, ohne auf Risiken, Grenzen und Alternativen einzugehen, hinterlässt den Eindruck, die Lösung nicht vollständig durchdacht zu haben.

Bewertungsbereich 5 — Formale Qualität (2 Punkte): Struktur, Sprache, Umfang. Diese 2 Punkte sind die am einfachsten erreichbaren — und werden am häufigsten durch Nachlässigkeit verschenkt. Einheitliche Formatierung, korrekte Rechtschreibung und eine vollständige Gliederung sichern diese 2 Punkte.

Die Pflichtgliederung in der Praxis: Die acht Pflichtkapitel folgen einer inhärenten Logik: Kapitel 1–2 definieren das Problem und den Kontext (Was? Warum?). Kapitel 3–4 analysieren und priorisieren (Wie wird untersucht?). Kapitel 5–6 lösen (Was wird gebaut oder entworfen?). Kapitel 7–8 reflektieren und planen (Was wurde gelernt? Was kommt als nächstes?). Wer diese Logik versteht, kann die Gliederung inhaltlich füllen statt sie nur formal einzuhalten.

Scope-Abgrenzung als Kommunikationsaufgabe: Die In/Out-Matrix ist ein Kommunikationsinstrument. Sie zeigt der Kommission, dass Sie bewusst Grenzen gesetzt haben und Ihren Use-Case kontrollieren können. Typische “Out”-Positionen: Implementierung im Produktivsystem, Schulung anderer Mitarbeitender, rechtliche Zertifizierung des Systems, vollständige DSFA nach Art. 35 DSGVO. Typische “In”-Positionen: Analyse des Ist-Zustands, Entwicklung eines Prototyps oder Konzepts, Dokumentation, KPI-Abschätzung.

Häufige Themen-Fallen beim Scope: Drei Scope-Fallen führen regelmäßig zu schwachen Projekten: (1) Der Scope ist zu groß — “KI-Strategie für das gesamte Unternehmen” ist kein 120-UE-Kurs-Projekt. (2) Der Scope ist zu unspezifisch — “KI im Marketing” ist kein Use-Case, sondern ein Themenbereich. (3) Der Scope ist nicht implementierbar — ein Use-Case ohne Testdaten und technische Voraussetzungen kann keinen Prototyp erzeugen.

Praxistipp — Scope-Check in drei Fragen: (1) Kann ich diesen Use-Case in 4–6 Wochen nebenbei prototypisieren? (2) Habe ich Zugang zu den notwendigen Daten oder Systemen? (3) Kann ich das Projektergebnis in 10 Minuten einer anderen Person erklären, die meinen Beruf nicht kennt? Wenn alle drei Fragen mit “Ja” beantwortet werden, ist der Scope gut gewählt.

Vertiefung — Evaluations-Framework: Drei Ebenen und Wirtschaftlichkeitsberechnung

Die systematische Auswertung eines KI-Prototyps erfordert ein strukturiertes Framework. Das dreistufige Evaluations-Framework gibt dieser Auswertung die notwendige Tiefe und Nachvollziehbarkeit.

Ebene 1 — Technische Qualität: Misst, ob der Prototyp das tut, was er technisch soll. Relevante Metriken je nach Use-Case-Typ:

Für Klassifikationsaufgaben: Genauigkeit (Accuracy), Präzision und Recall, F1-Score. Nicht nur die Gesamtgenauigkeit betrachten — systematische Fehler bei bestimmten Kategorien sind oft kritischer als eine niedrigere Gesamtgenauigkeit.

Für Generierungsaufgaben: Kohärenz, Faktentreue (Halluzinationsrate schätzen), Formatkonformität, Tonalität. Qualitative Bewertungen durch Testpersonen sind hier oft aussagekräftiger als automatisierte Metriken.

Für Extraktionsaufgaben: Vollständigkeit (alle relevanten Informationen extrahiert?), Präzision (keine irrelevanten Informationen extrahiert?), Format-Konformität der Ausgabe.

Ebene 2 — Nutzererfahrung: Misst, ob der Prototyp von tatsächlichen Nutzenden als hilfreich erlebt wird. Werkzeuge: kurze Nutzerbefragung (5 Fragen, Likert-Skala 1–5), Think-Aloud-Test, strukturiertes Interview. Typische Schlüsselfrage: “Was würde Sie vom Einsatz abhalten?” Diese Frage benennt häufig Adoption-Barrieren, die technisch nicht sichtbar sind.

Ebene 3 — Geschäftlicher Mehrwert: Misst, ob der Prototyp das ursprünglich definierte Problem löst und wirtschaftlichen Nutzen erzeugt. Diese Ebene ist für die Prüfungskommission besonders relevant — sie zeigt, ob Sie den Use-Case betriebswirtschaftlich durchdacht haben.

Wirtschaftlichkeitsberechnung — Schritt für Schritt:

Schritt 1 — Kosten erfassen: Entwicklungskosten (Arbeitszeit × Stundensatz), Infrastrukturkosten (API-Gebühren, Serverkosten, Lizenzkosten), Schulungskosten, laufende Wartungskosten (geschätzt, jährlich).

Schritt 2 — Nutzen quantifizieren: Zeitersparnis × Stundensatz × Anzahl Mitarbeitende × Arbeitswochen/Jahr; Fehlerreduzierung × Kosten pro Fehler × erwartete Fehleranzahl; Kapazitätsgewinn (freigewordene Stunden für höherwertige Tätigkeiten).

Schritt 3 — Break-Even berechnen: Break-Even-Punkt in Monaten = Gesamtinvestitionskosten dividiert durch monatlicher Nettonutzen. Beispiel: Investition 8.000 Euro (Entwicklung + erste drei Monate Betrieb), monatlicher Nutzen 1.200 Euro (40 Std. × 30 Euro/Std.), Break-Even: 8.000 / 1.200 = 6,7 Monate.

Schritt 4 — Sensitivitätsanalyse: Was ändert sich am Break-Even, wenn die Zeitersparnis 20 % geringer ausfällt? Was wenn API-Kosten steigen? Eine einfache Sensitivitätsanalyse mit zwei bis drei Szenarien zeigt, wie robust die Wirtschaftlichkeitsbetrachtung ist.

KPI-Schätzung ohne harte Daten: In vielen Projektarbeiten sind die notwendigen Daten nicht exakt messbar. Das ist kein Einwand gegen die Wirtschaftlichkeitsbetrachtung — es ist ein Argument für transparente Schätzungen. Formulieren Sie KPIs explizit als Schätzungen: “Auf Basis von [X] schätzen wir, dass…” Eine begründete Schätzung ist prüfungsrelevanter als ein Verzicht auf die Wirtschaftlichkeitsbetrachtung.

Roadmap für die Implementierung: Die Roadmap zeigt, was nach dem Prototyp kommt. Drei Phasen: Phase 1 — Pilot (4–8 Wochen): Einsatz mit ausgewählten Nutzenden, Datenerhebung, Fehler identifizieren. Phase 2 — Roll-out (2–3 Monate): Ausweitung auf alle relevanten Nutzenden, Schulung, Prozessanpassungen. Phase 3 — Optimierung (fortlaufend): KPI-Monitoring, Modell-Updates, Nutzerfeedback einarbeiten. Jede Phase sollte einen klaren Erfolgsmeilenstein haben.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

In einem IT-Beratungshaus werden monatlich zehn bis zwanzig Angebote für IT-Projekte erstellt — von Infrastruktur-Migrationen über Softwareentwicklung bis zu Sicherheitsaudits. Jedes Angebot erfordert eine strukturierte Leistungsbeschreibung, die auf den jeweiligen Kunden zugeschnitten ist. Derzeit verbringt das Projektmanagement-Team durchschnittlich zwei bis drei Stunden pro Angebot mit Recherche und Formulierungsarbeit. Der Großteil dieser Zeit wird für Tätigkeiten aufgewendet, die stark auf früheren Projekten basieren: ähnliche Technologien, ähnliche Herausforderungen, ähnliche Lösungsansätze.

Ein KI-gestützter Angebots-Assistent mit Zugriff auf eine Bibliothek früherer anonymisierter Angebote könnte die Formulierungszeit erheblich reduzieren. Für die Projektarbeit bietet sich dieser Use-Case an, weil alle Bewertungsbereiche sinnvoll bearbeitet werden können: Das Problem ist messbar (Zeitaufwand in Stunden), die Methode ist klar (LLM mit RAG auf Angebotsbibliothek), die Compliance ist handhabbar (keine Personendaten in Standardangeboten, DSGVO: minimales Risiko) und ein Prototyp ist in einer Schulungssession realisierbar. Der Scope lässt sich gut eingrenzen: Leistungsbeschreibungen ja, Preiskalkulation nein.

Industrie & Fertigung

In einem mittelständischen Produktionsunternehmen fallen täglich Anfragen an die technische Dokumentationsabteilung an: Wartungsanleitungen müssen für neue Maschinenversionen aktualisiert werden, Sicherheitsdatenblätter müssen übersetzt und angepasst werden, Qualitätsberichte müssen aus Messdaten erstellt werden. Diese Tätigkeiten sind zeitintensiv, strukturiert und in ihrer Kernlogik repetitiv — ideale Kandidaten für KI-Unterstützung.

Eine Projektarbeit in diesem Kontext könnte sich auf die automatisierte Erstellung von Wartungszusammenfassungen konzentrieren: Ein KI-Assistent erhält strukturierte Maschinendaten als Input (Betriebsstunden, Fehlercodes, Wartungshistorie) und erstellt daraus einen ersten Wartungsbericht-Entwurf, der vom Techniker überprüft und freigegeben wird. Der Scope ist klar abgrenzbar: nur ein Maschinentyp, nur Standardwartungen, keine sicherheitskritischen Entscheidungen. Die DSGVO-Relevanz ist gering (keine Personendaten), die AI-Act-Einordnung ist voraussichtlich minimales Risiko, und ein Prototyp ist mit einem Custom-GPT-Ansatz realisierbar.

Finanzdienstleistung & Versicherung

In einer Bank oder Versicherung fallen täglich Anfragen ein, die eine sorgfältige Prüfung und strukturierte Antwort erfordern: Kreditanträge, Schadenmeldungen, Kundenbeschwerden. Die Erstbearbeitung dieser Anfragen ist oft zeitintensiv und erfordert das Abrufen von Informationen aus mehreren internen Systemen.

Eine Projektarbeit könnte sich auf die KI-gestützte Vorklassifizierung eingehender Kundenbeschwerden konzentrieren: Art der Beschwerde (Gebühren, Produkt, Beratung), Dringlichkeit, zuständige Abteilung. Der Assistent erstellt eine strukturierte Zusammenfassung mit Ersteinschätzung — der Sachbearbeiter entscheidet final. Besonders interessant für Kapitel 4 der Projektarbeit: KI-Systeme, die Entscheidungen im Bereich Finanzdienstleistungen vorbereiten, müssen auf ihre Hochrisikeinstufung nach EU AI Act Anhang III geprüft werden. Eine vorbereitende Klassifizierung, die keine finalen Kreditentscheidungen trifft, ist in der Regel als geringes Risiko einzustufen — aber diese Abgrenzung muss sorgfältig begründet werden und ist prüfungsrelevant.

Öffentliche Verwaltung

In einer Behörde oder Stadtverwaltung gehen täglich Bürgeranfragen ein, die Bearbeitung erfordert das Abrufen von Informationen aus verschiedenen Regelwerken, Gesetzen und internen Verfahrenshandbüchern. Die Bearbeitungszeit variiert stark je nach Komplexität der Anfrage und dem Wissensstand des Sachbearbeiters.

Eine Projektarbeit könnte einen internen Wissens-Assistenten konzipieren, der Sachbearbeitende bei der Beantwortung häufiger Bürgeranfragen unterstützt: Der Assistent greift auf eine RAG-Datenbank aus Verfahrenshandbüchern, Gesetzen und FAQs zu und liefert einen ersten Antwortvorschlag mit Quellennachweis. Der Sachbearbeiter prüft, ergänzt und sendet die finale Antwort. Datenschutz ist hier besonders wichtig: Bürgeranfragen können personenbezogene Daten enthalten, was eine sorgfältige DSGVO-Analyse erfordert. Für die Projektarbeit bietet dieser Use-Case eine besonders reichhaltige rechtliche Betrachtungsebene — ein Plus für Kapitel 4.

Warnung — Datenschutz bei der Projektarbeit

Beim Prototyping und beim Schreiben der Projektarbeit gilt: Keine echten Kundendaten, Personaldaten, laufenden Projektkalkulationen oder sonstigen vertraulichen Informationen ohne Anonymisierung verwenden. Das gilt auch für das Hochladen von Dokumenten in Cloud-KI-Dienste für den Prototyp. Ein Verstoß gegen diesen Grundsatz ist kein formaler Fehler — er kann ein DSGVO-Verstoß nach Art. 5 Abs. 1 lit. f (Vertraulichkeit und Integrität) darstellen, für den der Verantwortliche haftet. Verwenden Sie synthetische oder anonymisierte Testdaten. Rechtsgrundlage: DSGVO Art. 5 und 28 (EUR-Lex).

Übung 1 — Themenblatt erstellen

Übung 1 — Themenblatt erstellen

Aufgabe: Entwickeln Sie in 15 Minuten ein erstes Themenblatt für Ihre Projektarbeit. Das Themenblatt ist kein fertiges Konzept, sondern ein Orientierungsrahmen — es dient als Grundlage für das Trainerfeedback und Ihre eigene Planung.

Material: Laptop oder Stift und Papier; Vorlage „Themenblatt Projektarbeit” (im Schulungsbegleitmaterial)

Schritt-für-Schritt: 1. Wählen Sie einen Prozess aus Ihrem Arbeitsalltag, der Sie persönlich beschäftigt oder bei dem Sie Verbesserungspotenzial sehen. 2. Formulieren Sie das Problem in genau drei Sätzen: Was ist der aktuelle Zustand? Was kostet er (Zeit, Qualität, Geld)? Was wäre der gewünschte Zustand? 3. Formulieren Sie einen vorläufigen Titel (Muster: „KI-gestützter [Prozess] — Konzeption, Prototyping und Risikobetrachtung”). 4. Notieren Sie, welche KI-Methode Sie vermutlich einsetzen werden (LLM-Assistent, RAG, Automatisierungsworkflow) und warum. 5. Skizzieren Sie, wie ein Prototyp aussehen könnte (Custom GPT, Copilot Studio, n8n, dokumentierter PoC). 6. Füllen Sie die In/Out-Matrix aus: 3 Punkte, die explizit IN-Scope sind, und 3 Punkte, die OUT-of-Scope sind. 7. Notieren Sie eine erste Einschätzung: Welches Kapitel der Pflichtgliederung wird am schwierigsten für Sie? 8. Reichen Sie das Themenblatt am Ende der UE beim Trainer ein.

Erwartetes Ergebnis: Ein ausgefülltes Themenblatt (1 Seite) mit klarer Problemstellung, vorläufigem Titel, Methoden-Idee und erster Scope-Abgrenzung.

Musterlösung:

Thema: KI-gestützte Angebotserstellung für Infrastrukturprojekte — Konzeption, Prototyp und Risikobewertung

Problemstellung: Im Projektmanagement-Team werden monatlich ca. 12–18 Angebote für IT-Infrastrukturprojekte erstellt. Die Erstellung eines Standardangebots dauert durchschnittlich 2,5 Stunden, davon entfallen ca. 1,5 Stunden auf Formulierungsarbeit, die stark auf vorherigen Projekten basiert. In Summe werden monatlich 18–27 Personenstunden für Formulierungsaufgaben aufgewendet, die mit KI erheblich beschleunigt werden könnten.

Methode: LLM-Assistent (Custom GPT oder Copilot Studio) mit Zugriff auf eine Bibliothek früherer Angebote als Kontextdokumente (RAG-ähnliche Konfiguration). Systemanweisung definiert Stil, Struktur und typische Formulierungsbausteine.

Scope: - IN: Problemanalyse, Canvas, Prototyp-Konfiguration, Beispielinteraktionen mit anonymisierten Testdaten, DSGVO-Betrachtung, Zeitersparnis-Schätzung - OUT: Produktivsetzung, CRM-Integration, Schulung aller Anwender, Vertragsverhandlungen mit KI-Anbieter

Schwierigste Kapitel-Einschätzung: Rechtliche Betrachtung (DSGVO-Grundlage für die Verarbeitung von Angebotsdaten)

Übung 2 — Peer-Scope-Check

Übung 2 — Peer-Scope-Check

Aufgabe: Tauschen Sie Ihr Themenblatt mit einer anderen Teilnehmerin oder einem anderen Teilnehmer aus. Bewerten Sie deren Scope-Abgrenzung nach den Kriterien aus dem Lerntext und geben Sie drei konkrete Rückmeldungen.

Material: Themenblatt der anderen Person; Bewertungskriterien aus dem Lerntext

Schritt-für-Schritt: 1. Lesen Sie das Themenblatt Ihrer Partnerperson sorgfältig durch (5 Minuten). 2. Beurteilen Sie: Ist das Thema spezifisch genug? Notieren Sie Ihre Einschätzung in einem Satz. 3. Beurteilen Sie: Ist die Problemstellung klar und mit einer konkreten Belastungssituation hinterlegt? 4. Prüfen Sie die In/Out-Matrix: Sind die Out-of-Scope-Elemente klar begründet? 5. Identifizieren Sie einen Punkt, der zu breit formuliert ist, und formulieren Sie einen Eingrenzungsvorschlag. 6. Nennen Sie eine Stärke des Themenblatts. 7. Teilen Sie Ihr Feedback mündlich mit (3 Minuten pro Person). 8. Notieren Sie aufgrund des Feedbacks eine Anpassung an Ihrem eigenen Themenblatt.

Erwartetes Ergebnis: Jede Person hat schriftliches und mündliches Peer-Feedback erhalten und mindestens eine konkrete Verbesserung an ihrem Themenblatt vorgenommen.

Musterlösung:

Feedback-Beispiel:

Stärke: Die Problemstellung ist konkret und mit einer Zeitangabe belegt (2,5 Stunden pro Angebot) — das macht die Wirtschaftlichkeitsbetrachtung später einfach.

Verbesserungsvorschlag: Der Titel ist noch etwas weit. Gemeint ist vermutlich das Textieren der Beschreibungsabschnitte, nicht die Preiskalkulation. Das sollte im Titel explizit werden: „KI-gestütztes Formulieren von Leistungsbeschreibungen in Infrastrukturangeboten”.

Fehlende Begründung: Die Out-of-Scope-Elemente sind aufgelistet, aber nicht begründet. Warum ist die CRM-Integration OUT? Weil sie eine separate Architekturentscheidung erfordert, die über den Rahmen hinausgeht — das sollte explizit stehen.

Cheatsheet — Die wichtigsten Punkte

Scope-Disziplin: Lieber einen kleinen Prozess sehr gründlich als drei Prozesse oberflächlich

Problemstellung: Immer mit einer konkreten Zahl (Zeit, Fehlerquote, Kosten)

Pflichtgliederung: 8 Kapitel — jedes hat seinen definierten Inhalt

Prototyp: Muss kein Produktivsystem sein, muss Machbarkeit zeigen

Bestehensgrenze: 12/20 Punkte (60 %) — alle 5 Bewertungsbereiche zählen

Vertraulichkeit: Keine echten Kundendaten, Verträge oder Finanzdaten ohne Anonymisierung

Methodik: Use-Case zuerst denken, dann Tool wählen — nie umgekehrt

In/Out-Matrix: Explizit aufschreiben, was OUT-of-Scope ist — mit Begründung

KI-Nutzung beim Schreiben: Erlaubt und erwünscht — aber mit eigener kritischer Reflexion

Verbindung zu früheren Modulen: Modul 8 Canvas ist der natürliche Ausgangspunkt

Reflexionsfragen

Welchen Prozess aus Ihrem Alltag haben Sie schon länger als verbesserungswürdig empfunden — und wie würde KI konkret helfen?

Was ist der größte Widerstand, den Sie bei der Einführung Ihrer Lösung im Team erwarten — und wie würden Sie damit umgehen?

Wie viel Zeit verbringen Sie aktuell pro Woche mit Tätigkeiten, die potenziell durch KI beschleunigt werden könnten?

Welches Kapitel der Pflichtgliederung bereitet Ihnen die meiste Unklarheit — und warum?

Was würde passieren, wenn Ihr Prototyp in einem Jahr produktiv wäre und gut funktioniert?

Quellen & Weiterlesen

Vertiefung — Die acht Kapitel der Pflichtgliederung: Inhaltliche Logik und typische Fallstricke

Die Pflichtgliederung der Projektarbeit ist kein bürokratisches Schema — sie folgt einer inhärenten inhaltlichen Logik, die dem Denk- und Handlungsprozess einer verantwortungsvollen KI-Projektverantwortlichen entspricht. Wer diese Logik versteht, füllt die Kapitel inhaltlich — statt sie nur formal abzuarbeiten.

Kapitel 1 — Einleitung und Problemstellung: Dieses Kapitel beantwortet die Frage: „Warum ist dieses Projekt notwendig?” Es enthält die quantifizierte Problemdefinition, den organisatorischen Kontext und die Begründung, warum genau dieser Use-Case ausgewählt wurde (und nicht andere). Fallstrick: Teilnehmende schreiben eine lange Einleitung über KI im Allgemeinen, bevor sie zum eigentlichen Problem kommen. Besser: In Satz zwei ist das konkrete Problem benannt.

Kapitel 2 — Analyse des Ist-Zustands: Dieses Kapitel zeigt, wie der betroffene Prozess heute funktioniert — mit Prozesskette, Verantwortlichkeiten, Zeitaufwand und Fehlerquellen. Methode: Prozessflussdiagramm (vereinfacht) oder tabellarische Beschreibung. Fallstrick: Der Ist-Zustand wird zu vage beschrieben. Ohne konkrete Zahlen (Zeit, Häufigkeit, Kosten) lässt sich keine Wirtschaftlichkeit berechnen.

Kapitel 3 — Use-Case-Konzeption: Das KI-Use-Case-Canvas ist hier das Kerndokument. Alle acht Felder müssen vollständig ausgefüllt und erklärt sein — nicht nur als Tabelle, sondern mit Verbindungstext. Fallstrick: Das Canvas wird als Tabelle eingefügt, ohne dass die Entscheidungen erklärt werden. „Warum diese KI-Methode?” gehört in den Fließtext, nicht nur in die Tabellenzelle.

Kapitel 4 — Technische und rechtliche Betrachtung: Dieses Kapitel enthält drei Pflichtabschnitte: (a) technische Architektur des Prototyps (Systemanweisung, Datenfluss, Schnittstellenbeschreibung), (b) EU AI Act-Risikoeinordnung mit Begründung, (c) DSGVO-Analyse (Rechtsgrundlage, Hosting, AVV, DSFA-Prüfung). Fallstrick: Die rechtliche Betrachtung wird auf einen Absatz reduziert. Mit 4 Prüfungspunkten ist Kapitel 4 zu wichtig für eine oberflächliche Behandlung.

Kapitel 5 — Prototyp oder Proof-of-Concept: Dokumentation des Prototyps nach der 9-Komponenten-Systemprompt-Architektur, Screenshots, drei bis fünf Beispielinteraktionen, Iterationsprotokoll. Fallstrick: Der Prototyp wird nur beschrieben, nicht dokumentiert. Ohne Screenshots, vollständige Systemanweisung und nachvollziehbare Testinteraktionen ist Kapitel 5 unvollständig.

Kapitel 6 — Evaluation und Risikobewertung: Dreistufige Evaluation (technische Qualität, Nutzererfahrung, geschäftlicher Mehrwert) mit definierten Testfällen und ehrlicher Grenzenanalyse. Fallstrick: Die Evaluation bewertet nur Stärken. Eine ausgewogene Evaluation benennt auch Schwächen und Grenzen — das zeigt Kompetenz, nicht Schwäche.

Kapitel 7 — Wirtschaftlichkeitsbetrachtung: Vollständige Wirtschaftlichkeitsrechnung nach dem Vier-Schritte-Modell (Kosten, Nutzen, Break-Even, Sensitivitätsanalyse) plus eine kurzfristige Roadmap für die nächsten Phasen. Fallstrick: Wirtschaftlichkeit wird auf eine Tabelle ohne Erklärung reduziert. Die Annahmen und Schätzwerte müssen transparent begründet werden.

Kapitel 8 — Fazit und nächste Schritte: Zusammenfassung der Kernerkenntnisse in drei bis vier Sätzen plus eine konkrete Roadmap für die Produktivimplementierung (Pilot, Roll-out, Optimierung). Fallstrick: Das Fazit wiederholt nur, was in den vorherigen Kapiteln stand. Ein gutes Fazit bewertet die Ergebnisse und leitet Empfehlungen ab.

Merksatz

Die Pflichtgliederung folgt der Logik eines vollständigen Projektzyklus: Problem erkennen → analysieren → konzipieren → rechtlich einordnen → bauen → evaluieren → wirtschaftlich bewerten → reflektieren und empfehlen. Wer diese Logik versteht, hat ein natürliches Gerüst für den gesamten Schreibprozess.

Branchen-Vignette — Logistik & Transport

In einem mittelständischen Logistikdienstleister mit zehn Standorten werden täglich Kundenanfragen zu Sendungsstatus, Lieferterminen und Schadenfällen bearbeitet. Das Call-Center-Team aus zwölf Personen verbringt schätzungsweise 40 % der Arbeitszeit mit dem Abrufen von Informationen aus drei verschiedenen Tracking-Systemen, die nicht integriert sind. Ein Use-Case für die Projektarbeit: ein KI-gestützter interner Wissens- und Auskunfts-Assistent (RAG-Architektur über die drei Tracking-Systeme), der dem Call-Center-Team auf eine Anfrage hin sofort alle relevanten Informationen konsolidiert liefert — ohne drei Systeme manuell abzufragen. Scope-Abgrenzung: Der Assistent liefert Informationen, trifft keine Entscheidungen und kommuniziert nicht direkt mit Kunden. Datenschutz: Sendungsdaten enthalten Kundenadressen (Personenbezug) → AVV mit KI-Anbieter und EU-Hosting. AI Act: minimales Risiko (internes Auskunfts-Tool, Human-in-the-Loop). Wirtschaftlichkeit: 40 % Zeitersparnis × 12 Personen × durchschnittlicher Stundensatz ergibt ein erhebliches Einsparpotenzial.

Praxis-Einschub — Zehn Qualitätssignale einer guten Projektarbeit

Wer wissen möchte, ob die eigene Projektarbeit auf dem richtigen Weg ist, kann die folgenden zehn Signale als Checkliste verwenden. Diese Signale stammen aus der Perspektive erfahrener Prüfender.

Jedes Kapitel beginnt mit einer Kernaussage — nicht mit einer Einleitung in die Einleitung.

Kapitel 1 enthält mindestens eine Zahl — Zeit, Geld, Fehlerquote oder Häufigkeit.

Das Canvas in Kapitel 3 hat keine leeren Felder — auch nicht bei Feld 6 (Risiken) und Feld 8 (Nächste Schritte).

Kapitel 4 benennt die AI-Act-Risikoklasse mit Begründung, nicht nur als Behauptung.

Kapitel 5 enthält die vollständige Systemanweisung — nicht nur einen Auszug.

Die Evaluation in Kapitel 6 benennt mindestens drei Grenzen des Prototyps.

Kapitel 7 enthält einen Break-Even in Monaten — mit nachvollziehbaren Annahmen.

Kapitel 8 enthält eine konkrete Empfehlung — mit Zeitangabe und nächstem Schritt.

Die Sprache ist konsistent formal — keine wechselnden Anrede-Stile (Sie/du).

Alle Quellen sind korrekt zitiert — konsistenter Stil (APA oder IEEE).

Projekte, die alle zehn Signale erfüllen, erzielen regelmäßig hohe Bewertungen — unabhängig vom gewählten Use-Case oder der technischen Komplexität des Prototyps.

Trainer-Hinweise

Vertiefung: Qualitätsmerkmale einer tragfähigen Projektarbeit

Eine Projektarbeit im Rahmen einer KI-Qualifizierung unterscheidet sich von klassischen Seminararbeiten durch ihren konsequenten Praxisbezug. Die folgende Checkliste hilft Teilnehmenden, ihren gewählten Scope frühzeitig zu validieren.

Sieben Kriterien für einen validen Projektscope

Auswertung: 6–7 Grün = sofort starten. 4–5 Grün = mit Anpassungen machbar. Unter 4 Grün = Scope überdenken.

Branchen-Vignette: Chemische Industrie — Qualitätssicherung per KI-gestützter Dokumentenanalyse

Unternehmen: Mittelständischer Spezialchemie-Hersteller (450 Mitarbeitende)

Ausgangssituation: Die Qualitätssicherung prüft monatlich ca. 800 Lieferscheine, Zertifikate und Analysebefunde auf Konformität mit ISO-Vorgaben. Bisher erfolgte dies manuell durch zwei QS-Mitarbeitende (je ~12 Stunden/Monat).

Projektthema der Teilnehmerin: Automatische Erkennung von Abweichungen in PDF-Dokumenten mittels Prompt-Engineering und Large-Language-Model-Extraktion.

Projektverlauf: - Scope-Phase (UE 109): Eingrenzung auf drei Dokumenttypen (Analysezertifikate, Lieferscheine, Prüfberichte). Klärung: Kein Zugang zu rohen Scan-Daten → OCR-vorverarbeitete PDFs werden genutzt. - Prototyp (UE 111): Systemprompt mit Extraktionsregeln; Output: JSON mit Feldern charge_id, parameter, grenzwert, istwert, abweichung. - Ergebnis: 94 % korrekte Extraktionen bei Standarddokumenten; Fehlerquote bei handschriftlich ergänzten Feldern: 23 % → Einschränkung dokumentiert. - Präsentation (UE 113): Empfehlung: Pilotbetrieb für Standarddokumente; manuelle Nachkontrolle für Ausnahmen.

Lernimpuls: Das Projekt illustriert, dass ein klar abgegrenzter Scope — drei Dokumenttypen statt „alle Dokumente” — den Unterschied zwischen einem abgeschlossenen Projekt und einem nie fertigen Vorhaben macht.

Prompt-Box — UE 109: Scope-Validierung per KI-Selbsttest

Prompt:

Ich entwickle eine KI-gestützte Lösung für folgendes Problem:

[PROBLEMBESCHREIBUNG]



Mein geplanter Scope: [SCOPE-BESCHREIBUNG]



Bitte analysiere meinen Scope nach diesen 7 Kriterien:

1. Realweltverankerung

2. Datenzugang

3. Entscheidungsrelevanz

4. Umsetzbarkeit in 4–6 Wochen

5. Stakeholder-Akzeptanz

6. Messbarkeit

7. KI-Relevanz (vs. einfachere Alternativen)



Für jedes Kriterium: Bewertung (Grün/Gelb/Rot), Begründung (1 Satz), und falls Gelb/Rot: konkrete Anpassungsempfehlung.

Abschluss: Gesamturteil in 2–3 Sätzen.

Verwendung: Teilnehmende geben ihren geplanten Scope ein und erhalten in Sekunden ein strukturiertes Feedback, das sie in der Plenumsdiskussion präsentieren können.

Reflexionsfragen — Vertiefungsstufe

Beantworten Sie die folgenden Fragen schriftlich (je 3–5 Sätze) als Vorbereitung auf das Coaching-Gespräch in UE 110:

Problemresonanz: Wie oft und in welchen Situationen begegnen Ihnen die Folgen dieses Problems in Ihrer täglichen Arbeit? Was kostet es Sie konkret — Zeit, Qualität, Stress?

Datensouveränität: Welche Daten bräuchten Sie für Ihr Projekt, und wem gehören diese Daten? Welche datenschutzrechtlichen oder internen Compliance-Hürden sind zu erwarten?

Worst-Case-Szenario: Was passiert, wenn Ihr Prototyp scheitert oder die KI-Lösung schlechtere Ergebnisse liefert als der bisherige Prozess? Wie würden Sie damit umgehen?

Nächster konkreter Schritt: Was ist die eine Aktion, die Sie in den nächsten 48 Stunden unternehmen können, um Ihren Projektscope zu schärfen?

Hinweise für AI Champions — So vermitteln Sie das Thema — UE 109

Timing (45 Min): 8 Min Einstieg und Rahmenerklärung, 10 Min Lerntext (Bewertungskriterien, Scope-Methodik), 15 Min Übung 1 (Themenblatt), 7 Min Übung 2 (Peer-Feedback), 5 Min Plenums-Sicherung.

Methodische Empfehlung: Beginnen Sie mit einem kurzen Blick auf die Pflichtgliederung — vielen Teilnehmenden hilft es, das „große Bild” der Projektarbeit vor dem Themenblatt zu sehen. Danach Einzelarbeit für das Themenblatt, da Themen sehr individuell sind.

Häufige Stolpersteine: (a) Teilnehmende wählen ein zu breites Thema — frühzeitig eingreifen und mit der In/Out-Matrix eingrenzen. (b) Teilnehmende wählen ein Thema, das sie interessiert, aber das keine KI-Komponente hat — gentle redirect zu KI-gestützter Version. (c) Teilnehmende ohne eigene Idee — Canvas aus Modul 8 als Ausgangspunkt anbieten.

Diskussionsfragen für Plenum: (1) Wer hat ein Thema mit einem klaren quantifizierbaren Problem? (2) Welche Scope-Abgrenzung war für jemanden die schwierigste?

Tafelbild-Vorschlag: SMART-Kriterien für den Scope (Spezifisch / Messbar / Realisierbar / Relevant / Terminiert) plus kurze Erinnerung: Prototyp muss in 4 Stunden baubarer sein.

Differenzierung Power-User ↔ Einsteiger: Power-User können direkt den RAG-Ansatz als Methodenwahl angehen und technische Details im Themenblatt festhalten. Einsteiger beginnen mit Custom-GPT-Ansatz und konzentrieren sich auf Problemformulierung.

Materialliste: Laptop, Vorlage Themenblatt (ausgedruckt oder im LMS), Stift, ausgedruckte In/Out-Matrix-Vorlage.

Tipp zur Branchenauswahl: Die Branchen-Galerie bietet vier Szenarien. Für Gruppen aus dem IT-Umfeld eignet sich die IT-Dienstleistungs-Vignette als Gesprächseinstieg — die dort genannte Angebotserstellung ist fast universell bekannt. Für gemischte Gruppen empfiehlt sich die Industrie-Vignette (Wartungsberichte) als niedrigschwelliger Einstieg, weil sie keine Branchenvorerfahrung voraussetzt.

Übergang zur nächsten UE: „Das Themenblatt ist der Kompass — in UE 110 füllen wir das Canvas vollständig aus, das zur Roadkarte für Ihre Projektarbeit wird.”

Weiteres Praxis-Insight — KI-Adoption in unterschiedlichen Organisationsgrößen

Ein wichtiger Kontext für KI-Qualitätsmanagement: Die Herausforderungen variieren erheblich nach Organisationsgröße. Großunternehmen verfügen über mehr Daten, mehr Ressourcen für Datenvorbereitung und formale Governance-Strukturen — aber auch über mehr Bürokratie, mehr Silos und längere Entscheidungswege. Mittelständische Unternehmen sind oft agiler, aber ressourcenknapper und haben weniger standardisierte Datenprozesse.

Für die Qualitätssicherung von KI-Projekten bedeutet das: Es gibt keine universell richtige Vorgehensweise. Was in einem Großkonzern mit dediziertem KI-Team als Best Practice gilt, kann für ein mittelständisches Unternehmen mit einem KI-Anwender im Nebenprojekt überdimensioniert und unpraktikabel sein.

Merksatz

KI-Qualitätsmanagement muss zur Größe und Reife der Organisation passen. Ein schlankes, pragmatisches Qualitätsrahmenwerk, das tatsächlich angewendet wird, ist wertvoller als ein umfassendes Framework, das an der Organisationsrealität vorbeigeht.

Dieser Gedanke ist besonders relevant für die eigene Projektarbeit: Formulieren Sie Empfehlungen immer im Kontext der spezifischen Organisation, auf die Ihr Use Case sich bezieht. Eine kontextsensitive Empfehlung ist überzeugender als eine generische.

Abschlussbemerkung — Warum Qualität kein Endzustand ist

Qualitätsmanagement für KI-Systeme ist kein Projekt mit definiertem Abschluss, sondern ein kontinuierlicher Prozess. KI-Modelle driften über Zeit — ihre Vorhersagequalität verändert sich, weil sich die Welt, auf die sie angewendet werden, verändert. Ein Modell, das heute exzellente Ergebnisse liefert, kann in zwölf Monaten deutlich schlechter sein, wenn sich die Datenbasis verändert hat.

Dies hat eine wichtige Konsequenz für Ihre Projektarbeit und für spätere KI-Projekte in der beruflichen Praxis: Monitoring und periodische Neubewertung müssen von Anfang an eingeplant werden. Die Frage „Wer überprüft, ob das System noch gut funktioniert?” sollte beantwortet sein, bevor das System produktiv geht.

Für die Projektarbeit in diesem Kurs: Auch wenn Sie nur einen Prototyp entwickeln, sollten Sie in der Dokumentation beschreiben, welche Monitoring-Maßnahmen Sie für eine produktive Implementierung vorsehen würden. Diese Zukunftsperspektive zeigt methodische Reife und macht Ihre Arbeit überzeugender.

Vertiefung — Die Problemdefinition als Fundament der Projektarbeit

Eine präzise Problemdefinition ist schwieriger zu formulieren als sie zunächst erscheint. Viele Teilnehmende schreiben in einem ersten Entwurf: „Der Prozess ist ineffizient.” Das ist eine Beobachtung — keine Problemdefinition. Eine Problemdefinition beantwortet vier Fragen gleichzeitig:

1. Was passiert konkret (Zustand)? Beschreiben Sie den aktuellen Ablauf in zwei bis drei Sätzen. Wer macht was, wann, wie oft? Ohne genaue Beschreibung des Ist-Zustands fehlt die Baseline für den Soll-Zustand.

2. Was kostet das (Quantifizierung)? Jede starke Problemdefinition hat eine Zahl: Stunden pro Woche, Fehlerquote in Prozent, Kosten in Euro, Bearbeitungszeit in Minuten. Wenn Sie keine Zahl kennen, schätzen Sie — und benennen Sie die Schätzung als solche. Eine begründete Schätzung ist besser als das Fehlen jeglicher Quantifizierung.

3. Warum ist das relevant (Bedeutung)? Was passiert, wenn das Problem nicht gelöst wird? Rückstände, Qualitätsmängel, Mitarbeiterfrustration, Kundenverluste? Die Relevanz verknüpft das technische Problem mit dem strategischen Kontext Ihrer Organisation.

4. Für wen ist es ein Problem (Betroffene)? Wer leidet unter dem Problem — und wer würde von der Lösung profitieren? Diese Frage leitet direkt in die Stakeholder-Analyse in UE 110 über.

Eine vollständige Problemdefinition in diesem Sinne braucht selten mehr als einen Absatz — aber dieser Absatz enthält alle vier Elemente. Die häufige Schwäche in frühen Projektarbeitsentwürfen ist nicht zu viel, sondern zu wenig Spezifität.

Typische Problemdefinitionen im Vergleich:

Beachten Sie: Auch die starken Versionen sind möglicherweise Schätzungen — aber sie sind begründet und zielführend.

Merksatz

Eine Problemdefinition ohne Zahl ist unvollständig. Wenn Sie die Zahl nicht kennen, schätzen Sie sie mit Begründung — und kennzeichnen Sie sie als Schätzung. Eine transparente Schätzung ist prüfungsrelevanter als ein Verzicht auf Quantifizierung.

Übung 3 — Problemdefinition schärfen

Übung 3 — Problemdefinition schärfen

Aufgabe: Überarbeiten Sie Ihre Problemdefinition aus Übung 1 (Themenblatt) nach den vier Fragen der starken Problemdefinition.

Material: Themenblatt aus Übung 1, Lerntext zu Problemdefinition

Schritt-für-Schritt: 1. Lesen Sie Ihre ursprüngliche Problemdefinition (3 Sätze aus Übung 1) erneut. 2. Prüfen Sie: Welche der vier Fragen (Was? Was kostet es? Warum relevant? Für wen?) sind beantwortet — welche fehlen? 3. Ergänzen Sie die fehlenden Dimensionen. Wenn Sie keine Zahl kennen, schätzen Sie mit Begründung: „Basierend auf ca. X Fällen pro Monat schätze ich, dass…” 4. Formulieren Sie die überarbeitete Problemdefinition in maximal fünf Sätzen neu. 5. Tauschen Sie mit einer Partnerperson: Hat die Person sofort verstanden, was das Problem ist und warum es relevant ist? 6. Notieren Sie eine konkrete Verbesserung basierend auf dem Feedback.

Erwartetes Ergebnis: Eine überarbeitete Problemdefinition mit allen vier Dimensionen — als direkte Vorstufe zu Kapitel 1 der Projektarbeit.

Musterlösung:

Überarbeitete Problemdefinition:

Der IT-Support bearbeitet täglich 40–60 Anfragen. Die Erstklassifizierung (Priorität, Kategorie, Zuweisung) erfolgt manuell durch einen erfahrenen Mitarbeitenden und dauert im Schnitt 3–5 Minuten je Anfrage. Bei 50 Anfragen täglich sind das 2,5 bis 4 Stunden reiner Klassifizierungsaufwand — schätzungsweise 50–80 Arbeitsstunden pro Monat. Hinzu kommt eine Fehlklassifizierungsrate von geschätzt 10–15 %, die Eskalationen und Verzögerungen erzeugt. Die direkten Betroffenen sind die Support-Mitarbeitenden (Zeitverlust), die anfragenden Kolleginnen und Kollegen (längere Wartezeiten) und die Teamleitung (Kapazitätsengpass in Spitzenlastzeiten).

Prompt-Beispiel

Prompt: Problemdefinition für Projektarbeit entwickeln

Persona: Du bist ein erfahrener KI-Projektberater, der Unternehmen bei der Identifikation und Schärfung von KI-Use-Cases unterstützt. Aufgabe: Analysiere folgende Prozessbeschreibung und formuliere eine vollständige Problemdefinition für eine KI-Projektarbeit. Kontext: Prozess: [Kurzbeschreibung des Prozesses, z. B. „manuelle E-Mail-Kategorisierung im Kundenservice”]. Organisation: [Typ, z. B. mittelständisches Handelsunternehmen, 80 Mitarbeitende]. Geschätzte Häufigkeit: [z. B. 30 E-Mails täglich]. Format: Vier Abschnitte: (1) Ist-Zustand in 2 Sätzen. (2) Quantifizierung: geschätzte Kosten in Stunden/Monat oder Euro. (3) Strategische Relevanz in 1 Satz. (4) Betroffene Stakeholder. Einschränkung: Keine allgemeinen Aussagen — nur auf den angegebenen Prozess und Kontext bezogene Formulierungen.

Vertiefung — Häufige Themenentscheidungs-Fallen und wie man ihnen entgeht

Neben dem bekannten Scope-Fehler (zu breit) gibt es weitere typische Fallen bei der Themenentwicklung, die früh erkannt und vermieden werden sollten.

Falle 1 — Der technologiegetriebene Use-Case: „Ich möchte einen Custom GPT bauen — jetzt suche ich ein passendes Problem.” Diese Logik führt fast immer zu schwachen Projektarbeiten. Das Tool ist die Antwort auf eine Frage — aber die Frage muss zuerst formuliert werden. Umkehrung: Finden Sie ein echtes, messbares Problem, dann wählen Sie das Tool, das es löst.

Falle 2 — Der unkontrollierbare Use-Case: Manche Use-Cases scheitern nicht am Schreiben, sondern daran, dass der Prototyp nicht gebaut werden kann. Häufige Gründe: kein Zugang zu den relevanten Daten, keine Testumgebung, zu komplexe API-Integration. Prüfen Sie frühzeitig: Kann ich in vier bis sechs Wochen tatsächlich eine funktionsfähige Demo bauen?

Falle 3 — Der zu persönliche Use-Case: Ein Use-Case, der so spezifisch auf Ihre Funktion oder Ihre Teamkonstellation zugeschnitten ist, dass ihn außenstehende Prüferinnen und Prüfer nicht nachvollziehen können, verliert Bewertungspunkte bei der Darstellungsqualität. Testen Sie: Kann eine fachkundige Person ohne Insider-Wissen Ihren Use-Case in 5 Minuten verstehen?

Falle 4 — Der unbedingt ausgewählte Use-Case: Wenn Teilnehmende emotional in eine Idee investiert sind, fällt es schwer, Schwächen in der Themenentwicklung zu erkennen. Das Peer-Scope-Check-Format aus Übung 2 hilft hier: eine andere Person sieht, was Sie nicht sehen können. Nehmen Sie kritisches Feedback in dieser Phase an — Korrekturen jetzt sind einfacher als Umstrukturierungen während der Schreibphase.

Merksatz

Der beste Test für ein Projektarbeit-Thema: Können Sie es in drei Sätzen einer berufsfremden Person erklären — Problem, KI-Ansatz, Erwarteter Nutzen? Wenn Sie drei Sätze brauchen, ist das Thema gut abgegrenzt. Wenn Sie zehn Sätze brauchen, ist der Scope noch zu groß.

Reflexionsfragen — Vertieft

Welche drei Tätigkeiten aus Ihrem Berufsalltag würden Sie für KI-Unterstützung priorisieren — und nach welchem Kriterium?

Was ist das Riskanteste an Ihrem gewählten Use-Case — und wie würden Sie dieses Risiko in der Projektarbeit transparent machen?

Stellen Sie sich vor, Ihre Projektarbeit wird in zwei Jahren von einem Nachfolger in Ihrer Rolle gelesen. Was würde diese Person am nützlichsten finden?

Welche Anforderung der Pflichtgliederung fühlt sich am schwersten an — und was können Sie konkret tun, um sich vorzubereiten?

Wenn Sie Ihren Use-Case mit drei verschiedenen KI-Methoden umsetzen müssten — welche drei wären das, und welche würde die höchste Qualität liefern?

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.