KI im Audit, ohne Kontrollverlust: Anforderungen an eine fachspezifische Audit-Software - und warum "der Mensch im Loop" kein Lippenbekenntnis bleiben darf
1. Ausgangslage: Datenflut trifft Stichprobenpflicht
Die Digitalisierung pharmazeutischer Qualitätsmanagementsysteme hat das Volumen prüfbarer Daten in den letzten zehn Jahren vervielfacht. Wo früher ein Aktenordner mit Chargenprotokollen genügte, liegen heute hunderte SOPs, Risikoanalysen, Validierungsberichte, eBatch Record-Auszüge und Lieferantenqualifikationen vor - meist als PDF, Word, gescanntes Bild oder Excel. Auditorinnen und Auditoren stehen vor einem strukturellen Dilemma: Die regulatorische Erwartung ("systematisch, unabhängig, dokumentiert, mit hinreichend objektivem Nachweis") trifft auf eine Datenmenge, die in der vereinbarten Audit-Zeit faktisch nicht mehr qualitativ zu sichten ist.
Genau hier setzen KI-gestützte Audit-Werkzeuge an. Der GMP-Journal-Beitrag von David Abraham skizziert dafür einen Rahmen - Dokumentenprüfung, Checklistenerstellung, Nichtkonformitätserkennung, Berichterstellung - und warnt zugleich vor zwei Gefahren: dem Datenschutzrisiko offener Cloud-LLMs (Large Language Models) wie z.B. ChatGPT, Gemini, Copilot und einem "checklistenorientierten Tunnelblick", der oberflächliche Konformität mit echter Beurteilung verwechselt.
Beide Risiken sind real. Sie lassen sich jedoch durch die richtige Werkzeugarchitektur entschärfen, nicht durch Verzicht auf KI. Der folgende Beitrag formuliert dafür einen produktneutralen Anforderungskatalog: Welche Eigenschaften muss eine fachspezifische, auditfähige Software mitbringen, damit ein produktiver KI-Workflow entsteht, der die Compliance messbar erhöht und zugleich das fachliche Urteilsvermögen der Auditierenden in den Mittelpunkt stellt?
2. Vom Norm-Katalog zum individuellen Interview
Ein belastbares Audit beginnt nicht beim Modell, sondern beim richtigen Fragebogen. Eine geeignete Audit-Software sollte daher auf Standardkatalogen einschlägiger Normen und Leitfäden aufsetzen können (u. a. EU-GMP, ICH Q7/Q9/Q10, ISO 13485, ISO 9001, GDP, anwenderspezifische Lieferantenfragebögen). Aus diesen Katalogen sollte sich ein auf das konkrete Audit zugeschnittenes Interview komponieren lassen. Anforderungen an die Komposition:
- Hierarchische Struktur mit ausreichender Tiefe (z.B. Kapitel ? Unterkapitel ? Hauptfrage ? Folgefragen). Hauptfragen werden typischerweise als Ja/Teilweise/Nein-Frage geführt, Folgefragen als Freitext zur Detaillierung.
- Kritikalitätsfestlegung für jede einzelne Frage, damit im Vorfeld der Einfluss eines Themas auf das Produkt oder den Prozess des auditierten Unternehmens festgelegt werden kann - gerade bei beauftragten Audits ein wichtiger Hebel zur Steuerung von Aufwand und Tiefe.
- Modulare Komposition ganzer Kapitelbäume oder einzelner Fragen aus einem oder mehreren Regularien - etwa wenn ein Lieferantenaudit GMP-Anforderungen mit ISO-9001-Prozessanforderungen kombinieren muss.
- Wiedervorlage offener CAPAs aus vorangegangenen Audits desselben Auditees, sodass nicht abgeschlossene Maßnahmen automatisch in den nächsten Fragebogen eingebettet werden.
Seminarempfehlung
Copenhagen, Denmark25 August 2026
Raw Data - Understanding, Defining and Managing
Der entscheidende Punkt: Die KI sollte nach der Fragebogenkomposition ins Spiel kommen - nicht davor. Damit wird das von David Abraham zu Recht kritisierte Anti-Pattern "LLM würfelt Checkliste aus dem Nichts" strukturell ausgeschlossen. Der Bewertungsrahmen bleibt normgebunden, auditierbar und versionierbar.
3. Die KI-Schicht im Interview-Modus
Während der Audit-Durchführung sollte die Software ein klar abgegrenztes KI-Panel direkt am Fragebogen anbieten, das im Wesentlichen aus zwei Komponenten besteht:
1. Datei-Manager für die vom Auditee bereitgestellten Belege (Anhänge zum Audit).
2. KI-Integration für die lokale oder Cloud-basierte Inferenz.
3.1 Dual-Deployment: Lokal oder souveräne Cloud
Eine auditfähige Lösung sollte zwei sich ergänzende Betriebsmodi unterstützen:
| Modus | Endpunkt (Beispiel) | Anwendungsfall |
| Lokal | On-Prem-Runtime (z.B. Ollama unter http://localhost:11434) mit Open-Weight-Modellen wie Mistral, Gemma, Qwen oder GPT-OSS | Maximale Datenhoheit; Auditor-Notebook oder On-Prem-Server, z.B. bei sensiblen Lieferanten- oder Behörden-Audits |
| Souveräne Cloud | Serverseitiger Proxy mit Bearer-Token gegen einen vertraglich gebundenen Anbieter | Höhere Modellqualität, wenn eine belastbare Datenschutzvereinbarung mit dem Cloud-Anbieter besteht |
Beide Modi müssen pro Audit flexibel umschaltbar sein. Ein unkontrolliertes Default-Routing an offene Endkundendienste (wie die Consumer-Weboberflächen von ChatGPT oder Gemini) muss systemseitig blockiert sein. Während dies den offensichtlichen Datenabfluss verhindert, offenbart ein Blick auf die regulatorischen Details der Cloud-Nutzung jedoch tiefere Hürden.
3.2 Die datenschutzrechtliche Realität
Viele Softwareanbieter argumentieren, dass das Datenschutzrisiko gelöst sei, sobald der Cloud-Anbieter vertraglich zusichert, die übermittelten Prompts nicht zu Trainingszwecken zu verwenden. Aus datenschutzrechtlicher (DSGVO) und regulatorischer (GxP) Sicht greift dies jedoch viel zu kurz. Das Verhindern des Modelltrainings schützt lediglich das geistige Eigentum vor dem Einfließen in öffentliche Modell-Antworten - das fundamentale Datenschutzproblem auf Infrastrukturebene bleibt ungelöst:
1. Das Problem der Datenübermittlung (Art. 28 DSGVO)
Auch ohne Modelltraining werden Audit-Dokumente (die unzählige personenbezogene Daten wie Mitarbeiternamen, Unterschriften und IDs enthalten) an Drittserver übertragen, dort verarbeitet und im Rahmen des Missbrauchs-Monitorings oft bis zu 30 Tage gespeichert. Dies erfordert zwingend eine lückenlose Auftragsverarbeitungsvereinbarung (AVV) und eine vorherige Datenschutz-Folgenabschätzung (DSFA).
2. Die Geopolitik des US CLOUD Act
Werden kommerzielle Cloud-Schnittstellen von US-Anbietern genutzt (selbst wenn die Server in Europa stehen), unterliegen diese Konzerne dem US CLOUD Act. US-Behörden können damit theoretisch Zugriff auf sensible Daten erzwingen. Eine echte "Souveräne Cloud" im Audit-Kontext verlangt daher eine europäische Infrastruktur ohne US-Rechtsbezug sowie ein striktes Zero-Data-Retention-Protokoll (Löschung aller Prompts unmittelbar nach der Verarbeitung im flüchtigen RAM).
3. Das Validierungs-Dilemma (Annex 11)
Im GMP-Bereich gilt: Was nicht validiert ist, existiert nicht. Kommerzielle Cloud-Modelle verändern sich durch kontinuierliche Anbieter-Updates im Hintergrund (Model Drift). Ein reproduzierbares Audit-Ergebnis ist damit kaum zu garantieren. Für kritische GxP-Prozesse ist das lokale Deployment der einzig gangbare Weg, da nur hier das Modell "eingefroren", qualifiziert und validiert werden kann.
3.3 Aufbereitung der Belege: OCR und Textkonversion
Bevor ein LLM Belege bewerten kann, müssen sie in eine textuell verlässliche Form gebracht werden. Eine geeignete Audit-Software bringt dafür eine deterministische Vorverarbeitung mit:
- Text-Dateien (.txt, .md, .json, .csv, .xml, .html) werden direkt geladen.
- Bild-Dateien (.jpg, .png, .webp …) werden Base64-kodiert und an ein Vision-fähiges Modell übergeben.
- PDF-Dokumente werden seitenweise in Bilder zerlegt und in konfigurierbaren Batches verarbeitet, um das Kontextfenster des Modells nicht zu sprengen.
- Texte aus Word-Dokumenten (.docx) werden extrahiert.
Anschließend wird ein Bild-zu-Seite-Index aufgebaut - eine explizite Zuordnungstabelle, die dem LLM mitteilt, welche Bildnummer zu welcher Seite welchen Dokuments gehört. Dieser Index ist die Grundlage für saubere Quellenangaben (siehe Abschnitt 4) und unterscheidet eine fachspezifische Lösung deutlich von einem blanken "PDF in den Chat ziehen".
Eine spezialisierte OCR-Profilierung (z.B. temperature: 0, konstanter Seed, top_p: 1, top_k: 1, ein passend gewähltes repeat_penalty und repeat_last_n, harte Stop-Sequenzen) sorgt dafür, dass die Textextraktion möglichst deterministisch ist. Konvertierte Texte sollten als .txt neben dem Original gespeichert, in das Audit-Filesystem versioniert eingehängt und beim nächsten Aufruf wiederverwendet werden - keine Doppelverarbeitung, vollständige Nachvollziehbarkeit.
3.4 Token-Budgetierung: Kein stilles Abschneiden
Die Eingabe (Prompt) füttert die KI mit Daten. Die Verarbeitung (Inferenz) nutzt das gelernte Wissen eines KI-Modells, um die Eingabe zu analysieren und eine Ausgabe zu erzeugen.
Vor jedem Inferenzaufruf sollte die Software die Tokens des Gesamtprompts lokal zählen (z.B. mit einem dem Modell entsprechenden Tokenizer) und mit dem konfigurierten Kontextfenster (num_ctx) vergleichen. Überschreitet der Prompt das Budget, darf der Aufruf nicht durchgeführt werden; stattdessen ist der Anwender hinzuweisen. So wird das in der Praxis häufige Phänomen vermieden, dass das Modell stillschweigend nur einen Teil der Belege „gesehen” hat und gleichwohl eine plausibel klingende, aber unvollständige Antwort liefert.
4. Die zwei KI-Workflows im Audit
Sinnvoll ist eine Aufteilung der KI-Funktionalität in zwei klar getrennte, jeweils in sich validierbare Schritte. Beide sollten niemals direkt in das Interview schreiben, sondern einen Vorschlag erzeugen, der erst nach Bestätigung übernommen wird.
4.1 Workflow A — Kapitel-Abdeckung (Coverage-Analyse)
Frage an die KI: „Welche Kapitel meines Interviews werden durch die vorliegenden Dokumente inhaltlich abgedeckt — und mit welchem Prozentsatz?“
Das Modell erhält den reduzierten Interview-JSON sowie alle aufbereiteten Belege und gibt das Interview mit zwei zusätzlichen Feldern auf jeder Kapitelebene zurück:
- Coverage: Prozentwert der inhaltlichen Abdeckung, auch für Kapitel ohne eigene Fragen (aggregiert aus Unterkapiteln).
- Documents: Liste der konkreten Belege, die Fragen dieses Kapitels eindeutig beantworten.
Der Output beantwortet eine in der Vorbereitung zentrale Frage: „Wo lohnt sich eine Vertiefung im Audit-Gespräch — und wo kann ich kürzertreten, weil die Dokumentenlage eindeutig ist?“ Die Auditorin verteilt ihre knappe Audit-Zeit damit nicht mehr nach Bauchgefühl, sondern nach einer datenbasierten Heatmap.
Seminarempfehlung
Copenhagen, Denmark26-28 August 2026
Data Integrity Master Class
4.2 Workflow B — Frage-Vorbeantwortung
Frage an die KI: „Welche Hauptfragen lassen sich aus den Dokumenten eindeutig mit ja, teilweise oder nein beantworten — und welche Folgefragen sind durch konkrete Textstellen begründet?“
Das Modell befüllt:
- Optionsfeld der Hauptfrage mit einem numerischen Code, z.B. 2 = ja, 1 = teilweise, 0 = nein, -3 = zurückgestellt (= keine ausreichende Datenlage).
- Antwort der Folgefragen — verpflichtend mit einer strukturierten Quellenangabe: Quelle: [Dateiname], Seite [N], Zitat: ‘[kurzer Textauszug aus dem Dokument]’
Der Prompt sollte mindestens drei explizite Halluzinations-Gegenmaßnahmen enthalten:
1. Bild-zu-Seite-Index als Tabelle direkt vor den Audit-Fragen (Interview) — das Modell muss die korrekte Seite nachschlagen.
2. Verbot pauschaler Angaben („Schreibe nicht pauschal ‚Seite 1’ für alles”).
3. Pflicht zum wörtlichen Zitat aus dem Dokument („Zitiere den ECHTEN Text aus dem Bild, nicht erfundene Beispiele”).
Hauptfragen mit Antwort nein erfordern eine inhaltliche Begründung; Fragen ohne passende Belege werden zwingend auf zurückgestellt gesetzt — mit einem maschinenlesbaren Hinweis, was fehlt. Das ist exakt das, was David Abraham unter „angemessenen Grenzen zwischen automatisierter Unterstützung und professioneller Beurteilung” meint: Die KI darf nicht raten; sie muss explizit zugeben, wenn sie nicht entscheiden kann.
4.3 Auditor-im-Loop: Bestätigung statt Automatik
Nach jedem Workflow sollte das Ergebnis als Vorschau neben dem Original-Interview angezeigt werden. Erst auf eine bewusste Bestätigung hin wird der Vorschlag übernommen — und auch dann nicht durch Überschreiben, sondern durch einen Deep-Merge mit dem Originalkatalog: Erhalten bleiben alle bereits getätigten Annotationen, statistischen Aggregate, Tags und die Quell-Kataloghistorie. Die KI ergänzt, sie ersetzt nicht.
Das ist die technische Umsetzung des Grundsatzes, den David Abraham in Abschnitt 4 seines Beitrags betont: Der Einsatz von KI im Audit sollte stets durch das fachliche Urteilsvermögen der Auditierenden ausgeglichen werden. In der Praxis bedeutet das, dass die KI-Antwort niemals das Audit-Ergebnis ist, sondern dessen Vorbereitung — verifiziert, gegengezeichnet und bei Bedarf korrigiert.
5. Audit-Kontext als Prompt-Bestandteil
Ein häufig unterschätzter Hebel für die Antwortqualität ist die Kontextualisierung des Audits selbst. Strukturierte Audit-Metadaten sollten bei jedem Aufruf an das Modell gereicht werden, etwa:
**Audit-Kontext:**
- Audit: Lieferantenqualifikation Primärpackmittel 2026-Q2
- Auditee: Beispiel GmbH, Werk Süd
- Location: 70xxx Stuttgart, DE
- Program: GMP / ICH Q7
Dieser Kontext beeinflusst die Bewertung der Belege messbar — z.B. wird ein Reinraum-Monitoring-Bericht im Kontext „Primärpackmittel” anders bewertet als im Kontext „Wirkstoffherstellung Klasse A”. Damit wird ein risikobasierter Bewertungsmaßstab erzwungen, anstatt das Modell „im luftleeren Raum” antworten zu lassen.
6. Vom Befund zum Bericht: Automatisierte Reportgenerierung
Nach Abschluss der Audit-Begehung sollte das fertige Interview zusammen mit den Reportparametern (Audit-Atmosphäre, Auditort, Auditziel, Klassifikation des Audit-Ergebnisses, Begründung bei abweichender Klassifikation, Anhänge) an eine serverseitige Berichtsfunktion übergeben werden.
Das Ergebnis ist ein vollständig formatiertes AuditReport.docx (optional zusätzlich .pdf), inklusive:
- Deckblatt und Audit-Metadaten in der gewählten Sprache,
- Kapitelbaum mit Bewertung je Hauptfrage,
- Folgefragen mit Antwortdetails und maschinenverifizierten Quellenangaben aus der Frage-Vorbeantwortung,
- automatisch erzeugter CAPA-Liste,
- Atmosphärenbewertung und Begründung bei Re-Klassifikation des Gesamtergebnisses.
Derselbe Mechanismus kann eine Audit-Agenda im Vorfeld erzeugen. Berichte lassen sich damit am Tag der Audit-Durchführung in durchgehend belegbarer Qualität ausliefern — was die im GMP-Journal-Beitrag skizzierte „Berichterstattung und Follow-Up”-Phase verkürzt. Das eigentliche Follow-Up bleibt natürlich abhängig vom Umfang der Findings und ihrer Abarbeitung.
7. Wie eine fachspezifische Lösung die im GMP-Journal genannten Risiken adressiert
| Risiko | Architektonische Antwort |
| Datenschutzverletzungen durch öffentliche LLMs | Lokale Inferenz (On-Premises) als sicherster Standard. Bei Cloud-Nutzung: Ausschließliche Verwendung europäischer Cloud-Proxies mit striktem Zero-Data-Retention-Protokoll (kein Caching, kein Logging) |
| Weitergabe sensibler Informationen | Belege verlassen die Audit-Workspace nur, wenn der gewählte Modus dies erlaubt; Konvertierungsergebnisse werden im Audit-Filesystem persistiert, nicht beim Modellanbieter. |
| Verzerrte oder falsche Ergebnisse | Strikte Quellenpflicht im Prompt (Datei + Seite + wörtliches Zitat); Bild-zu-Seite-Index gegen pauschale Angaben; Halluzinationsverbot durch Stop-Sequenzen und niedrige Temperatur in OCR-Pfaden; lokale Token-Zählung gegen stilles Abschneiden. |
| IP-Probleme | Norm-Kataloge sind lizenziert und versioniert in der Anwendung integriert; das Modell erhält nicht den ganzen Katalog als „Trainingsfutter”, sondern eine reduzierte JSON-Sicht des aktuellen Interviews. |
| Sicherheitslücken | Webanwendungen sollten als PWA mit Service-Worker, CSP-fähig und ohne API-Keys im Client-Bundle ausgeliefert werden (Cloud-Schlüssel werden über lokalen Proxy oder lokal verschlüsselt gehalten). |
| Checklisten-Tunnelblick | Zwei-Phasen-Workflow: Erst die Coverage-Karte sichtbar machen (also wissen, wo es dünn ist), dann erst die Vorbeantwortung anwenden. KI-Antworten dürfen nie automatisch übernommen werden; Vorschläge müssen manuell bestätigt werden; Original-Interview-Felder bleiben durch Deep-Merge erhalten. |
| Verwischung der Grenze KI <-> professionelle Beurteilung | Eindeutige Antwort-Optionscodes (inkl. zurückgestellt) zwingen das Modell, Wissenslücken explizit zu deklarieren statt zu plausibilisieren. |
| Mangelnde Validierbarkeit (Annex 11) | Ausschluss von unkontrolliert driftenden Consumer-APIs. Bevorzugung lokaler, „eingefrorener“ Open-Weight-Modelle, die eine reproduzierbare Softwarequalifizierung erlauben. Ein Cloud-Hosting ist im GMP-Umfeld nur dann zulässig, wenn es sich um eine dedizierte Private-Cloud-Instanz (z. B. Azure OpenAI Enterprise) handelt, die ein Zero-Data-Retention-Protokoll garantiert und bei der das Modell über eine spezifische Versionsnummer (Pinned Model Version) dauerhaft eingefroren wird, um den Anforderungen der Softwarevalidierung nach Annex 11 gerecht zu werden. |
8. Was KI im Audit nicht ersetzt
Es wäre fahrlässig, KI als „Audit-Autopiloten” zu verkaufen. Drei Begrenzungen bleiben — und sollten in einer auditfähigen Software absichtlich nicht aufgehoben werden:
1. Beobachtung im Audit.
Eine KI sieht keine schmutzigen Schleusenböden, keinen unbeschrifteten Reagenzbehälter, keinen unsicheren Bediener. Die Anwesenheit der Auditorin oder des Auditors vor Ort bleibt unverzichtbar bei kritischen Produkten oder Prozessen — die Software macht nur Zeit für mehr Beobachtung frei.
2. Interview-Dynamik.
Das Wie einer Antwort — Zögern, Ausweichen, Rückversicherung beim Vorgesetzten — kann ein Indikator für Schwachstellen sein. Es wird vor Ort erfasst und manuell in die Folgefrage geschrieben; die KI-Vorbeantwortung dient nur als Strukturgerüst.
3. Risikobasiertes Urteil.
Ob eine 70-prozentige Coverage in einem Kapitel „ausreichend” ist, hängt vom Gesamtrisiko des Audits ab. Diese Entscheidung treffen die Auditierenden — nicht das Modell.
Eine gut entworfene Software unterstützt diese Begrenzungen aktiv: Felder, die geschützt sind oder die KI nichts angehen (Statistiken, Tags, Aggregate), sollten vom Deep-Merge geschützt und nicht durch KI-Antworten überschrieben werden.
9. Fazit: KI als Stichproben-Verstärker, nicht als Audit-Ersatz
Der zentrale Fortschritt, den eine fachspezifische KI-Integration in das pharmazeutische Audit bringt, lässt sich in drei Sätzen zusammenfassen:
1. Die Auditorin sieht mehr Belege gründlicher in derselben Zeit — die Stichprobenqualität steigt strukturell. Damit steigt auch die Aussagekraft hinsichtlich der Compliance des auditierten Unternehmens.
2. Jede KI-Aussage ist rückverfolgbar an Datei, Seite und Zitat — Halluzinationen werden zwar nicht ausgeschlossen, aber sofort sichtbar gemacht.
3. Das fachliche Urteilsvermögen bleibt bei den Auditierenden, da die Übernahme jedes Vorschlags ein bewusster Akt ist, nicht ein Default.
Damit erfüllt eine so konzipierte Lösung beides: die regulatorische Erwartung an einen objektiven, auf Nachweisen basierenden Audit-Prozess und die in ISO 19011 wie ICH Q9 verankerte Forderung nach professioneller Beurteilung. KI im Audit ist kein Ersatz von Auditoren, sondern eine strukturelle Verstärkung — vorausgesetzt, das Werkzeug ist auf diesen Zweck hin gebaut und nicht aus einem generischen Chat-Frontend zusammengeklebt.
Wer KI im GMP-Audit ernsthaft einsetzen möchte, sollte sein Werkzeug an genau diesen Kriterien messen: Datenhoheit, Quellenpflicht, kontrollierte Ergebnisübernahme, normbasierte Kataloge, dokumentierter Audit-Trail. Die Diskussion, ob KI ins Audit gehört, ist damit beendet — sie tut es bereits. Die offene Frage ist nur noch, wie sie hineingelassen wird.
Quellen / Weiterlesen
- David Abraham: Einsatz von künstlicher Intelligenz (KI) im Audit, GMP Journal, 2026.
- ICH Q9(R1) - Quality Risk Management.
- ISO 19011:2018 - Leitfaden zur Auditierung von Managementsystemen.
- EU GMP Guide, Annex 11 - Computerised Systems.
Über die Autoren:
Dr. Klaus Bonadt ... ist Diplom-Mathematiker und Epidemiologe sowie CTO der iduneo GmbH und Mitgesellschafter der ilytics GmbH, wo er die Backend-Architektur und KI gestützte Lösungen für GMP-Audits verantwortet.
Peter Riebel ... ist Diplom-Ingenieur für Bauinformatik und Mitge sellschafter der ilytics GmbH, wo er Marketing, Front End-Entwicklung und die KI-Integration in den Audit Analyzer für GMP-Audits verantwortet.
