CompTIA SecAI+ — Übungsfragen und Probeprüfung

Der EU AI Act ist eine wegweisende Gesetzgebung, die ein risikobasiertes regulatorisches Framework für künstliche Intelligenz etabliert. Er kategorisiert AI-Systeme in vier Risikostufen: inakzeptables Risiko (vollständig verboten, z. B. Social-Scoring-Systeme), hohes Risiko (unterliegt strengen Anforderungen einschließlich Konformitätsbewertungen, z. B. AI im Recruiting oder in der Strafverfolgung), begrenztes Risiko (Transparenzpflichten, z. B. Chatbots, die offenlegen müssen, dass sie AI sind) und minimales Risiko (keine spezifischen Anforderungen, z. B. Spam-Filter). Organisationen, die AI in der EU einsetzen oder Daten von EU-Bürgern verarbeiten, müssen die Anforderungen der jeweiligen Stufe erfüllen. Der Act enthält außerdem Bestimmungen für General-Purpose-AI-Modelle wie Large Language Models. Das Verständnis der Risikoklassifizierung des EU AI Act ist für die SecAI+-Prüfung entscheidend, weil sie den weltweit umfassendsten regulatorischen Ansatz für AI Governance darstellt. Prüfungstipp: Der EU AI Act hat vier Risikostufen — merke dir die Hierarchie von inakzeptabel bis minimal.

Zwei Anforderungen müssen von einer einzigen Kontrolle erfüllt werden, und das grenzt das Feld schnell ein. Kostenzuordnung braucht eine Abrechnung pro Consumer; faire Isolation braucht eine Obergrenze pro Consumer. Eine Token-Limit-Policy am Gateway liefert beides, denn sie erzwingt Limits pro API-Consumer auf Basis des Token-Verbrauchs und lässt dich eine Tokens-pro-Minute-Rate zusammen mit einem Kontingent über einen längeren Zeitraum festlegen, gebunden an etwas, das den Aufrufer identifiziert, etwa einen Subscription-Key.

Tokens sind die richtige Einheit. Sowohl die Kosten als auch die Backend-Kapazität eines Sprachmodells skalieren mit Tokens und nicht mit der Anzahl der Requests, deshalb ist ein einfaches Requests-pro-Minute-Limit ein schlechter Näherungswert: Ein einziger sehr langer Prompt kann mehr Kapazität verbrauchen als tausend kurze und trotzdem eine Prüfung der Request-Rate bestehen. Den Zähler pro Consumer zu führen, macht aus einem globalen Sicherheitsventil erst eine Isolation, denn ein Team, das seine Obergrenze erreicht, wird gedrosselt, ohne den Spielraum eines anderen anzutasten.

Die Distraktoren lösen andere Probleme. Ein Filter für gesperrte Themen ist eine Content-Safety-Kontrolle und misst gar nichts. Semantisches Caching reduziert Backend-Aufrufe bei wiederholten Prompts, was den durchschnittlichen Kosten hilft, aber nichts über Fairness oder Zuordnung garantiert. Ein größeres Kontextfenster erhöht, wie viel ein einzelner Request verbrauchen darf, und macht das Risiko des Aushungerns damit größer statt kleiner.

Prüfungstipp: Wenn eine Gateway-Frage Kosten mit Kapazität kombiniert, such nach der Kontrolle, deren Einheit Tokens sind und deren Geltungsbereich der Consumer-Key ist.

Zerlege die Anforderungen und prüfe, welche Technologie jede einzelne erfüllt. Ein Ticket erstellen, die relevanten Logs sammeln und ein Playbook vorschlagen sind Aktionen über verschiedene Systeme hinweg, also Orchestrierung. Diese Schritte automatisch auszuführen, sobald ein Alarm mit hohem Schweregrad ausgelöst wird, ist ereignisgesteuerte Automatisierung. Das passendste Playbook anhand des Alarmkontexts vorzuschlagen, ist der Punkt, an dem KI-Unterstützung einen Mehrwert bringt. Die endgültige Entscheidung beim Analysten zu lassen, ist Human-in-the-Loop-Validierung. Analysten bestätigen Aktionen mit großer Tragweite, müssen aber nicht jeden Routineschritt freigeben. Eine SOAR-Plattform (Security Orchestration, Automation and Response) gehört zu der Kategorie, die genau für diese Kombination gebaut ist. Ihre Playbooks sind vorkonfigurierte Abfolgen von Abhilfemaßnahmen, die automatisch ablaufen, wenn ein Alarm oder Vorfall einer Regel entspricht, oder die ein Analyst während einer Untersuchung manuell auslöst.

Jede Alternative lässt mindestens eine Anforderung fallen. Statische Korrelationsregeln allein erkennen und alarmieren, aber nichts in dieser Option eröffnet ein Ticket oder sammelt Logs. Ein Chatbot ohne Integrationen kann über einen Vorfall sprechen, erreicht aber weder das Ticketsystem noch den Log-Speicher und kann deshalb keinen dieser Schritte selbst ausführen. Ein Runbook, das von geplanten Jobs gesteuert wird, ist weder ereignisgesteuert noch adaptiv. Die Jobs laufen nach Zeitplan, unabhängig davon, was passiert ist, und die manuellen Schritte warten weiterhin auf eine Person.

Prüfungstipp: Achte auf die Verben in der Fragestellung. „Erkennen“ deutet auf Monitoring hin, „orchestrieren“ und „beheben“ auf Response-Tools, und ein ausdrücklicher menschlicher Entscheidungspunkt zeigt dir, dass die gesuchte Antwort den Analysten im Loop hält, statt ihn zu entfernen.

Lernziel 1.2 nennt Datenverarbeitungskonzepte, die für die Sicherheit von KI-Daten wesentlich sind: Datenbereinigung, Verifizierung, Lineage, Integrität, Provenance, Augmentierung und Balancing. Data Provenance hält Herkunft und Eigentümerschaft der Daten fest, während Data Lineage ihren Weg und ihre Transformationen durch die Pipeline nachverfolgt; zusammen liefern sie die dokumentierten Nachweise, die nötig sind, um die Vertrauenswürdigkeit zu beurteilen und Audits sowie die Untersuchung von Vorfällen zu unterstützen. Das ist für die Sicherheit wichtig, weil vergiftete oder manipulierte Daten viel leichter zu erkennen sind, wenn Herkunft und Historie dokumentiert und überprüfbar sind. Verwechsle Provenance/Lineage nicht mit Augmentierung (Erzeugen synthetischer Daten), Balancing (Ausgleichen ungleich verteilter Klassen) oder Watermarking (Einbetten von Eigentumsmarkierungen oder Erkennen KI-generierter Inhalte). Prüfungstipp: „Woher kommen die Daten und wie wurden sie transformiert?“ entspricht Provenance und Lineage.