Dieser Audit prüft konkrete Aussagen zu Funktionen und Integrationen Ihrer SaaS-Plattform. Grundlage sind aktuelle Dokumentation, Tarif, Version und Datum. Vergleichen Sie KI-Antworten manuell; Markennennung und Quellenzitat beweisen keine sachliche Richtigkeit.
Zerlegen Sie Antworten in einzelne Aussagen. „Die Integration liest Daten und veröffentlicht automatisch Änderungen“ enthält zwei verschiedene Behauptungen. Trennen Sie Lesen und Schreiben, manuelle und automatische Vorgänge sowie Entwurf und Veröffentlichung.
Eine fehlende Dokumentation bedeutet unbestätigt, nicht nachweislich nicht vorhanden. Eine falsche Aussage erfordert widersprechende Belege oder die Bestätigung des Produktverantwortlichen. Auslassungen werden nur anhand des vorher festgelegten Testumfangs bewertet.
Register der manuellen Prüfung
| KI-Aussage | Quelle / Version / Tarif | Bewertung |
|---|---|---|
| Aktuell dokumentiert | Gleiche Funktion und gleicher Tarif | Zutreffend |
| Widerspricht dem Produktzustand | Beleg oder Bestätigung des Verantwortlichen | Falsch |
| Keine abschließende Information | Mit dem Produktteam prüfen | Unbestätigt |
| Erwartete Information fehlt | Vorher festgelegter Testumfang | Ausgelassen |
Zählen Sie jede Klasse separat. Bei einer Genauigkeitsquote müssen Nenner und ungelöste Fälle angegeben werden. Unbestätigte Aussagen gelten nicht automatisch als richtig. Diese manuelle Prüfung ist von Semly-Sichtbarkeitsmetriken getrennt.
Voraussetzungen: Was Sie vor der Prüfung bereithalten müssen
Eine belastbare Prüfung scheitert selten an der Analyse, sondern an fehlenden Referenzdokumenten. Ohne eine definierte Wahrheitsgrundlage lässt sich nicht entscheiden, ob eine KI-Aussage falsch ist.
Checkliste "Prüf-Setup"
- Offizielle Produktdokumentation als primäre Faktenquelle, mit Versionsstand und Datum.
- Changelog oder Release Notes zur Erkennung veralteter Aussagen.
- Statuspage zur Einordnung von Ausfällen und temporären Einschränkungen.
- API-Referenz für technische Details wie Endpunkte, Limits und Authentifizierungsverfahren.
- Preisliste mit Tarifständen, enthaltenen Limits und Gültigkeitsdatum.
- Integrationsübersicht mit Status je Integration (verfügbar, Beta, geplant).
- Zugang zu zwei bis fünf AI-Modellen, um modellspezifische Muster zu erkennen.
- Testprompt-Set mit Funktions-, Integrations-, Preis- und Limit-Fragen.
- Dokumentationsvorlage mit den Feldern Datum, Modell, Prompt, Antwort, genannte Quelle, Bewertung.
Die Methode hat Grenzen. Sie passt nicht, wenn keine öffentliche Dokumentation existiert, weil dann keine Referenzgrundlage für den Abgleich vorliegt. Sie passt eingeschränkt bei Beta-Funktionen, deren Verhalten sich kurzfristig ändern kann. Und sie stößt an Grenzen, wenn Funktionen nur unter Vertraulichkeitsvereinbarung dokumentiert sind.
Prüfung in 6 Schritten
Schritt 1 – Testprompts definieren
Ziel dieses Schritts ist ein Prompt-Set, das Funktions- und Integrationsangaben systematisch abdeckt. Formulieren Sie Fragen in mindestens drei Varianten: direkt ("Unterstützt [Produkt] SAML-SSO?"), indirekt ("Wie richte ich SSO für [Produkt] ein?") und vergleichend ("Welche SaaS-Plattformen im Bereich X unterstützen SAML?").
Kontrollpunkt: Jede Frage muss eine überprüfbare Tatsachenbehauptung provozieren. Fragen, die nur Meinungen erzeugen, gehören nicht ins Set. Typisches Fehlerbild ist ein Set, das ausschließlich direkte Ja/Nein-Fragen enthält; solche Prompts liefern selten die Nuancen, in denen Fehler sichtbar werden.
Schritt 2 – Antworten erfassen und reproduzieren
Erfassen Sie jede Antwort mit vollständiger Konfiguration: Datum, Modellversion, Prompt-Wortlaut, Antworttext und genannte Quellen. Wiederholen Sie identische Prompts mehrfach, um Einzelantwort von Muster zu unterscheiden. Generative Systeme sind nicht deterministisch; eine einzelne abweichende Antwort belegt noch keinen systematischen Fehler.
Kontrollpunkt: Reproduzierbarkeit. Tritt derselbe Fehler bei wiederholter Abfrage und über mehrere Modelle hinweg auf, handelt es sich um ein Muster. Typisches Fehlerbild ist die Verallgemeinerung einer Einzelantwort.
Schritt 3 – Primärquellen abgleichen
Vergleichen Sie jede Tatsachenbehauptung auf Statement-Ebene mit der Primärquellen-Trias: Produktdokumentation, Changelog/Release Notes und Statuspage/API-Referenz. Prüfen Sie nicht die Antwort als Ganzes, sondern zerlegen Sie sie in einzelne Aussagen. Eine Antwort mit fünf korrekten und einer falschen Aussage ist keine korrekte Antwort.
Kontrollpunkt: Jede Aussage erhält eine Bewertung (bestätigt, widersprochen, nicht prüfbar). Typisches Fehlerbild ist der Abgleich gegen Sekundärquellen wie Vergleichsportale statt gegen die eigene Dokumentation.
Schritt 4 – Fehler klassifizieren
Ordnen Sie jeden Befund einer der vier Kategorien zu: falsch, korrekt-aber-unbelegt, veraltet oder fehlende Nennung. Die Klassifikation bestimmt die Reaktion.
| Fehlerart | Reaktion |
|---|---|
| Faktisch falsch | Öffentliche Quelle prüfen und korrigieren, danach erneut abfragen |
| Korrekt, aber unbelegt | Belegkette stärken: klare, zitierfähige Aussagen in der Dokumentation |
| Veraltet | Changelog und Dokumentation aktualisieren, Datumsangaben ergänzen |
| Fehlende Nennung | Sichtbarkeit der Funktion in strukturierten Inhalten verbessern |
Kontrollpunkt: Jeder Befund hat genau eine Kategorie. Typisches Fehlerbild ist die Vermischung von Korrektheit und Sichtbarkeit.
Schritt 5 – Quellen bewerten
Kontrollpunkt: Die Quelle muss die Aussage direkt und im Wortlaut stützen. Typisches Fehlerbild ist die Akzeptanz eines Links als Beweis, ohne den Inhalt zu prüfen.
Schritt 6 – Korrigieren und erneut messen
Korrigieren Sie die öffentliche Quelle, die die falsche Aussage begünstigt. Fragen Sie anschließend mit identischem Prompt-Set erneut ab und dokumentieren Sie den Zeitraum. Eine Änderung der Antwort nach einer Korrektur belegt noch keine Kausalität; sie ist ein Hinweis, kein Beweis.
Kontrollpunkt: Vorher-Nachher-Vergleich mit identischer Methodik. Typisches Fehlerbild ist die Bewertung einer einzelnen Folgeantwort als Erfolg.
Mini-Case: erfundene Integration
Ein B2B-SaaS-Anbieter für Lagerverwaltung stellt fest, dass ein Sprachmodell eine Integration mit einem großen ERP-System als "verfügbar" beschreibt. Tatsächlich befindet sich die Integration in der Beta-Phase. Der Anbieter prüft die Primärquellen: Die Integrationsübersicht führt die Funktion ohne Statusangabe. Die Korrektur besteht darin, den Status explizit zu kennzeichnen ("Beta, verfügbar ab Q1"). Nach der Aktualisierung und erneuter Abfrage über mehrere Modelle hinweg nennt ein Teil der Antworten den Beta-Status, ein anderer Teil nicht. Das Ergebnis ist ein Muster, kein Einzelfall, und begründet laufendes Monitoring.
Häufigste Fehler und wie Sie sie beheben
- Link als Beleg akzeptieren. Korrektur: Prüfen Sie, ob die Quelle die konkrete Aussage stützt, nicht nur ob sie existiert.
- Einzelantwort verallgemeinern. Korrektur: Wiederholen Sie die Abfrage und vergleichen Sie über mehrere Modelle.
- Nur ein Modell testen. Korrektur: Nutzen Sie mindestens zwei bis fünf Modelle, um modellspezifische von systemischen Fehlern zu trennen.
- Veraltete Dokumentation prüfen. Korrektur: Ziehen Sie immer den aktuellen Changelog hinzu und dokumentieren Sie den Versionsstand.
- Prompt-Bias ignorieren. Korrektur: Formulieren Sie neutrale Prompts ohne eingebaute Prämissen.
- Fehlende Nennung mit Fehler verwechseln. Korrektur: Klassifizieren Sie Sichtbarkeitslücken getrennt von Faktenfehlern.
- Gesamtantwort statt Einzelaussagen bewerten. Korrektur: Zerlegen Sie jede Antwort in prüfbare Statements.
Semly bietet Einblick in KI-Antworten und Quellen. Eine sachkundige Person prüft Funktions- und Integrationsangaben.
