# Defensible AI Governance for Regulated Industries

> Source: https://ibl.ai/resources/capabilities/ai-governance-for-regulated-industries


*Inventory, model risk management, audit-of-record, BAA chain, and workforce governance — built into the platform, not bolted on as policy.*

Regulators in banking, healthcare, government, legal, and insurance have converged on the same expectation for AI: treat it like the regulated technology it is. Inventory every model. Tier it by risk. Validate before deployment. Monitor in production. Capture audit evidence. Bind every interaction to identity.

Most institutions try to satisfy this with policy documents and vendor SOC 2 reports. The institutions that pass the second examination get there with architecture — a platform that captures audit evidence by default, binds identity to every prompt, and routes per workload to keep sensitive data inside the perimeter.

ibl.ai is the platform layer that turns AI governance from a policy document into an operational reality across every regulated industry the institution serves.

## The Challenge

Regulated industries face the same governance failure mode: AI gets deployed in pilots, the pilots succeed, scaling begins, and the governance posture has not caught up. The first examination — OCC, HHS OCR, state attorney general, accreditor, internal audit — reveals the gap.

The gap is rarely a missing policy. It is missing evidence. The policy says audit logs are maintained. The vendor dashboard cannot produce them in the auditor's format. The policy says identity is bound to every AI session. The pilot used personal accounts because the IdP integration was deferred. The policy says model risk is managed. The model inventory is a spreadsheet that has not been updated since the pilot launched.

The gap closes when the architecture supports the policy by default — not when the policy is rewritten harder.

## How It Works

1. **The Platform Captures the Inventory by Default:** Every model and agent deployed on the platform appears in the inventory automatically — including the third-party LLMs they call. The inventory is queryable, exportable, and aligned with SR 11-7, clinical-governance, and accreditor frameworks.
2. **Risk Tiering Is a Policy Configuration, Not a Spreadsheet:** Risk tiers — high (customer- or patient-facing, fiduciary, advisory), medium (operations), low (productivity) — are configured at the platform level and applied to every model and agent. Tier-appropriate validation requirements are enforced before deployment.
3. **Every Prompt and Response Lands in Your SIEM:** Audit-of-record events flow into the institution's SIEM — Splunk, Sentinel, Elastic, Sumo Logic, Datadog — in the institution's format, on the institution's retention schedule. Vendor dashboards are supplementary; the SIEM is the source of truth.
4. **Identity Is Federated to Your IdP — Every Session:** Every AI session is identity-bound through the institution's identity provider (Okta, Azure AD, Ping, Shibboleth) via SAML 2.0, OIDC, or SCIM. No personal accounts, no shared service accounts, no unbound API keys for institutional work.
5. **Per-Workload Routing Keeps Sensitive Data Inside the Perimeter:** PHI, customer data, classified information, or other regulated data routes to a local open-weights model running on institutional GPUs. Non-sensitive workloads route to BAA- or contract-covered frontier models. The platform captures evidence for every path.
6. **Workforce Governance Is a First-Class Workflow:** Sanctioned-path adoption, training completion, attestation, and DLP integration for shadow-usage detection are platform-level workflows. Compliance, security, and learning teams see the same data, in their existing systems.

## Features

### Automatic Model and Agent Inventory

Every model, agent, and third-party LLM the platform calls appears in the inventory automatically. Queryable by risk tier, business owner, validator, and deployment status. Exportable for SR 11-7, clinical-governance, and accreditor evidence.

### Policy-Driven Risk Tiering

Risk tiers configured at platform level. Tier-appropriate validation, monitoring, and change-management requirements applied automatically. New deployments above tier threshold trigger pre-deployment review workflow.

### Audit-of-Record SIEM Integration

Every prompt, response, and model invocation captured as a structured event with user identity, timestamp, model identifier, prompt reference, and response reference. Streamed to the institution's SIEM in real time.

### End-to-End Identity Federation

Every AI session bound to a named workforce member through the institution's IdP. SAML 2.0, OIDC, SCIM. No personal accounts; no shared service accounts; no unbound API keys for production work.

### BAA- and Contract-Aware Routing

Routing decisions reflect the BAA and contract coverage of each external service. PHI workloads route to local models or BAA-covered frontier paths. Audit evidence captures which path each prompt took.

### Workforce Governance Workflows

Sanctioned-path enforcement, training completion tracking, attestation workflows, and DLP integration for shadow-usage detection. Compliance, security, and learning teams see unified data.

### Source-Code Ownership and Continuity

The complete platform code is the institution's, under a perpetual license. Vendor changes, model deprecations, and price moves do not stall regulated AI deployments — they become routing changes inside the institution's platform.

## With vs. Without

| Aspect | Without | With |
|--------|---------|------|
| Model and Agent Inventory | Spreadsheet inventory updated manually, missing shadow usage and embedded SaaS AI. Quickly out of date and not defensible in examination. | Automatic inventory of every model and agent deployed on the platform, including third-party LLMs called. Queryable, exportable, and continuously current. |
| Risk Tiering | Risk tiers defined in policy but applied inconsistently across pilot deployments and production rollouts. | Risk tiers configured at platform level and enforced for every deployment. Tier-appropriate validation and monitoring applied automatically. |
| Audit-of-Record | Vendor dashboards in vendor formats, on vendor retention schedules, accessible through vendor interfaces. Not the institution's source of truth. | Every prompt and response captured in the institution's SIEM in the institution's format, on the institution's retention schedule. Source of truth is institutional. |
| Identity Binding | Personal accounts, shared service accounts, and unbound API keys in production. Identity chain breaks under examination. | Every AI session bound to a named workforce member through the institutional IdP. Identity chain is unbroken end-to-end. |
| BAA and Contract Coverage | BAAs and vendor contracts in folders, not actively managed against actual workload routing. Scope drift goes unnoticed. | BAA and contract metadata attached to each routing destination. Every routing decision captured in audit evidence. |
| Workforce Governance | Sanctioned-path adoption depends on vendor UX; shadow usage invisible to the institution. | Sanctioned-path enforcement at the platform level, DLP integration for shadow detection, training and attestation tracked in compliance systems. |
| Continuity | Vendor changes, deprecations, and price moves stall regulated AI deployments and trigger re-procurement. | Source-code ownership and per-workload routing make vendor changes routing changes inside the institutional platform. |

## FAQ

**Q: How does ibl.ai support SR 11-7 model risk management for AI?**

ibl.ai captures the inventory, risk tier, validation status, and ongoing performance evidence each model and agent in a form aligned with SR 11-7's expectations for inventory, validation, and ongoing monitoring. The institution's existing MRM program extends to AI without operating a parallel regime — the platform supplies the evidence the program runs on.

**Q: Where does the audit evidence live?**

Audit evidence is written to the institution's SIEM and audit-of-record storage. Supported integrations include Splunk, Elastic, Microsoft Sentinel, Datadog, Sumo Logic, and any syslog- or webhook-capable system. The institution defines retention, storage location, and access. ibl.ai does not retain or transmit customer audit evidence.

**Q: How does the platform support BAA and contract chain management?**

BAA and contract metadata is attached to each external routing destination (OpenAI ChatGPT Enterprise, AWS Bedrock for Claude, Google Vertex AI for Gemini, others). The audit record for every prompt captures which routing destination handled it and which BAA or contract covers that path, producing defensible evidence for examinations.

**Q: Can ibl.ai operate air-gapped for the strictest regulated workloads?**

Yes. Air-gapped deployment is a supported topology for classified, PHI-heavy, or other workflows that require complete isolation. Local-model inference runs on customer GPUs in the air-gapped zone, audit logs flow to local storage, and identity federates through the customer's air-gapped IdP.

**Q: How does the platform handle workforce shadow usage?**

Shadow usage is addressed through three layers: a sanctioned path that is genuinely better than alternatives (faster, integrated, trustworthy), platform-level workflows for training and attestation, and DLP integration (Zscaler, Netskope, Microsoft Purview) that surfaces PHI- or PII-shaped content moving toward unsanctioned AI tools. The combination reduces shadow usage to a measurable, addressable signal rather than an invisible risk.

**Q: What does the first-deployment scope look like?**

A typical first deployment is 60-90 days, scoped to one or two workflows in one regulated business unit, with the full governance posture in place from day one: inventory, risk tiering, audit-of-record SIEM integration, identity federation, and the workforce-policy layer. The next deployments extend the posture to additional workflows and business units without re-engineering the governance layer.

**Q: Does ibl.ai itself need to be in our model-risk inventory?**

Yes. The platform is a third-party model risk for SR 11-7 purposes and falls within the institution's clinical-governance, accreditor, or other model-risk frameworks as applicable. ibl.ai provides the evidence the institution's model-risk program requires for third-party model risk, including the source-code arrangement that lets the institution's validators inspect the platform directly rather than rely on vendor representations.

**Q: How does this interact with our existing compliance team's tools?**

The audit-of-record flows into the institution's SIEM, which is typically already integrated with the compliance team's GRC platform (ServiceNow, Workiva, AuditBoard, etc.). The inventory and risk-tier metadata exports to GRC tooling. Compliance teams see AI deployments as first-class entries in the tools they already operate, rather than a separate system to learn.