Ihr interner KI-Assistent beantwortet Fragen während der Vorführung korrekt. Er liest außerdem Dokumente, speichert Gespräche und kann über ein verbundenes Werkzeug Kundendaten ändern. Bevor Sie ihn den Mitarbeitenden übergeben, fragt jemand, ob er getestet wurde. Einige gute Antworten reichen dafür nicht aus.
Für Organisationen in Luxemburg und der Großregion muss eine sinnvolle KI-Prüfung Sicherheit und vorgesehene Leistung abdecken. KI-Pentesting untersucht ausnutzbare Schwachstellen. KI-Tests messen, ob das System seine Aufgabe zuverlässig erfüllt. Dieser Leitfaden erklärt den Umfang beider Prüfungen, die erforderlichen Nachweise und die Rolle von Modellen, Agenten-Harnesses, MCP-Integrationen und Bias.
KI-Pentesting und KI-Tests beantworten unterschiedliche Fragen
Ein Pentest untersucht, welche Informationen ein Angreifer offenlegen oder welche Aktionen er auslösen könnte. Eine Qualitätsprüfung bewertet akzeptable Ergebnisse unter realistischen Nutzungsbedingungen. Ein System kann gewöhnliche Fragen gut beantworten und zugleich fremde Dokumente offenlegen. Ebenso kann es einen Jailbreak abwehren und dennoch eine Kundenantwort überzeugend erfinden.
| Prüfung | Hauptfrage | Nützliche Nachweise |
|---|
| KI-Pentesting | Kann ein Angreifer eine Sicherheitsgrenze überschreiten? | Reproduzierbare Angriffe, betroffene Berechtigungen und Geschäftsauswirkungen |
| KI-Tests | Erfüllt das System seine vorgesehene Aufgabe? | Repräsentative Fälle, Messergebnisse und Abnahmekriterien |
| Konformitätsvorbereitung | Für welche anwendbaren Anforderungen liegen Nachweise vor? | Kontrollzuordnung, technische Unterlagen, Lücken und Maßnahmenverantwortliche |
Unser KI-Pentesting-Service untersucht die Sicherheitsgrenzen der vollständigen Anwendung. Qualitäts- und Bias-Prüfungen können hinzukommen, wenn der Auftrag eine breitere Bewertung verlangt. Halten Sie die Ziele im Leistungsumfang getrennt fest, damit keines hinter einem allgemeinen Versprechen verschwindet, das Modell zu testen.
Definieren Sie die Systemgrenze vor der Werkzeugwahl
Beginnen Sie mit einem Diagramm für Nutzer, Anwendung, Modell, Dokumentquellen, Speicher, Werkzeuge und nachgelagerte Systeme. Markieren Sie Identitätswechsel und Informationsflüsse zwischen Organisationen. Berücksichtigen Sie Verwaltungsoberfläche, Hintergrundprozesse und Überwachung; diese können weitergehenden Zugriff besitzen als der sichtbare Chatbot.
Benennen Sie anschließend vorgesehene Nutzer, erlaubte Aufgaben und verbotene Aktionen. Ein Assistent, der einen Einkaufsantrag vorbereitet, hat ein anderes Risikoprofil als einer, der ihn einreicht. Dokumentieren Sie, ob er E-Mails versenden, Datensätze ändern, Code ausführen oder abteilungsübergreifend Dokumente lesen darf. Daraus entstehen die Grenzen, die die Prüfung überschreiten soll.
Vereinbaren Sie Autorisierung, Testumgebungen, Einschränkungen von Drittanbietern, synthetische Daten, Eskalationskontakte und Abbruchbedingungen. Nutzen Sie kontrollierte Ziele für simulierte Datenexfiltration. Falls eine produktive Abhängigkeit einbezogen werden muss, legen Sie erlaubte Aktionen ausdrücklich fest. Die Erlaubnis zur Prüfung Ihrer Anwendung umfasst nicht automatisch den Dienst eines anderen Anbieters.
Betrachten Sie einen beispielhaften Supportassistenten, der eine E-Mail vorbereiten, aber nicht versenden darf. Die Prüfung sollte Entwurf, vorgeschlagenen Empfänger und Ausführungsnachweis getrennt kontrollieren. Behauptet die Unterhaltung einen Versand, klären Sie, ob ein tatsächlicher Werkzeugaufruf stattgefunden hat. Bewahren Sie auch den Nachweis einer blockierten Ausführung auf. So verwechseln Sie eine erfundene Erfolgsmeldung nicht mit einer ausgeführten Aktion und erkennen die Komponente, die korrigiert werden muss.
Prüfen Sie das Modell über realistische Einstiegspunkte
Modelltests sollten die tatsächlich unterstützten Sprachen, Dateitypen und Interaktionsmuster umfassen. Bei mehrsprachigen Abläufen in Luxemburg reicht die Übersetzung eines englischen Prompts möglicherweise nicht aus. Unterschiedliche Dokumentformate, gemischtsprachige Nachrichten und Fachvokabular können Verständnis und Schutzverhalten verändern.
OWASP unterscheidet direkte und indirekte Prompt Injection: Eine Anweisung kann aus Nutzereingaben oder abgerufenem Material stammen. Diese Unterscheidung hilft bei der Wahl realistischer Einstiegspunkte, statt nur das Chatfenster zu prüfen.
Dokumentieren Sie für jeden Test Anwendungs- und Modellversion, Prompts, bereitgestellten Kontext, Konfiguration und beobachtetes Ergebnis. Unterscheiden Sie anstößige Antworten von tatsächlichen Grenzverletzungen. Eine harmlose Systemanweisung offenzulegen hat andere Folgen als Kundendaten preiszugeben, auch wenn beide Ergebnisse auf einem Screenshot spektakulär wirken.
Ein allgemeiner automatisierter Scanner bietet Breite und Wiederholbarkeit. Er benötigt dennoch anwendungsspezifische Fälle: vorhandene Daten, verfügbare Werkzeuge und geschäftlich unzulässige Aktionen. Ein unauffälliger Scan liefert Nachweise zu diesen Tests und keine Garantie für sämtliche denkbaren Interaktionen.
Bewerten Sie den Agenten-Harness und seine Aktionskontrollen
Der Agenten-Harness ist die Anwendungsschicht, die Kontext bereitstellt, Speicher verwaltet, Werkzeuge auswählt und Aktionen um das Modell ausführt. Hier kann ein plausibler Vorschlag zu einer echten Datenbankänderung werden. Untersuchen Sie den Weg von der Modellausgabe bis zur Ausführung und welche Kontrollen der Code durchsetzt.
Prüfen Sie Freigaben anhand eines synthetischen Geschäftsablaufs. Beispielsweise darf ein Assistent eine Kundendatenänderung vorbereiten, benötigt aber menschliche Zustimmung. Bestätigen Sie, dass die Freigabe genau die Aktion und ihre Argumente umfasst, angemessen abläuft und nicht für eine andere Operation wiederverwendet werden kann. Kontrollieren Sie das tatsächliche Ausführungsergebnis statt der Beschreibung des Assistenten.
Testen Sie Abbruch, Wiederholungen, Werkzeugfehler und Sitzungswechsel. Eine abgebrochene Freigabe muss auch nach einem Wiederholungsversuch abgebrochen bleiben. Eine fehlgeschlagene Suche darf den Zugriff nicht unbemerkt erweitern. Gesprächsspeicher darf sensible Inhalte nicht an andere Nutzer übertragen. Begrenzen Sie wiederholte Werkzeugaufrufe, damit unproduktive Agentenschleifen kein unbegrenztes Betriebsbudget verbrauchen.
Beziehen Sie MCP-Server, Clients und nachgelagerte Berechtigungen ein
Das Model Context Protocol, kurz MCP, verbindet KI-Anwendungen mit Werkzeugen und Ressourcen. Erfassen Sie jeden Client und Server, Hosting, verwendete Identität und nachgelagerte Berechtigungen. Ein sinnvolles Prüfziel umfasst den gesamten Weg von der Nutzeranfrage bis zum abschließenden API-Aufruf.
Die offiziellen MCP-Sicherheitshinweise behandeln protokollspezifische Risiken wie Token-Durchreichung und Confused-Deputy-Verhalten. Prüfen Sie diese Hinweise gegen den tatsächlich verwendeten Transport und Autorisierungsablauf Ihrer Implementierung.
Erstellen Sie ausdrücklich positive und negative Fälle. Ein berechtigter Nutzer sollte die genehmigte Aufgabe ausführen können. Ein anderer Nutzer, ein abgelaufener Berechtigungsnachweis oder eine Anfrage außerhalb des erlaubten Umfangs muss scheitern, ohne zusätzliche Daten offenzulegen. Untersuchen Sie Werkzeugbeschreibungen, Ergebnisse, lokale Ausführung und Geheimnisverwaltung zusammen mit der Serverauthentifizierung.
Ein vertrauenswürdiger Connector beweist nicht, dass sämtliche zurückgegebenen Inhalte vertrauenswürdige Anweisungen sind. Ein Supportticket oder Dokument kann trotz authentifiziertem Abruf feindlichen Text enthalten. Prüfen Sie dessen Wirkung auf die folgende Aktion anhand synthetischer Datensätze und ungefährlicher Testziele.
Prüfen Sie Retrieval, Qualität und Bias getrennt
Ein System mit Retrieval-Augmented Generation, kurz RAG, sollte beim Abruf und bei der Antwort geprüft werden. Kontrollieren Sie, ob erlaubte Dokumente gefunden, unzulässige Dokumente ausgeschlossen und abgerufene Inhalte korrekt verwendet werden. Eine scheinbar richtige Antwort kann einen fehlerhaften Zugriffsfilter verdecken.
Erstellen Sie für Qualitätsprüfungen einen überprüften Datensatz aus realistischen Aufgaben. Nehmen Sie beantwortbare Fragen, Fragen ohne Antwort in der Wissensbasis, widersprüchliche Quellen, veraltete Dokumente und Anliegen mit menschlichem Bearbeitungsbedarf auf. Erwartete Ergebnisse und Bewertungsregeln müssen unabhängig vom geprüften System bleiben.
Bias-Prüfungen benötigen einen benannten Kontext. Definieren Sie relevante Nutzergruppen, Sprachen oder Umstände und was ein unfairer Unterschied im vorgesehenen Einsatz bedeutet. Vergleichen Sie gegebenenfalls ansonsten gleichwertige Fälle, bei denen sich nur ein relevantes Merkmal ändert. Dokumentieren Sie Unsicherheit und Stichprobengrenzen, statt eine kleine Prüfung zum universellen Fairnessnachweis zu erklären.
Das NIST-Profil für generative KI ist eine freiwillige Ressource zur Risikosteuerung über den Lebenszyklus. Es kann ein Prüfprogramm strukturieren; Freigabekriterien müssen weiterhin Ihren konkreten Ablauf abbilden. Unser KI-Testservice setzt diese Kriterien in wiederholbare Bewertungen und Regressionstests um.
Verbinden Sie Prüfnachweise mit der Arbeit zum EU AI Act
Technische Tests tragen zur regulatorischen Vorbereitung bei, benötigen aber den richtigen Kontext. Klären Sie den vorgesehenen Zweck, Ihre Anbieter- oder Betreiberrolle und anwendbare Anforderungen vor der Auswahl der Nachweise. Ein Chatbot, ein Rekrutierungssystem und ein Modell in einem anderen regulierten Produkt erfordern unterschiedliche Bewertungen.
Artikel 15 des EU AI Act behandelt Genauigkeit, Robustheit und Cybersicherheit von Hochrisiko-KI-Systemen. Ordnen Sie relevante Testergebnisse den anwendbaren Verpflichtungen zu und machen Sie Umfang und Grenzen sichtbar. Ein einzelner Prompt-Test ersetzt das umfassendere Konformitätsverfahren nicht.
Bewahren Sie Nachweise über Datensätze, menschliche Aufsicht, Protokollierung und Korrekturen zusammen mit technischen Befunden auf. Unser Leitfaden zum EU AI Act erläutert den größeren Compliance-Kontext. Die Prüfung sollte Lücken und Verantwortliche benennen, ohne einen Pentest oder Bias-Wert als rechtliches Konformitätszertifikat darzustellen.
Ein nützlicher Testnachweis verknüpft den Fall mit erwartetem Ergebnis, Beobachtung und unterstützender Ablaufspur. Speichern Sie sensible Nachweise zugriffsbeschränkt und schwärzen Sie breiter geteilte Kopien. Ordnen Sie Maßnahmenverantwortliche und Nachtestergebnis demselben Datensatz zu. So lassen sich offene Probleme, akzeptierte Einschränkungen und bestätigte Korrekturen bei der Freigabe unterscheiden, ohne die Prüfung aus Gesprächsprotokollen rekonstruieren zu müssen.
Verlangen Sie einen Bericht, mit dem Ihr Team arbeiten kann
Jeder Sicherheitsbefund sollte betroffene Komponente, Voraussetzungen, Reproduktionsschritte, beobachtete Auswirkungen, Schweregradbegründung und Korrekturvorschlag enthalten. Qualitätsbefunde benötigen Testpopulation, Bewertungsmethode und verfehlte Abnahmekriterien. Beide müssen ungeprüfte Bereiche und die Abhängigkeit von bestimmten Modellen oder Konfigurationen ausweisen.
Vereinbaren Sie Nachtests und bewahren Sie Regressionsfälle auf. Änderungen an Prompt, Modell, Dokumentindex oder MCP-Werkzeug können das Verhalten verändern, obwohl die Oberfläche gleich bleibt. Die Checkliste für Bereitstellung und Administration erklärt, wie diese Tests in den laufenden Betrieb einfließen.
Wenn Sie ein KI-System prüfen lassen möchten, bringen Sie Architektur, erlaubte Aktionen und Bereitstellungsstand zu einem Gespräch mit ObsidianCorps über den Prüfungsumfang mit. Wir können einen gezielten Pentest, eine Qualitäts- und Bias-Evaluierung oder eine kombinierte Prüfung mit klaren Nachweisen und Maßnahmen definieren.
