AI Provider Compliance Review: Security Controls and Evidence
An AI provider compliance checklist is a decision tool that maps an organization's obligations and risks to provider controls, customer responsibilities, and verifiable evidence. It should not ask whether a vendor is compliant in the abstract. Compliance depends on the workload, data, jurisdiction, service scope, configuration, contracts, and the way both parties operate the environment.
The most useful provider review converts each claim into four fields: the control objective, the provider's implementation, the evidence available, and the owner who handles exceptions. This approach helps legal, security, infrastructure, and procurement teams evaluate the same operating model without relying on certifications alone.
Define the Workload and Responsibility Boundary First
List models, datasets, prompts, responses, embeddings, checkpoints, logs, integrations, users, locations, and service levels. Identify which items are regulated, confidential, export-controlled, contractually restricted, or operationally critical. Then map every service that creates, receives, maintains, transmits, or can administratively access them.
Ask the provider for a responsibility matrix covering facilities, hardware, hypervisor or cluster layer, operating system, container runtime, orchestration, identity integration, data, model, application, monitoring, backup, incident response, and deletion. A control is incomplete when each party assumes the other owns it.
Evaluate Eight Control Domains
| Domain | Questions to ask | Evidence to request |
|---|---|---|
| Tenancy and architecture | Which compute, network, storage, and management components are shared? | Architecture diagram, isolation tests, asset and data-flow map |
| Identity and privilege | How are customer and provider administrators approved, authenticated, and reviewed? | Role matrix, access records, session evidence, revocation test |
| Encryption and keys | Who controls keys and which services can decrypt data? | Key architecture, rotation logs, recovery procedure, configuration samples |
| Vulnerability and change | How are firmware, drivers, runtimes, images, and platform components updated? | Patch SLA, scan results, exceptions, change and rollback records |
| Logging and incidents | Can the provider detect, investigate, notify, and preserve evidence? | Event catalog, retention settings, alert test, exercise report |
| Resilience | What failure is covered and how is the full service restored? | Dependency map, backup policy, measured restore and failover tests |
| Location and third parties | Where do data, processing, support, backups, and subprocessors operate? | Location register, access logs, subprocessor list, change notices |
| Lifecycle and exit | How are data, models, logs, keys, and residual copies exported or deleted? | Exit plan, export test, deletion workflow, completion evidence |
Test Tenancy and Privileged Access
Labels such as private, dedicated, and single tenant need a precise boundary. Determine whether exclusivity applies to GPUs, hosts, network fabric, storage, control plane, management tooling, and support accounts. Ask how maintenance access crosses that boundary and whether another customer can influence performance or configuration.
Run negative access tests using real identity paths. Attempt cross-project reads, unapproved image deployment, forbidden network access, and unauthorized privilege elevation. Verify that controls block the action and that logs identify the subject, resource, time, source, and result. Private AI Infrastructure can provide dedicated capacity, but acceptance should still prove the complete isolation model.
Inspect the AI-Specific Change and Vulnerability Process
AI stacks combine firmware, drivers, GPU libraries, container runtimes, model servers, schedulers, notebooks, images, and data tools. Ask how the provider inventories versions, scans artifacts, prioritizes vulnerabilities, tests compatibility, handles exceptions, and rolls back. A generic server-patching statement may not cover the components that actually expose the workload.
Include model and image supply chain controls. Verify artifact provenance, registry permissions, image signing or integrity checks where used, promotion approvals, and rollback. The provider should distinguish infrastructure patching from customer-owned model and application remediation.
Require Operational Evidence, Not Policy Documents Alone
Policies show intended behavior; records show whether the process runs. Request a recent access review, patch report, restore result, alert test, incident exercise, and representative change record. Sensitive details can be protected or reviewed under controlled conditions, but the evidence should still demonstrate dates, scope, outcomes, exceptions, and accountable owners.
Managed AI Infrastructure can cover monitoring, optimization, support, and lifecycle operations. The contract should identify the service objectives, escalation path, evidence cadence, and controls that remain with the customer.
Map Certifications to the Service You Will Use
Reports and certifications can accelerate due diligence, but confirm the legal entity, facilities, services, control period, subservice organizations, customer responsibilities, exceptions, and complementary controls. An organization-level badge may not cover a new GPU site, a managed platform component, or the exact support process in scope.
Build a crosswalk from the customer's control requirements to provider evidence. Mark fully covered, shared, customer-owned, not applicable, and gap. Do not invent equivalence across frameworks; have compliance and legal teams approve the mapping for the relevant jurisdiction and contractual obligations.
Verify Data Residency, Recovery, and Deletion Together
Location controls should cover primary data, derivatives, prompts, responses, logs, snapshots, backups, recovery sites, subprocessors, and administrative access. Test failover because a compliant normal location is insufficient when recovery can move workloads elsewhere. Require advance notice for material changes to sites and subprocessors where the risk decision requires it.
Exit testing should prove data and model export, identity closure, key handling, deletion of active copies, and the scheduled expiry of immutable backups. AI storage architecture should make the lifecycle of each copy visible rather than treating deletion as one storage command.
Run an Evidence-Based Proof of Concept
- Deploy a representative model and approved test dataset through the intended identity and network paths.
- Execute authorized and unauthorized access scenarios across user, service, and provider roles.
- Trigger a security alert and follow notification, investigation, export, and evidence-preservation steps.
- Restore the service into an approved location and validate model, data, permissions, and measured recovery time.
- Export the workload, remove access, initiate deletion, and confirm the treatment of backups and logs.
FAQ
Which compliance certification should an AI provider have?
The answer depends on the customer's industry, jurisdiction, data, contracts, and service scope. Start from applicable obligations, then evaluate whether reports or certifications cover the provider entity, facility, services, period, and subservice organizations in use. Certifications support due diligence; they do not replace architecture review, configuration, contracts, or customer controls.
What is the most important AI provider security document?
No single document proves the operating model. A current architecture and responsibility matrix are essential because they define scope and ownership. Pair them with operational records such as access reviews, patch results, alert tests, restore tests, and incident exercises. The combination connects policy, technical implementation, and observed execution.
How much provider evidence is enough?
Evidence depth should match data sensitivity, workload criticality, architectural exposure, and third-party dependence. A low-risk experiment may need less than regulated production inference. Define evidence requirements before procurement, allow controlled review for sensitive records, and establish a recurring cadence. Escalate gaps that prevent the customer from meeting its own obligations.
Should compliance questions be repeated after contract signing?
Yes. Provider controls, sites, subprocessors, software, and customer workloads change. Monitor critical configurations continuously where possible and perform formal reviews based on risk. Trigger new review after material changes, incidents, acquisitions, new data classes, new regions, or recovery redesign. Compliance evidence is a lifecycle process, not a procurement snapshot.
Summary
Evaluate AI provider compliance by mapping obligations to an explicit service boundary, shared responsibilities, technical controls, operational records, and tested lifecycle outcomes. Organizations can request a OneSource Cloud security and architecture review to turn workload requirements into a provider evidence matrix and acceptance plan.
Related Articles