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.