Two years ago, "responsible AI" was a principles document. Today it's an audit finding. The EU AI Act went into enforcement in 2025. The FTC has issued civil investigative demands to AI vendors who misrepresented their data handling. State-level privacy laws in the US now explicitly extend to automated decision systems. And CISOs at regulated companies — healthcare, financial services, defense contractors, government SaaS — are being held personally accountable for third-party AI deployments they approved.

The challenge isn't that compliance requirements are new. It's that most AI vendor evaluation checklists were written before regulators got serious. The checklist below reflects what actually gets asked in 2026 enterprise security reviews, SOC 2 audits, and HIPAA breach investigations involving AI tools.

Each item includes what "good" looks like — not just what the box says, but what it means in practice for your audit posture.

Section 1: Data Residency & Sovereignty

Item 01 / 15
☐ Data residency is contractually guaranteed and technically enforced
"We store data in US-East" is not a data residency guarantee — it's a current configuration statement that can change with a cloud region migration. Good data residency means your data cannot leave a defined geographic boundary by architectural constraint, not just policy. For regulated industries, this often needs to be in your BAA, DPA, or MSA, not just in the vendor's privacy policy.
✓ What good looks like
Data processed within your own cloud account in your chosen region. BYOC deployment means no data crosses the boundary — contractual guarantees become irrelevant because there's nothing to guarantee.
Item 02 / 15
☐ Subprocessor list is current, disclosed, and auditable
Every AI vendor uses third-party infrastructure: cloud providers, model APIs, monitoring tools, support platforms. Your auditor will ask for a complete subprocessor list. If the vendor can't produce one within 24 hours — or maintains it on a page that hasn't been updated since last year — that's a vendor risk finding before you've looked at anything else.
✓ What good looks like
A maintained, versioned subprocessor list with notification mechanism for changes. Ideally, you appear on no subprocessor list because the vendor never receives your data.
Item 03 / 15
☐ Cross-border data transfer mechanism is documented
Under GDPR, transferring personal data outside the EU requires a legal mechanism: Standard Contractual Clauses (SCCs), adequacy decision, or Binding Corporate Rules. Under newer frameworks emerging in 2025–2026 (UK IDTA, EU-US Data Privacy Framework), the specific mechanism matters. If your AI vendor is US-based and you have EU users, verify which mechanism applies — and that it's executed, not just claimed.
✓ What good looks like
Executed SCCs or equivalent attached to DPA. Better: BYOC deployment where data never leaves your EU cloud region — no transfer mechanism required.

Section 2: Model Audit Trail & Explainability

Item 04 / 15
☐ Every AI decision that affects a regulated outcome is logged with sufficient detail to reconstruct it
The EU AI Act requires "human oversight" for high-risk AI systems — which means a human must be able to review and challenge automated decisions. That's impossible without a complete audit trail. For healthcare AI: which data inputs produced this diagnosis recommendation, at what time, using which model version? For financial AI: what factors contributed to this credit or fraud determination? Logs that say "model returned positive" are not audit trails.
✓ What good looks like
Immutable logs capturing: input data hash, model version, inference timestamp, output with confidence, and the human who reviewed it. Logs stored in your infrastructure, not the vendor's.
Item 05 / 15
☐ Model version is pinned and changes require explicit approval
"We use GPT-4o" doesn't tell you which version, which fine-tune, which system prompt, or when that will change. When a model update changes behavior in a regulated context — a compliance check that now passes, a risk score that shifts — you need to know it happened and approve it. Unannounced model updates in regulated AI deployments are a control failure, not a product feature.
✓ What good looks like
Model version, system prompt version, and configuration pinned in your deployment. Change notifications with 30-day approval window before model updates are applied in your environment.

The explainability gap: Most AI vendors can tell you what the model decided. Very few can tell you why in terms that satisfy an auditor or a regulator who received a consumer complaint. In 2026, "the model said so" is not a defensible explanation for any consequential automated decision in a regulated industry.

Section 3: Access Controls & IAM

Item 06 / 15
☐ AI system follows least-privilege IAM — not broad administrative access
AI agents and automation tools routinely request more access than they need. A compliance monitoring tool that asks for administrator rights to your AWS account is a security incident waiting to happen. Define exactly what resources the AI system reads, what it writes, and what it cannot touch — then enforce that with IAM policies, not trust.
✓ What good looks like
Dedicated IAM role with scoped read-only access to specific services. No cross-account trust without explicit approval. All permissions documented in your access request record before deployment.
Item 07 / 15
☐ Vendor employees have zero standing access to your production environment
"Our support team may access your environment for troubleshooting" is a compliance gap. In regulated industries, any human with standing access to production — regardless of employer — must appear in your access review records, be covered by your background check requirements, and be subject to your access termination process. Most companies aren't equipped to manage vendor employee access with the same rigor as their own employees.
✓ What good looks like
Zero vendor access to your production data. Agents run autonomously in your cloud. If debugging requires data, it uses anonymized logs with your approval for each instance.

Section 4: SOC 2 Type II for AI Systems

Item 08 / 15
☐ SOC 2 Type II report covers AI-specific controls — not just infrastructure
A SOC 2 Type II report for a cloud storage vendor tells you about their access controls, change management, and availability. A SOC 2 report for an AI system should additionally cover: model governance, training data controls, output monitoring, and incident response specific to AI failures. Many AI vendors have SOC 2 reports that were designed for a SaaS product and don't address AI-specific trust services criteria.
✓ What good looks like
SOC 2 Type II with AI/ML-specific controls tested. If the report doesn't mention model governance or AI output monitoring, ask whether those controls are tested elsewhere. If the answer is "we rely on our cloud provider's SOC 2," that's a gap.
Item 09 / 15
☐ Your AI deployment does not expand your own SOC 2 audit scope unexpectedly
Every third-party system that touches your regulated data potentially becomes a new node in your own SOC 2 scope. If your auditor didn't know about the AI compliance tool you deployed six months ago and it touches customer records, you have a scope gap — which can invalidate controls or trigger a qualified opinion. Run your AI vendor decisions through your internal audit team before procurement, not after.
✓ What good looks like
BYOC-deployed AI tools don't appear as new subprocessors because they run in your own infrastructure. Your auditor sees an agent running in your account — same as your own code.

Section 5: HIPAA Considerations for AI in Healthcare

Item 10 / 15
☐ Business Associate Agreement executed before any PHI touches the AI system
HIPAA requires a signed BAA with any vendor that creates, receives, maintains, or transmits PHI on your behalf. "Our AI doesn't store PHI" is not a BAA substitute — if PHI passes through their system even transiently (inference request, log entry, API call), they're a Business Associate. BAA must be in place before first use, not after you discover you needed one.
✓ What good looks like
Signed BAA on file before deployment. Alternatively: BYOC architecture where PHI never reaches the vendor — their system runs in your VPC, BAA may be optional depending on what telemetry is transmitted.
Item 11 / 15
☐ AI-generated clinical or administrative outputs are reviewed by a qualified human before action
HIPAA's minimum necessary standard and the emerging AI Act's human oversight requirements converge on this point: AI cannot be the final decision-maker for regulated health outcomes. Automated prior authorization, clinical documentation summarization, and diagnostic support all require a defined human review step in your workflow — and evidence that the review happened.
✓ What good looks like
Documented review workflow with audit log showing which human reviewed which AI output, at what time, and what action they took. Review step is enforced by the system — not just a policy recommendation.

Section 6: GDPR Requirements for AI Processing

Item 12 / 15
☐ Legal basis for AI processing of personal data is defined and documented
GDPR Article 6 requires a lawful basis for processing personal data. For AI systems making automated decisions, Article 22 adds additional requirements: the right not to be subject to solely automated decisions with significant effects, right to explanation, and right to human review. If your AI system processes EU personal data and influences decisions, you need a documented legal basis that your DPO has reviewed — not a boilerplate "legitimate interests" claim that hasn't been tested.
✓ What good looks like
Documented lawful basis in your record of processing activities (ROPA). DPIA completed for high-risk automated processing. Article 22 safeguards implemented and tested before EU user launch.
Item 13 / 15
☐ Data subject rights (erasure, portability, access) can be honored for data AI systems have processed
If an EU user requests deletion of their data under GDPR, that deletion must extend to every system that holds or processed their data — including AI systems, their embeddings, their fine-tuning datasets, and their inference logs. "We deleted it from our main database" while the AI vendor's system retains an embedding of the user's data is not GDPR-compliant erasure. Most AI vendors have not built deletion propagation into their products.
✓ What good looks like
Documented deletion process that covers AI inference logs, embeddings, any cached outputs. Ideally: BYOC deployment where all data lives in your infrastructure, deletions run in your environment, nothing to propagate to vendor.

Section 7: Vendor Assessment & Continuous Monitoring

Item 14 / 15
☐ Vendor is assessed annually — not just at onboarding
A vendor who passed your security review in 2024 may have changed their data processing practices, updated their subprocessor list, experienced a breach, or changed ownership since then. Annual reassessment is a SOC 2 control requirement and a reasonable expectation from any enterprise procurement policy. Most companies do this for software vendors. Fewer do it rigorously for AI vendors — where the attack surface and the regulatory exposure are higher.
✓ What good looks like
Annual vendor questionnaire cycle with updated SOC 2 report, pen test summary, and confirmation of no material changes to data practices. Automated alerts when vendor posts changes to privacy policy or subprocessor list.
Item 15 / 15
☐ Incident response plan covers AI-specific failure modes
Standard incident response plans cover data breaches, system outages, and ransomware. AI systems introduce failure modes that most IR plans don't address: model output drift producing incorrect compliance findings, prompt injection attacks that manipulate AI behavior, data poisoning of training sets, and AI vendor breaches that expose the inference data you sent them. Your IR plan needs a specific runbook for each category — including who to notify, what to preserve as evidence, and how to assess downstream harm.
✓ What good looks like
AI-specific IR appendix reviewed by your security team and tested in a tabletop exercise. Includes vendor communication protocol, evidence preservation steps for AI incidents, and regulatory notification timeline if PHI or personal data was involved.

The Summary Checklist

Print this. Bring it to your next AI vendor review.

AI Compliance Checklist — 15 Items
☐Data residency is contractually guaranteed and technically enforced
☐Subprocessor list is current, disclosed, and auditable
☐Cross-border data transfer mechanism is documented and executed
☐Every AI decision affecting a regulated outcome is logged in detail
☐Model version is pinned; changes require explicit approval
☐AI system follows least-privilege IAM — not broad admin access
☐Vendor employees have zero standing access to your production environment
☐SOC 2 Type II covers AI-specific controls, not just infrastructure
☐AI deployment does not expand your own SOC 2 audit scope unexpectedly
☐BAA executed before any PHI touches the AI system
☐AI-generated clinical/admin outputs reviewed by qualified human before action
☐Legal basis for AI processing of personal data is defined and documented
☐Data subject rights (erasure, portability, access) can be honored for AI-processed data
☐Vendor reassessed annually — not just at onboarding
☐Incident response plan covers AI-specific failure modes

How BYOC Eliminates 11 of These 15 Requirements

The hardest items on this checklist — data residency, subprocessor disclosure, cross-border transfers, vendor access, SOC 2 scope expansion, BAA necessity, and GDPR deletion propagation — all exist because the AI vendor holds or processes your data on their infrastructure.

Foundri's BYOC architecture inverts this. Our agents deploy directly into your AWS, GCP, or Azure account. Your data never leaves your cloud. What Foundri receives is operational telemetry: run status, completion signals. No raw data. No inference requests routed through our servers. No model trained on your configuration or your user data.

The remaining items — audit trail logging, model version pinning, IAM least privilege, human review workflows, legal basis documentation, vendor reassessment, and AI incident response — are controls you own regardless of vendor. We provide the infrastructure; your compliance team implements the governance layer.

If your current AI compliance posture involves trusting a vendor's SOC 2 badge and moving on, this checklist is your gap analysis. If you're building a regulated AI program from scratch in 2026, start with architecture — it determines how many of these 15 items are existential requirements versus implementation details.