Yes, a lighter one. You cannot inspect the weights of a hosted model, but you still depend on it. Record the provider, the model name and version, the terms you accepted, what data you send, and which services call it. That gives you something to act on when a model changes or is retired.
Why a hosted model still belongs in the inventory
When you call a model through an API, the provider owns the weights, the serving stack and the update schedule. That does not remove the dependency. If the provider changes the model behind a name, retires a version or alters its data terms, your product changes with it. An inventory entry lets you answer three questions quickly: what do we depend on, who owns it, and what is affected if it moves.
What an entry should hold
| Field | Why it is there |
|---|---|
| Provider and contract owner | Who to contact and who signed |
| Model name and version string | The exact identifier your code sends |
| Pinned or floating | Whether the name tracks the latest model |
| Endpoint and region, if configurable | Where requests are processed |
| Data sent | Categories of data in prompts and files |
| Data terms | Retention, training use and logging, as stated in the agreement you accepted |
| Services that call it | Blast radius if it changes |
| Fallback | What happens when it is unavailable |
| Review date | When someone last read the terms |
Keep the data terms as a reference to the document and its date. Do not summarize from memory.
Steps
- Search your code and configuration for API client libraries and for model name strings. The same search used for local models finds these too.
- Check environment variables and secret stores for provider keys. Each key points at a dependency.
- For each, fill in the table above.
- Mark each entry as pinned or floating. A floating alias is a change you did not schedule.
- Link the entry to the services and owners that depend on it.
- Review on a schedule and whenever the provider announces a model change.
How this differs from a local model record
For a model you host, you record file digests, license, base model and datasets. For a hosted model, many of those fields are not yours to see, so the record shifts toward contract, data flow and change control. You can ask the provider for documentation such as a model card or system card where one exists, and file it with the entry.
Do not invent values you cannot confirm. "Training data: not disclosed" is a legitimate entry.
What good looks like
A reviewer can open the list and see every hosted and local model, who owns each one, and what data touches it. When a provider announces a deprecation, you search the list, find the affected services and plan the move, instead of discovering it from an outage. When a customer asks which AI providers process their data, you answer from the record.
Quick check
Should I use the same format for hosted and local models?
Use one inventory with a type column. The fields differ, but one list is easier to search and review.
What if the provider will not share training data details?
Record that it was requested and not provided, with the date. That is a fact your risk review can use.
Safeguard scans repositories for dependencies and generates SBOMs, which shows the client libraries you use to reach hosted models. Try a free scan at gold.safeguard.sh/scan. For local model records, see what goes in an ML BOM for a model.
Last reviewed: 19 October 2026.
