Routing Policy

Routing policy is the set of rules that determines which model, tier, or fallback path handles each AI request. When the policy is weak, organisations can under-protect high-stakes work or over-spend on routine tasks.

Expanded Definition

Routing policy is the control layer that decides how an AI request is directed across models, tiers, tools, or fallback paths. In practice, it sits between user intent and execution, translating business rules into routing decisions such as which model can answer a sensitive query, when a cheaper tier is acceptable, and when escalation is required. For NHI Management Group, the important distinction is that routing policy is not the same as model selection alone. It includes conditions for risk, data sensitivity, latency, cost, and availability, and it may also account for whether an agent has permission to invoke tools or reach downstream systems.

Definitions vary across vendors and platforms because no single standard governs this yet. Some environments treat routing as an orchestration concern, while others fold it into AI governance or application policy. The security relevance becomes clearer when aligned with the governance structure of the NIST Cybersecurity Framework 2.0, where decision logic should support risk-informed control rather than ad hoc automation. The most common misapplication is treating routing policy as a cost-saving switchboard, which occurs when organisations send sensitive or regulated prompts to a lower-assurance path without explicit review criteria.

Examples and Use Cases

Implementing routing policy rigorously often introduces operational complexity, requiring organisations to weigh faster, cheaper responses against stricter control over sensitive or high-impact requests.

• A healthcare assistant routes routine benefits questions to a lightweight model, but sends clinical or personal data prompts to a higher-assurance path with tighter logging and access controls.
• An internal finance copilot routes invoice summarisation to a standard model, while payments advice or anomaly investigation is escalated to a more constrained model and human review.
• An agentic workflow routes read-only tasks to one model tier, but blocks tool execution unless the request satisfies policy conditions tied to authorisation and context.
• A customer support platform routes low-risk FAQ traffic to a low-cost model, then falls back to a safer or more accurate model when confidence drops or policy thresholds are crossed.
• Security teams may map routing logic to the governance ideas in NIST CSF 2.0 so that decisions about sensitivity, recovery, and oversight are explicit rather than implicit.

In mature environments, routing policy is also used to separate public, internal, and regulated workloads. That separation helps reduce unnecessary exposure of secrets, personal data, or privileged instructions, especially when an LLM is embedded inside a broader workflow. The same routing logic can also enforce fallback behaviour when a preferred model is unavailable, which matters because availability controls are part of security design, not just uptime engineering.

Why It Matters for Security Teams

Routing policy matters because it determines where trust boundaries are placed in AI operations. A weak policy can route sensitive prompts, confidential documents, or agent actions to a model path that was never intended for that risk level. It can also create governance gaps when the policy does not distinguish between ordinary content generation and requests that trigger tool use, external retrieval, or downstream execution. For security teams, the issue is not only model quality but also whether the correct control path is applied before the request reaches the model.

This becomes especially important in agentic AI and NHI governance, where the routing layer may decide which identity, credential, or permission set is used for an action. A poorly designed policy can allow a low-risk interaction to inherit excessive privileges, or block a legitimate high-stakes workflow because no safe fallback exists. Organisations typically encounter the operational cost of weak routing only after a data exposure, an unsafe automated action, or a service outage, at which point routing policy becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who should own routing and retention policy when telemetry spans security and IT?
• Who is accountable when routing policy or telemetry retention fails?
• Model routing policy
• Policy-based routing