Which Data Can Go to Which AI Model? Writing a Model Routing Policy for Your Organisation

The Problem No One Has Written a Policy For

Most enterprise AI governance programmes have made real progress on the obvious questions: which models are approved, which vendors are in scope, and whether the organisation needs to comply with the EU AI Act. What almost no organisation has answered in writing is a far more operational question: when a specific piece of data leaves an employee's hands and enters an AI model, which model is that data actually allowed to reach?

This gap is not theoretical. A legal team member pastes a draft acquisition agreement into an LLM prompt. A finance analyst uploads a payroll extract to an AI spreadsheet tool. A customer success manager summarises a support ticket, including personally identifiable information, in a third-party AI assistant. In each case, the organisation has implicitly made a data routing decision — but no one has made it explicitly, and no record exists.

As enterprises move from running one or two AI tools to running genuine multi-model environments — combinations of Microsoft Copilot, OpenAI, Anthropic, Mistral, Gemini, and internal fine-tuned models — the number of implicit routing decisions compounds weekly. A model routing policy is the governance instrument that makes those decisions explicit, consistent, and auditable. This article explains how to build one.

Why 'Just Use Approved Tools' Is Not a Policy

Many organisations believe that maintaining an approved AI tool list is equivalent to governing data flow. It is not. An approved tool list answers the question of which vendors are permitted. A model routing policy answers the question of which data classifications can travel to which model endpoints, under what conditions, with what controls, and with what audit trail.

The distinction matters because the same vendor may offer multiple model tiers with different data handling terms. OpenAI's API with zero data retention enabled is materially different from ChatGPT Enterprise, which is in turn different from the consumer ChatGPT product. Routing a contract to the API is a different risk decision from routing the same contract to a product with training opt-outs that require manual configuration. Approving 'OpenAI' as a vendor does not capture this.

There is also a compliance dimension that a tool list cannot address. Under the EU AI Act, deploying organisations bear obligations that extend to how systems are used, not merely which systems are procured. Article 26 places responsibility on deployers to use high-risk AI systems in accordance with provider instructions and to ensure inputs are relevant and sufficient. If an employee routes sensitive personal data to a general-purpose model that was not designed or evaluated for that data type, the deployer has made a risk decision without a documented basis for it. That absence is an audit finding waiting to happen.

A routing policy creates the documented basis. It takes the approved tool list and adds a second axis: data classification. The intersection of those two axes — model type and data sensitivity — produces a routing rule.

Building the Data Classification Foundation

Before any routing logic can be written, an organisation needs a working data classification scheme that employees can actually apply in real time. Academic classification frameworks with seven tiers and elaborate decision trees are largely useless in practice. For routing purposes, three or four levels are sufficient and operable.

A pragmatic starting point is: Public, Internal, Confidential, and Restricted. Public data is anything the organisation has already made externally available or that carries no meaningful sensitivity — press releases, published documentation, marketing copy. Internal data is business information that is not sensitive enough to cause serious harm if shared inadvertently, but is not intended for external distribution — general internal communications, non-sensitive project updates, aggregate performance data. Confidential data carries a higher potential for harm: commercial contracts, financial forecasts, HR information about individuals, customer data, and legal advice. Restricted data is the highest tier: regulated personal data under GDPR, special category data, material non-public financial information, data subject to confidentiality agreements with specific terms, and any data that regulators or contracts require to be handled with explicit controls.

The classification scheme needs to be defined in a policy document before the routing matrix is built, and it needs to be trained into employees' reflexes. One practical technique is to anchor each tier to a concrete example that the organisation's workforce immediately recognises. Abstract definitions fail; a two-sentence concrete example per tier succeeds. Fronterio's AI estate registry allows data classification tags to be associated with each registered model or workflow, creating a machine-readable version of this foundation layer that feeds directly into routing rule evaluation.

The Traffic-Light Routing Matrix

With a classification scheme in place, the routing policy is built as a matrix. The rows represent data classification tiers. The columns represent model categories — not individual tools, but logical categories that share meaningful characteristics: externally hosted commercial models with training opt-out available, externally hosted commercial models with contractually confirmed zero retention, internally hosted open-weight models, fine-tuned internal models trained on proprietary data, and any purpose-built AI system deployed for a specific high-risk use case. The cells in the matrix contain one of three routing statuses: Allow, Conditional, or Deny.

Allow means the data classification is compatible with the model category without additional controls. A piece of Public data can be routed to any external commercial model without restriction. Internal data might be allowed to reach externally hosted models with confirmed zero retention, on the basis that the residual risk is acceptable given the data's low sensitivity.

Conditional means the routing is permitted only when specified controls are active or when a defined approval step has been completed. Confidential data routed to an externally hosted model with zero retention contractually confirmed might be Conditional on the employee confirming they have removed all direct identifiers from the prompt, and on that confirmation being logged. The condition is not a bureaucratic hurdle — it is a documented control that converts an unmanaged risk into a managed one.

Deny means the routing is prohibited regardless of controls. Restricted data should almost always be Deny for any externally hosted model where the organisation does not have full control over the processing infrastructure. This is not an overreaction; it reflects the reality that GDPR Article 28 requires a data processing agreement with specific terms before any personal data is shared with a processor, and that the EU AI Act's obligations around high-risk system inputs cannot be discharged by a vendor's standard terms.

EU AI Act Obligations That Make This Policy Non-Optional

Organisations operating AI systems classified as high-risk under Annex III of the EU AI Act face explicit obligations that a model routing policy directly satisfies. Article 26(5) requires deployers to monitor the operation of the high-risk AI system and to report serious incidents. That monitoring obligation presupposes a record of what data entered which system — a record that a routing policy and its associated audit trail creates.

Article 27 requires deployers in certain contexts to carry out a Fundamental Rights Impact Assessment before deploying a high-risk system, and that assessment must consider how inputs to the system are controlled. A routing policy that has been formally adopted, with defined conditions for Confidential data and explicit Deny rules for Restricted data, is a concrete artefact that can be cited in the FRIA as evidence of a governance control.

Beyond high-risk systems, the GPAI obligations under Article 50 and Article 72 affect organisations using general-purpose AI models for consequential tasks. Article 73 creates an incident reporting pathway that requires organisations to have sufficient traceability to reconstruct what happened when an AI system produces a harmful output. If there is no record of which data reached which model, Article 73 compliance is practically impossible. Fronterio's Article 73 incident workflow captures the model endpoint, the data classification of the input, and the routing status that was in effect at the time of an incident, creating exactly the reconstruction chain the regulation demands.

Finally, Article 4 requires providers and deployers to ensure their staff have sufficient AI literacy to fulfil their obligations. Publishing a routing policy and training employees to apply the traffic-light logic is a concrete, documentable AI literacy measure — one that regulators can observe when they ask what steps the organisation has taken to govern its AI use.

Writing the Policy Document: Structure and Key Clauses

A model routing policy is a governance document, not a technical specification. It needs to be written in language that a compliance officer can enforce, an auditor can evaluate, and an employee can follow. The structure that works in practice has six sections: purpose and scope, data classification definitions, model category definitions, the routing matrix, responsibilities and enforcement, and review cadence.

The purpose and scope section should be brief but precise. It should name the regulation it is designed to address — the EU AI Act, GDPR, and any sector-specific regulation relevant to the organisation — and it should define which AI systems and data types are in scope. A common scoping mistake is limiting the policy to 'AI tools approved by IT.' If the policy does not explicitly address what happens when an employee uses a personal account on an unapproved model, it leaves shadow AI behaviour unaddressed.

The responsibilities section needs to avoid the trap of assigning everything to IT or security. The routing decision for a specific piece of data is made by the employee who is drafting the prompt. The policy must therefore create a clear individual obligation: the employee is responsible for correctly classifying the data they intend to submit and for applying the routing matrix before doing so. The AI governance function or compliance team is responsible for maintaining the matrix, training employees, and reviewing incidents. This distribution of responsibility is important both for practical enforceability and for demonstrating to regulators that there is a genuine governance structure rather than a notional one.

The review cadence clause should specify that the routing matrix is reviewed at least quarterly, or immediately when a new model is onboarded, a new data category is identified, or a vendor's data handling terms change materially. Model routing is not a set-and-forget governance exercise; the model landscape and vendor terms are moving fast enough that a policy with an annual review cycle will be materially outdated within months.

Operationalising the Policy: From Document to Live Control

A routing policy that exists only as a PDF in a SharePoint folder is not a control; it is a liability. If employees cannot access it in the moment they need it, and if there is no mechanism to log whether routing rules were followed, the policy provides audit theatre rather than audit evidence. Operationalising it requires three things: accessibility at the point of decision, machine-readable rule enforcement where technically feasible, and an audit trail.

Accessibility means that when an employee is about to submit a prompt containing data to an AI tool, they can quickly reach the routing matrix, identify the relevant row and column, and read the routing status. This can be as simple as a pinned Slack message with a link to a one-page matrix, or as sophisticated as a browser extension that surfaces the relevant routing rule based on which tool the employee has open. The medium matters less than the friction: if following the policy requires more than thirty seconds, compliance rates will be low.

Machine-readable enforcement is possible for organisations that route AI traffic through a gateway or that use AI platforms with API-layer controls. In those environments, routing rules can be enforced programmatically — a Restricted-tagged data object cannot be submitted to an externally hosted model endpoint regardless of employee intent. This is the strongest form of control, but it requires technical infrastructure that many mid-market organisations do not yet have. Fronterio's model routing module provides a policy-as-configuration layer that maps the traffic-light matrix onto registered model endpoints, flagging or blocking submissions that violate the active routing rules and logging every evaluated decision for the audit trail.

The audit trail is the governance product that makes everything else meaningful. Every routing decision — whether Allow, Conditional with logged confirmation, or a blocked Deny attempt — should produce a timestamped record that associates the data classification, the model endpoint, the user, and the outcome. That record is what an Article 73 investigation, a GDPR supervisory authority inquiry, or an internal incident review will ask for first.

Maintaining the Policy as the Model Landscape Evolves

The practical challenge of model routing governance is not writing the policy once; it is keeping it current as new models are released, vendor terms change, and the organisation's own AI use cases expand. A policy written in early 2024 for a three-model environment may be applied to an eight-model environment by late 2025, with several of those models operating under terms that did not exist when the matrix was first drafted.

The governance mechanism for this is a model onboarding gate: no new AI model or tool is made available to employees until it has been assigned to a model category in the routing matrix and the matrix has been reviewed against that assignment. This gate does not need to be slow — for a well-established model category, the assignment decision may take thirty minutes — but it must be mandatory. Bypassing the gate, even for a trial deployment, means employees are using a model without a routing rule, which is precisely the condition the policy is designed to eliminate.

Vendor term changes require a lighter-weight but equally systematic process. When a vendor publishes updated data handling terms, the governance team should evaluate whether the change affects the model's category assignment and whether any routing rules need updating. Subscribing to vendor change notification channels and assigning a named owner for each registered model to monitor terms is the minimum viable process. Fronterio's post-market monitoring synthesiser can surface vendor policy change signals alongside internal usage data, providing a single review surface rather than requiring manual monitoring across multiple vendor portals.

The long-term value of a well-maintained routing policy is not merely compliance. It is the organisational confidence to adopt new AI capabilities faster, because the governance framework that manages risk has already been built. When the next capable model arrives, the question is not 'is this safe to use?' but 'which category does it belong to?' — and the answer to that question takes hours rather than months.