AI Governance
From AI inventory to operating controls, review evidence and audit support.
AI Warden does more than list AI assets. It gives governance, risk and platform teams a reviewable evidence chain: discovered assets, business products, mapped controls, live policy bindings, review periods, approvals, runtime request logs and evidence snapshots.
Asset discovery
Governance starts with knowing what AI exists.
Read-only connectors and AI Warden registries provide the starting point for governance: cloud AI services, model deployments, Bedrock models, Copilot entitlements, LLM provider aliases, MCP servers, hosted agents, agent extensions and request-log activity.
Products, labels and ownership
Map AI assets to business products, then let labels drive governance scope.
Products are the bridge between technical AI assets and business accountability. A product can carry region, data classification, environment, owner group and labels such as gdpr=true, tier=production, business=retail or data=personal. Controls can be pinned directly to a product or automatically applied to every product whose labels match.
- Product ownership assigns accountable business and platform owner groups.
- Resource tags bind products to LLM aliases, MCP servers, cloud resources, dashboards and other artefacts.
- Label filters keep scope dynamic: a new product tagged
gdpr=truecan automatically fall under GDPR controls. - Discovered metadata such as cloud region and environment helps classify assets and review exceptions.
product: customer-insights-agent owner_group: retail-digital region: eu data_classification: personal_data labels: gdpr: true tier: production business: retail data: personal resources: - llm_model_alias:gpt-4o-eu - mcp_server:customer-profile-readonly - azure_resource:/subscriptions/.../openai-prod matched_controls: - gdpr_personal_data_ai_processing - eu_region_model_residency - approved_models_only - mcp_servers_approved_and_scanned
Controls and standards
Apply controls from industry, government, regulator and internal frameworks.
A control is an owned governance statement with scope, framework references, required policies, optional machine checks, review cadence and evidence. AI Warden can use a control catalog for common standards and also support customer-specific control frameworks.
Framework mapping
Controls can reference external obligations and internal policies so the same runtime policy can support multiple assurance requirements where mapped by the customer.
- EU AI Act control obligations and high-risk-system guardrails.
- NIST AI RMF governance, mapping, measurement and management outcomes.
- ISO/IEC 42001 AI management system controls.
- SOC 2, DORA, FCA/SYSC, GDPR and internal risk frameworks.
Control templates
Governance teams can start from catalog templates, then adapt ownership, scope labels, required policies, predicates and review cadence.
- Approved models only for regulated products.
- EU-region model and cloud-resource residency.
- MCP servers must be approved and recently scanned.
- Required firewall, content, ICAP or budget policies must exist.
Control anatomy
Controls are not PDFs. They are live objects tied to the platform.
Each control can have an owner, statement, function, review cadence, product scope, label filters, framework references, required policies and one or more predicates. The result is a live status: evidence pass, fail or unknown; cadence ok, pending or overdue; and an overall status that highlights failing or overdue controls.
- Owner group defines who is accountable for review and remediation.
- Scope comes from direct product pins plus label filters.
- Predicates machine-check whether the control appears to be operating.
- Reviews can preserve the evidence snapshot at attestation time.
| Control field | Example | Why it matters |
|---|---|---|
| Framework refs | GDPR Art. 5 · ISO 42001 8.4 · NIST GV-1 | Maps one control to multiple assurance requirements. |
| Scope labels | gdpr=true · tier=production | Includes matching products where configured. |
| Required policies | llm_content_policy · mcp_firewall_policy · icap_policy | Binds governance to live enforcement configuration. |
| Predicate | llm_only_approved | Checks whether scoped model aliases are approved. |
| Cadence | quarterly | Creates pending/overdue review state and notifications. |
Mapping controls to policies
A governance statement can point at the exact policy that enforces it.
Controls do not need to duplicate the LLM Gateway, MCP Gateway or ICAP policy engines. They can bind to existing artefacts and required policies, then evaluate whether those artefacts exist and are configured. This gives reviewers a cleaner chain from framework obligation to policy document to runtime request evidence.
- Map data-leakage controls to LLM content policy, MCP content policy and ICAP request/response enforcement.
- Map residency controls to approved cloud resources, approved model aliases and product region labels.
- Map access controls to RBAC groups, MCP server approvals and system-principal approval flows.
- Map cost-governance controls to budget policies and AI FinOps reporting.
control: gdpr_personal_data_ai_processing statement: Personal data AI workloads must use approved EU-hosted models and DLP controls. framework_refs: - GDPR Art. 5(1)(f) - GDPR Art. 32 - ISO 42001 8.4 scope_label_filters: - gdpr=true - tier=production required_policies: - llm_content_policy: global - llm_icap_policy: global - mcp_icap_policy: global predicates: - cloud_region_allowlist: [eu-west-1, eu-central-1, switzerlandnorth] - llm_only_approved - required_policies_present
Review periods and evidence snapshots
Controls can be reviewed monthly, quarterly, annually or on a custom cadence.
AI Warden tracks when each control is due for review, whether its evidence is currently passing, and whether the overall state is healthy, pending, overdue or failing. Reviews can store the evidence snapshot as it looked at attestation time.
Cadence management
- Review periods can be set by control: monthly, quarterly, annually or custom days.
- Pending and overdue controls create owner notifications.
- Failing machine evidence can surface before the next scheduled review.
Evidence at review time
- Review outcomes can be attested, failed or skipped with notes.
- The platform can preserve the current predicate result as an evidence snapshot.
- Reviewers can inspect what evidence existed when the owner last approved the review.
Approvals
Governance changes and live policy changes follow different approval paths.
AI Warden separates compliance approvals, product/control ownership reviews and strict four-eyes policy changes so day-to-day platform operation does not become uncontrolled system configuration.
Compliance and catalog approvals
Newly discovered cloud AI models, services and entitlements can enter approval queues before becoming approved assets for product use.
- Approve or reject models and services with reason.
- Track pending approvals and out-of-policy resources.
- Use approved catalogs in governance predicates.
Four-eyes policy changes
Firewall, content, LLM, MCP, ICAP and system-principal policy changes can require a submitter and a separate approver before live enforcement changes.
- Review current and proposed policy documents as a diff.
- Prevent self-approval unless break-glass permission is held.
- Apply approved changes and retain audit history.
Proof chain
From framework obligation to runtime evidence in one chain.
A control can point to the product scope, required policy documents, current predicate status, approval history and the LLM or MCP request logs that support enforcement review. That is the difference between static governance documentation and operating assurance.
Assurance outcome
When auditors ask for a control, AI Warden helps show the scope, policy, review and runtime evidence.
The governance story connects asset discovery, product labels, standards-mapped controls, policy bindings, approvals, request logs and review snapshots into one reviewable evidence chain.