When AI workloads can change destinations through fallback routing, model updates, or new external services. Static manifests show intended egress, but runtime AI-BOM shows actual recipients of PHI. If BAA scope is part of the control objective, runtime observation has to take priority.
When runtime AI-BOM should outrank a static manifest
Healthcare teams should prioritise runtime AI-BOM when the question is not “what was approved?” but “what actually handled PHI?” That becomes important as soon as model routing, fallback services, or external dependencies can change during operation. In those cases, the manifest is still useful, but it is no longer the best control record for exposure, destination, or BAA scope.
Static manifests are strongest when the AI path is stable: the model, endpoint, and downstream service set do not change materially between reviews. They give procurement, architecture, and governance teams a baseline for intended integration design. Runtime AI-BOM becomes the decision source when the workload can select alternate models, call new vendors, or shift traffic based on availability, performance, or product updates.
The practical distinction is that a manifest captures declared intent, while runtime observation captures actual behavior. For healthcare, that matters most when PHI may leave the original trust boundary through orchestration logic, prompt routing, agent tool use, or SDK-level failover. In that setting, the control question is less about documentation completeness and more about whether the team can prove where sensitive data flowed at a specific point in time.
Why intended egress can diverge from actual PHI recipients
AI systems often change their recipient set without any visible change to the declared architecture. A fallback model may be invoked when latency rises, a hosted provider may be swapped during deployment, or a tool chain may call an external service that was not present when the static inventory was signed off. If that new recipient touches PHI, the compliance impact follows the runtime path, not the original diagram.
That is why runtime AI-BOM is the better control when BAA scope is part of the objective. BAA coverage depends on which service actually received protected data, not which service the team expected to receive it. A static manifest can support due diligence, but it cannot by itself prove that the current processing path remains inside the contracted boundary.
AI Supply Chain Security and AI-BOM Guide is useful here because AI-BOM discipline is not just about listing models, it is about recording the supply chain, tools, and credential-containment assumptions that shape real exposure.
NIST SP 800-190 Container Security also fits this problem well because container and runtime controls are where the effective egress path is often enforced, observed, or broken.
What healthcare teams should treat as the control boundary
For this decision, the control boundary should be the data path that can be demonstrated in production, not the path that was approved at design time. If the AI workload is static, tightly pinned, and externally sealed, a manifest may be enough for most reviews. If the workload can redirect, chain tools, or update providers dynamically, runtime evidence should become the primary artifact.
That means the team should expect the runtime AI-BOM to answer questions such as which model handled a request, which external service saw the payload, and whether the observed destination set matches the BAA-covered set. A manifest remains a planning document; runtime telemetry becomes the operational source of truth when privacy, contracting, or breach response depends on the exact route.
CIS Controls v8 supports this posture because inventory, access, logging, and configuration management are all needed to make runtime evidence trustworthy.
ISO/IEC 27001:2022 Information Security Management is also relevant when teams need a governance model that ties documented control intent to evidence of operating effectiveness.
When to switch from manifest-led review to runtime-led review
Use runtime-led review when any of these are true: routing can change automatically, the workload depends on third-party model hosting, tool or agent behavior is dynamic, or the data classification is high enough that a hidden recipient creates unacceptable exposure. In those cases, the team should assume the actual AI-BOM may be broader, shorter, or simply different from the static version.
Health systems should also switch when the review goal is incident containment or legal assurance. If an investigation asks where PHI went, the manifest can describe intended architecture, but only runtime records can bound the exposure window and identify the real recipients. That is the point where stale documentation becomes a liability rather than a comfort.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Runtime AI-BOM depends on observable execution and recipient evidence. |
| CM-8 — System Component Inventory | AI-BOM is an inventory of models, tools, and external services in use. | |
| SA-9 — External System Services | BAA scope depends on actual third-party services that receive PHI. | |
| Recommendation — Log AI request routing and downstream recipients for PHI-bearing flows. Maintain an inventory of AI components and update it when routing changes. Review and constrain external AI services that can process PHI. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Runtime AI-BOM exposes which suppliers actually receive protected data. |
| A.8.15 — Logging | Runtime observation requires trustworthy logs of AI activity and egress. | |
| Recommendation — Map live AI data flows to supplier obligations and contract scope. Enable logging that can prove actual AI recipients and data paths. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | AI runtime routing and external calls depend on controlled access paths. |
| Recommendation — Restrict AI service access so runtime recipient changes stay bounded. | ||
Practitioner Guidance
What to verify: Confirm that the runtime AI-BOM records the actual model, service, and tool recipients for PHI-bearing flows, not just the approved vendor list. If you cannot correlate a request to a live recipient set, the control is not yet strong enough for BAA scoping or incident response.
Decision rule: If the workload can alter its downstream recipient without a human change ticket, treat runtime observation as the primary evidence source and keep the static manifest as supporting documentation only. If the path is fixed and externally sealed, the manifest can remain the lead artifact for periodic review.
What good looks like: The architecture team can explain why the runtime recipient set matches the contractual boundary, and security can prove that any deviation is detected quickly enough to act on it before PHI exposure spreads.
Practitioner takeaway: In healthcare, the safest control is the one that reflects where PHI actually went, not where the design said it should go.
Related resources from NHI Mgmt Group
- Should security teams prioritise runtime reachability over static AI inventory?
- When should organisations prioritise runtime AI controls over static approvals?
- When should teams prioritise runtime API discovery over static scanning?
- When should organisations prioritise static discovery over runtime-only AI security controls?