You can outsource the model.
Not the responsibility.

Enterprise platforms from Anthropic (Claude Enterprise) and OpenAI (ChatGPT Enterprise) give you a genuinely strong security foundation. For an SME financial services firm, though, that foundation is the start of the job rather than the end of it. Regulators in the UK, EU, and US now expect you to understand, govern, and prove out every AI system that touches client data or shapes a decision. This report shows you where the providers stop and where your own responsibilities begin.

This report sets out

Before we look at what providers cover, it helps to be clear-eyed about how much you are exposing in the first place. It falls into three areas.

Native controls in Claude Enterprise and ChatGPT Enterprise as of June 2026. Firms should validate commitments directly against current enterprise agreements, data processing addenda, and each provider's trust portal.

2.1 · Control coverage overlay, grouped by control area

2.2 Summary assessment

Both platforms provide a solid security infrastructure baseline: encrypted storage and transit, no training on enterprise data, SSO, DPA coverage, SOC 2, and ISO 27001. New capabilities in 2025-2026 (BYOK/EKM, Compliance APIs, network isolation, SCIM) meaningfully extend the native control set.

The following ten domains are not covered by platform-native controls and remain your firm's responsibility.

3.1 Full audit trail & decision evidencing

What is missing. Platform audit logs record access metadata, not the full prompt, model response, retrieved RAG context, data sources, or downstream human action. Under ZDR, prompt content is not logged at all: the security control that protects your data also eliminates the record you need for regulatory evidencing.

UK/EU: FCA SYSC 9 (reconstruct transactions & advice); MiFID II Art 25 (suitability); EU AI Act Art 12 (automatic logging, retained 6 months; 10 years for credit & insurance).

US: SR 11-7 & April 2026 interagency guidance; SEC Rule 17a-4 (tamper-evident WORM retention); FINRA Rule 4511. The 2026 guidance makes explicit that LLMs influencing financial decisions are models, a classification firms have avoided by labelling LLMs as productivity tools.

A complete audit trail requires

• Prompt capture with timestamp, user identity, and session context
• Model response capture including tool calls and retrieval steps
• Data source & lineage tagging (which feed, document, or API underpinned the response)
• Downstream action linkage (which decision, document, or client communication resulted)
• Immutable, tamper-evident log storage aligned to regulatory retention
• Human reviewer & approval records where human-in-the-loop is mandated

3.2 Model inventory & SR 11-7 compliance

US: The April 2026 interagency guidance (OCC, Fed, FDIC) makes an LLM materially assisting a financial decision a model, regardless of labelling. Treasury's 230-control AI Risk & Control Matrix (July 2025) translates NIST AI RMF into 230 auditable control objectives for financial institutions.

UK: FCA model risk management principles (SS1/23) require AI/ML models in regulated activities to receive equivalent governance to statistical models, including challenger testing.

Controls required

• Model inventory entry per use case, risk rating, data inputs, regulatory implications
• Conceptual soundness documentation linking model outputs to financial decisions
• Independent validation of high-risk use cases by staff not involved in deployment
• Ongoing performance monitoring with defined drift thresholds and alerts
• Third-party AI due diligence per provider, sub-processors, versions, control evidence

3.3 Role-based access & use-case governance

What is missing. Platform role controls determine who can log in. They do not govern which use cases a user may run, which data categories they may input, or whether a workflow has compliance approval. A junior analyst and a senior portfolio manager may have identical LLM access despite very different entitlements and accountability.

UK/EU: GDPR Art 5(1)(f); EU AI Act Art 26 (deployer role assignments & human oversight); SM&CR (decisions attributable to named individuals).

US: GLBA Safeguards Rule; NYDFS Part 500 (access privilege controls, unique user ID); FINRA Notice 24-09 & Rule 3110 supervision at enterprise and individual levels.

Controls required

• AI use-case register with risk tiering, regulatory mapping, and review cadence
• Role-based entitlements mapped to approved use cases, not just platform access
• Approval workflow for new use cases before staff deployment
• Policy controls on permitted data categories per use case
• Named accountable individuals per use case (SM&CR Senior Managers or equivalent)
• Article 22 safeguards where a use case feeds a solely automated decision with legal or significant effect: a documented human-review route and meaningful information on the logic
• Defined escalation processes for unexpected or borderline outputs

3.4 Data anonymisation & privacy engineering

What is missing. Neither provider automatically anonymises data before it enters a prompt. If staff paste raw client records, trade data, or KYC documents, the model processes identifiable personal data regardless of the no-training commitment, processing that requires a lawful basis, safeguards, and documentation.

UK/EU: GDPR Art 25 (data protection by design); EDPB 2024 guidance on prompt-level personal data; purpose limitation across fine-tuning pipelines.

US: GLBA lifecycle protection; CCPA & state data-minimisation requirements where client personal data enters a prompt.

Controls required

• Pre-prompt anonymisation / pseudonymisation for client-data workflows
• Structured data masking, tokenise account numbers, names, identifiers before prompt construction
• Technical guardrails & staff guidance preventing raw personal data in prompts
• Differential privacy or synthetic data substitution where fine-tuning is contemplated
• Data protection impact assessment (GDPR Art 35) and a record of processing (Art 30) for each high-risk AI use case, refreshed on material change
• Adversarial testing for training-data reproduction (AML.T0024/T0025)

3.5 Output validation & data quality

What is missing. LLM outputs are probabilistic. Neither platform validates that a response is factually correct, current, or consistent with your internal data. Responses that misquote product rates, misstate regulatory thresholds, or fabricate client instructions will not be flagged, identified as a distinct, unmitigated risk by OWASP LLM09 (Misinformation).

UK: FCA Consumer Duty (PS22/9) accurate, non-misleading communications; COBS suitability reflecting verified client data.

US: SEC Advisers Act 206(1)/(2) anti-fraud applies to AI-generated advice; Rule 206(4)-7 compliance programmes. The SEC brought AI-washing enforcement actions in 2025.

Controls required

• Output validation layers for high-risk use cases (credit, suitability, regulatory submissions)
• Data-currency indicators flagging information outdated beyond a defined threshold
• Human-in-the-loop checkpoints before AI output enters client-facing or filing records
• Tagging of AI-generated content (EU AI Act Art 50; Consumer Duty transparency)
• Statistical monitoring of AI outputs at scale for anomaly detection

3.6 Bias & fairness testing

What is missing. Platform content filtering does not test for disparate impact across protected characteristics. Bias in credit scoring, affordability, insurance pricing, or service routing is invisible to general-purpose monitoring. MITRE ATLAS and OWASP LLM09 both identify model bias as a distinct impact category with documented financial risk-scoring examples.

UK/EU: Equality Act 2010 (indirect discrimination); EU AI Act Art 9 (risk management for high-risk AI, incl. discriminatory-outcome assessment).

US: ECOA, Fair Housing Act, FCRA; FINRA Notice 24-09; interagency guidance requires disparate-impact testing for AI-involved credit decisions before deployment. New York's RAISE Act (Jan 2027) adds transparency & incident reporting for frontier AI.

Controls required

• Pre-deployment bias assessment for credit, onboarding, pricing, or eligibility use cases
• Ongoing monitoring of output distributions across demographic proxies
• Fairness scorecard maintained as model documentation
• Alert thresholds & remediation when bias risk increases after data/model updates
• Independent third-party validation for high-risk use cases, documented for examination

3.7 Confidential compute & inference security

What is missing. Standard encryption at rest and in transit does not protect data while a model actively processes it. Data in memory during inference is accessible to the compute infrastructure. For firms handling MNPI or sensitive client data on shared cloud infrastructure, this is a material risk that vendor SOC 2 / ISO certifications do not attest to.

Controls required

• Assessment of whether current inference architecture exposes data during processing
• Evaluation of confidential computing (AWS Nitro Enclaves, Azure Confidential Computing)
• Architecture review for private-cloud / on-prem where inference security is a hard requirement
• Inference-time security included in AI risk assessments & vendor due-diligence questionnaires

3.8 AI agent least-privilege & integration scope

What is missing. When AI agents connect to internal systems via API, the credential typically grants broader access than the agent's function requires, and no native platform mechanism enforces least-privilege at the integration layer. OWASP LLM06 and MITRE ATLAS (AML.T0048; Modify AI Agent Configuration) document this as a high-priority attack surface; OWASP's Agentic AI Top Ten (ASI01-ASI10) extends it to orchestration and multi-agent trust boundaries.

UK/EU: GDPR Art 25; DORA (mandatory Jan 2025) ICT risk management & operational resilience for AI-connected integrations.

US: OCC 2023-17 third-party risk; PCI DSS need-to-know for cardholder data; SEC Rule 17a-4 for agent-produced records.

Controls required

• Scope definition per agent integration: permitted actions, data objects, prohibited operations
• Just-in-time permission grants rather than standing broad access
• Integration tokens in secrets vaults with rotation, never in code or config
• Monitoring of agent API calls against scope, with out-of-scope alerts
• Penetration testing of agent integrations (AML.T0048; OWASP LLM06)
• Regular scope review and recertification as use cases evolve

3.9 Secrets & API key hygiene

What is missing. LLM API keys, vector database credentials, and integration tokens grant access to models, prompts, completions, and connected data. Neither provider manages key storage, rotation, or revocation within your environment. CVEs disclosed in 2025 showed compromised repositories can be sufficient to exfiltrate these credentials, frequently found hardcoded in repositories, config files, or shared environments.

Controls required

• Mandatory secrets vaults (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) for all keys
• Automated rotation schedules and revocation capability
• Repository scanning for hardcoded secrets in CI/CD pipelines
• Inventory of active API keys mapped to owning systems and responsible individuals
• Incident-response runbook for key compromise, including provider notification

3.10 Cross-border data transfers & data sovereignty

What is missing. EU or UK data residency is a configuration option, not a transfer mechanism. The moment a prompt, a retrieved document, or a support interaction reaches a sub-processor outside the UK or EEA, you are making a restricted transfer that you, as controller, must lawfully cover. This is the data equivalent of passporting: your authorisation to operate does not travel with the data unless you put the instruments in place. The same gap governs where data is retained and for how long.

UK/EU: UK and EU GDPR Chapter V (Art 44-49); Schrems II transfer risk assessments; EU Standard Contractual Clauses and the UK International Data Transfer Agreement / Addendum; EDPB supplementary-measures guidance; storage limitation and erasure under Art 5(1)(e) and Art 17.

FS outsourcing & resilience: FCA SYSC 8 and the EBA/PRA outsourcing expectations treat a material LLM provider as outsourcing, with regulator notification, audit rights, sub-outsourcing transparency, and an exit plan. Operational resilience (FCA/PRA PS21/3) requires the service to stay within impact tolerances even if the provider fails.

Controls required

• Map every data flow and sub-processor location before go-live; identify each restricted transfer
• Execute SCCs or the UK IDTA / Addendum with a documented transfer risk assessment per provider
• Maintain a register of processing locations, residency settings, retention periods, and the lawful transfer basis for each
• Treat material AI providers as outsourcing: regulator notification, audit and access rights, sub-outsourcing controls, and an exit / substitutability plan
• Set impact tolerances and a fallback so a provider outage stays within operational-resilience limits
• Reconcile regulatory record-keeping against GDPR storage limitation so data is neither over-retained nor erased before its retention period ends

Of 27 control domains assessed, three are delivered by the provider, one is shared, and the remaining twenty-three sit with your firm.

A four-phase programme spanning roughly twelve months, calibrated for an SME firm with limited in-house AI governance resource. Priority is driven by what causes the most immediate regulatory finding, what is already causing live exposure, and what unlocks the next phase of safe adoption.

Programme summary

Phases 2 and 3 overlap deliberately, model validation and red teaming inform the governance design and should begin while the foundation is still being built, not after it is complete.