When it comes to safety policies for generative AI, one size does not fit all. Each organization and use case needs to mitigate different risks depending on the application context, regulatory environment, organizational values, and user personas. Yet, existing policy specification approaches are designed for traditional access control and fail to capture the nuances of GenAI application: the enforcement of content-based constraints. We present two contributions to address this gap: (1) the Actionable Policy schema, a YAML-based format for specifying what model responses can and cannot contain. The schema enables exception-based policy governance, proposing exceptions to track policy violations; (2) synthetic data generation pipeline that produces policy-aligned training data for model alignment and testing, and a set of tools to help define the schema and enforce policy. Together, these enable organizations to specify policies once and enforce them throughout the GenAI application lifecycle: from model alignment to runtime monitoring. The Actionable Policy schema, example policies, and tools are available as open source: https://github.com/ibm-granite/granite.trust.policy-tools We welcome new ideas, contributions and feedback.
Figures & tables
Figure 1: Overview of the proposed policy framework. During Stage 1, the policy is defined as a result of a risk management process to mitigate relevant risks. Risks may change, and so do policies. The resulting policy is used in Stage 2 for a variety of applications including generating synthetic datasets for model alignment and assessing system compliance before deployment, compliance monitoring and runtime enforcement.
Figure 2: The policy format provides a concrete definition of Exception types that allow tracking policy violations and handle them properly either in the application or upstream (in another agent). The third example in the figure shows the exception is passed to the agent so the agent can handle it appropriately.
Field
Type
Description
risk_group
string
Category name for a group of related risks. Unique identifier (snake_case) for the risk group, e.g. violence_and_physical_harm
risk_group_id
integer
Numeric ID for the group, unique within a policy set
description
string
Human-readable explanation of what this risk group covers and the deployment context it targets
policy_version
string
Version of the policy schema used, e.g. v1.0
risks
list
List of one or more specific risks within the group (see Table 2 )
Table 1: Description of top level structure (lines 1 – 5)
Field
Type
Description
risk
string
Name of the specific risk. It is a unique identifier (snake_case) for this specific risk, e.g. murder , alcohol_beer_underage
risk_id
float
Unique identifier (e.g., 14.1, 14.2). Dot-notation ID combining group and risk number, e.g. 1.3 for risk group 1, risk 3
description
string
Describes the type of request this risk covers
reason_denial
string — null
Code explaining why requests are denied Denial reason code (ALL_CAPS) when the model must refuse. This field is optional, but if it is set to null , some tools may not work properly.
short_reply_type
string
Specifies how the model should respond (EXPLICIT_REFUSAL, POLITE_REDIRECT, etc.) (see Reply Types table 3 )
exception
string — null
Name of the exception triggered when policy is violated. Exception code (ALL_CAPS).
Table 2: Description of field within a risk (line 6 – 17)
Value
Meaning
EXPLICIT_REFUSAL
Clearly decline to fulfill the request
INFORMATIVE_RESPONSE
Provide factual, helpful information
INFORMATIVE_WITH_DISCLAIMER
Provide information with a disclaimer (e.g., “consult a professional”)
POLITE_REDIRECT
Redirect to an alternative topic or resource
PARTIAL_RESPONSE
Answer the safe parts only
ESCALATE_TO_HUMAN
Transfer to human agent
Table 3: Common reply types
Code
Context
VIOLENCE_EXCEPTION
Exception to be triggered when there is a violence related policy violation
ALCOHOL_MINORS_EXCEPTION
Exception to be triggered when underage alcohol information is requested
ALCOHOL_CIRCUMVENTION_EXCEPTION
Exception to be triggered when there is a request to circumvent alcohol regulations.
Table 6
Figure 3: Policy-aware synthetic data generation through DGT
Figure 4: Five-stage safety_sdg pipeline
Figure 5: Mapping between a Granite.trust Policy and DGT safety_sdg
Figure 6: Annotated YAML configuration for the DGT safety_sdg Data Builder
Artificial intelligence governance studies how laws, institutions, and technical controls shape AI development, deployment, accountability, and social effects.
Generative AI (GenAI) applications have flourished enabling users to chat with large language models, and to create agents to act on their behalf for a variety of tasks. The pace of development of capabilities in this field is incredibly fast with security and safety taking a back seat. Unfortunately, the slower pace at which security and safety mechanisms have evolved has led to real incidents. Policy enables the definition of desirable behavior of applications, and for that reason, it is a cornerstone of making systems secure and compliant. Policy however means different things to different practitioners creating confusion and siloed solutions that are not adequate for compliance. This paper takes a tour of the good, the bad and the ugly when it comes to policy enforcement in GenAI applications. We propose a methodology to systematically analyze and dissect existing approaches to define and enforce policy found in the wild. Based on this principled analysis, we provide recommendations and call for action for the community to address. This paper is a companion extension of USENIX Security 2026 Enigma talk titled "From Alignment to Access Control: A Unified View of GenAI Policy Enforcement" by the author Nathalie Baracaldo.
Enterprise generative AI applications require robust safety mechanisms that can accommodate diverse risk postures, evolving policies, and varying latency constraints. Current guardrail solutions often suffer from rigidity, relying on fixed policy sets and offering limited transparency or reasoning flexibility. We present Adaguard, an adaptive LLM-as-a-Judge framework designed to address these challenges through dynamic policy enforcement and adaptive reasoning-budget allocation. Built using supervised fine-tuning (SFT) and reinforcement learning (GRPO), AdaGuard generalizes to user-defined safety and compliance policies at runtime without requiring frequent model updates. A core innovation of our approach is the ability to dynamically infer the complexity of input-policy pairs, allowing the model to switch between high-speed black-box inference and explainable, reasoning-enabled moderation. This flexibility enables developers to balance stringent latency requirements with the need for actionable transparency. This adaptive capability allows AdaGuard to rival other guardrail and frontier models several times its size, while its auto-reasoning mode recovers the accuracy of always-on reasoning at a fraction of the latency
Trust in the application of generative Artificial Intelligence (AI) relies on well-governed measurable evidence of performance and safety. In practice, however, evaluation data is often fragmented across systems, inconsistently structured and difficult to compare. We introduce the Generative Responsible AI Data Evaluation Schema (GRAIDES) as a lightweight open-source data model for centralising AI observability across popular vendors. Practical blueprints for code, architecture and statistical evaluation are shared as guidance about how to approach generative system assurance at the organisational level. Illustrative case study results are reported from Westminster City Council's AI catalogue with a focus on measuring human-model alignment including detecting systematic disagreement between evaluators. By framing evaluations as a data modelling problem, GRAIDES provides a practical pathway toward more consistent and reproducible benchmarking, tuning and assurance activities for generative AI systems.
Ethan Knights, Christopher Conlan, Temilorun Gbolahan +2