This article defines a structured method for evaluating GPAI providers, names the dimensions that matter, anchors the method to current regulation and standards, and explains the practical realities of assessing actors who hold most of the information asymmetrically.
Why GPAI Providers Need Their Own Method
Conventional Information Technology (IT) vendor questionnaires are inadequate for GPAI providers for four reasons.
First, the artefact is non-deterministic. A traditional vendor ships a binary that does the same thing every time it is invoked. A GPAI provider ships a model whose outputs depend on the prompt, the seed, the temperature, the system message, the context window, and the silently updated weights behind the application programming interface (API). Risk is a distribution, not a checklist.
Second, the contract surface is shallow. Most GPAI providers offer take-it-or-leave-it terms. Custom indemnification, audit rights, and source-code escrow — staples of enterprise IT procurement — are usually unavailable to all but the largest customers. Risk assessment must compensate for what cannot be negotiated.
Third, regulation is now binding. The European Union (EU) AI Act, accessible at https://artificialintelligenceact.eu/, imposes documentation, copyright-policy, and training-data-summary obligations on every GPAI provider serving the EU market under Articles 53 and 54. Models classed as having systemic risk (above the 10²⁵ FLOPs threshold) bear additional Article 55 obligations: state-of-the-art evaluations, adversarial testing, incident reporting, and cybersecurity protections. Downstream deployers benefit from these obligations and should require documentary evidence of compliance.
Fourth, upstream change propagates instantly. A model deprecation, safety-filter shift, or pricing change at the GPAI layer can reset the behaviour of every dependent product without warning. Continuous monitoring (Article 10 of this module) is the operational complement to point-in-time assessment.
The Six Assessment Dimensions
A defensible GPAI assessment covers six dimensions. Each maps to evidence the provider should be able to supply or, where it cannot, to a residual risk that the deployer must explicitly accept.
1. Training Data Provenance and Lawfulness
What data trained the model? Was it lawfully obtained? Are copyright, privacy, biometric, and special-category protections respected? The Stanford Foundation Model Transparency Index at https://crfm.stanford.edu/fmti/ documents that even leading providers score weakly here. The EU AI Act now requires GPAI providers to publish a “sufficiently detailed summary” of training content under Article 53(1)(d). Deployers should obtain this summary, evidence of copyright opt-out honouring (Article 53(1)(c)), and any lawful basis assertions for personal-data processing under the General Data Protection Regulation (GDPR).
2. Capability Profile and Known Failure Modes
What can the model do, and where does it fail? Evidence includes published model cards, capability evaluation results, refusal-rate statistics, jailbreak resistance benchmarks, hallucination rates on standard tasks, and known sensitive-topic behaviours. Public leaderboards offer some signal, but provider-supplied internal evaluations against the deployer’s specific use case are far more probative.
3. Safety, Alignment, and Red-Team Evidence
What adversarial testing has been performed and by whom? For systemic-risk models under EU AI Act Article 55, this is mandatory and must be documented. The National Institute of Standards and Technology (NIST) AI Risk Management Framework (AI RMF) at https://www.nist.gov/itl/ai-risk-management-framework provides the GOVERN-6 control family that anchors third-party safety expectations. Deployers should ask for the categories tested, the personas used, the bypass rates observed, and the mitigations deployed in response.
4. Security of the Model Weights and Inference Pipeline
How are weights protected from theft, poisoning, and extraction attacks? Supply-chain Levels for Software Artifacts (SLSA) at https://slsa.dev/ defines four progressive levels of build-pipeline integrity that increasingly apply to model artefacts. The Hugging Face Safetensors format at https://huggingface.co/docs/safetensors illustrates one specific control: a serialisation format that prevents arbitrary code execution at load time. Cloud Security Alliance materials at https://cloudsecurityalliance.org/ provide additional guidance for inference infrastructure.
5. Operational Reliability and Change Management
What is the provider’s track record for uptime, latency, deprecation notice, and silent model swaps? Historical incident data, status-page transparency, and explicit version-pinning options are evidence. A provider that ships unannounced model updates should be assessed differently from one that publishes a deprecation calendar.
6. Governance, Policy, and Regulatory Posture
Does the provider participate in International Organization for Standardization / International Electrotechnical Commission (ISO/IEC) 42001 certification, accessible at https://www.iso.org/standard/81230.html? Does it publish Service Organization Control (SOC) 2 reports? Does it appear on relevant regulatory registers? Does it have a published vulnerability disclosure policy and responsible-AI public commitments? These signals indicate institutional maturity even where direct audit access is denied.
Anchoring the Assessment to Cybersecurity Supply-Chain Practice
GPAI assessment is a special case of broader cybersecurity supply-chain risk management. NIST Special Publication (SP) 800-161 Revision 1 at https://csrc.nist.gov/pubs/sp/800/161/r1/final defines the canonical practice: identify critical suppliers, assess them against documented criteria, monitor them continuously, and plan for their failure. Software Bill of Materials (SBOM) practice promoted by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) at https://www.cisa.gov/sbom is now extending to model artefacts; the Software Package Data Exchange (SPDX) standard at https://spdx.dev/ is being extended to cover model and dataset components. GPAI providers that participate in these standards reduce the deployer’s attestation burden materially.
The Asymmetric-Information Problem
Most of what the deployer needs to know lives inside the provider. This is the structural reality of GPAI assessment. Three mitigations help.
The first is standardised disclosure. Refuse to design a custom questionnaire from scratch; instead, request the artefacts the provider already produces — model cards, transparency reports, ISO/IEC 42001 conformance statements, EU AI Act technical documentation summaries, and FMTI submissions. Providers that produce none of these are signalling their governance posture.
The second is third-party attestation. Independent assessors, regulators, and standards bodies aggregate provider information at scale. The EU AI Office, the U.S. AI Safety Institute, and academic transparency efforts produce evaluations that no single buyer could replicate.
The third is structured residual-risk acceptance. Where information cannot be obtained, document the gap explicitly, assign it to a named risk owner, and revisit it at every contract renewal. Pretending the gap does not exist is the most common failure mode.
Maturity Indicators
| Maturity | What GPAI risk assessment looks like |
|---|---|
| Foundational (1) | Foundation models are selected by engineering teams with no governance involvement; the legal entity behind the model is sometimes unclear. |
| Developing (2) | A simple GPAI questionnaire is sent for new providers; responses are filed but not systematically scored. |
| Defined (3) | All six assessment dimensions are scored; missing evidence is recorded as residual risk; assessments refresh annually or on material model release. |
| Advanced (4) | Assessments inform a tiered list of approved GPAI providers; usage of unapproved providers is blocked at the API gateway; provider failure scenarios are rehearsed. |
| Transformational (5) | The organization participates in industry GPAI evaluation consortia and publishes its own assessment criteria; providers actively compete for the organization’s approval. |
Practical Application
A regulated insurer evaluating two GPAI providers for an underwriting copilot should begin with the same six-dimension grid, populate it with provider-supplied evidence, attach the FMTI score and any ISO/IEC 42001 statement, and then test whichever provider scores higher against its own actual underwriting-question corpus. A provider that scores 70 percent on public benchmarks but 35 percent on the insurer’s domain-specific evaluation set is a worse choice than the reverse, regardless of brand. The output of the assessment is not a number — it is a written, dated decision recording what is known, what is unknown, what residual risk has been accepted, and by whom. That document is the artefact a regulator or board will eventually demand.
The next article (Module 1.10, Article 3) generalises this method to the broader population of AI suppliers — fine-tuners, application builders, and SaaS providers — for whom GPAI-specific obligations may not apply but for whom equally rigorous due diligence remains essential.