Fairness and bias

​

Our stance in one paragraph

​

What we monitor at runtime

​

What we do support: content-level fairness controls

• Slur / harassment denial. The policy library includes a curated policy that blocks slurs targeting protected classes and dehumanising language. Operators can enable it as-is or use it as a starting point for their own deny lists. See Policies.
• Intent-based denials via semantic_guard. Operators describe prohibited intents in plain English (“incitement of discrimination against a protected class”, “harassment-as-a-service requests”); the LLM-backed judge applies those intents on the prompt and the response.
• Output regex filters. Pattern-based blocks for known problematic surface forms.

​

What we do not do

• We do not infer race, ethnicity, gender, age, religion, disability, sexual orientation, immigration status, or any other protected attribute about end users from prompt content.
• We do not run statistical-parity, equal-opportunity, calibration, or any other fairness metric internally and serve it to operators as a finding.
• We do not flag agents as “biased” or “fair.” The trust score is operational risk, not a fairness verdict.
• We do not train models on customer data under any plan.

​

Supporting your fairness audit

1. Per-agent. Slice block-rate and sanitization-rate by agent_id to see whether one agent is disproportionately refusing or redacting traffic relative to its peers.
2. Per-customer-cohort. Group by your own customer cohort attribute (the value you put in set_context(user_id=…) or set_context(session_id=…)) to compare verdict distributions across the cohorts you defined.
3. Per-policy. Group by matched_policy to see whether a specific rule has uneven impact across cohorts.

​

Example: cohort block-rate comparison

import pandas as pd

# Load the export.
requests_df = pd.read_csv("request_logs.csv")

# Join with your customer cohort table (lives in your data warehouse).
cohorts_df = pd.read_csv("your_customer_cohorts.csv")  # user_id → cohort
joined = requests_df.merge(cohorts_df, left_on="request_text", right_on="...")  # use your own key

# Per-cohort block-rate.
summary = (
    joined.groupby("cohort")
          .agg(total=("id", "count"),
               blocked=("verdict", lambda s: (s == "block").sum()))
)
summary["block_rate"] = summary["blocked"] / summary["total"]
print(summary)

​

What a fairness-conscious operator should do

1. Author the fairness policies you need. Use the slur policy, write intent-based semantic_guard rules for the harms your product cannot produce, and review the matched-policies audit trail.
2. Tag traffic with cohort-stable opaque identifiers. Attach an internal user_id or session_id you can later join against your own cohort tables.
3. Export the audit log on the cadence your governance committee requires (typically monthly or quarterly).
4. Run fairness analytics offline in the tool your team already uses. The export is designed for direct ingest into Pandas, Snowflake, Databricks, or any SIEM.
5. Treat any positive finding as a policy or product change, not as an EgisAI ticket. The audit log is evidence; the fix lives in your policies or in your product.

​

What a regulator usually asks for

1. The policy inventory at the moment in question — which rules were enabled, with what configuration. policies.csv from the audit-evidence export delivers this.
2. The operator-action audit trail — who changed which policy when. audit_log.csv delivers this.
3. The per-call decision log — which call hit which policy, with verdict and matched-policy id. request_logs.csv delivers this.

​

What’s next