AI Vendor Risk Assessment: A Procurement Checklist

What a risk committee actually needs from AI vendors

Traditional third-party risk management (TPRM) frameworks were architected for static enterprise software: databases, ERP platforms, and monolithic web applications. When applied to machine learning infrastructure, standard security questionnaires routinely overlook the operational vulnerabilities unique to generative models. Asking whether a vendor encrypts data at rest or maintains daily off-site backups does not reveal whether customer inputs are ingested into fine-tuning datasets, whether prompt tokens linger in shared GPU memory, or how model weights are quarantined during multi-tenant execution.

An enterprise evaluation of artificial intelligence systems requires a structured assessment of data privacy and confidentiality exposures rather than generic software metrics. Risk committees must isolate how inputs and outputs move through the inference pipeline, where weights are hosted, and whether the provider operates under enforceable legal jurisdictions.

Moving beyond verbal sales assurances

Sales representations regarding data privacy and infrastructure security often diverge from production reality. Account teams frequently promise that customer data is never retained, only for the underlying terms of service to contain exceptions for abuse monitoring or quality assurance. To build a defensible procurement record that satisfies internal auditors and regulatory bodies, procurement teams must demand written technical commitments embedded directly within contractual agreements and data processing addenda.

• Training data lineage and copyright exposures across proprietary and open-weight architectures.
• Runtime prompt retention, ephemeral KV-cache storage, and memory-scraping vectors in shared compute environments.
• Dynamic model drift, silent weight updates, and abrupt endpoint deprecations that disrupt downstream production systems.
• Transatlantic data routing and jurisdictional exposure under foreign surveillance legislation such as the US CLOUD Act.

A rigorous vendor questionnaire must force infrastructure providers to answer operational questions with concrete technical specifications rather than marketing generalities. By examining continuity, data rights, hosting locations, compliance artefacts, and exit mechanics, procurement teams can separate genuine enterprise infrastructure from brittle wrapper platforms.

Continuity and vendor concentration questions

The rapid pace of development in AI infrastructure has created severe vendor concentration and continuity risks. Many infrastructure providers operate on aggressive burn rates with thin capital reserves, leasing capacity from upstream brokers without owning physical hardware. If a provider faces insolvency or loses access to upstream GPU allocations, downstream applications face immediate service disruption.

Assessing financial runway and capacity commitments

When evaluating a GPU cloud provider, procurement teams must scrutinize the vendor's balance sheet, corporate structure, and hardware ownership model. Providers that broker spot instances across disparate data centres introduce latency instability and sudden capacity reclamation risks, whereas teams managing dedicated hardware deliver predictable throughput.

For transparency, this checklist is published by a provider running its own infrastructure in European data centres rather than reselling brokered capacity. A young company can answer these questions honestly; the point of the questionnaire is that every shortlisted vendor should have to.

Service-level agreements (SLAs) represent another critical continuity checkpoint. Many vendors advertise high availability percentages on public websites but exclude them entirely from self-serve developer tiers. Our own answer: there is no SLA, availability tier, uptime target, or service credit for self-serve Serverless Inference or Smart Routing, because these are self-serve, pay-per-token offerings without individual business contracts. Contractual SLAs and availability tiers are negotiated strictly per business agreement for Dedicated Inference, On-demand GPU VM, Serverless Training, and Large-Scale GPU Cluster products, with no standardized public percentage.

Procurement teams should require vendors to provide real-time, independent observability into platform uptime. We publish our system metrics openly on our public status page at status.lyceum.technology to give engineering and risk teams immediate visibility into service health.

Data privacy and training rights questions

The central data risk in generative AI procurement is unauthorized training on enterprise prompts and outputs. Major foundation model providers differentiate their data retention and training policies across consumer, developer API, and enterprise tiers: OpenAI, for example, states that by default it does not use business data from its API platform or enterprise products for training, while its consumer services are governed by separate controls. A vendor that advertises a strict no-training stance on enterprise plans may still handle data submitted through lower-tier accounts under different terms.

Zero data retention and prompt caching mechanics

Procurement teams must distinguish between verbal promises and technical zero data retention (ZDR). Standard inference engines often retain prompts on local disk for up to thirty days to support abuse filtering and trust-and-safety audits. True ZDR requires that customer inputs and outputs are processed ephemerally in GPU memory (VRAM) without persisting to disk, server logs, or persistent databases.

Our own answer to that question: zero data retention is enforced across all standard inference workloads. Prompts and generated tokens are processed in GPU memory for the duration of the active session and are never written to disk, retained for logging, or utilized to train base models. KV-cache data is isolated to the active session and cleared upon request completion.

A standard Data Processing Agreement (DPA) must accompany any enterprise AI contract to govern data handling under European privacy legislation. Our DPA is available upon request, but we do not maintain or provide a named sub-processor list in the agreement or on demand. Regulated buyers must evaluate whether their internal compliance rules require a named sub-processor schedule or whether a standard DPA framework satisfies their legal obligations.

1. Does the vendor utilize customer prompts, completions, or embeddings to train, fine-tune, or evaluate models on any pricing tier?
2. Is Zero Data Retention enforced technically at the hardware layer, or is data stored in temporary logging buffers for abuse detection?
3. Where is the KV-cache stored during multi-turn conversations, and how is it purged between distinct client sessions?
4. Does the Data Processing Agreement clearly define processor obligations, and what sub-processor commitments are documented in writing?

Infrastructure residency and hosting questions

For regulated European enterprises, data residency cannot be verified by looking solely at where a vendor is incorporated. An AI vendor registered in the European Union may still route API requests to GPU clusters in the United States, subjecting sensitive customer payloads to foreign jurisdiction and violating requirements for GDPR-compliant LLM inference.

Physical cluster topology versus corporate registration

Risk committees must verify the physical location of the data centres where model weights are loaded and execution takes place. If an inference workload executes on hardware subject to the US CLOUD Act, European data controllers face potential regulatory conflicts regarding extraterritorial data access. Maintaining strict European data residency requires infrastructure physically located within the EU/EEA and managed under European legal frameworks.

Our own core compute infrastructure sits in European data centres across Paris and Finland (EU/EEA). We do not operate a data centre in Germany, and procurement teams should take note of this specific geographical footprint when assessing data residency requirements.

Furthermore, sovereignty claims must be evaluated on a per-model basis rather than as a blanket platform assertion. Across our catalogue of 35 open-weight models, 31 run entirely within European data centres. Exactly four models are hosted globally outside the EU: Qwen3.5-397B-A17B, MiniMax-M2.5, Nemotron-3-Ultra-550B, and Nemotron-3-Super-120B-A12B. In addition, Kimi-K2.6 and DeepSeek-V4-Pro offer global opt-in variants alongside their default European endpoints. Global models never receive traffic unless a developer explicitly configures the request for those endpoints.

Security, certifications and evidence to request

Regulated buyers in banking, healthcare, and public sector verticals routinely mandate formal compliance certifications such as ISO 27001, SOC 2 Type II, BSI C5, TISAX, and ISO 42001. These frameworks provide structured assurance that an organization maintains formal policies for access control, cryptographic key management, threat monitoring, and incident response.

Evaluating compliance maturity in emerging infrastructure

The machine learning infrastructure sector is young, and many specialized providers are in the process of building their formal audit frameworks. A common procurement pitfall is conflating upstream data centre certifications with the AI platform's own corporate certifications. A vendor leasing space in an ISO-certified facility does not automatically possess an ISO 27001 certificate for its own software orchestration layer.

In the interest of full transparency, our own answer here is a negative one: we currently hold no ISO 27001, SOC 2, BSI C5, TISAX, or ISO 42001 certifications. We do not distribute an external penetration testing report and we issue no formal EU AI Act conformity statement. We operate as a lean, engineering-led infrastructure team.

• SOC 2 Type II and ISO 27001 audit reports covering the vendor's own software and orchestration layers.
• Independent third-party penetration testing summaries conducted within the last twelve months.
• Vulnerability management and patch disclosure policies detailing remediation timeframes for critical CVEs.
• Encryption architecture documentation detailing TLS cipher suites in transit and AES-256 key management at rest.
• Formal AI governance policies or ISO 42001 frameworks governing training data hygiene and model testing.

When evaluating vendors without formal enterprise badges, risk committees must decide whether architectural controls such as network isolation, transparent open-source inference engines, and verified European hosting compensate for the absence of formal compliance reports.

Commercial terms and exit strategy questions

Evaluating the total cost of compute requires looking beyond raw per-token or hourly GPU rates. Hidden networking egress fees, minimum annual commitments, and rigid scaling tiers can dramatically inflate operational expenditure. Procurement teams must model the full inference cost per token under real-world traffic distributions, factoring in peak loads and idle capacity.

Model deprecation timelines and version drift

Unlike traditional databases, AI models are deprecated on rapid schedules as newer architectures emerge. When a provider retires a model checkpoint, downstream prompts and integrations often break or produce unpredictable outputs. OpenAI's published policy sets minimum notice periods of at least 6 months for generally available models, at least 3 months for specialized variants of those models, and as little as 2 weeks for preview models, so the notice window a buyer can rely on depends entirely on which tier a model sits in.

Procurement contracts must explicitly define minimum notice windows for model deprecations and establish whether legacy weights can be transitioned to dedicated instances. If a vendor discontinues an endpoint on short notice, your engineering team bears the unplanned engineering cost of re-benchmarking and prompt engineering on a new model.

Vendor lock-in is another key risk. Proprietary APIs with custom SDKs make migrations expensive and time-consuming. Regulated buyers should mandate open standards, such as full OpenAI SDK compatibility, ensuring that switching inference providers requires changing only the base URL and API key rather than rewriting application code.

How to score the answers and decide

When scoring vendor risk assessments, risk committees should weigh technical precision and contractual honesty over polished sales rhetoric. In AI infrastructure, a provider that openly documents its architectural boundaries, current certification gaps, and specific hardware locations presents a lower operational risk than a vendor that provides ambiguous, unverified assertions.

Weighting transparency over generic compliance marketing

A vendor score should reflect four primary pillars: verifiable data sovereignty, technical zero data retention, operational continuity, and commercial flexibility. If a workload involves non-sensitive data, a missing ISO certificate may be acceptable if balanced by substantial cost efficiencies and standard API compatibility. Conversely, for workloads involving protected health information or regulated financial records, strict European data residency and dedicated hardware isolation are non-negotiable prerequisites.

1. Distribute the AI procurement questionnaire across all shortlisted infrastructure providers.
2. Verify technical and residency claims against physical cluster architecture and network topology.
3. Review the exact data processing addendum, zero data retention terms, and deprecation policies in writing.
4. Score responses based on verifiable technical evidence rather than self-asserted marketing claims.

Rigorous due diligence enables engineering teams to deploy artificial intelligence with confidence, knowing their infrastructure rests on a compliant, transparent foundation. Send this checklist to every shortlisted provider, including us.