Emergency management relies on a third-party foundation model hosted outside city infrastructure for draft situation summaries. How should the AI asset inventory treat that model?

Including the externally hosted foundation model as an AI asset subject to municipal inventory and classification is the action that brings it under municipal governance. The model is a critical dependency for emergency management decision-making; whether it is city-built or third-party-hosted does not change its importance to operations or its need for oversight. Formal inventory and classification capture: (1) the model's location and access method (API endpoint, vendor account), (2) performance characteristics (uptime SLA, latency), (3) configuration (model version, prompt settings), (4) monitoring (does the city alert on model errors or slow responses), and (5) fallback plan (what does emergency management do if the model is unavailable). Externally hosted models require contractual governance (SLA review, incident escalation) more intensely than on-premise models. Recording it only in the procurement catalog as a cloud service for contract tracking is an artificial scope boundary: a billing and vendor-tracking entry captures who gets paid, not the AI-specific fields—model version, classification, monitoring, fallback—that the municipal AI inventory exists to hold, so the dependency stays invisible to AI governance even though it is paid against. Inventorying only the draft situation summaries as municipal records referencing the foundation model via vendor documentation creates the same blind spot: it files the model's output as a record but leaves the model itself identified nowhere except a vendor's own paperwork, so the formal inventory—the one auditors, continuity planners, and incident responders actually consult—still shows nothing. Classifying the externally hosted foundation model in the operational technology register as decision support software is a mismatch: an OT register built for radios and sirens doesn't capture model version, prompt configuration, or AI-specific monitoring and fallback, so filing the model there satisfies a checklist item without producing the oversight the AI inventory is meant to provide. Operational check: confirm the emergency-management AI asset inventory includes: (1) the vendor name and model version, (2) the SLA (uptime guarantee, response time), (3) configuration (which emergency decision types trigger the model, what prompts are used), (4) monitoring details (how the city is alerted to model failures), and (5) fallback procedure (manual decision-making process if model is unavailable).