Third Parties, Vendors, and Foundation Model Providers

The Stable API That Changed Behavior

A benefits-service assistant calls a provider’s model through a stable alias. The provider updates the model behind that alias. The API remains available, latency improves, and the release note calls the change an upgrade. In production, refusal behavior shifts, citations become less consistent, and the assistant escalates fewer ambiguous cases.

Nothing in the buyer’s application repository changed, but the governed system did.

Buying an AI capability transfers work; it does not transfer accountability for the buyer’s use. The buyer must govern the whole dependency through evidence, independent evaluation, enforceable change controls, production monitoring, and an exit that has survived rehearsal.

Write the Decision Before Reading the Offers

The benefits team should not begin with a leaderboard or a polished demo. It should begin with the work: summarize case material, cite the source record, refuse unsupported conclusions, and route ambiguity to a trained reviewer. It should name the data classes involved, supported languages, response-time and cost budgets, minimum groundedness, unacceptable failures, human authority, and the non-AI fallback. Those requirements turn vendor comparison into a decision instead of a beauty contest.

The sourcing form changes where control and labor sit. An API model offers quick access and provider-operated scale, but behavior, data handling, region, and versions may remain partly outside the buyer’s control. AI embedded in SaaS reduces implementation effort while sometimes hiding the model, evaluation surface, and disable switch. A dedicated managed deployment may improve isolation and operational terms without removing provider dependence. A self-hosted open model exposes more of the stack and gives the buyer more deployment control, while making the buyer responsible for security, maintenance, licensing, evaluation, and capacity. An internal build offers the most design ownership only if the organization can sustain the data, expertise, assurance, and lifecycle cost.

These are allocation choices, not a ladder from weak to strong. Compare each with a reduced-scope or non-AI design. A model can be an impressive product and still be wrong for consequential benefits work.

Draw the Chain Behind the Product Name

The first architecture diagram shows one box labeled model provider. Procurement asks the team to open it.

Behind the API sit a base-model developer; training, adaptation, safety, and evaluation data; an API operator and cloud region; moderation and monitoring services; support and incident teams; and subprocessors that may receive prompts or logs. The buyer adds retrieval, identity, review queues, and perhaps third-party connectors. Open-source packages, adapters, and model artifacts create further dependencies even when no supplier invoice exists.

For every link, the team records what it supplies, which party operates it, which data it can access, where processing occurs, what evidence describes it, who receives a change or incident notice, and how the link can be replaced or closed. Prompts, outputs, feedback, embeddings, fine-tunes, logs, and derived data each need an answer for use, retention, export, and deletion—including backups and subprocessors.

The resulting map reveals the boundary that matters. The provider can describe its service, but only the buyer knows the complete workflow: purpose, user notice, access, retrieval design, acceptance thresholds, reviewer authority, appeals, monitoring, incident response, and retirement. Provider evidence cannot approve that composed system.

Ask What Each Piece of Evidence Can Prove

The team requests model and system documentation, intended and prohibited uses, version policy, evaluation reports, security and privacy evidence, data-flow and retention terms, subprocessor lists, service history, incident procedures, licensing terms, and export and deletion capabilities. A questionnaire helps discover these artifacts; it does not turn their existence into assurance.

Every artifact has a subject, scope, method, date, and exclusions. A security certification may cover a corporate management system but not the product or region in use. A benchmark may omit the team’s languages, retrieval corpus, adversarial users, or cost of a missed escalation. A safety policy may describe provider moderation while saying nothing about the tools and reviewer interface the buyer adds.

The team keeps an evidence-gap register rather than converting missing evidence into a favorable score. A gap may lead to a buyer-run test, a narrower pilot, a compensating control, a contractual obligation, an explicit exception, or rejection. The decision owner and expiry belong beside the gap.

The benefits assistant is then tested as a complete integration. The test set includes difficult source records, contradictory policy passages, sparse evidence, unsupported requests, language variation, access boundaries, and cases that require escalation. It exercises retrieval, prompts, model, policies, interface, reviewer behavior, fallback, latency, and cost. The vendor’s endpoint result is only one observation inside that system test.

Put Control on Both Sides of the Contract Boundary

Suppose the evaluation finds three material risks: the provider can silently change behavior, it retains prompts longer than the service requires, and an outage could strand a claimant mid-workflow. Each risk needs something the team can operate and something it can enforce.

For model change, the team pins a version where possible, maintains regression tests, uses staged exposure, monitors behavior, and keeps rollback ready. It seeks advance notice, useful release detail, a coexistence window, and migration support. For data, it minimizes or redacts prompts, restricts access, configures logging, and verifies deletion; the agreement defines permitted use, training restrictions, retention, locations, deletion, and flow-down to subprocessors. For availability, the application uses timeouts, queues, safe degradation, and a tested manual path; sourcing terms establish service objectives, support, capacity expectations, and recovery communication.

The same pairing applies to security incidents, weak evaluation access, license disputes, and lock-in. Audit and evidence rights are valuable only if a named owner can obtain useful material and change the product in response. A notification clause without an incident route merely delivers bad news on time. A service credit does not restore an exposed secret or a denied benefit.

Terms such as liability, warranties, confidentiality, insurance, intellectual-property allocation, regulatory cooperation, and audit scope depend on the transaction and jurisdiction. Qualified owners must negotiate them. The engineering contribution is to make the real failure modes and required operating controls legible before signature.

Treat a Provider Change as a Release

The stable-alias update now enters the same kind of controlled path as an internal release. The inventory identifies every benefits workflow using the alias. The team obtains the new model identity and release evidence, then repeats the relevant component and end-to-end tests. Because refusal, citation, and escalation behavior changed, risk, privacy, impact, and operational owners reassess the decision. Exposure is staged only while the prior version, another provider, or the manual path remains available.

A release can be material even when the weights do not change. New data use, retention, subprocessors, hosting region, context handling, safety policy, tool capability, license, price, rate limit, or deprecation date can invalidate an earlier decision. Contracts should define which changes require notice, but monitoring must also detect what the provider fails to announce.

In production, the team watches the outcomes users experience as well as supplier health: citation quality, severe errors, refusals, escalation, latency, cost, incidents, status events, support response, subprocessor and policy changes, and signs of operational or financial distress. The question is not whether the vendor is generally healthy. It is whether this dependency still supports the approved use under the recorded conditions.

Open Weights Move the Boundary

After the silent update, self-hosting an open model looks attractive. It would let the team pin weights and choose the deployment region, but it would not make the supply chain disappear. The model and dataset licenses, provenance, integrity, serialized format, inference code, containers, adapters, and dependencies all require review. Someone must track vulnerabilities and upstream changes, patch the stack, rerun evaluations, document limitations, operate capacity, and decide when the artifact is no longer supportable.

The team preserves checksums or signatures and a software and model bill of materials, restricts untrusted serialized formats, and scans code and containers. It tests the same benefits workflow rather than assuming inspectability equals fitness. Open weights exchange one form of dependence for a larger operating responsibility.

Test the Exit While You Still Have Leverage

Before signature, the team runs a small departure. It exports a representative set of configuration and records in a usable format, points a safe test workload at the fallback, rotates test credentials, and measures the work needed to change models. The rehearsal finds that embeddings cannot be reused with the replacement and that deletion evidence excludes one logging subprocessor. Those facts change architecture and terms while alternatives are still available.

A credible exit identifies every dependent system, user, decision, prompt, log, embedding, fine-tune, tool, and record. It explains how service continues during transition or emergency suspension; what can be exported; which replacement or non-AI path has been tested; how access, credentials, data, backups, and subprocessors are closed; which evidence and appeals must survive; who communicates with users and customers; and how deletion, transition, and residual risk are verified.

An exit clause becomes a control only after the organization has tried to leave.

AI Vendor Assessment Questionnaire

Use the questionnaire to produce evidence and decisions, not a pile of completed cells.

• Identity and chain: Which legal entities, models, versions, hosts, locations, subprocessors, open-source components, and support teams deliver the service?
• Use fit: Which intended and prohibited uses, limitations, customer controls, and evaluation access apply to this exact workflow?
• Data: How are inputs, outputs, logs, feedback, embeddings, and derived data used, isolated, retained, transferred, exported, and deleted?
• Assurance: What evaluation, safety, security, privacy, accessibility, incident, audit, and certification evidence exists, and what are its date, scope, method, and exclusions?
• Operations: What service objectives, capacity, recovery, monitoring, abuse response, support, and incident cooperation can the buyer exercise?
• Change: Can the buyer identify and pin versions, receive material-change notice, test during coexistence, reject a regression, and roll back?
• Rights and terms: Which licenses, usage restrictions, confidentiality duties, audit rights, warranties, allocations, and cooperation terms govern the actual use?
• Exit: What is portable, which assistance is available, how does fallback work, and how will access closure and deletion be proved?

Each answer should point to an artifact, owner, unresolved gap, and next action. Reissue the questions when the system or supplier changes; a completed assessment is not permanent permission.

Decide Between Two Imperfect Offers

Return to the benefits assistant. Provider A supplies strong evaluation reports and regional processing, but offers only a floating alias and thirty days’ migration notice. Provider B permits version pinning and a long coexistence window, but its evidence omits two supported languages and its deletion statement does not cover a subprocessor. Neither can be selected from these facts alone.

Write the missing questions and evidence requests. Then choose what the buyer can test, what must become an enforceable term, what requires a narrower pilot, and what would stop the purchase. Draft the operative requirements for a model change: its scope, notice period, evidence, buyer test window, coexistence, rejection or rollback route, and emergency exception. Finally, decide whether the same use should proceed with each provider. Vendor selection and system approval are separate decisions; an acceptable supplier does not make every proposed use acceptable.

The original production failure was possible because a product name stood in for a changing chain of models, data, infrastructure, people, and terms. Once that chain has named owners, evidence, tests, change gates, and a rehearsed exit, procurement becomes part of system engineering. Accountability stays with the organization that puts the capability to work.

Source Notes

• NIST AI RMF Core includes third-party software, data, intellectual-property, internal-control, and contingency outcomes in Govern 6 and Map 4; voluntary guidance verified 2026-07-20.
• European Commission guidance for general-purpose AI providers illustrates how provider role, model classification, documentation, and value-chain information can carry legal significance in the European Union; verified 2026-07-20.
• Contract, audit, privacy, security, open-source, licensing, liability, and regulatory requirements depend on the actual transaction and jurisdiction. Qualified owners should review the final arrangement.
• See Model Selection, Change Management, and Decommissioning.