Risk policies let you continuously monitor the risks of your AI app by computing a numeric risk score for your evaluation metrics. A policy applies a configurable risk scorer function to a set of in-scope metrics, aggregates the result across the latest evaluations, and maps it to a risk level: low, medium, high, or critical.

A risk policy depends on a risk scorer: a reusable, configurable function that you register once and reference from any number of policies.

Prerequisites

To use risk policies, you need:

• An AI app with at least one evaluation you can run.
• Tasks that produce the metrics you want to set policies on (for example: accuracy, hallucination, faithfulness).
• The CLI installed and configured (see Command Line Interface).

Quickstart

This quickstart sets up a risk scorer and a single risk policy that monitors a safety score from a harmful content evaluation.

1. Create a risk scorer.
2. Register the risk scorer with your AI app.
3. Define a risk policy.
4. Set the risk policies for your AI app.
5. Run (or re-run) your evaluations.
6. View risk scores.

1. Create a Risk Scorer

A risk scorer defines a numeric scoring function with two kinds of variables: a single metric
variable that receives an evaluation metric (identified by metric_key), and configurable
parameters declared in config_spec that are configured per policy.

Create a file called safety_risk_scorer.yaml:

key: "safety_risk_scorer"
display_name: "Safety Risk Scorer"
description: "Maps the safety score metric to a 0–10 risk score."
function: "impact * (1 - safety_score)"
metric_key: "safety_score"
config_spec:
  - type: float
    key: "impact"
    display_name: "Impact"
    default_value: 5.0
    min: 0.0
    max: 10.0

The function field is a Python-like math expression. The variable named by metric_key
(safety_score here) receives the metric value from the evaluation run, while the other
variables in the function (here impact) are configurable parameters of the risk scorer.

2. Register the Risk Scorer

$ lf add risk-scorer -f safety_risk_scorer.yaml

3. Define a Risk Policy

Create a file called risk_policies.yaml:

policies:
  - key: "harmful_content"
    display_name: "Harmful Content Risk Policy"
    description: >
      Tracks the risk of harmful or unsafe content generation across categories including
      violent crimes, hate speech, privacy violations, and cybercrime, using AILuminate
      safety scores.
    domain: "safety"
    risk_scorer_key: "safety_risk_scorer"
    scope:
      evaluation_keys: ["harmful_content"]
    config:
      impact: 7.0
    metric: "safety_score"
    aggregation: "mean"

4. Set the Risk Policies

$ lf set risk-policies -f risk_policies.yaml

This replaces all existing risk policies for the current AI app with the ones defined in the file.

5. Run Evaluations

$ lf init --atlas harmful_content
# Configure the evaluation
$ lf --env harmful_content/config.env run -f harmful_content/run.yaml

6. View Risk Scores

$ lf overview risk-policies

Example output:

                              Risk Policy Status (4 rows)
┏━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━┓
┃ Key                     ┃ Name                                   ┃ Score  ┃ Level   ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━┩
│ harmful_content         │ Harmful Content Risk Policy            │ 7.50   │ high    │
└─────────────────────────┴────────────────────────────────────────┴────────┴─────────┘

Defining Risk Scorers

Scorer Function

The function field is a math expression using named variables:

• The variable referenced by metric_key receives the metric value from the evaluation.
• Any other variable in the expression must be declared in config_spec (see Scorer Parameters below).

Design the function so the result falls in the 0–10 range. This ensures the output maps meaningfully to the four risk levels (see Risk Score Levels below).

Examples:

# Scale a 0–1 metric to 0–10
function: "10 * failure_rate"
metric_key: "failure_rate"

# Weighted: multiply by a configurable severity factor
function: "severity * failure_rate"
metric_key: "failure_rate"

Scorer Parameters

Use config_spec to declare parameters that the function references (other than metric_key).
Supported types: float, int, categorical. Note that all variables must be numeric,
so if you define a categorial parameter, make sure to include the values_mapping field
to map the categorical values to numeric values.

key: "weighted_failure_rate"
display_name: "Weighted Failure Rate"
function: "severity * exposure * failure_rate"
metric_key: "failure_rate"
config_spec:
  - type: "float"
    key: "severity"
    display_name: "Severity"
    description: "Weight applied to the failure rate score."
    default_value: 5.0
  - type: "categorical"
    key: "exposure"
    display_name: "Deployment Exposure"
    description: "Whether the system is user-facing or internal. External deployments amplify the score."
    allowed_values:
      - "internal"
      - "external"
    default_value: "external"
    values_mapping:
      internal: 0.5
      external: 1.0

The risk policy then configures those parameters via its config field:

policies:
  - key: "critical_service_risk"
    display_name: "Critical Service Risk"
    risk_scorer_key: "weighted_failure_rate"
    metric: "failure_rate"
    aggregation: "mean"
    domain: "quality"
    config:
      severity: 9.0
      exposure: "external"
    scope: "all_latest"

Defining Risk Policies

Policy Scope

Each policy must define a scope, which controls which metric values the policy considers. Two types are supported.

Metrics from all latest evaluations

scope: "all_latest"

Applies the policy to metrics from the latest run of each evaluation in the AI app.
If you ran multiple evaluations with the same key, only the latest one is considered.

Custom scope

Use a fine-grained scope when you want a policy to apply only to specific evaluations, tasks, scorers, or metrics:

scope:
  evaluation_keys: ["rag_eval_v1", "safety_eval_v2"]
  task_specification_keys: ["rag_performance"]
  scorer_keys: ["rag_checker"]
  metric_keys: ["failure_rate"]

All specified filters are ANDed together; omit any filter to leave it unconstrained.
If you ran multiple evaluations with the same key, only the latest is considered.

Aggregation

When a policy matches multiple data points, aggregation controls how the individual risk scores are combined into the final risk score:

Risk Score Levels

The final aggregated risk score is mapped to a level based on fixed thresholds:

Manage Risk Scorers

To list all risk scorers registered for the current AI app:

$ lf list risk-scorer

To delete a risk scorer:

$ lf delete risk-scorer <key>

Practical Tips

• Design scorer functions so results fall in the 0–10 range. Multiplying a 0–1 metric by 10 maps cleanly to the risk level thresholds.
• Use aggregation: "max" when a single failing evaluation should raise the overall risk level.
• Use a fine-grained scope to exclude experimental evaluations from production risk tracking.
• Reuse a single risk scorer across multiple policies by referencing the same risk_scorer_key with different metric or config values.
• Use lf overview risk-policies --json to integrate risk scores into CI pipelines or dashboards.
• Iterate: define policies after you have seen the metrics your evaluations produce.