In der traditionellen Softwareentwicklung ist Qualitätssicherung ein reifes, gut verstandenes Handwerk. Eine Funktion, die zwei Zahlen addiert, liefert für dieselben Eingaben immer dasselbe Ergebnis. Ein Test prüft: Kommt bei der Eingabe „2 plus 2“ die Ausgabe „4“ heraus? Wenn ja, ist die Funktion korrekt – heute, morgen und in einem Jahr. Software ist deterministisch: Ihr Verhalten ist von Menschen explizit in Regeln gegossen, und diese Regeln lassen sich mit Testfällen abdecken, deren Ergebnis eindeutig richtig oder falsch ist.
KI-Systeme, insbesondere solche auf Basis maschinellen Lernens, funktionieren fundamental anders. Sie werden nicht programmiert, sondern aus Daten trainiert. Ihr Verhalten ergibt sich aus statistischen Mustern in den Trainingsdaten, nicht aus einer von Menschen geschriebenen Regel. Das hat weitreichende Folgen für die Qualitätssicherung: Es gibt oft keine einzelne, eindeutig richtige Ausgabe, das System kann bei ähnlichen Eingaben unterschiedlich reagieren, und sein Verhalten lässt sich nicht vollständig durch das Lesen des Quellcodes verstehen. Qualität wird damit von einer binären Frage („richtig oder falsch?“) zu einer statistischen und mehrdimensionalen Frage („wie gut, wie zuverlässig, wie fair, unter welchen Bedingungen?“).
Nehmen wir ein KI-System, das eingehende Kundennachrichten automatisch der richtigen Abteilung zuordnet. In klassischer Software würde man Regeln definieren: „Enthält die Nachricht das Wort ‚Rechnung‘, gehe an die Buchhaltung.“ Solche Regeln sind testbar und erklärbar. Ein lernendes System hingegen entscheidet auf Grundlage von tausenden Beispielen, die es gesehen hat – und trifft auch bei Formulierungen, die es nie explizit gelernt hat, eine Entscheidung. Diese Verallgemeinerungsfähigkeit ist die große Stärke von KI, aber sie ist zugleich der Grund, warum man KI nicht mit einer Handvoll Testfälle abnehmen kann. Man muss ihr Verhalten über eine repräsentative Menge realistischer Fälle statistisch vermessen.
Hinzu kommt die Frage der Grenzfälle: Ein KI-System kann bei den häufigen, typischen Eingaben exzellent funktionieren und bei seltenen, ungewöhnlichen Eingaben – dem sogenannten „langen Schwanz“ der Verteilung – auf überraschende Weise versagen. Klassische QS würde solche Fälle vielleicht gar nicht als Testfall vorsehen, weil niemand sie explizit programmiert hat. KI-QS muss diese Grenzfälle aktiv suchen, weil sie erfahrungsgemäß die Quelle der teuersten Fehler sind.
KI-Qualitätssicherung lässt sich am besten entlang des Lebenszyklus eines KI-Systems denken. In der Entwicklungs- und Auswahlphase geht es darum, Modelle zu evaluieren und das am besten geeignete auszuwählen. In der Abnahmephase vor dem Produktivgang werden Akzeptanzkriterien geprüft: Erfüllt das System die definierten Anforderungen gut genug für den Einsatz? In der Betriebsphase schließlich wird das System überwacht, weil sich seine Qualität durch veränderte Daten und Rahmenbedingungen im Laufe der Zeit verschieben kann. Diese drei Phasen entsprechen grob den Begriffen Testen, Evaluieren und Überwachen – und bilden das Gerüst dieses Artikels.
Wichtig ist die Erkenntnis, dass diese Phasen keine Einbahnstraße sind, sondern einen Kreislauf bilden. Erkenntnisse aus dem Betrieb fließen zurück in die Evaluierung, Auffälligkeiten führen zu neuen Testfällen, und ein nachlassendes System wird neu trainiert und erneut abgenommen. Qualitätssicherung ist damit keine Station am Ende des Projekts, sondern eine Disziplin, die den gesamten Lebenszyklus durchzieht.
Die Korrektheit ist die intuitivste Dimension: Trifft das System die richtige Antwort? Sie ist jedoch nur so aussagekräftig wie die Daten, an denen sie gemessen wird. Ein System kann auf einem bequemen Testdatensatz glänzen und in der Realität enttäuschen, wenn dieser Datensatz die tatsächlichen Einsatzbedingungen nicht abbildet. Deshalb ist Korrektheit immer im Kontext der Testdaten zu bewerten – ein Punkt, auf den Kapitel 03 näher eingeht.
Die Robustheit ergänzt die Korrektheit um die Frage der Stabilität. Ein robustes System liefert auch dann brauchbare Ergebnisse, wenn Eingaben unvollständig, verrauscht, ungewöhnlich formuliert oder leicht abweichend sind. In der Praxis zeigt sich mangelnde Robustheit oft an den Rändern: Das System funktioniert bei Standardfällen tadellos, kippt aber bei seltenen Konstellationen. Gerade weil diese Fälle im Alltag vorkommen, gehört das gezielte Testen an den Rändern – etwa mit bewusst schwierigen oder untypischen Eingaben – zum Pflichtprogramm.
Über die technische Leistung hinaus treten drei Dimensionen, die besonders sensibel sind. Fairness fragt, ob das System vergleichbare Personen vergleichbar behandelt oder ob es systematisch bestimmte Gruppen benachteiligt. Eine hohe Gesamtgenauigkeit kann eine ungleiche Fehlerverteilung verbergen: Wenn ein System für eine Teilgruppe deutlich schlechter funktioniert als für eine andere, ist der Durchschnittswert trügerisch. Fairness lässt sich deshalb nur durch eine nach Teilgruppen aufgeschlüsselte Analyse beurteilen – nicht durch eine einzige Kennzahl.
Die Sicherheit betrifft die Widerstandsfähigkeit gegen gezielte Angriffe und Manipulationen sowie die Frage, ob das System schädliche oder unerwünschte Ausgaben produzieren kann. Bei generativen Systemen gehört dazu insbesondere die Frage, ob sich Schutzmechanismen umgehen lassen. Hierfür hat sich das Red Teaming etabliert – das bewusste, methodische Angreifen des Systems durch ein internes oder externes Team. Der Datenschutz schließlich prüft, ob das System personenbezogene Daten schützt: Gibt es keine Trainingsdaten preis, lässt es keine unzulässigen Rückschlüsse auf einzelne Personen zu und hält es die Grundsätze der Datenminimierung ein? Diese Dimension verzahnt sich eng mit der DSGVO, auf die Kapitel 09 eingeht.
Der Kerngedanke jeder KI-Evaluierung ist einfach: Man legt dem System eine Menge von Eingaben vor, für die man die gewünschte Ausgabe kennt, und vergleicht die tatsächlichen mit den erwarteten Ergebnissen. Entscheidend ist die strikte Trennung zwischen den Daten, mit denen ein Modell trainiert wurde, und den Daten, an denen es getestet wird. Wird ein System an denselben Beispielen geprüft, die es beim Training gesehen hat, misst man nur sein Auswendiglernen, nicht seine Fähigkeit, auf Neues zu verallgemeinern. Diese Trennung von Trainings-, Validierungs- und Testdaten ist die wichtigste methodische Grundregel – ihre Verletzung ist einer der klassischen Anfängerfehler.
Benchmarks sind standardisierte Datensätze und Aufgaben, an denen sich verschiedene Modelle unter gleichen Bedingungen vergleichen lassen. Sie sind nützlich für eine grobe Orientierung, insbesondere bei der Modellauswahl: Welches Modell schneidet auf einer definierten Aufgabe besser ab? Ihr großer Vorteil ist die Vergleichbarkeit, ihr großer Nachteil die begrenzte Übertragbarkeit. Ein Modell, das auf einem allgemeinen Benchmark hervorragend abschneidet, muss für den spezifischen Anwendungsfall eines Unternehmens nicht das beste sein – der Benchmark misst eine allgemeine Aufgabe, nicht Ihre konkrete.
Hinzu kommt ein zunehmend relevantes Problem: Sind Benchmark-Daten öffentlich verfügbar, können sie – bewusst oder unbewusst – in die Trainingsdaten großer Modelle gelangen. Das verfälscht die Ergebnisse, weil das Modell die Testfragen faktisch schon kennt. Man spricht von „Datenkontamination“. Aus diesem Grund sind öffentliche Benchmarks für die Auswahl hilfreich, ersetzen aber niemals eine eigene, anwendungsspezifische Evaluierung mit eigenen Daten.
Der wertvollste Baustein einer unternehmensspezifischen KI-QS ist ein sorgfältig kuratierter eigener Testdatensatz – oft als Golden Set oder Referenzdatensatz bezeichnet. Es handelt sich um eine Sammlung realistischer Eingaben aus dem tatsächlichen Anwendungsfall, für die eine korrekte, von fachkundigen Menschen geprüfte Referenzantwort hinterlegt ist. Ein Golden Set ist gewissermaßen die „Wahrheit“, an der sich jede Version des Systems messen lassen muss.
Ein gutes Golden Set zeichnet sich durch mehrere Eigenschaften aus. Es ist repräsentativ, bildet also die reale Verteilung der Eingaben ab, statt nur die einfachen Fälle. Es enthält bewusst schwierige Fälle und Grenzfälle, weil dort die interessanten Unterschiede liegen. Es deckt relevante Teilgruppen ab, damit sich Fairness beurteilen lässt. Und es ist stabil und versioniert, sodass Ergebnisse verschiedener Modellversionen über die Zeit vergleichbar bleiben. Der Aufbau eines solchen Sets ist Arbeit – aber es ist die Investition mit dem höchsten Hebel, weil sich jede künftige Änderung am System daran objektiv bewerten lässt.
Bei einem klassifizierenden System lässt sich Korrektheit klar bestimmen: Die Zuordnung stimmt oder sie stimmt nicht. Bei generativer KI existiert dieser eindeutige Maßstab meist nicht. Eine gute Zusammenfassung, eine hilfreiche Antwort, ein passender Textentwurf – all das kann in vielen unterschiedlichen, gleichwertigen Formen vorliegen. Zugleich können generative Systeme Halluzinationen produzieren: plausibel klingende, aber sachlich falsche oder erfundene Aussagen. Diese zu erkennen, ist eine Kernaufgabe der Evaluierung generativer KI und lässt sich nicht durch einfaches Abgleichen mit einer Musterlösung erledigen.
Die verlässlichste Methode, die Qualität generativer Ausgaben zu beurteilen, ist die menschliche Bewertung durch fachkundige Personen. Menschen können beurteilen, ob eine Antwort sachlich korrekt, hilfreich, verständlich, im richtigen Ton gehalten und frei von problematischen Inhalten ist. Damit diese Bewertung nicht beliebig wird, braucht sie Struktur: klare Bewertungskriterien, eine einheitliche Skala und Anleitungen, wie mit Grenzfällen umzugehen ist. Bewährt haben sich unter anderem der direkte Vergleich zweier Ausgaben („welche ist besser?“) sowie die kriterienbasierte Bewertung anhand einer definierten Rubrik.
Menschliche Bewertung ist gründlich, aber aufwendig und langsam. Sie eignet sich hervorragend für die sorgfältige Abnahme, für die regelmäßige Stichprobe und für die Kalibrierung anderer Methoden. Für die kontinuierliche Prüfung großer Mengen ist sie allein jedoch oft zu teuer. Genau hier setzt eine ergänzende Methode an, die in den letzten Jahren an Bedeutung gewonnen hat.
Beim Ansatz LLM-as-Judge wird ein leistungsfähiges Sprachmodell selbst als Bewertungsinstanz eingesetzt: Es beurteilt die Ausgabe eines anderen Systems anhand vorgegebener Kriterien. Der Charme dieser Methode liegt in ihrer Skalierbarkeit – ein Modell kann sehr viele Ausgaben in kurzer Zeit bewerten, was für eine kontinuierliche Qualitätsmessung praktisch ist. Die Methode eignet sich besonders, um große Mengen automatisiert vorzufiltern und Auffälligkeiten sichtbar zu machen.
Zugleich ist Vorsicht geboten: Ein bewertendes Modell hat eigene Schwächen und Verzerrungen. Es kann längere Antworten bevorzugen, sich von selbstbewusstem Ton täuschen lassen oder eigene Fehleinschätzungen einbringen. LLM-as-Judge ist deshalb kein Ersatz für menschliches Urteil, sondern eine Ergänzung. In der Praxis bewährt sich ein zweistufiges Vorgehen: Das Modell übernimmt die breite, kontinuierliche Vorbewertung, während Menschen die Kriterien definieren, das bewertende Modell an einem von Menschen geprüften Maßstab kalibrieren und kritische Fälle final beurteilen. Die menschliche Bewertung bleibt der Maßstab, an dem sich die automatisierte Bewertung messen lassen muss.
Die naheliegendste Metrik ist die Genauigkeit: der Anteil der richtigen Ergebnisse an allen Ergebnissen. Sie ist intuitiv, aber tückisch – besonders bei ungleich verteilten Fällen. Ein Beispiel: Wenn nur ein kleiner Bruchteil aller Vorgänge tatsächlich kritisch ist, erreicht ein System, das schlicht alles als „unkritisch“ einstuft, bereits eine hohe Genauigkeit – und ist dennoch völlig nutzlos, weil es keinen einzigen kritischen Fall erkennt. Dieses Phänomen zeigt, warum die Genauigkeit allein oft in die Irre führt und durch differenziertere Kennzahlen ergänzt werden muss.
Zwei Kennzahlen sind für die Praxis besonders wichtig. Die Präzision beantwortet die Frage: Wenn das System einen Fall als kritisch meldet, wie oft liegt es damit richtig? Sie misst die Verlässlichkeit der Meldungen. Die Trefferquote (auch Sensitivität) beantwortet die Frage: Von allen tatsächlich kritischen Fällen, wie viele hat das System gefunden? Sie misst die Vollständigkeit. Beide stehen in einem Spannungsverhältnis: Wer die Schwelle so setzt, dass möglichst kein kritischer Fall übersehen wird, produziert mehr Fehlalarme – und umgekehrt.
Welche der beiden wichtiger ist, hängt vom Anwendungsfall ab. Bei einer Vorprüfung sicherheitsrelevanter Vorgänge wiegt ein übersehener Fall oft schwerer als ein Fehlalarm, sodass die Trefferquote Vorrang hat. Bei einer automatischen Aktion ohne menschliche Nachkontrolle kann die Präzision entscheidender sein. Diese Abwägung ist keine technische, sondern eine fachliche und geschäftliche Entscheidung – sie gehört in die Hände der Verantwortlichen im Fachbereich, nicht allein in die der Technik.
Der vielleicht wichtigste, aber am häufigsten übersprungene Schritt der KI-QS ist die Definition von Akzeptanzkriterien vor dem Test. Ein Akzeptanzkriterium legt fest, welches Qualitätsniveau ein System erreichen muss, um für den Einsatz freigegeben zu werden – und zwar bevor man die Ergebnisse kennt. Ohne vorab definierte Kriterien besteht die Gefahr, das Ergebnis im Nachhinein schönzureden: Ein Wert, der eigentlich enttäuschend ist, wird plötzlich als „ausreichend“ interpretiert, weil das System ja bereits gebaut wurde.
Gute Akzeptanzkriterien sind mehrdimensional und an das Risiko angepasst. Sie legen nicht nur eine Mindestgenauigkeit fest, sondern auch Anforderungen an die Fehlerverteilung über Teilgruppen (Fairness), an das Verhalten in Grenzfällen (Robustheit) und an die maximale Rate bestimmter kritischer Fehler. Bei einem risikoreichen Anwendungsfall liegen die Schwellen höher und der menschliche Kontrollanteil größer als bei einem unkritischen. Entscheidend ist, dass diese Kriterien schriftlich fixiert, mit dem Fachbereich abgestimmt und im Rahmen der Abnahme dokumentiert werden – sie sind der Maßstab, an dem die Freigabeentscheidung nachvollziehbar wird.
Das zentrale Phänomen heißt Drift. Ein KI-System hat aus historischen Daten gelernt und funktioniert am besten, solange die aktuelle Realität diesen Daten ähnelt. Ändern sich jedoch die Eingabedaten (etwa weil sich Kundenverhalten, Sprache, Märkte oder Rahmenbedingungen wandeln), passt das gelernte Muster immer schlechter. Man unterscheidet grob zwei Formen: Bei der Datendrift verändert sich die Verteilung der Eingaben, bei der Konzeptdrift verändert sich der Zusammenhang zwischen Eingabe und richtiger Antwort selbst. In beiden Fällen sinkt die Qualität schleichend – oft unbemerkt, weil das System weiterhin plausibel wirkende Ausgaben produziert.
Ein wirksames Monitoring beobachtet mehrere Ebenen zugleich. Auf der Eingabeebene wird geprüft, ob sich die Verteilung der eingehenden Daten gegenüber den Trainings- und Testdaten verschiebt – ein Frühindikator für Datendrift, der oft auffällt, bevor sich die Qualität sichtbar verschlechtert. Auf der Ausgabeebene werden die Ergebnisse des Systems beobachtet: Verschiebt sich die Verteilung der Vorhersagen, häufen sich unsichere Entscheidungen oder ungewöhnliche Ausgaben? Auf der Ergebnisebene schließlich wird, wo immer möglich, die tatsächliche Qualität gemessen, indem die Ausgaben des Systems mit später bekannt werdenden echten Ergebnissen abgeglichen werden.
Ergänzend gehören zum Monitoring auch technische und betriebliche Kennzahlen wie Antwortzeiten, Auslastung und Fehlerraten sowie – gerade bei generativer KI – eine kontinuierliche Stichprobenprüfung der Ausgabequalität. Wichtig ist, dass Auffälligkeiten nicht nur erfasst, sondern mit klaren Schwellenwerten und Alarmen versehen werden, die eine Reaktion auslösen. Ein Dashboard, das niemand ansieht, schützt vor nichts.
Der wertvollste Rohstoff für die laufende Qualitätssicherung entsteht im Betrieb selbst. Feedback-Loops sammeln systematisch Rückmeldungen darüber, wie gut die Ausgaben des Systems tatsächlich waren – etwa durch Korrekturen von Mitarbeitenden, durch explizite Bewertungen von Nutzerinnen und Nutzern oder durch den späteren Abgleich mit dem realen Ausgang eines Vorgangs. Diese Rückmeldungen sind Gold wert: Sie zeigen, wo das System schwächelt, sie liefern neue, realistische Beispiele für das Golden Set, und sie bilden die Grundlage für ein späteres Nachtrainieren.
Damit schließt sich der Kreis zum Lebenszyklus aus Kapitel 01: Erkenntnisse aus dem Monitoring fließen in eine erneute Evaluierung, führen bei nachlassender Qualität zu einem aktualisierten Modell und durchlaufen dann wieder die Abnahme mit ihren Akzeptanzkriterien. Ein sauber aufgesetzter Feedback-Loop verwandelt die Qualitätssicherung von einer einmaligen Prüfung in einen lernenden, sich selbst verbessernden Prozess – vorausgesetzt, die Rückmeldungen werden datenschutzkonform erhoben und verarbeitet.
Wer KI-Qualitätssicherung ernst nimmt, erfüllt damit zugleich einen erheblichen Teil dessen, was Regulierung und Normen fordern. Das ist eine gute Nachricht: QS ist keine zusätzliche Bürokratie neben der Compliance, sondern in weiten Teilen deren praktischer Kern. Umgekehrt liefern die Rahmenwerke eine hilfreiche Struktur dafür, welche Aspekte eine belastbare QS abdecken sollte.
Für Hochrisiko-KI-Systeme verlangt der EU AI Act nach aktuellem Stand ein fortlaufendes Risikomanagement, Anforderungen an Daten und Daten-Governance, technische Dokumentation, Protokollierung, menschliche Aufsicht sowie ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit – dazu eine Beobachtung nach dem Inverkehrbringen. Übersetzt in die Sprache dieses Artikels bedeutet das: Der AI Act fordert genau jene Evaluierung entlang mehrerer Qualitätsdimensionen und jenes Monitoring im Betrieb, die den Kern der KI-QS ausmachen. Wer eine strukturierte Qualitätssicherung betreibt, legt damit einen großen Teil des Fundaments für die Konformität – die abschließende rechtliche Bewertung im Einzelfall gehört jedoch in fachjuristische Hände.
Die ISO/IEC 42001 beschreibt, wie eine Organisation ein Managementsystem für den verantwortungsvollen Umgang mit KI aufbaut – mit Rollen, Richtlinien, Risikobetrachtung, Kontrollen und kontinuierlicher Verbesserung. Für die Qualitätssicherung liefert sie den organisatorischen Rahmen: Sie hilft, QS nicht als losen Aktivitätenhaufen, sondern als geregelten, wiederholbaren und nachweisbaren Prozess zu verankern. Das NIST AI Risk Management Framework wiederum gliedert das KI-Risikomanagement in Funktionen, von denen eine ausdrücklich das Messen von Risiken und Eigenschaften umfasst – also Evaluierung und Monitoring im hier beschriebenen Sinne. Beide Rahmenwerke sind freiwillig, ergänzen sich gut und geben der QS eine anerkannte Struktur.
Für den Mittelstand ergibt sich daraus ein pragmatischer Zugang: Man muss nicht alle Rahmenwerke gleichzeitig formal einführen. Aber es lohnt sich, die eigene QS an ihren Grundgedanken auszurichten – klare Rollen, dokumentierte Kriterien, systematisches Messen, kontinuierliche Verbesserung. So entsteht eine Qualitätssicherung, die zugleich anschlussfähig für künftige Zertifizierungen und regulatorische Nachweise ist.
Viele mittelständische Unternehmen setzen KI nicht selbst entwickelt, sondern als eingekauften Dienst ein. Das entbindet nicht von der Qualitätssicherung – im Gegenteil: Auch bei fertigen KI-Werkzeugen bleibt die Frage, ob das System für den eigenen Anwendungsfall gut genug funktioniert, fair entscheidet und im Betrieb stabil bleibt. Die QS verschiebt sich dann von der Modellentwicklung hin zur anwendungsbezogenen Evaluierung und Überwachung: Wie gut löst dieses Werkzeug meine konkrete Aufgabe, gemessen an meinen eigenen Testdaten und meinen Akzeptanzkriterien?
Qualitätssicherung braucht klare Zuständigkeiten – gerade im Mittelstand, wo Ressourcen knapp sind, darf QS nicht zwischen den Stühlen verschwinden. Bewährt hat sich eine schlanke Rollenverteilung, in der eine Person mehrere Rollen ausfüllen kann, solange die Verantwortlichkeiten klar benannt sind.
Der Markt bietet zahlreiche Kategorien von Werkzeugen: Bibliotheken zur Berechnung von Metriken, Frameworks für automatisierte Evaluierung und LLM-as-Judge, Werkzeuge zur Fairness- und Bias-Analyse, Plattformen für das Monitoring von Datendrift und Modellleistung im Betrieb sowie Lösungen für das Red Teaming und Sicherheitstests. Viele davon sind quelloffen und herstellerneutral einsetzbar. Bei der Auswahl gilt der gleiche Grundsatz wie bei jedem Werkzeug: Es sollte zum Anwendungsfall, zur vorhandenen Infrastruktur und zu den Datenschutzanforderungen passen – nicht umgekehrt der Anwendungsfall zum Werkzeug.
So nützlich Werkzeuge sind, sie haben klare Grenzen. Erstens produzieren sie Zahlen, kein Urteil: Ein Werkzeug kann eine Metrik berechnen, aber nicht entscheiden, ob dieser Wert für den konkreten Einsatz gut genug ist – das bleibt eine fachliche Abwägung. Zweitens ist jede automatisierte Bewertung nur so gut wie ihre Kalibrierung; eine scheinbar objektive Kennzahl kann in die Irre führen, wenn die zugrunde liegende Methode verzerrt ist. Drittens können Werkzeuge blinde Flecken haben: Sie messen, wonach man sie fragt – und übersehen Probleme, an die niemand gedacht hat. Deshalb bleibt der Mensch die entscheidende Instanz, die Ergebnisse interpretiert, hinterfragt und in den Kontext stellt.
Eine besondere Grenze betrifft die generative KI: Kein Werkzeug kann derzeit garantieren, dass ein Sprachmodell niemals halluziniert oder in jedem denkbaren Fall sicher reagiert. Qualitätssicherung reduziert Risiken und macht sie messbar, sie eliminiert sie nicht vollständig. Diese Ehrlichkeit gehört zu einer seriösen KI-QS dazu – ebenso wie die Konsequenz, kritische Anwendungen mit menschlicher Aufsicht abzusichern statt sich blind auf das System zu verlassen.
Qualitätssicherung berührt den Datenschutz an mehreren Stellen, die oft übersehen werden. Sobald Testdaten, Golden Sets oder Betriebsdaten personenbezogene Daten enthalten – etwa echte Kundenanfragen, Bewerbungsunterlagen oder Kommunikationsverläufe –, gelten die Anforderungen der DSGVO: eine tragfähige Rechtsgrundlage, der Grundsatz der Datenminimierung, Zweckbindung und geeignete Schutzmaßnahmen. Auch das Sammeln von Rückmeldungen in Feedback-Loops und das Speichern von Ein- und Ausgaben für das Monitoring sind Verarbeitungen personenbezogener Daten, wenn Personenbezug besteht, und müssen entsprechend gestaltet werden.
In der Praxis bewährt sich, personenbezogene Testdaten wo möglich zu anonymisieren oder zu pseudonymisieren, nur die wirklich benötigten Daten zu verwenden und den Umgang mit ihnen im Verzeichnis der Verarbeitungstätigkeiten abzubilden. Bei risikoreichen Anwendungen kann eine Datenschutz-Folgenabschätzung angezeigt sein. Wichtig ist die Erkenntnis, dass gute QS und guter Datenschutz sich nicht widersprechen, sondern gemeinsam anzugehen sind – die Prüfung auf Datenlecks und unzulässige Rückschlüsse ist selbst eine Qualitätsdimension (siehe Kapitel 02). Wie die Anforderungen im konkreten Fall auszugestalten sind, ist datenschutzrechtlich zu bewerten; dies ist keine Rechtsberatung.
