AI: It’s Infrastructure | RSAC Field Notes, Part 2

Part A: Methodology and Evidence Architecture

Executive Summary

The legal architecture for AI governance is no longer about policy adoption but about whether an organization can produce evidence that traces from board-level authorization to production inference, drift event, prompt or tool change, or downstream agent action. Regulators, plaintiffs, enterprise buyers, and procurement officers now converge on a single standard: Show what the system did, under what authorization, what the organization knew, when it knew it, and what it did next.

That standard is the lens through which the Governance and Risk Orchestration platform domain should be evaluated. This Part A defines the methodology and evidence architecture used to assess vendors in the RSA 2026 Field Notes; our forthcoming Part B applies that framework with specific vendor battle cards (IBM, Credo AI, Collibra, and Monitaur).

The legal floor rests on overlapping regimes, including the EU AI Act’s logging and monitoring requirements, the NIST AI RMF, emerging federal and state frameworks, procurement-driven obligations, insurance constraints, and sectoral overlays such as FTC enforcement, securities law, healthcare regulation, and safety and harm-prevention expectations across product liability and AI governance.

The central conclusion is straightforward: The pipeline is the policy. A Governance and Risk Orchestration platform tool that cannot reconstruct what a covered Automated Decision-Making Technology (ADMT)¹ or high-risk AI system did, who authorized it, what documentation governed its use, what controls were operating, and what the organization represented to regulators, buyers, or counterparties is not aligned with where AI accountability is heading.

This does not mean a governance platform itself must generate every technical log. Machine Learning Operations (MLOps)² telemetry, prompt-change histories, identity records, and model-monitoring events may live elsewhere. The legal question is whether the Governance and Risk Orchestration platform can ingest, preserve, map, and explain that evidence against approvals, obligations, controls, risk decisions, incidents, remediations, and attestations. Appendix 1 includes a road map of this series with the domain-by-domain evidence architecture.

Governance and Risk Orchestration Platform Selection Is a Legal Operations Issue

Governance and Risk Orchestration tools are the connective tissue of a serious AI governance program: the layer where policies become operationally binding, risk decisions are recorded, and operational accountability is assigned to systems making consequential choices at scale.

The practical legal test is a demonstrable chain of accountability. Stakeholders should be able to move from the original governance decision to actual system behavior: Who approved the use case? Which model, agent, or tool was deployed? What data, prompts, safety filters, or configurations were in place? What happened at runtime? What alert was generated? What mitigation followed? And who accepted any residual risk? The chain should resemble this example: Board approval X → use case Y → model or agent version Z → data, prompt, tool, or safety-filter configuration A → runtime event B → alert C → mitigation D → residual-risk acceptance E for a governance plane.

This article picks up where decision-surface mapping ended: Before governing AI risk, organizations must first identify which technologies drive consequential decisions, which are assistive, which are external, and who (or what) executes actions across models, agents, humans, service accounts, and APIs.

The Legal and Procurement Requirements Governance and Risk Orchestration Platforms Must Operationalize

The emerging baseline is an evidence floor created by overlapping legal duties, enforcement theories, procurement requirements, buyer expectations, and sectoral controls. Governance and Risk Orchestration platforms must operationalize these obligations into traceable, regulator-ready records, including the following:

EU AI Act

The EU AI Act requires high-risk AI systems to log relevant events across their life cycle and mandates that documented post-market systems continuously monitor, analyze, and ensure ongoing compliance. Platforms need not generate all logs but should ingest, preserve, map, and explain them against approvals, controls, risk decisions, technical documentation, incident handling, and post-market monitoring obligations to produce an integrated evidentiary chain.

NIST AI RMF

Governance orchestration that stops at “govern” can be perceived as organizational chart work. A platform aligned with the RMF should help map use cases and context, measure risks and performance, manage prioritized risks, and maintain governance records across the AI life cycle.

Litigation and regulatory reconstruction

FTC, SEC, state AG, and private litigation inquiries consistently converge on the same questions: What was represented; what did the system do; what evidence supported the representation; and what did the organization know when the risk materialized? FTC Section 5 authority and SEC AI-washing enforcement demonstrate that AI governance records must support both operational risk management and truth-in-representation review.

The US preemption ceiling

The March 2026 National AI Legislative Framework is a legislative recommendation and executive legal signal. Its preemption pillar would bar many state AI-specific regulatory requirements, but it preserves state authority over traditional police powers such as child safety, fraud, consumer protection, zoning, and state procurement or government use of AI. The result is a shift from regulatory checklist compliance to evidentiary defensibility aligned with federal priorities.

Colorado design input

Colorado’s legislation should be understood as an evolving law with delayed implementation rather than a settled regime. SB 24-205 established duties around reasonable care, risk-management programs, impact assessments, annual reviews, notices, correction and appeal rights, developer documentation, and AG enforcement. The 2026 Work Group proposal reflects a shift toward transparency, adverse-outcome notices, human review or reconsideration, documentation, and three-year record retention. Ongoing legislative consideration and litigation context continue to shape timing and implementation. Platforms should be flexible enough to support frameworks as well as evolving documentation and recordkeeping expectations.

California procurement

California Executive Order N-5-26 creates a procurement pathway through which certification standards may emerge. The order gives the Department of General Services and the California Department of Technology 120 days to recommend new certifications that may be incorporated into state contracting processes, including requirements for vendors to attest to and explain their policies and safeguards regarding illegal-content exploitation, harmful-bias governance, and civil rights/civil liberties protections. Procurement operationalizes AI risk, safety, and rights-based obligations through contracting, even in the absence of broadly applicable regulatory mandates.

Financial services and healthcare overlays

The April 2026 interagency model-risk-management guidance supersedes prior interagency model risk management guidance and emphasizes a risk-based approach to model development and use, validation and monitoring, governance and controls, and vendor and third-party risk management. It excludes generative and agentic AI, signaling further AI-specific guidance to come.

Treasury Financial Services AI RMF (February 2026) adapts the NIST AI RMF for financial-sector use cases, translating high-level AI risk management principles into supervisory-aligned expectations for explainability, fairness, robustness, and oversight, effectively serving as a bridge between conceptual AI governance and examination-ready controls.

Interagency Model Risk Guidance (April 2026) supersedes prior interagency model risk management guidance, emphasizes a risk-based approach to model development and use, validation and monitoring, governance and controls, and vendor and third-party risk management. It excludes generative and agentic AI, signaling further AI-specific guidance to come, and creating an immediate gap for institutions deploying those systems today, which must therefore extend existing model risk, operational risk, and third-party risk frameworks to cover AI in advance of formal supervisory direction.

HIPAA applies where AI systems handle ePHI on behalf of covered entities or business associates, triggering obligations under the Privacy, Security, and Breach Notification Rules and, critically, requiring organizations to treat AI vendors as business associates where applicable, implement appropriate safeguards, and ensure that model outputs and training data flows are governed as regulated health information throughout the AI life cycle.

Traditional legal non-discrimination law applied to AI

The evidence described above also supports constitutional and statutory anti-discrimination requirements independent of AI-specific legislation. Equal protection, Title VII, ADA accessibility, and the Fair Housing Act all require the ability to reconstruct how and why a system produced a particular outcome for a member of a protected class.

A Governance and Risk Orchestration platform that cannot reliably preserve and make accessible the data inputs, model logic, scoring rationale, and decision pathway associated with an individual adverse outcome may create material risk in the organization’s ability to defend against anti-discrimination claims, regardless of whether the jurisdiction has enacted AI-specific transparency or impact-assessment duties.

These obligations persist regardless of AI-specific statutory frameworks and will drive discovery that demands auditable evidence.

Safety and harm prevention obligations

The same evidence architecture also supports emerging safety and harm-prevention expectations across sectoral regulators, product liability frameworks, and evolving AI-specific rules. Regimes focus on whether an AI system can produce harmful or unsafe outputs and on whether organizations can demonstrate that the company has identified, monitored, and effectively responded to those risks promptly.

A Governance and Risk Orchestration platform that cannot connect runtime signals, incident reports, model updates, and mitigation actions into a coherent record of detection and response will face the same evidentiary gaps seen in discrimination and consumer-protection contexts. As AI systems move into operational and customer-facing environments, the ability to reconstruct how a system behaved under potentially harmful conditions, and what the organization did in response, becomes central to regulatory, litigation, and procurement scrutiny.

Insurance

The AI insurance landscape shifted in January 2026 when model insurance forms introduced generative AI exclusions for Commercial General Liability policies, narrowing silent coverage and creating a growing protection gap. Carriers and reinsurers are developing stand-alone AI products (covering risks such as hallucinations, model drift, IP infringement, and regulatory exposure) while increasingly requiring technical due diligence at underwriting. This shift places the evidentiary burden on deploying organizations: Coverage depends on whether organizations can demonstrate, with defensible records, how systems functioned, what controls were in place, and how risks were monitored and addressed.

Proposed Evidence Architecture for a Governance and Risk Orchestration Platform

The platform diligence question is not whether the vendor can display a control library. It is whether the platform can preserve a defensible evidence chain across the life cycle. The seven evidence objects below operationalize, at the Governance and Risk Orchestration layer, the four-layer evidence model introduced in Part 1—Decision Entry Points, Invocation Signals, Execution Traces, and Identity/Authority Binding—and should be first-class records or reliably linked artifacts:

Cross-Vendor Legal-Risk Patterns

The vendor assessments themselves are in Part B. The patterns below are important and should shape any Governance and Risk Orchestration evaluation regardless of vendor.

Runtime enforcement is weaker than marketing language implies. Buyers should distinguish between observing behavior, flagging behavior, routing behavior for review, blocking behavior, and modifying behavior. These distinctions have different implications for monitoring, enforcement, and liability.

Prompts, tools, retrieval lists, and safety filters should be governed artifacts. Behavior often changes more due to a prompt edit, tool-permission change, retrieval-source update, or safety-filter adjustment than from a model swap. If the governance plane does not see those artifacts, it may not see the real operational risk surface.

Nonhuman identity binding is underdeveloped. A defensible governance platform should bind AI actions to accountable owners, authorization scope, and identity records. Nonhuman identity is the larger below-the-waterline risk of the identity iceberg.

Developer/deployer allocation should be explicit. Colorado-style ADMT governance, EU AI Act provider/deployer obligations, and procurement attestations all require proof of what the vendor supplied, what the deployer changed, and which party controlled the relevant risk.

Evidence exports must be tested, not assumed. Audit outputs should be tested early for retention, integrity, and legal usability. To fully understand the reports, you may need to add context to your reporting template.

Domain Boundary Caution: This Is Not Security Posture Management (SPM)

Several vendors that surface in Governance and Risk Orchestration conversations are more accurately evaluated under the AI Security/AI-SPM domain. This precision matters because security coverage does not substitute for governance evidence. AI/ML Bill of Materials (AI/ML-BOM),³ adversarial ML defense, runtime moderation, model detection and response, red-teaming, SaaS/shadow-AI discovery, and agentic action security are valuable, but they are not a governance plane unless they connect actions to approval, obligations, ownership, controls, retention, and attestation. Domain 2 tools can feed Governance and Risk Orchestration.

The Proof-of-Concept Test

Counsel, security, data, engineering, and procurement should jointly require a live demonstration that starts with a new AI use case and ends with an exportable evidence package. The test should include:

• Intake of a new AI use case or Covered ADMT, including material-influence analysis and owner assignment
• Developer/deployer documentation capture, third-party dependency records, and approval workflow
• Mapping to NIST AI RMF, EU AI Act, Colorado/California-style notice and records requirements, and sectoral controls
• A model, prompt, tool, retrieval source, or safety-filter change that requires approval and creates a traceable change record
• A runtime event: drift, bias, adverse action, hallucination, out-of-policy tool call, or unauthorized agent action
• Human review, escalation, mitigation, closure, residual-risk acceptance, and follow-up monitoring
• Export of a regulator-, buyer-, insurer-, or procurement-ready evidence package
• Retention proof, audit trail, privilege/redaction handling, and API/log export

The governing test remains: If a deployed AI system under a governance approval started behaving outside its authorized parameters right now, what would your platform surface, to whom, in what time frame, and with what evidence? A vendor that answers with a live workflow is a governance platform. A vendor that answers with a policy library is a documentation tool. Both have a market. They are not the same product.

Looking Ahead

Over the next 12-24 months, three shifts should reshape the legal evaluation criteria:

1. The line between the Governance and Risk Orchestration domain and the AI Security/AI-SPM domain will continue to blur as runtime telemetry becomes governance evidence.
2. Agentic governance will become the leading edge; platforms unable to articulate action-level authorization and per-action governance records may become incomplete as systems mature.
3. Procurement-driven governance will shift vendor evaluation from whether a platform can produce evidence for a regulator to whether it can provide attestable, buyer-verifiable proof.
   
   

Policies promise governance. Decision surfaces define it. Pipelines prove it. Governance and Risk Orchestration platforms are where that proof must live.

¹ Note: ADMT refers to systems that process personal data using algorithms, AI, or other computational methods to make, replace, or substantially influence decisions about individuals, with limited or no meaningful human involvement. Examples include hiring and employment screening tools, credit or lending decision-making, insurance underwriting, healthcare decision-making, and certain forms of profiling, targeted advertising, or behavioral tracking that affect individuals’ opportunities or access to services.

² Note: MLOps refers to the practices and tools used to manage and automate the life cycle of machine learning (ML) systems, including development, deployment, monitoring, and maintenance in production. It combines ML, data engineering, and development operations principles to ensure models are deployed reliably and continuously monitored and improved over time.

³AI/ML-BOM is a structured inventory of the models, datasets, code, and dependencies that comprise an AI system, including their origins, versions, and configuration. While governance platforms record approvals, policies, and controls, an AI/ML-BOM captures the underlying system components and relationships, supplying the detailed evidence layer needed to trace behavior, assess risk, and validate governance assertions.