What does board-level AI risk reporting actually look like?

A useful board report cites specific incidents, specific volumes, and specific exposure numbers. Examples: number of unauthorized AI tool interactions last quarter, number that touched PII or NPI, number of vendor incidents where AI was implicated, exposure under EU AI Act Article 99 for current high-risk deployments, breakdown of AI activity by department and by data classification. The report does not say "we are working on AI governance." It says, with specifics, what the AI activity was and what the current risk position is. Programs that produce this report have an evidence layer at the AI request boundary. Programs that do not produce it lack the layer.

How does AI risk reporting differ from cloud risk reporting?

Cloud risk reporting tracks misconfigurations, IAM posture, data exposure, and shared responsibility gaps. AI risk reporting tracks unauthorized usage, prompt-level data classification, policy enforcement outcomes, and per-decision audit completeness. The cloud reporting framework relies on CSPM tools that read configuration state. AI reporting relies on a per-request evidence layer that reads decisions. The two are complementary. AI risk is not a subset of cloud risk because the relevant evidence is the prompt content and the per-decision authorization outcome, not the infrastructure configuration.

What is the minimum AI control set a CISO should require before allowing new AI rollouts?

Five controls. First, identity context that travels with every AI request and identifies the natural person behind the call. Second, per-route and per-role policy evaluation at the AI request boundary. Third, deterministic data classification of the prompt content with a blocking or redaction outcome on sensitive matches. Fourth, signed, tamper-evident audit records committed before the response returns to the application. Fifth, retention of those records for the longer of the regulatory floor and the organization's existing record-keeping policy. Rollouts that cannot satisfy these five should pause until the controls are in place.

What is the CISO's exposure for vendor AI usage?

Vendor SaaS tools that embed model calls under the hood put the disclosure obligation on the deployer. The CISO's environment never sees the prompt, the response, or the data classification, but the regulator holds the enterprise accountable for AI mistakes made by subcontractors and vendors. Fannie Mae LL-2026-04 explicitly extends to vendor AI usage. EU AI Act obligations follow the deployer. Procurement contracts have to require vendor-side audit records the deployer can request on demand. Without that, the CISO faces a disclosure gap they cannot close.

What is the right architectural place for AI security to live in the org?

AI security sits at the intersection of identity, data, and AI platform engineering. The owner is usually the CISO. The implementation is co-owned with the AI platform team and the IAM team. The enforcement architecture has to be infrastructure the platform team operates, not a control the AI feature team has to remember to wire in. Programs that delegate AI security to the AI feature teams discover the gaps when an incident happens. Programs that build the enforcement at the infrastructure layer produce consistent records across teams.

DeepInspect for CISOs: Board-Level AI Risk in Audit-Ready Evidence

CISOs sit between three pressures that did not exist in their current form eighteen months ago. The board asks for specific numbers on AI risk exposure. The regulators ask for per-decision audit records sufficient to reconstruct risk situations. The procurement team asks them to sign off on enterprise AI deployments whose architecture they did not get to design. The artifacts that satisfied the board on cloud risk five years ago do not satisfy the board on AI risk today. The shape of the question has changed. I want to walk through the three architectural facts that shape what a CISO can credibly report and where the gaps in most enterprise AI programs lie today.

The questions boards ask about AI risk

The board does not ask "are we doing AI security." The board asks specific questions. How many employees used unauthorized AI tools last month. How many of those interactions exposed PII or NPI. How many AI-related vendor incidents in the last twelve months. What is our exposure under the EU AI Act and Fannie Mae LL-2026-04. What is the breakdown of AI activity by department, by data classification, by model provider. What did our AI agents do last week that we cannot reconstruct from the records.

These questions cannot be answered from a policy document. They have to be answered from a per-decision audit record at the AI request boundary. Programs that have not built the architecture cannot produce the numbers. The board notices.

The three architectural facts

Fact 1: Shadow AI is the largest single AI risk most enterprises carry

IBM's Cost of Data Breach Report found that one in five breached organizations experienced breaches linked to shadow AI. Shadow AI breaches cost $670,000 more on average and take 247 days to detect. Cloud Radix reports that 78% of employees use unauthorized AI tools at work and 77% admit to pasting sensitive business data into unsanctioned models. 86% of IT leaders are blind to these interactions.

DLP cannot see this traffic. The prompt travels as an HTTPS POST to api.openai.com or claude.anthropic.com or another model endpoint. Network DLP sees encrypted web traffic. The classification decision the DLP product was designed to make does not happen at the prompt layer.

Fact 2: AI security has to be inline. Log-and-alert is structurally incapable.

Google Mandiant's M-Trends 2026 report, based on 500,000+ hours of frontline incident response, found that the median time between initial access and handoff to a secondary threat group collapsed from over 8 hours in 2022 to 22 seconds in 2025. At that tempo, asynchronous controls do not prevent damage. They produce forensic value. Prevention requires the decision to happen before the request reaches the model.

A blocked request never reaches the model. A blocked response never reaches the user. Enforcement overhead is under 50 ms in production tests, against an LLM inference baseline of 500 ms to 5 seconds. The overhead is invisible relative to the model's response time.

Fact 3: Applications cannot audit themselves.

When the application that generates an AI decision also writes the compliance log, the audit record has three failure modes. Selective logging records successes and "misses" edge-case failures. Suppression lets the same system that failed modify the log. Loss on crash means the action commits but the evidence does not. True audit independence requires a decoupled proxy architecture that writes the record before the response returns to the application.

This is the self-attestation problem that vendor liability silence highlighted earlier this year. The CFO does not sign the audit of financial statements they prepared. The same standard has to apply to AI decision logs.

What a production CISO program produces

A program that satisfies the board, the regulator, and the procurement team produces the same evidence layer for all three. A per-decision audit record at the AI request boundary that captures identity, role, policy version, data classification, resource, outcome, and timestamp. The record is signed, tamper-evident, and committed before the application receives the model's response. The application that ran the request never had custody of the write path.

From that evidence layer, board metrics fall out. Regulatory disclosures fall out. Vendor risk reviews fall out. Programs that have built the evidence layer can answer every question with specifics. Programs that have not built it answer with documentation.

Regulatory exposure CISOs carry now

EU AI Act Article 12 takes effect for high-risk systems on August 2, 2026. Penalties under Article 99 reach €15 million or 3% of global annual turnover. Fannie Mae LL-2026-04 takes effect August 6 for mortgage lenders, with vendor and subcontractor activity in scope. Texas TRAIGA took effect January 1, 2026. California's AI Transparency Act took effect January 1, 2026 for systems with one million or more monthly users. The disclosure obligation sits with the deployer regardless of whether AI ran in-house or through a vendor's product.

DeepInspect

This is the architecture DeepInspect provides for the CISO program. DeepInspect sits at the AI request boundary as an external enforcement layer between authenticated users and agents and any LLM. Every request is evaluated against per-route, per-role policies using identity context the application supplies. Every decision produces a signed audit record bound to the natural person behind the request, with policy version, data classification, and outcome captured.

For board reporting, the records produce the metrics directly. For regulatory disclosure, the records satisfy Article 12 and LL-2026-04 reconstruction requirements. For procurement, the records demonstrate due care that survives a security review.