How a Customer-Hosted AI Runtime Affects an AI Vendor's Third-Party Risk Tier

How AI vendor risk tiering works

Tiering assigns oversight in proportion to risk. Banking third-party guidance states that not all relationships present the same level of risk or require the same oversight, and that assessments commonly weigh the magnitude of potential harm and the likelihood it will occur. There is no single prescribed method.

The factors in use are consistent across frameworks. The 2023 interagency guidance on third-party relationships describes the nature of an arrangement through volume of activity, use of subcontractors, technology needed, interaction with customers and use of foreign-based third parties. The NIST Generative AI Profile suggests factors such as data protection requirements, dependencies between the AI system and other IT or data systems, cadence of vendor releases and updates, human review of outputs, and legal or regulatory requirements.

Some of these depend on where software runs and where data is processed and stored. Others do not. A defensible reassessment separates the two groups instead of treating the deployment model as a single discount.

One scoping note. The proposed US banking third-party risk guidance, published in the Federal Register on September 15, 2026, is proposed guidance and sets no enforceable standards as of November 2026. It applies to banking organizations, so other sectors should treat it as a reference only.

Which tiering factors move and which stay

The mapping below is analytical. It tests each factor against a runtime that sits in the customer's cloud. Your own methodology may name these factors differently, and the outcome for each remains a judgment the assessing team has to evidence.

• Data egress and vendor-side custody: Can decrease. If prompts, outputs and evidence stay inside the customer boundary, the vendor does not hold the content. Verify through network and storage configuration, not through a vendor statement.
• Residency exposure: Can decrease. Residency follows the customer's own region and storage choices, provided the runtime and its evidence store are configured accordingly.
• Reliance on vendor attestations: Can decrease for data handling, because the customer can inspect records itself. It does not disappear for how the vendor builds and ships software.
• Software supply chain: Unchanged. Vendor-delivered code, models and components carry provenance and integrity questions wherever they run.
• Update and remote support access: Unchanged, and possibly more prominent. Release cadence is a tiering input, and any vendor path into the customer environment stays in scope.
• Use-case criticality: Unchanged. The consequence of failure depends on what the AI is used for, not on where it is hosted.

Why the unchanged factors still drive the tier

Supply chain guidance treats provenance and integrity as continuing concerns. OWASP's LLM supply chain entry recommends model integrity checks with signing and file hashes, software and dataset bills of materials with regular audits, and vendor attestation for models deployed at the edge. These controls address artifacts the vendor delivers, so they apply whether the runtime sits in the vendor's cloud or the customer's.

Update delivery is a separate input. A customer-hosted runtime still receives vendor releases, and the cadence of those releases is named as a tiering factor. The assessor should ask how updates are signed, verified and approved before they run, and what access the vendor retains for updates or remote support. A self-managed model can reduce what the vendor sees while leaving the vendor a way in. The reduction in data exposure does not offset that path, so each needs its own evidence.

Criticality is determined by the use case. NIST supply chain guidance advises analyzing criticality, threats, vulnerabilities, likelihood and impact. A runtime that mediates a consequential decision keeps its weight in the tier even when the data never leaves the building. Dependencies between the runtime and other systems also remain, since NIST lists them as a tiering factor.

Finally, scope boundaries matter. NIST's secure development profile for generative AI addresses cybersecurity risk only and treats deployment and operation as out of scope, so privacy and other risks need separate management. It also notes that an acquirer and a producer can agree which party is responsible for each practice and how each will attest to conformance. In a self-managed deployment, that split should be written down.

Customer-held evidence compared with vendor attestations

NIST supply chain guidance says supplier controls can be verified through supplier self-assessment, acquirer review or third-party assessment. It advises looking first to established third-party assessments, which may not address all of an enterprise's specific requirements. NIST AI RMF adds that a developer's risk metrics may not align with those of the organization deploying the system.

Reports such as SOC 2 Type II or ISO 27001 describe the vendor's controls. They remain useful for the vendor-side factors that a self-managed deployment does not change. Records of what the runtime allowed, redacted or blocked inside the customer's environment answer a different question: what happened to this organization's data and requests. The customer can inspect those records directly, which is why they can support a reduction in reliance on vendor attestations. Neither type replaces the other.

Trussed is one worked reference. It supports self-managed deployment in the customer cloud and enforces policy in the execution path, with allow, redact and block outcomes applied to individual interactions and tool calls at runtime, not reviewed after the fact. Audit-ready evidence generated by that enforcement stays in the customer's environment, with configurable retention and data residency. Trussed has run continuously in production in a regulated enterprise for more than 18 months. Its own SOC 2 Type II and ISO 27001 reports are still vendor attestations, and the supply chain, update and support access factors above still need to be assessed for it like any other vendor. No tier outcome follows automatically.

Documenting the decision

Treat the reassessment as a recorded decision, not a label change. Start from the organization's own tiering methodology and score each factor separately against the deployment model. Reduce only the factors for which the customer holds evidence, and leave the others at their prior values.

NIST AI RMF defines residual risk as the risk remaining after treatment and notes that documenting it informs acquirers about potential negative impacts. Record the residual risk after the deployment model is taken into account, together with the explicit risk acceptance decision. NIST does not prescribe risk tolerance, so thresholds are the organization's to set.

Keep an inventory of third parties with access to organizational content and an approved provider list. Revisit the tier when the vendor's release cadence, support access or use-case scope changes. A self-managed deployment can justify a lower tier on data-related factors. It is one input among several, and the tier should reflect the factors that remain.