Shadow AI for Finance: MNPI, DORA, and the Audit Gap

A typical investment bank's compliance stack covers email, Bloomberg chat, voice, and trading communications. The compliance stack does not see AI prompts. When an equity analyst pastes a draft earnings model into Claude to clean up the assumptions, the prompt carries material non-public information into a third party the bank has no surveillance arrangement with. When a credit underwriter feeds an internal credit decision memo into ChatGPT to summarize, the prompt crosses a books-and-records boundary the bank's regulator expects to be preserved.

The historical surveillance stack was built for human-to-human communication channels. Shadow AI is a human-to-machine channel that bypasses every one of those stacks. DORA Article 28 attaches a third-party risk obligation that the bank cannot satisfy with an "we did not authorize that usage" answer.

I want to walk through how shadow AI surfaces in trading, research, and operations, and what the architectural fix actually requires under DORA, SR 11-7, and the EU AI Act.

Shadow AI

Shadow AI in financial services is AI usage by traders, analysts, underwriters, operations staff, and risk teams that operates outside the firm's sanctioned AI program. Cloud Radix found 78% of employees across industries use unauthorized AI at work. The financial services number tracks the cross-industry baseline closely, with concentration in research, operations, and middle-office functions.

The usage patterns that matter for compliance:

• Equity research analysts pasting earnings models into models to stress-test assumptions
• Credit underwriters summarizing internal credit decision memos
• Operations staff translating wire transfer instructions or reconciliation breaks
• Risk teams feeding portfolio composition data into models for narrative generation
• Investment banking junior staff cleaning up CIM drafts

Each pattern moves data that should never leave the firm into a third party.

What financial regulators expect

The SEC, FINRA, OCC, and PRA expect firms to maintain records of decisions material to the business. The expectation predates AI. The records rule applies regardless of where the decision-supporting analysis happened. SR 11-7 on model risk management requires governance, validation, and documentation for models that affect firm decisions. SR 11-7 was written for traditional statistical models. Regulators have signaled that AI assistance falls under the same governance posture.

DORA Article 28

DORA Article 28 requires financial entities to manage ICT third-party risk, including obligations on third-party providers that are critical to the financial entity's operations. Shadow AI creates a third-party dependency the firm never registered. When the model provider has access to draft trade ideas or credit memos, the firm has an unmanaged third-party risk under DORA.

DLP and surveillance blind spot

The financial services compliance stack has invested heavily in surveillance. Bloomberg chat archival, voice transcription, email DLP, and trader communication monitoring run continuously. Shadow AI moves outside every one of those channels.

Identity correlation

The egress packet from the analyst's workstation to api.openai.com identifies the source IP and the destination. The packet does not carry the natural-person identity of the analyst, the desk they sit on, the deal team they belong to, or the information barrier policy that should have applied to the prompt. Without identity correlation, the egress event becomes a network-noise alert.

Data classification

DLP classifies at the document level. The analyst's prompt mixes the company name, the ticker, the draft earnings model, and the confidential research view in one buffer. The classification needs to apply at the prompt level, recognizing MNPI markers that exist only when combined.

Information barrier enforcement

Investment banks operate information barriers between research and banking, between private side and public side, between deal teams covering competing transactions. The barriers are enforced through email rules, distribution lists, and physical office separation. Shadow AI traffic does not pass through any of those enforcement points. A research analyst with a personal ChatGPT account can paste draft research that has not yet been approved by Compliance into a model the firm has no agreement with.

Governing shadow AI in finance

A workable governance posture for shadow AI in financial services has four layers.

AI traffic identification

The firm's egress proxy or HTTP enforcement layer must recognize AI traffic as a distinct class. The destination list includes the major model providers and the dozens of vendor SaaS endpoints that embed AI under their own infrastructure.

Identity mapping with desk and barrier context

Every AI request must carry the natural-person identity of the analyst, trader, or staff member. The identity context must include the desk and any information barrier groups. The HTTP enforcement layer reads the identity header on every AI request and attaches the verified identity, desk, and barrier set to the audit record.

Prompt-level classification for MNPI markers

Inside the prompt, the enforcement layer needs to detect MNPI markers. Ticker symbols combined with forward-looking statements, deal codenames, draft research language, position data, client identifying information. Detection runs at the prompt layer.

Inline policy enforcement

Detected MNPI triggers a policy decision: permit with redaction, deny with audit, or escalate to Compliance review. The decision happens before the prompt reaches the model. The audit record satisfies SR 11-7 documentation expectations and DORA Article 28 third-party risk evidence.

DeepInspect

This is the layer DeepInspect operates at. The HTTP proxy sits inline between financial applications and the LLM APIs they call. For every request, the proxy reads the identity from the application's header, classifies the prompt content for MNPI markers, evaluates per-desk and per-barrier policy, and writes a tamper-evident audit record before the model receives the request.

The compliance fit is structural. The audit record identifies the analyst or trader, the desk, the information barrier set, the data classification, the policy version, and the outcome. The record satisfies SR 11-7 model risk management expectations for AI assistance and DORA Article 28 third-party risk evidence at the same time. The proxy applies the same policy to a firm-built analytics tool, a vendor SaaS embedding a model, or a browser extension forwarding text.

If your firm is facing DORA Article 28 obligations on AI third-party risk, Book a demo today.