Kurzbeitrag : Semantic Risk Classification – need for runtime solutions : aus der RDV 1/2026, Seite 30 bis 35
This is a follow-up to my article on End-User responsibilities on a GPAI system that was published recently at – https://www.rdv-online.com/print/ausgabe-4-2025/end-user-responsibilities-on-a-generative-ai-conversation/. I was contemplating titling this as either “Runtime Ontology” vs being a little more descriptive – in calling out the need for staying dynamic with semantic risk classifi cation. Stuck with the simpler and more descriptive title, as you can see above! To set some context, we could defi ne Semantic Risk Classifi cation on the following lines: A dynamic approach to evaluating and categorizing risks in AI systems based on the actual meaning, context, and intent of user interactions, model outputs, and system behaviors—rather than relying solely on static, predefi ned use cases or domains. This enables real-time identifi- cation and mitigation of evolving risks as AI systems operate in unpredictable environments.
I. Scope
I also used Notebook LM to get me a jump start in this topic on the below lines. Fascinating mind-map, in my view.
The AI act has multiple aspects in relevance, but we will focus primarily on the shaded regions above, that talk about – what defines a High-Risk system.
The Five Core High-Risk Concepts that determine classifi cation are:
- Domain: The area in which the AI system is used.
- Purpose: The intended goal of the AI system
- AI capability: Specifi c function the AI system performs
- AI user: Who is the intended user of the AI system 5. AI subject: The person or entity about whom the AI system makes a decision
The current approach seems a little too static where we go about defi ning the purpose of an AI system, largely based on its domain and capabilities offered and make a determination on whether it qualifi es for a high-risk AI system or not.
Ganesh Srinivasan ist General Manager für Informationssicherheit bei Icertis, einem amerikanischen Anbieter für Vertragsmanagement-Software.
However, given that the model behind the scenes is a GPAI model – that has far reaching capabilities outside of the intended boundaries, it does leave a large gap to our own imagination, which may or may not be captured by guardrails in play.
Just to recap from the previous article, a high-risk AI system could deal with one or more of the following.
High-Risk AI Category |
|---|
Biometric identification and categorization |
Critical infrastructure management |
Education and vocational training |
Employment, workers management, and self-employment |
Access to essential private and public services |
Law enforcement |
Migration, asylum, and border control management |
Administration of justice and democratic processes |
II. Risk of compromise
If we now dig into each of the above parameters that drive a risk classification, they could be examined this way.
Parameter | Ease of compromise (how easily real use deviates from the intended classification) | Typical guardrails and extent of protection |
|---|---|---|
Domain | Medium–High. “Domain drift” in open chat or with | Domain whitelists/ blacklists; runtime domain classifier + refusal/route; tenant/ data segmentation; DLP and egress allow lists. Protection: moderate if enforced at runtime; |
Purpose | High. Function creep: advisory turns into decisioning; users ask for actions beyond scope; prompt injection reframes intent. | Policy as code for allowed intents; action Protection: moderate–strong if gates block execution, weak if only warnings/disclaimers. |
AI | High. Tooling/plugins (code exec, RPA, data writes, | Least privilege tool permissions; sandboxed execution; network egress allow list; rate limits; Protection: strong if capabilities are permissioned and sandboxed; moderate otherwise. |
AI user | High. Broad access, weak identity, or low literacy raises misuse and insider risk; external users | Strong IAM (MFA, RBAC/ABAC with purpose binding), scoped tokens, session risk scoring, Protection: moderate–strong if tied to ABAC + monitoring; weak with generic SSO only. |
AI subject | Medium (can be High for vulnerable groups). Bias, | Data minimization, PII detection, fairness testing/monitoring, DPIA, notice/contestability, explainability, human review for impactful Protection: moderate; becomes strong with continuous fairness monitoring and enforced review gates. |
III. Runtime Solutions
The current AI solution stack – at an abstracted level has the following options. Emerging GenAI/LLM-specific security categories.
Category | Purpose (what it does) | Typical risks addressed |
|---|---|---|
LLM Firewall | Filters/blocks malicious inputs/ outputs; enforces | Prompt injection, jailbreaks, data leakage, unsafe |
LLM Automated Benchmarking (incl. vuln scanning) | Probes models to find weaknesses; evaluates behavior across scenarios | Injection/adversarial inputs, leakage, bias, robustness gaps |
LLM Guardrails | Constrains model behavior with policies, content | Harmful/biased content, policy violations, unsafe |
AI Security Posture Management (AI-SPM) | Lifecycle posture, governance, and drift/attack monitoring for AI systems | Data poisoning, model drift, adversarial attacks, |
Below is a merged table: your risk parameters + emerging GenAI/LLM categories + best-fit solutions from the OWASP landscape.
Parameter | Ease of compromise | Typical guardrails & protection | Best-fit emerging category | Suggested solutions (examples from OWASP matrix) |
|---|---|---|---|---|
Domain | Medium–High | Whitelists/blacklists; runtime domain classifier | LLM Guardrails; LLM Firewall; AI SPM (monitor | Cisco AI Runtime (LLM enabled WAF/guardrails); |
Purpose | High | Policy as code for allowed | LLM Guardrails; LLM Firewall; AI SPM (governance) | Lasso Secure Gateway; |
AI capability | High | Least privilege tools; sandbox; egress allow Protection: strong with | LLM Guardrails; LLM Firewall; AI SPM | Cisco AI Runtime |
AI user | High | Strong IAM (MFA, RBAC/ Protection: moderate–strong with ABAC + | LLM Guardrails; AI SPM | Pangea Authentication/ |
AI subject | Medium → High (for vulnerable groups) | Data minimization; PII Protection: strong with continuous monitoring + | AI SPM; LLM Automated | AI Verify (bias/fairness |
To summarize the solution alternatives to our Categories:
- Domain: Cisco AI Runtime + Lasso + Lakera.
- Purpose: Lasso + Prompt Security + Pangea Authorization.
- AI capability: Cisco AI Runtime + PurpleLlama CodeShield + Pangea Authorization.
- AI user: Pangea Authentication + AISec Platform.
- AI subject: AI Verify + Giskard + Pangea Redact/Cloaked AI.
IV. Risk Assessment priorities
From a risk management perspective, it is better to review every single AI solution on the below lines to better assess the need for external or commercial solutions as the dynamic layer of protection.
Parameter | Assessment lines (questions to answer) | Baseline controls (OSS/DIY) | Add dynamic Solutions when... |
|---|---|---|---|
Domain | Regulated domain involved? RAG uses external/cross tenant data? Domain drift observed in pilots? Cross border/egress requirements? | Domain allow/deny lists; runtime | Drift exceeds threshold; external/ |
Purpose | Advisory vs. action/decision? Users | Policy as code for allowed intents; | Any automatic actions beyond advisory; high volume transactions; |
AI capability | Tools/plugins enable code exec/ | Tool allow list; least privilege scopes; | Multiple high impact tools or unsandboxed paths; autonomy in |
AI user | External/contractor access? Privileged roles? MFA + ABAC tied | SSO + MFA; RBAC/ABAC with scoped tokens; session risk scoring; | Large/heterogeneous user base; privileged operations; repeated |
AI subject | PII/sensitive data processed? | Data minimization; PII detection/redaction; OSS fairness/ | High stakes individual impact; regulated fairness/reporting; |
V. Closing thoughts
Static decision making on identifying a high-risk system is challenged already. The push to solutions that operate at runtime on the user prompts, model response, underlying data, behavior/pattern analysis will become mainstream as quickly as the models and GPAI systems evolve.
Ultimately, this shift is driven by the need for compliance. Continuous assessment is the only viable path to demonstrate that a system remains within its defined risk profile, preventing functional drift, managing vulnerability to jailbreaks, and ensuring fairness metrics do not degrade. The risk assessment categories should keep pace with this rate of change.
For any organization deploying AI, especially those falling under the high-risk classification defined by the EU AI Act’s Annex III, the regulatory mandate is clear: trustworthiness and compliance must be demonstrable. Moving beyond simple upfront documentation, the incorporation of runtime classifiers, guardrails, and dynamic risk monitoring becomes less of a technical preference and more of a fundamental regulatory requirement for compliance attestation and maintaining control over the five core high-risk parameters.