Projektcoaching II – Prototyping mit KI-Tools

Lernziele

Sie haben für Ihren Use-Case einen funktionalen Prototyp erstellt — als Custom GPT, Copilot Studio Agent, n8n-Workflow oder dokumentierten Proof-of-Concept.

Sie kennen die vier zulässigen Prototyping-Optionen und können begründen, welche für Ihren Use-Case geeignet ist.

Sie verstehen, wie die 9-Komponenten-Systemprompt-Architektur den Qualitätsunterschied zwischen einem durchschnittlichen und einem überzeugenden Prototyp ausmacht.

Sie haben die Datenschutzgrenzen beim Prototyping eingehalten.

Sie können Ihren Prototyp mit mindestens drei dokumentierten Beispielinteraktionen vorstellen.

Sie kennen die typischen Prototyping-Fehler und können diese in Ihrer Arbeit vermeiden.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

In der Softwareentwicklung gibt es das Konzept des „Minimum Viable Product” (MVP) — das kleinstmögliche Produkt, das die Kernfunktionalität demonstriert und echtes Feedback ermöglicht. Beim KI-Prototyping in der Projektarbeit gilt dasselbe Prinzip: Sie brauchen kein produktionsreifes System. Sie brauchen eine Demo, die zeigt, dass Ihre Idee funktioniert.

Der Prototyp ist für viele Teilnehmende die lehrreichste Phase der Projektarbeit. Denn erst beim Bauen zeigen sich die echten Herausforderungen: Die Systemanweisung ist zu vage und der Assistent gibt inkonsistente Antworten. Das RAG-System findet die richtigen Dokumente nicht. Der n8n-Workflow scheitert an der API-Authentifizierung. Diese Probleme sind keine Niederlage — sie sind wertvoller Inhalt für Kapitel 6 (Evaluation) Ihrer Projektarbeit.

Der Trainer steht in dieser UE als technischer Coach zur Verfügung. Ziel: Am Ende der UE haben mindestens 80 % der Teilnehmenden einen Screenshot ihres Prototyps, den sie in die Projektarbeit einbinden können.

Lerntext — Theorie und Konzepte

Die vier Prototyping-Optionen

Option A — Custom GPT (OpenAI GPT Builder) Geeignet für: LLM-basierte Assistenz, Textgenerierung, Q&A über hochgeladene Dokumente. Aufwand: 30–60 Minuten für einen ersten Prototyp. Deliverable: Screenshot der Konfiguration + vollständige Systemanweisung als Text + 3 dokumentierte Beispielinteraktionen.

Option B — Copilot Studio (Microsoft) Geeignet für: Organisationen mit Microsoft 365-Lizenz, Teams-Integration, SharePoint-Zugriff. Wie: Im Microsoft Copilot Studio konfigurieren Sie einen Agenten via Low-Code-Interface. Aufwand: 45–90 Minuten.

Option C — n8n-Workflow Geeignet für: Automatisierungs-Use-Cases (Berichterstellung, E-Mail-Verarbeitung, Daten-Transformation). n8n ist Open Source und kann lokal oder über n8n Cloud betrieben werden. Aufwand: 60–120 Minuten. Deliverable: Screenshot + JSON-Export + Testlauf-Protokoll.

Option D — Dokumentierter Proof-of-Concept Geeignet für: Use-Cases, bei denen aus technischen oder datenschutzrechtlichen Gründen kein Live-System gebaut werden kann. Wie: Vollständige Systemanweisung (nach 9-Komponenten-Architektur) + 5 dokumentierte Beispielinteraktionen mit anonymisierten Inputdaten + technische Architektur.

Abb. 111.1 — Prototyping-Schleife: Von der Systemanweisung zur dokumentierten Demo

Merksatz

Systemanweisung zuerst offline schreiben, dann in das Tool eingeben. Die 9-Komponenten-Systemprompt-Architektur vollständig abdecken ist der wichtigste Qualitätsfaktor für einen konsistenten Prototyp.

Die 9-Komponenten-Systemprompt-Architektur im Prototyping

Der Qualitätsunterschied zwischen einem durchschnittlichen und einem guten KI-Prototyp liegt fast immer in der Systemanweisung. Die 9-Komponenten-Systemprompt-Architektur liefert die Checkliste:

Identität/Rolle: Wer ist der Assistent?

Zweck/Aufgabe: Was soll er tun?

Verhaltensgrenzen: Was soll er explizit NICHT tun?

Kontext: Was muss er über den Prozess, die Nutzenden wissen?

Ausgabeformat: Wie soll die Antwort strukturiert sein?

Tonalität/Stil: Formell oder informell?

Wissensquellen: Auf welche Dokumente darf er zurückgreifen?

Eskalationsregeln: Wann soll er nicht antworten?

Beispiele (Few-Shot): 2–3 Beispiel-Input/Output-Paare

Je mehr dieser Komponenten vollständig ausgefüllt sind, desto konsistenter und zuverlässiger ist das Verhalten des Assistenten. Die vollständige Systemanweisung gehört in den Anhang der Projektarbeit.

Merksatz

Keine echten Kundendaten, Verträge oder Personaldaten im Prototyp. Synthetische oder anonymisierte Testdaten erstellen ist selbst eine Kompetenz — und demonstriert verantwortungsvollen Umgang mit KI.

Datenschutz beim Prototyping — keine echten Daten

Eine kritische Randbedingung: Im Prototyp dürfen keine echten Kundendaten, Personaldaten, laufenden Projektkalkulationen oder anderen vertraulichen Informationen verwendet werden. Für Tests werden stattdessen genutzt:

Synthetische Daten: Selbst erstellte, fiktive Daten mit realistischer Struktur

Anonymisierte Daten: Echte Dokumente, aus denen alle personenbezogenen Informationen entfernt wurden

Dieser Grundsatz gilt auch für das Einfügen von Dokumenten in Custom GPTs oder Copilot Studio: Das Hochladen von Kundendokumenten als Wissensbasis in einen Cloud-KI-Dienst ohne DSGVO-konformen Auftragsverarbeitungsvertrag ist ein Datenschutzverstoß — auch wenn es „nur für den Prototyp” ist.

Vertiefung — Prototyping-Strategien und typische Fehler

Strategie 1 — Vertikaler Prototyp: Zeigt einen einzigen Use-Case vollständig durch: von der Eingabe bis zur Ausgabe. Der Kernbeweis, dass die KI die richtige Qualität produziert.

Strategie 2 — Horizontaler Prototyp: Zeigt viele Funktionen, aber keinen vollständigen Durchfluss. Zeigt Breite, aber nicht Tiefe.

Strategie 3 — Wizard-of-Oz-Prototyp: Eine Person spielt die Rolle der KI, während Nutzer mit der Oberfläche interagieren. Als Ergänzung zu einem dokumentierten PoC akzeptabel. Methodik: Nielsen Norman Group.

Typische Fehler:

Fehler 1 — Den Prototyp zu früh zeigen: Wenn der erste Prototyp noch nicht stabil funktioniert und internen Stakeholdern gezeigt wird, riskiert man einen dauerhaft schlechten ersten Eindruck. Empfehlung: Erst intern testen, bis mindestens 80 % der Testfälle zufriedenstellend funktionieren.

Fehler 2 — Keine Testfälle definiert: Wer nicht vorab definiert, wann ein Prototyp „gut genug” ist, kann das nicht feststellen. Mindestens drei bis fünf repräsentative Testfälle sollten vor dem Prototyping definiert werden.

Fehler 3 — Technologie-Begeisterung statt Problemfokus: Wenn beim Prototyping Features gebaut werden, die im Canvas nicht stehen — stoppen und priorisieren. Mehr dazu in der Lean-Startup-Methodik von Eric Ries.

Prototyp-Dokumentation als Prüfungsleistung: Die Dokumentation des Prototyps ist eine eigenständige Prüfungsleistung. Die Prüfungskommission prüft nicht nur, ob ein Prototyp funktioniert, sondern ob er nachvollziehbar dokumentiert ist. Eine gute Prototyp-Dokumentation enthält: (a) die vollständige Systemprompt-Architektur mit Erklärung jeder Komponente, (b) drei bis fünf Beispiel-Eingaben mit zugehörigen Ausgaben, (c) eine Grenzen-Analyse (was kann der Prototyp nicht?), (d) Datenschutz-Assessment (welche Daten werden verarbeitet, unter welchen Bedingungen?). Diese vier Elemente reichen für eine vollständige Prototyp-Dokumentation im Rahmen der Projektarbeit.

Iterationsprotokoll — Verbesserungen sichtbar machen: Viele Teilnehmende entwickeln den Prototyp iterativ, dokumentieren aber nur die finale Version. Das verschenkt wertvolle Bewertungspunkte. Ein Iterationsprotokoll — zwei bis drei Zeilen pro Iteration: Was wurde geändert? Warum? Was hat sich verbessert? — zeigt der Prüfungskommission, dass ein systematischer Entwicklungsprozess stattgefunden hat, nicht nur Trial-and-Error. Dieses Protokoll kann als Anhang zur Projektarbeit eingereicht werden.

Datenschutzkonformität beim Prototyp belegen: Die Frage “Ist Ihr Prototyp datenschutzkonform?” ist im Kolloquium häufig. Die Antwort muss konkret sein, nicht allgemein. Drei Aspekte: (1) Welche personenbezogenen Daten werden verarbeitet — oder bewusst nicht verarbeitet? (2) Wenn externe APIs genutzt werden: Liegt ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO vor? (3) Falls Personendaten in Prompts eingespeist werden: Gibt es eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO oder einen begründeten Verzicht? Wer diese drei Fragen für seinen Prototyp beantworten kann, ist datenschutzrechtlich solide aufgestellt.

Vertiefung — Systemprompt-Architektur: Neun Komponenten im Detail

Die Qualität eines KI-Prototyps hängt maßgeblich von der Qualität seines Systemprompts ab. Ein gut strukturierter Systemprompt ist kein Text — er ist eine Architektur. Die neun Komponenten geben dem Prototyp die notwendige Robustheit.

Komponente 1 — Rollenbezeichnung (Persona): Definiert, als wen das Modell sich verhalten soll. Eine gute Persona erhöht die Konsistenz der Ausgaben und reduziert Ablenkungsanfälligkeit. Die Persona sollte domänenspezifisch sein — ein “hilfsbereiter KI-Assistent” ist zu generisch.

Komponente 2 — Aufgabenbeschreibung: Was soll das Modell konkret tun? Präzise Verben verwenden: klassifizieren, zusammenfassen, extrahieren, übersetzen, evaluieren, generieren. Mehrdeutige Verben wie “helfen” oder “bearbeiten” führen zu inkonsistenten Ausgaben. Die Aufgabenbeschreibung ist die wichtigste Einzelkomponente.

Komponente 3 — Kontext und Hintergrundwissen: Welche Informationen braucht das Modell, die nicht in der Nutzereingabe enthalten sind? Prozessbeschreibungen, Terminologien, Organisationsstruktur, relevante Normen. Dieser Kontext unterscheidet einen generischen von einem unternehmensspezifischen Prototyp.

Komponente 4 — Ausgabeformat: Wie soll die Antwort strukturiert sein? Tabelle, JSON, nummerierte Liste, Fließtext? Das Format explizit zu definieren verhindert inkonsistente Ausgaben und erleichtert die Weiterverarbeitung durch andere Systeme.

Komponente 5 — Tonalität und Sprache: Formal oder informell? Technisch oder allgemeinverständlich? Deutsch oder Englisch? Diese Komponente wird häufig vergessen und führt zu Ausgaben, die nicht zum Verwendungskontext passen.

Komponente 6 — Beispiele (Few-Shot): Ein oder zwei Beispiele für eine gute Ausgabe erhöhen die Ausgabequalität erheblich. Few-Shot-Prompting ist eine der wirksamsten Techniken zur Verbesserung der Präzision, besonders bei Klassifikationsaufgaben.

Komponente 7 — Einschränkungen und Grenzen: Was soll das Modell nicht tun? Keine medizinischen oder rechtlichen Ratschläge erteilen, keine personenbezogenen Daten in Ausgaben aufnehmen, keine Entscheidungen treffen sondern nur Empfehlungen ausgeben. Diese Komponente ist aus Datenschutz- und Haftungsperspektive besonders relevant.

Komponente 8 — Fehlerbehandlung: Was soll das Modell tun, wenn es eine Anfrage nicht beantworten kann oder die Anfrage unklar ist? “Wenn du dir unsicher bist, frage nach statt zu raten” verhindert Halluzinationen und führt zu vorhersagbarem Verhalten.

Komponente 9 — Datenschutzhinweise: Explizite Anweisung, keine eingespielten personenbezogenen Daten in Ausgaben zu wiederholen und Anfragen mit sensiblem Inhalt entsprechend zu behandeln. Diese Komponente ist in Unternehmensumgebungen obligatorisch.

Prototyping-Strategie: Minimal Viable Prompt zuerst: Mit Komponenten 1 und 2 beginnen, testen, dann schrittweise weitere Komponenten hinzufügen. So lässt sich der Einfluss jeder Komponente beobachten und gezielt optimieren.

Datenschutz beim Prototyping — drei Regeln: (1) Keine echten Personendaten in Testprompts verwenden — synthetische Testdaten erstellen. (2) Keine vertraulichen Unternehmensdaten in externe KI-APIs einspeisen ohne Datenschutzprüfung. (3) Dokumentieren, welche Daten zu Testzwecken verwendet wurden.

Vier Prototyp-Optionen im Vergleich: Custom GPT: Wissensassistenten, Dokument-Analyse, Kommunikation — kein Code erforderlich, aber an externe Infrastruktur gebunden. Copilot Studio: Microsoft-365-Integration, Teams-Bots — Enterprise-Integration, aber Lizenz erforderlich. n8n: Automatisierungs-Workflows mit mehreren Systemanbindungen — offen und on-premise möglich, aber technische Einrichtung nötig. PoC mit Direktanfragen: Konzeptvalidierung ohne Tool-Aufwand — sofort startbar, aber nicht produktiv einsetzbar.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

In einem IT-Beratungshaus wird der Angebots-Assistent als Custom GPT konfiguriert. Die Systemanweisung definiert den Assistenten als Experte für IT-Infrastrukturangebote, der auf Basis von Projektinformationen (Umfang, Technologien, Laufzeit) eine strukturierte Leistungsbeschreibung erstellt. Als Wissensbasis werden drei anonymisierte frühere Angebote hochgeladen — ohne Kundennamen, ohne Preise. Das Ausgabeformat ist eine nummerierte Liste mit Überschriften und Bullet Points.

Nach 45 Minuten liegt vor: Screenshot des konfigurierten Assistenten, eine vollständige Systemanweisung (ca. 400 Wörter) und drei dokumentierte Testinteraktionen mit synthetischen Projektbeschreibungen als Input und generierten Leistungsbeschreibungen als Output. Das ist ein vollständiger Prototyp für Kapitel 5 der Projektarbeit.

Industrie & Fertigung

In einem Fertigungsunternehmen wird der Wartungsprotokoll-Assistent als n8n-Workflow realisiert. Der Workflow empfängt strukturierte Maschinendaten als Webhook-Trigger (JSON mit Betriebsstunden, Fehlercodes, Wartungsarbeiten), sendet diese an ein LLM mit vorbereiteter Systemanweisung und speichert das generierte Protokoll als Word-Dokument auf einem Netzlaufwerk. Die Systemanweisung legt das exakte Protokoll-Format gemäß der internen Vorlage fest.

Dieser Workflow ist technisch anspruchsvoller als Option A (Custom GPT), aber er demonstriert eine echte End-to-End-Automatisierung, die für Kapitel 5 der Projektarbeit besonders überzeugend ist. Als synthetische Testdaten werden fiktive Maschinendaten einer „Anlage A-47” mit realitätsnahen Parametern verwendet.

Finanzdienstleistung & Versicherung

In einer Versicherung wird der Beschwerde-Klassifizierer als Copilot Studio Agent realisiert, der in den Unternehmens-Teams integriert ist. Die Wissensbasis enthält anonymisierte Kategorisierungsrichtlinien und typische Beschwerdeformulierungen je Kategorie. Der Agent klassifiziert eine eingereichte Beschwerde nach Art und Dringlichkeit und schlägt die zuständige Abteilung vor.

Für den Prototyp werden synthetische Beschwerde-Texte verwendet — realistisch formuliert, aber ohne echte Kundendaten. Die Systemanweisung enthält explizite Grenzen: Der Agent gibt keine rechtlichen Einschätzungen ab, keine Zusagen und keine finalen Entscheidungen. Jede Klassifizierung wird als Vorschlag markiert und muss vom Sachbearbeiter bestätigt werden.

Öffentliche Verwaltung

In einer Gemeindeverwaltung wird der Wissens-Assistent als dokumentierter Proof-of-Concept (Option D) realisiert, weil der Zugang zu Produktivsystemen in der Schulungsphase nicht möglich ist. Die Systemanweisung ist vollständig nach der 9-Komponenten-Architektur ausgearbeitet. Als synthetische Wissensbasis dienen öffentlich zugängliche Verfahrenshinweise aus dem Gemeinderecht. Fünf dokumentierte Interaktionen demonstrieren typische Anfragen: Zuständigkeit für Bauanträge, Fristen für Widersprüche, Formulare für Ummeldungen.

Diese Option D ist für Verwaltungskontexte vollwertig: Sie zeigt die vollständige Systemprompt-Architektur, die Interaktionslogik und eine realistische Beschreibung der geplanten technischen Architektur (RAG über SharePoint-Dokumente mit On-Premises-Hosting).

Warnung — Synthetische Daten und Datenschutz

Die Verwendung von echten Produktionsdaten beim Prototyping ist ein häufiger Fehler mit ernsthaften Konsequenzen. Auch wenn es sich „nur um einen Test” handelt: Das Hochladen vertraulicher Unternehmensdaten in einen Consumer-Cloud-KI-Dienst ohne Auftragsverarbeitungsvertrag (AVV) kann einen DSGVO-Verstoß nach Art. 28 darstellen. Im schlimmsten Fall werden die Daten für das Training des Modells verwendet — ohne dass Sie es bemerken. Rechtsgrundlage: DSGVO Art. 28 (Auftragsverarbeitung) — EUR-Lex. Verwenden Sie immer synthetische oder anonymisierte Daten. Prüfen Sie bei Cloud-KI-Diensten explizit, ob ein Unternehmens-Account mit AVV vorhanden ist.

Übung 1 — Prototyp erstellen

Übung 1 — Prototyp erstellen

Aufgabe: Erstellen Sie in dieser UE einen ersten funktionalen Prototyp für Ihren Use-Case. Wählen Sie die Prototyping-Option, die am besten zu Ihrem Canvas passt.

Material: Laptop mit Internetzugang; Zugang zu ChatGPT Plus/Team ODER Microsoft Copilot Studio ODER n8n; Canvas aus UE 110; Synthetische Testdaten

Schritt-für-Schritt: 1. Entscheiden Sie sich für eine Prototyping-Option (A/B/C/D). 2. Schreiben Sie zunächst OFFLINE Ihre Systemanweisung nach der 9-Komponenten-Architektur. 3. Prüfen Sie: Sind alle 9 Komponenten abgedeckt? 4. Öffnen Sie das gewählte Tool und konfigurieren Sie den Assistenten/Workflow. 5. Führen Sie eine erste Testinteraktion durch und beurteilen Sie den Output gegen Canvas-Feld 5. 6. Passen Sie die Systemanweisung an und wiederholen Sie den Test (min. 2 Iterationen). 7. Dokumentieren Sie 3 Beispielinteraktionen vollständig. 8. Machen Sie einen Screenshot der Konfiguration. 9. Signalisieren Sie dem Trainer für eine 2-minütige Live-Demo.

Erwartetes Ergebnis: Funktionaler Prototyp mit Screenshot, vollständiger Systemanweisung und 3 dokumentierten Beispielinteraktionen.

Musterlösung:

Systemanweisung für Angebots-Assistent (Auszug): „Du bist ein erfahrener Angebotsberater für IT-Infrastrukturprojekte bei einem mittelständischen IT-Dienstleister. Deine Aufgabe ist es, auf Basis von Projektinformationen (Umfang, beteiligte Technologien, Dauer, Zielgruppe) eine strukturierte Leistungsbeschreibung zu erstellen, die als Rohentwurf für das Angebotsdeckblatt verwendet werden kann. Du formulierst klar, fachlich korrekt und auf Deutsch. Du machst keine Preisaussagen. Wenn du nicht genug Projektinformation hast, fragst du gezielt nach. Ausgabeformat: Nummerierte Abschnitte mit Kurzüberschrift und 3–5 Sätzen Beschreibungstext je Abschnitt.”

Übung 2 — Prototyp dokumentieren und Grenzen beschreiben

Übung 2 — Prototyp dokumentieren und Grenzen beschreiben

Aufgabe: Dokumentieren Sie Ihren Prototyp vollständig für Kapitel 5 der Projektarbeit und beschreiben Sie dessen technische Grenzen ehrlich und analytisch.

Material: Prototyp aus Übung 1; Screenshots; Systemanweisung

Schritt-für-Schritt: 1. Schreiben Sie einen Einleitungssatz: Welcher Prototyp-Typ wurde gewählt und warum? 2. Fügen Sie Ihren Screenshot ein und beschreiben Sie das Bild in 2–3 Sätzen. 3. Fügen Sie die vollständige Systemanweisung als formatierten Textblock ein. 4. Protokollieren Sie die drei Beispielinteraktionen im Format: INPUT → OUTPUT. 5. Beschreiben Sie 3–5 technische Grenzen des Prototyps. 6. Schreiben Sie 2–3 Sätze: „Was ich beim Prototyping gelernt habe.” 7. Prüfen Sie: Ist der Inhalt verständlich ohne mündliche Erklärung?

Erwartetes Ergebnis: Ein vollständig dokumentiertes Kapitel 5 (Prototyp) für die Projektarbeit.

Musterlösung:

Grenzen-Beschreibung: „Der aktuelle Prototyp hat folgende Grenzen: (1) Kein direkter Zugriff auf frühere Projekte im CRM — Dokumente müssen manuell hochgeladen werden. (2) Das Modell neigt bei sehr kurzen Projektbeschreibungen zu generischen Formulierungen. (3) Es gibt keine Versionierung der Systemanweisung. (4) Die Lösung ist nicht in das bestehende Dokumentensystem integriert — Copy-Paste bleibt notwendig.”

Cheatsheet — Die wichtigsten Punkte

Prototyp = Machbarkeitsnachweis, kein Produktivsystem

Systemanweisung zuerst offline schreiben, dann in das Tool eingeben

9-Komponenten-Architektur vollständig abdecken für konsistente Ergebnisse

Keine echten Kundendaten, Verträge oder Personaldaten im Prototyp

Synthetische Testdaten erstellen — das ist selbst eine Kompetenz

Mindestens 2 Iterationen der Systemanweisung vor der Dokumentation

Screenshots + vollständige Systemanweisung + 3 Interaktionen = vollständiges Deliverable

Grenzen des Prototyps ehrlich beschreiben — das zeigt Kompetenz

Option D (dokumentierter PoC) ist vollwertig wenn Option A–C nicht möglich ist

Der Prototyp ist der Kerninhalt von Kapitel 5 der Projektarbeit

Reflexionsfragen

Was war Ihre größte technische Überraschung beim Prototyping — und was haben Sie daraus gelernt?

Welche Qualitätsprobleme hat Ihr Prototyp gezeigt — und wie würden Sie diese in einem Produktivsystem adressieren?

Wie unterscheidet sich die erste Version Ihrer Systemanweisung von der finalen Version?

Welche Datenschutz-Überlegungen haben Sie beim Prototyping bewusst gemacht?

Wenn Sie für den Produktiveinsatz 3 Wochen Entwicklungszeit hätten — was würden Sie zuerst verbessern?

Quellen & Weiterlesen

Vertiefung — Systemprompt-Architektur: Vollständiges Beispiel und Analyse

Ein vollständig ausgearbeiteter Systemprompt nach der 9-Komponenten-Architektur für einen Support-Ticket-Klassifizierer zeigt, wie die Komponenten zusammenwirken:

Systemprompt: Support-Ticket-Klassifizierer

Komponente 1 — Rollenbezeichnung: Du bist ein präziser Support-Ticket-Klassifizierer für ein IT-Unternehmen mit Fokus auf Infrastruktur- und Softwareprojekte.

Komponente 2 — Aufgabenbeschreibung: Deine Aufgabe ist es, eingehende Support-Tickets zu klassifizieren und zu priorisieren. Du weist jedem Ticket (a) eine Priorität (P1/P2/P3/P4), (b) eine Kategorie (Netzwerk/Hardware/Software/Zugang/Sonstiges) und (c) einen ersten Lösungsvorschlag aus der Wissensdatenbank zu.

Komponente 3 — Kontext: P1 = kritische Systemausfälle (Produktionsstopp). P2 = schwerwiegende Beeinträchtigungen (mehrere Nutzer betroffen). P3 = einzelne Beeinträchtigungen. P4 = Informationsanfragen oder Wünsche. Unsichere Priorisierung immer eher eine Stufe höher ansetzen.

Komponente 4 — Ausgabeformat: Antwort immer im Format: PRIORITÄT: [P1/P2/P3/P4] | KATEGORIE: [Kategorie] | BEGRÜNDUNG: [1 Satz] | LÖSUNGSVORSCHLAG: [1–3 Sätze aus Wissensdatenbank oder „Eskalation empfohlen”].

Komponente 5 — Tonalität: Sachlich, präzise, kein Fließtext — nur das definierte Ausgabeformat.

Komponente 6 — Beispiele (Few-Shot): Eingabe: „Outlook startet nicht mehr, ich kann keine E-Mails lesen oder senden.” → PRIORITÄT: P3 | KATEGORIE: Software | BEGRÜNDUNG: Einzelne Beeinträchtigung, Kernkommunikation betroffen | LÖSUNGSVORSCHLAG: Outlook-Reparaturinstallation via Systemsteuerung → Programme → Office-Reparatur.

Komponente 7 — Einschränkungen: Keine Entscheidungen treffen — nur Klassifizierung und Erstvorschlag. Bei P1-Tickets immer den Hinweis ausgeben: „Sofortige Eskalation an [Bereitschaft] empfohlen.” Keine persönlichen Daten in der Ausgabe wiederholen.

Komponente 8 — Fehlerbehandlung: Wenn das Ticket unklar oder unvollständig ist: PRIORITÄT: P3 (Standardannahme) | KATEGORIE: Unklar | BEGRÜNDUNG: Ticket unvollständig | LÖSUNGSVORSCHLAG: Bitte Nachfrage beim Ticketersteller: „Welches System ist betroffen? Seit wann? Wie viele Nutzer?”

Komponente 9 — Datenschutzhinweise: Namen, E-Mail-Adressen oder andere personenbezogene Angaben aus dem Ticket nicht in der Ausgabe wiederholen. Ticket-Inhalt nicht über diesen Kontext hinaus verwenden.

Dieser Systemprompt deckt alle neun Komponenten vollständig ab. In einer Testphase würde er an zehn repräsentativen Tickets gemessen und ggf. in Komponente 3 (Kontext) oder Komponente 6 (Beispiele) iteriert.

Branchen-Vignette — Steuerberatung & Wirtschaftsprüfung

In einer Steuerberatungskanzlei fallen regelmäßig folgende zeitintensive Aufgaben an: Mandantenkorrespondenz (Standardantworten auf häufige Fragen), Zusammenfassung von Änderungen im Steuerrecht für mandantenbezogene Newsletter, Vorbereitung von Erstgespräch-Unterlagen. Ein Prototyp für einen Kanzlei-Assistenten könnte als Custom GPT konfiguriert werden, der auf Basis von anonymisierten Briefvorlagen und Standardtexten Entwürfe für Mandantenkommunikation generiert.

Besondere Datenschutz-Anforderung: Mandantendaten (Name, Steuernummer, Finanzdaten) sind streng vertraulich und dürfen unter keinen Umständen in Cloud-KI-Dienste eingegeben werden — auch nicht für Testzwecke. Für den Prototyp werden daher vollständig synthetische Mandanten-Szenarien entwickelt: fiktiver Name, fiktive Steuerklasse, fiktive Situation. Dies ist für Kapitel 4 der Projektarbeit (Datenschutz) ein besonders lehrreicher Abschnitt — da Kanzleien regelmäßig Art. 9 DSGVO-relevante Daten (Gesundheit, Finanzen) verarbeiten, ist die Datenschutz-Folgenabschätzungs-Pflicht nach Art. 35 DSGVO zu prüfen.

Praxis-Einschub — Häufige Prototyping-Entscheidungen und ihre Konsequenzen

In der Praxis treffen Teilnehmende beim Prototyping eine Reihe von Entscheidungen, deren Konsequenzen erst im Nachhinein sichtbar werden. Die folgenden fünf Entscheidungspaare helfen, vorab besser zu wählen.

Entscheidung 1 — Custom GPT vs. Direktanfragen: Custom GPT: Vorteil = persistente Systemanweisung, wiederholbar nutzbar, exportierbar; Nachteil = erfordert ChatGPT-Plus-Zugang. Direktanfragen: Vorteil = sofort startbar, kein besonderer Zugang nötig; Nachteil = Systemanweisung muss jedes Mal neu eingegeben werden, schwer zu dokumentieren. Empfehlung: Wenn ein ChatGPT-Plus-Zugang vorhanden ist, immer Custom GPT wählen — es bietet bessere Dokumentierbarkeit.

Entscheidung 2 — Deutsch vs. Englisch als Promptsprache: Die meisten LLMs liefern in Englisch etwas präzisere Ergebnisse bei technischen Aufgaben. Für deutschsprachige Ausgaben (die in der Projektarbeit fast immer gefordert sind) empfiehlt sich: Systemanweisung auf Deutsch, Ausgabeformat auf Deutsch definiert, Eingabe kann auf Deutsch oder Englisch erfolgen. Dies ist in Komponente 5 (Tonalität) der Systemanweisung zu spezifizieren.

Entscheidung 3 — Few-Shot-Beispiele vs. kein Few-Shot: Few-Shot-Beispiele erhöhen die Konsistenz der Ausgaben erheblich — besonders bei Klassifizierungsaufgaben. Aufwand: zwei bis drei Beispiele formulieren, die den Idealfall zeigen. Empfehlung: Für jeden Prototyp mindestens ein Beispiel in die Systemanweisung integrieren. Der Aufwand amortisiert sich durch deutlich konsistentere Testergebnisse.

Entscheidung 4 — Breite Demo vs. tiefe Demo: Eine breite Demo zeigt viele Funktionen, aber keinen vollständigen Durchfluss. Eine tiefe Demo zeigt einen einzigen Use-Case vollständig — von der Eingabe bis zur fertigen Ausgabe. Für die Projektarbeit ist immer die tiefe Demo besser: Sie zeigt, dass das System wirklich funktioniert, nicht nur dass es angewendet werden könnte.

Entscheidung 5 — Screenshot vs. Videoaufnahme: Screenshots sind in Projektarbeiten standard und ausreichend. Eine kurze Videoaufnahme (30–60 Sekunden) kann als optionaler Anhang ergänzt werden und überzeugt besonders bei dynamischen Interaktionen. Sie ist jedoch keine Pflicht und kein Bewertungsmerkmal.

Merksatz

Die beste Dokumentations-Entscheidung beim Prototyping: Machen Sie während des Bauens Screenshots — auch von Zwischenschritten und Fehlern. Diese Dokumentation ist am Ende wertvoller als nachträgliches Rekonstruieren. Eine Stunde Prototyping ohne Dokumentation ist für die Projektarbeit halb verloren.

Trainer-Hinweise

Vertiefung: Prototyping-Strategien für KI-Anwendungen

Beim Prototyping KI-gestützter Lösungen existieren drei grundlegende Ansätze mit unterschiedlichen Vor- und Nachteilen:

Ansatz A — Prompt-only Prototyp - Werkzeuge: ChatGPT, Copilot, Claude (direkt im Browser) - Stärken: Sofort startklar, keine technischen Vorkenntnisse nötig, iterierbar in Minuten - Grenzen: Keine Persistenz, keine Systemintegration, manuelle Eingabe - Geeignet für: Validierung des Grundkonzepts, Stakeholder-Demo, Machbarkeitsnachweis

Ansatz B — Automatisierter Workflow-Prototyp - Werkzeuge: n8n, Make (Integromat), Power Automate - Stärken: Echte Prozessautomatisierung, Datenbankanbindung möglich - Grenzen: Einrichtungszeit 2–8 Stunden, Debugging aufwändiger - Geeignet für: Wiederholende Prozesse, E-Mail-Verarbeitung, Datentransfer

Ansatz C — Code-basierter Prototyp - Werkzeuge: Python (Jupyter Notebook), Streamlit, Google Colab - Stärken: Maximale Flexibilität, skalierbar, produktionsnah - Grenzen: Erfordert Programmierkenntnisse oder KI-unterstütztes Coding - Geeignet für: Datenanalyse, Modelltraining, Komplexe Transformationen

Entscheidungsregel: > Beginnen Sie immer mit Ansatz A. Wechseln Sie zu Ansatz B, wenn der Prompt-Prototyp prinzipiell funktioniert, aber manueller Aufwand das Bottleneck ist. Wechseln Sie zu Ansatz C nur, wenn Ansatz B an technische Grenzen stößt.

Übung 2: Iteratives Prompt-Refinement in 4 Runden

Szenario: Sie entwickeln einen KI-Assistenten für eine bestimmte Aufgabe aus Ihrem Projekthema.

Ablauf (4 × 5 Minuten):

Auswertung: Notieren Sie, bei welcher Runde die größte Qualitätsverbesserung eintrat. Was hat das über die Wirkung einzelner Prompt-Elemente gelernt?

Branchen-Vignette: Architektur & Bauwesen — KI-gestütztes Flächenmanagement

Unternehmen: Architekturbüro mit 35 Mitarbeitenden, Schwerpunkt Gewerbeimmobilien

Prototyp-Aufgabe: Automatische Extraktion von Raumflächendaten aus Grundriss-PDFs und Erstellung von Flächenübersichtstabellen für Mietvertragsverhandlungen.

Prototyping-Verlauf: - Ansatz A (Woche 1): GPT-4 Vision mit Grundriss-Screenshots → Extraktion der Raumbezeichnungen und geschätzten Flächen funktioniert zu 70 % - Problem: Skalen werden nicht immer korrekt interpretiert; Flächen weichen um 5–15 % ab - Ansatz A, Iteration 3: Systemprompt um Maßstabsangabe ergänzt → Genauigkeit auf 85 % verbessert - Entscheidung: Kein Wechsel zu Ansatz B/C, da 85 % ausreichen für Vorverhandlungs-Schätzwerte; finale Vermessung bleibt manuell

Lesson Learned: Ein Prompt-Prototyp mit 85 % Genauigkeit hat in diesem Kontext mehr Wert als ein aufwändiger Code-Prototyp mit 92 % Genauigkeit — der Zusatznutzen rechtfertigt den Mehraufwand nicht.

Prompt-Box — UE 111: Iterativer System-Prompt-Builder

Prompt:

Ich möchte einen robusten System-Prompt für folgende Aufgabe entwickeln:

[AUFGABENBESCHREIBUNG]



Beispiel-Eingabe, die der Prompt verarbeiten soll:

[BEISPIELEINGABE]



Erwartetes Ausgabeformat:

[GEWÜNSCHTES FORMAT]



Bitte erstelle einen System-Prompt, der folgende Elemente enthält:

1. Klare Rollendefinition (wer ist die KI in diesem Kontext?)

2. Präzise Aufgabenbeschreibung

3. Ausgabeformat-Spezifikation (Markdown-Tabelle / JSON / Fließtext)

4. Mindestens ein Negativbeispiel (was soll die KI NICHT tun?)

5. Umgang mit unklaren oder unvollständigen Eingaben



Formuliere den System-Prompt so, dass er auch ohne zusätzliche Erklärung von einem Nicht-Experten genutzt werden kann.

Verwendung: Dieser Meta-Prompt hilft, schnell professionelle System-Prompts zu generieren. Das Ergebnis wird in Runde 2 der Iterationsübung eingesetzt.

Reflexionsfragen

Welche Aspekte Ihres Prototyps haben Sie am meisten überrascht — positiv oder negativ?

Wo liegen die Grenzen Ihres aktuellen Prototyps? Was könnte ihn zum Scheitern bringen?

Würden Sie nach dem heutigen Prototyping-Tag den Scope Ihres Projekts anpassen? Wenn ja: wie?

Merkhilfe: Die vier häufigsten Prototyping-Fehler

Beim ersten Prototyping-Durchgang begehen fast alle Teilnehmenden ähnliche Fehler. Diese vier Muster zu kennen, spart erhebliche Zeit:

Der Perfektionismus-Fehler: Den ersten Prompt so lange schreiben, bis er „perfekt” klingt — ohne ihn zu testen. Lösung: Nach 10 Minuten den ersten Versuch testen, egal wie unfertig er klingt.

Der Scope-Creep-Fehler: Beim Testen immer mehr Anforderungen hinzufügen. Lösung: Scope-Statement aus UE 110 als feste Leitplanke neben sich legen.

Der Single-Test-Fehler: Ein Prompt mit einem Beispiel testen und für fertig erklären. Lösung: Mindestens drei verschiedene Eingaben testen, davon eine „schwierige” oder ungewöhnliche.

Der Vergleichsfehler: Den KI-Output nicht mit dem bisherigen manuellen Prozess vergleichen. Lösung: Ergebnis explizit neben dem aktuellen Prozessergebnis legen — Was ist besser? Was ist schlechter?

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

Timing (45 Min): 5 Min Einstieg (vier Optionen kurz vorstellen), 8 Min Lerntext (9-Komponenten-Architektur, Datenschutz), 20 Min Übung 1 (Prototyping mit Coaching), 7 Min Übung 2 (Dokumentation), 5 Min Live-Demos.

Methodische Empfehlung: Lab-Format — alle arbeiten gleichzeitig, Trainer geht herum und gibt bei Blockaden Hilfe. Maximal 5 Minuten pro Person in der Coaching-Runde. Wer schon in der ersten Iteration gute Ergebnisse hat, direkt zu Übung 2 schicken.

Häufige Stolpersteine: (a) Systemanweisung direkt im Tool tippen, ohne vorher offline zu schreiben — führt zu unstrukturierten, zu langen Anweisungen. (b) Echte Daten hochladen — Datenschutz-Hinweis sofort und deutlich geben. (c) Option A als einzige Möglichkeit betrachten — auf Option D hinweisen, wenn Zugang fehlt.

Diskussionsfragen: (1) Wer hat die 9-Komponenten alle vollständig abgedeckt? Was war die schwierigste? (2) Welche Grenzen des Prototyps überraschten Sie am meisten?

Tafelbild-Vorschlag: 9-Komponenten-Architektur als nummerierte Liste; daneben „Was fehlt → was passiert”: Keine Verhaltensgrenzen → unkontrollierte Ausgaben. Keine Beispiele → inkonsistenter Stil.

Differenzierung: Power-User können den Prototyp direkt in eine API-Konfiguration überführen und den JSON-Export der Systemanweisung dokumentieren. Einsteiger konzentrieren sich auf Übung 2 und vervollständigen die Dokumentation.

Tipp zur Branchenauswahl: Die IT-Dienstleistungs-Vignette (Angebots-Assistent als Custom GPT) eignet sich als Live-Demo durch den Trainer am Beginn der UE — zeigt konkret, was in 45 Minuten realistisch erreichbar ist. Für Fertigungsgruppen eignet sich die Industrie-Vignette als Inspiration für den n8n-Ansatz.

Übergang zur nächsten UE: „Sie haben einen Prototyp. In UE 112 werten wir ihn systematisch aus und schreiben die Kapitel 6–8 der Projektarbeit. Das ist die intellektuell anspruchsvollste Phase — und die wichtigste für die Gesamtnote.”

Ergänzung — Prototyping in der Praxis: Häufige Fragen

Wie umfangreich muss der Prototyp sein? Der Prototyp muss nicht produktionsreif sein — er muss demonstrationsfähig sein. Das bedeutet: Er muss mit mindestens drei bis fünf realistischen Testfällen getestet worden sein, und die Ergebnisse müssen dokumentiert sein. Ein Custom GPT, der auf dem Laptop des Teilnehmers läuft, ist ein vollwertiger Prototyp — sofern er den definierten Use-Case adressiert und die Grenzen transparent beschrieben sind.

Kann ich einen “Prototyp” einreichen, der nur auf Papier existiert? Ja — wenn es sich um ein vollständiges Konzept handelt, das alle neun Komponenten der Systemprompt-Architektur beschreibt, einen Architektur-Sketch enthält, Testszenarien definiert und datenschutzrechtliche Aspekte adressiert. Ein “Konzept-Prototyp” erhält in der Bewertung dieselben möglichen Punkte wie ein technischer Prototyp — wird aber bei der Glaubwürdigkeit der Wirtschaftlichkeitsabschätzung typischerweise strenger bewertet, da keine empirischen Testergebnisse vorliegen.

Was tun, wenn der Prototyp nicht funktioniert? Das Nichtfunktionieren eines Prototyps ist kein Misserfolg — es ist ein Ergebnis. Dokumentieren Sie, was Sie versucht haben, warum es nicht funktioniert hat (Datenlage, Modellgrenzen, Komplexität des Use-Cases), und welche Schlüsse Sie daraus ziehen. Eine ehrliche Dokumentation eines gescheiterten Prototyp-Ansatzes mit alternativer Konzeptentwicklung wird von der Prüfungskommission positiv bewertet — weil sie zeigt, dass Sie mit Komplexität umgehen können.

Merksatz

Ein Prototyp ist ein Lernwerkzeug. Seine wichtigste Funktion ist nicht, perfekt zu sein — sondern zu zeigen, was in der Praxis funktioniert und was nicht. Dokumentieren Sie beides.

Datenschutzcheckliste für den Prototyp:

Lerntext-Vertiefung — Prototyping-Methodik und Systemdesign

Der Prototyp als Kommunikationsmittel: Ein KI-Prototyp hat im Kontext der Projektarbeit zwei Funktionen: Er dient als technischer Machbarkeitsnachweis und als Kommunikationsmittel gegenüber der Prüfungskommission. Als Kommunikationsmittel muss der Prototyp klar demonstrieren, wie er funktioniert, was er kann und was er nicht kann. Eine Demo, die in drei Testfällen scheitert, weil die Eingaben nicht dem Erwartungsformat entsprechen, überzeugt die Kommission weniger als ein Prototyp, der in fünf gut vorbereiteten Szenarien konsistent funktioniert.

Testfall-Design für aussagekräftige Prototyp-Tests: Ein Testfall-Set für einen KI-Prototyp sollte drei Kategorien abdecken: (a) Standardfälle — Eingaben, die dem häufigsten Anwendungsfall entsprechen. Diese sollten zuverlässig korrekt verarbeitet werden. (b) Grenzfälle — Eingaben, die an den Rändern des Use-Case-Spektrums liegen. Hier zeigt sich, wie robust der Prototyp ist. (c) Fehlerfälle — Eingaben, die bewusst außerhalb des Use-Case-Bereichs liegen oder fehlerhafte Daten enthalten. Hier zeigt sich, wie der Prototyp scheitert — idealerweise kontrolliert und mit erkennbarer Fehlermeldung.

Custom GPT konfigurieren — Schritt für Schritt: Schritt 1: Navigieren Sie zu ChatGPT → “Meine GPTs” → “Neuen GPT erstellen.” Schritt 2: Wählen Sie “Konfigurieren” und geben Sie die Systemprompt-Architektur in das Feld “Anweisungen” ein. Schritt 3: Laden Sie relevante Dokumente als Wissensbasis hoch (falls RAG-Ansatz gewählt). Schritt 4: Definieren Sie den GPT-Namen und ein kurzes Beschreibung für den späteren Zugang. Schritt 5: Testen Sie im “Vorschau”-Fenster mit mindestens fünf verschiedenen Eingaben. Schritt 6: Iterieren — überarbeiten Sie die Systemanweisungen basierend auf den Testergebnissen.

Alternativer Prototyp-Weg: Direktanfragen als PoC: Wenn keine vollständige Tool-Implementierung möglich ist, ist ein PoC-Ansatz legitim: Definieren Sie einen vollständigen Systemprompt, testen Sie ihn manuell in ChatGPT/Copilot/Claude, und dokumentieren Sie die Ergebnisse strukturiert. Dieser Ansatz demonstriert dasselbe Konzept wie ein vollständig eingerichteter Custom GPT — er hat jedoch keine automatisierte Schnittstelle und ist nicht direkt in bestehende Prozesse integriert. In der Bewertung erhält ein PoC-Ansatz volle Punktzahl für Konzept und Dokumentation, aber typischerweise weniger für “Reife des technischen Ansatzes.”

Merksatz

Fünf gut dokumentierte Testfälle mit ehrlicher Fehleranalyse überzeugen mehr als zwanzig flüchtig dokumentierte Testfälle mit beschönigten Ergebnissen. Qualität der Evaluation schlägt Quantität.

n8n-Prototyp: Grundstruktur eines Automatisierungs-Workflows: Ein typischer n8n-Workflow für einen KI-Use-Case folgt dieser Grundstruktur: Trigger (z. B. neues E-Mail-Eingang, Formular-Einreichung, Zeitplan) → Datenextraktion (relevante Felder aus Trigger-Daten) → KI-Verarbeitung (HTTP-Anfrage an LLM-API mit strukturiertem Prompt) → Ausgabe-Verarbeitung (Parsen der API-Antwort, Formatierung) → Ziel-Aktion (Datenbank-Eintrag, E-Mail-Versand, Dokument-Erstellung). Jeder dieser Schritte ist ein n8n-Node. Die Kette der Nodes definiert den Workflow. Für Prüfungszwecke genügt eine schematische Darstellung dieser Kette mit Erklärung der Funktion jedes Nodes.

Praxis-Handlungsfeld — Systemprompt-Iteration in der Praxis

Warum der erste Systemprompt selten der beste ist: Erfahrene KI-Praktiker beginnen mit einem einfachen Systemprompt und iterieren — typischerweise drei bis sieben Mal bis zur “production-ready”-Version. Jede Iteration verbessert Präzision, Konsistenz oder Robustheit. Die häufigsten Iterations-Schritte: Iteration 1 — Grundfunktion testen. Iteration 2 — Ausgabeformat präzisieren. Iteration 3 — Edge-Cases abfangen (Fehlerbehandlung). Iteration 4 — Few-Shot-Beispiele hinzufügen. Iteration 5 — Datenschutz-Einschränkungen ergänzen.

Dokumentation der Iteration als Prüfungsleistung: Für die Projektarbeit ist ein kompaktes Iterations-Log wertvoll: Was wurde in welcher Iteration geändert? Warum? Welches Testergebnis hat die Änderung motiviert? Drei bis vier Iterationen mit je einem Satz Erklärung genügen. Dieses Log zeigt methodisches Vorgehen und ist deutlich überzeugender als “Ich habe den Prompt mehrfach angepasst.”

Prompt-Beispiel

Prompt: Prototyp-Systemprompt für Dokumenten-Klassifikation

Persona: Du bist ein präziser Dokumenten-Klassifikations-Assistent für ein Verwaltungsteam. Aufgabe: Klassifiziere das folgende Dokument in genau eine der folgenden Kategorien: Antrag | Beschwerde | Anfrage | Bericht | Sonstiges. Gib immer genau eine Kategorie aus. Kontext: Das Dokument stammt aus dem Posteingang eines Verwaltungsamts. Dokumente können in Deutsch oder Englisch vorliegen. Format: Antwort im Format: Kategorie: [Kategorie]. Begruendung: [max. 2 Saetze]. Einschraenkung: Wenn kein Dokument-Text vorliegt, antworte mit: Kein Dokument erkannt. Beispiel Gut: Eingabe: “Ich beantrage die Ausstellung eines Fischereischeins.” -> Kategorie: Antrag. Begruendung: Explizite Antrag-Formulierung vorhanden.

Validierung des Prototyps durch Dritte: Ein besonders wertvoller Test: Geben Sie den Prototyp einer Person, die nicht in die Entwicklung involviert war, mit drei bis fünf Eingabe-Szenarien. Ohne Einführung. Beobachten Sie: Kommt das erwartete Ergebnis? Versteht die Person, was der Prototyp macht? Dieses “Naive User Test” deckt häufig Lücken in der Persona-Definition oder im Ausgabeformat auf, die intern nicht sichtbar waren.

Abschluss-Betrachtung — Prototyping als iterativer Lernprozess

Die Entwicklung eines KI-Prototyps ist kein linearer Prozess — sie ist ein Lernzyklus. Jeder Test zeigt, was funktioniert und was nicht. Jede Iteration verbessert die Qualität. Am Ende steht kein perfektes System, sondern ein System, das den definierten Use-Case mit ausreichender Zuverlässigkeit löst und dessen Grenzen transparent dokumentiert sind. Diese Transparenz ist das Zeichen professioneller Arbeit — nicht das Verschweigen von Grenzen, sondern deren klare Benennung.

Der Prototyp aus UE 111 ist nicht das Ende — er ist die Grundlage für die Auswertung in UE 112 und die Präsentation in UE 119. Wer in UE 111 sorgfältig arbeitet, macht die nachfolgenden UEs deutlich einfacher.

Vertiefung II — Datenqualität als strategische Voraussetzung

Die Entwicklung eines KI-gestützten Prüfprozesses scheitert in der Praxis häufiger an mangelhafter Datenqualität als an algorithmischen Schwächen. Dieser Abschnitt vertieft, warum Datenqualität nicht als technisches Detail, sondern als strategische Entscheidung behandelt werden muss.

Dimensionen der Datenqualität

Datenqualität ist kein eindimensionales Konzept. In der Fachliteratur werden typischerweise sechs Dimensionen unterschieden, die für KI-Projekte alle relevant sind:

Vollständigkeit: Sind alle erwarteten Datensätze vorhanden? Fehlende Werte (Missing Values) sind die häufigste Qualitätsdimension, die beim Prototyping Probleme verursacht. Unterscheiden Sie systematische Lücken (z. B. bestimmte Abteilungen liefern keine Daten) von zufälligen Lücken (einzelne Felder wurden vergessen).

Korrektheit: Entsprechen die Werte der Realität? Falsche Buchungen, Tippfehler oder Systemfehler erzeugen inkorrekte Daten. Interessant ist hier die Unterscheidung zwischen technisch korrekten Daten (das Feld ist befüllt) und sachlich korrekten Daten (der Wert bildet die Realität ab).

Konsistenz: Sind gleiche Sachverhalte einheitlich kodiert? Ein klassisches Beispiel ist die Benennung von Produktkategorien: „Milchprodukte”, „Molkerei”, „dairy” können in verschiedenen Systemen denselben Sachverhalt bezeichnen. Inkonsistenz zwingt KI-Modelle dazu, Muster zu lernen, die sachlich identisch sind, aber technisch unterschiedlich erscheinen.

Aktualität: Sind die Daten zum Zeitpunkt der Analyse noch gültig? Historische Daten aus 2019 spiegeln möglicherweise Marktbedingungen wider, die heute nicht mehr existieren. Bei schnelllebigen Branchen ist Aktualität oft kritischer als Vollständigkeit.

Eindeutigkeit: Existieren Duplikate? Doppelte Einträge führen zu verzerrten Analysen — ein Kunde, der zweimal gezählt wird, überschätzt seinen tatsächlichen Umsatzbeitrag.

Relevanz: Sind die verfügbaren Daten überhaupt die richtigen für die gestellte Frage? Diese Dimension wird am häufigsten übersehen. Organisationen verfügen oft über große Datenmengen, die jedoch die eigentliche Fragestellung nicht beantworten.

Merksatz

Datenqualität ist nicht binär (gut/schlecht), sondern mehrdimensional. Ein Datensatz kann vollständig und konsistent, aber irrelevant für die gestellte Frage sein. Prüfen Sie alle sechs Dimensionen, bevor Sie mit dem Prototyping beginnen.

Das Datenqualitäts-Audit als Projektvorbereitung

Vor dem Start eines KI-Projekts empfiehlt sich ein strukturiertes Datenqualitäts-Audit. Es umfasst vier Schritte:

Schritt 1 — Dateninventur: Welche Datenquellen existieren? Wer ist verantwortlich (Data Owner)? In welchem Format liegen die Daten vor? Wie groß ist der Datensatz? Diese Fragen lassen sich in einer einfachen Tabelle dokumentieren.

Schritt 2 — Stichprobenanalyse: Ziehen Sie eine repräsentative Stichprobe (typischerweise 5–10 % des Gesamtdatensatzes) und analysieren Sie die sechs Qualitätsdimensionen manuell. Automatisierte Tools können helfen, sind aber kein Ersatz für die fachliche Beurteilung.

Schritt 3 — Problematisierung: Welche Qualitätsmängel sind kritisch (blockieren den Use Case), welche sind akzeptabel (können durch Modelldesign kompensiert werden)? Diese Priorisierung erfordert fachliches Urteilsvermögen — sie ist nicht algorithmisch lösbar.

Schritt 4 — Bereinigungsplanung: Für kritische Mängel: Wie werden sie behoben? Wer ist zuständig? Wie lange dauert es? Diese Information fließt direkt in das Projektcontrolling ein.

Datenqualität und Bias

Ein besonderer Aspekt der Datenqualität, der für KI-Systeme zentrale Bedeutung hat, ist der Zusammenhang mit algorithmischem Bias. Bias entsteht, wenn die Trainingsdaten systematisch verzerrt sind — und diese Verzerrung überträgt sich auf die Vorhersagen des Modells.

Klassische Bias-Quellen sind historische Entscheidungen (wenn ein Modell mit Daten trainiert wird, die aus einer Zeit stammen, in der bestimmte Gruppen systematisch benachteiligt wurden), Erhebungsartefakte (bestimmte Bevölkerungsgruppen sind im Datensatz unterrepräsentiert) und Messartefakte (die verwendete Messmethode bevorzugt bestimmte Ergebnisse).

Für die Projektarbeit ist die Botschaft klar: Eine gründliche Datenqualitätsanalyse umfasst immer auch eine kritische Reflexion über mögliche Bias-Quellen. Dies ist nicht nur eine technische, sondern auch eine ethische Anforderung.

Merksatz

Daten spiegeln die Vergangenheit wider — mit allen Ungleichheiten, die darin enthalten waren. KI-Modelle, die aus solchen Daten lernen, reproduzieren diese Ungleichheiten, wenn keine Gegenmaßnahmen ergriffen werden. Datenqualität und Fairness sind untrennbar verbunden.

Transferimpuls — Datenqualität im eigenen Projekt

Nehmen Sie das Datenqualitäts-Framework aus diesem Abschnitt und wenden Sie es auf den Datensatz Ihrer eigenen Projektarbeit an. Erstellen Sie eine kurze Übersichtstabelle mit den sechs Qualitätsdimensionen und bewerten Sie Ihren Datensatz auf einer einfachen Skala (hoch/mittel/niedrig). Identifizieren Sie den kritischsten Mangel und formulieren Sie eine konkrete Maßnahme zur Behebung oder Kompensation.

Diese Übung dauert typischerweise 20–30 Minuten und schärft den analytischen Blick für die eigene Datenbasis erheblich.

Übung 3 — Datenschutz-Assessment für den Prototyp

Übung 3 — Datenschutz-Assessment für den eigenen Prototyp

Aufgabe: Führen Sie für Ihren Prototyp ein strukturiertes Datenschutz-Mini-Assessment durch und dokumentieren Sie das Ergebnis als Beitrag zu Kapitel 4 der Projektarbeit.

Material: Prototyp aus Übung 1, Datenschutz-Checkliste aus dem Lerntext

Schritt-für-Schritt: 1. Identifizieren Sie: Welche Daten fließen in Ihren Prototyp ein? (Personenbezogen / anonym / pseudonym / öffentlich) 2. Prüfen Sie: Werden Daten an eine externe API gesendet? Wenn ja — liegt ein AVV nach DSGVO Art. 28 vor? 3. Bestimmen Sie: In welches DSGVO-Risikoprofil fällt Ihr Prototyp? (Kein Personenbezug → minimal; einfacher Personenbezug → Prüfung Art. 6; besondere Kategorien Art. 9 → höchste Sorgfalt) 4. Formulieren Sie für jeden der folgenden drei Punkte einen kurzen Satz: (a) Welche Daten werden verarbeitet? (b) Auf welcher Rechtsgrundlage? (c) Welche Schutzmaßnahmen gelten? 5. Prüfen Sie: Ist eine DSFA nach Art. 35 DSGVO erforderlich? (Hochrisiko-KI oder umfangreiche Verarbeitung besonderer Kategorien) 6. Dokumentieren Sie das Ergebnis als kompakten Abschnitt (max. eine halbe Seite) für Kapitel 4 der Projektarbeit.

Erwartetes Ergebnis: Ein vollständiges Datenschutz-Mini-Assessment als direkt verwendbaren Kapitel-4-Beitrag.

Musterlösung (Angebots-Assistent):

Verarbeitete Daten: Anonymisierte Projektbeschreibungen (keine Personendaten, keine Preiskalkulationen). Externe API: ChatGPT Team-Account mit AVV (bestätigt durch IT). Rechtsgrundlage: Berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO — Optimierung interner Geschäftsprozesse; kein Personenbezug im engeren Sinne. Schutzmaßnahmen: Keine Kundennamen, keine vertraglichen Details in Prompts; Testablauf mit synthetischen Projektbeschreibungen dokumentiert. DSFA-Erfordernis: Nein — kein Hochrisiko-System nach AI Act, kein Personenbezug in den Eingabedaten.

Vertiefung — Prototyp-Reifegradmodell: Von PoC zu Production

Ein Prototyp in der Projektarbeit ist eine erste Stufe in einem mehrstufigen Entwicklungsprozess. Das Reifegradmodell hilft zu verstehen, was nach dem Kurs kommt — und macht die Evaluation realistischer.

Stufe 0 — Idee / Konzeptbeschreibung: Vollständige Beschreibung des Systems ohne technische Implementierung. Geeignet als Option D (Dokumentierter PoC). Wert: zeigt, dass das Konzept durchdacht ist.

Stufe 1 — Proof of Concept (PoC): Eine funktionierende Demo für einen einzigen Anwendungsfall, mit Testdaten, nicht produktiv einsetzbar. Das ist das Ziel der Projektarbeit. Wert: zeigt technische Machbarkeit.

Stufe 2 — Pilot: Ein PoC, der in einem begrenzten Produktivkontext mit echten Nutzenden getestet wird. Erfordert: AVV, Datenschutzprüfung, Nutzerzustimmung. Zeitaufwand: 4–8 Wochen. Wert: liefert echte Nutzerdaten.

Stufe 3 — Rollout: Ausweitung auf alle relevanten Nutzenden mit Schulung, Prozessanpassungen und Monitoring. Zeitaufwand: 2–6 Monate. Wert: entfaltet den wirtschaftlichen Nutzen.

Stufe 4 — Betrieb und Weiterentwicklung: Produktiver Betrieb mit regelmäßigem Monitoring, KPI-Überprüfung und Systemupdates. Zeitaufwand: fortlaufend. Wert: nachhaltiger Geschäftsnutzen.

Für die Projektarbeit ist Stufe 1 das Ziel. Stufe 2 (Pilot) sollte in der Roadmap (Kapitel 8) beschrieben werden — das zeigt strategisches Denken und wird von der Prüfungskommission positiv bewertet.

Merksatz

Der Prototyp (Stufe 1) beweist Machbarkeit. Die Roadmap (Stufe 2–4) zeigt, dass Sie über die Schnittstelle zwischen Konzept und Praxis nachgedacht haben. Beide zusammen ergeben ein vollständiges Kapitel 5 und 8.

Reflexionsfragen — Vertieft

Welchen der neun Systemprompt-Komponenten haben Sie in Ihrem Prototyp am gründlichsten ausgearbeitet — und welchen am wenigsten? Was sagt das über Ihren Use-Case?

Wenn Ihr Prototyp in sechs Monaten produktiv wäre — wer müsste in Ihrer Organisation über die Einführung entschieden haben?

Welche Datenprüfung hätten Sie vor dem Prototyping durchgeführt, wenn Sie mehr Zeit gehabt hätten?

Wie würde ein Prüfer mit Erfahrung in der Finanzbranche auf Ihren Prototyp reagieren — und was müssten Sie ihm erklären?

Was war die wertvollste Iteration Ihres Systemprompts — und was hat das Feedback auf die erste Version gezeigt?

Transferimpuls — Datenstrategien für verschiedene Reifegrade

Organisationen befinden sich auf unterschiedlichen Reifegraden der Datennutzung. Einige verfügen über vollständige Data Lakes, automatisierte Datenpipelines und dedizierte Data-Engineering-Teams. Andere sammeln Daten noch weitgehend in Excel-Tabellen und E-Mail-Anhängen. Diese Unterschiede sind nicht nur technischer, sondern auch kultureller und organisationaler Natur.

Für KI-Projekte ergibt sich daraus eine wichtige praktische Konsequenz: Der erste Schritt ist immer die ehrliche Einschätzung des Daten-Reifegrads der eigenen Organisation. Ein Use Case, der in einer datenreifen Organisation innerhalb weniger Wochen prototypisiert werden kann, erfordert in einer weniger reifen Organisation möglicherweise zunächst mehrere Monate Datenvorbereitung.

Merksatz

Die technische Komplexität eines KI-Projekts ist oft geringer als die Datenvorbereitung, die es voraussetzt. Wer den Daten-Reifegrad der Organisation überschätzt, plant realitätsfern.

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