AI Deployment Is a Jurisdiction Decision Before It Is a Model Decision

What the paper develops

The boundary comes before the shortlist

Which AI model should the enterprise buy? I would not let that question start the decision. A model can be impressive and still be wrong for the work, data, and authority the business is prepared to defend. The useful first move is to set a provisional operating boundary, then ask which candidates can fit inside it.

That boundary is a jurisdiction in the practical sense. Law is part of it, but so are customer promises, data policy, security architecture, contract terms, and decision rights. Together they determine what the system may touch, what it may do, and who can answer when the workflow changes.

Model-first sourcing reverses that sequence. Teams compare quality, speed, price, integrations, and vendor road maps. Once a favorite appears, they ask where prompts are processed, whether inputs are retained, which people are affected, and whether an automated action crosses a boundary. The preferred option already has sponsors, so a boundary question starts to feel like resistance.

Run a two-pass operating-jurisdiction review

The review has two passes because the model and architecture can change the boundary. Pass one occurs before the shortlist. It fixes the intended use, excluded uses, allowed data classes, maximum authority, accountable owner, and firm operating limits. Candidates that cannot fit are not scored.

Pass two occurs before commitment. Reviewers test the selected model, hosting pattern, workflow, contract, supplier chain, and evidence against the provisional record. Any change to the boundary returns as an explicit governance decision. The team can revise the first pass, but it cannot let a procurement preference revise it silently.

This sequence is timely because the EU AI Act does not arrive as one undifferentiated date. The general 2 August 2026 milestone is real, while GPAI duties began earlier and major high-risk provisions now have later application dates under the enacted Digital Omnibus on AI. A single field marked “AI Act applies” cannot carry that operating detail. The intake record needs the use, actors, affected population, system role, data path, and locations so qualified legal and compliance owners can map the current obligations.

This is not legal advice or a compliance test. It is an operating-boundary method that gives counsel and control owners a reliable fact pattern before the enterprise makes a technology commitment.

Fix five decisions

The review produces five decisions. First, fix the scope: the process, users, affected people, locations, outcome, and exclusions. Second, fix the data boundary: allowed classes, sources, movement, retention, training use, access, deletion, and prohibited inputs.

Third, fix authority. State the strongest action the system may take and the human decision that cannot be delegated. A reviewer needs time, evidence, authority to reject, and a clear standard. A nominal human step that people cannot perform is workflow decoration.

Fourth, fix the responsibility split across the business, technology, data, security, privacy, compliance, procurement, legal, and supplier roles. Shared responsibility becomes governable when each edge has an owner: evidence, change notices, logs, incidents, continuity, exit, and the right to halt use.

Fifth, fix approval and re-entry. Name who approves the provisional boundary, who approves the candidate, and which changes reopen the decision. A new user group, geography, data class, automated action, model family, hosting region, supplier, integration, or major capability can move the deployment into a different jurisdiction.

Keep one decision record

Each decision is complete only when it has an owner, the evidence reviewed, and a clear status: fact, judgment, or open question. Any open condition needs an owner and due point. The record also shows whether the item is provisional in pass one or confirmed in pass two.

Preserve rejected alternatives as well. A local deployment, managed service, smaller model, non-AI workflow change, or a decision to wait may fit the boundary better. Recording the alternatives prevents the chosen path from being remembered as inevitable.

The same record makes change visible after launch. Product, data, supplier, scope, and incident triggers show when the old approval no longer describes the operating system. The response may be confirmation, a control adjustment, a temporary limit, or a stop. Continued use becomes a conscious decision when the boundary moves.

Choose inside the boundary

Once the operating jurisdiction is explicit, model selection becomes more useful. Teams can compare quality on the real task, total operating cost, latency, integration effort, evidence, controls, and supplier terms. A candidate that misses a firm data or authority limit falls outside the decision.

The order is the point: define the work before the tool, the data path before the contract, and the authority before the integration. Name who can approve, stop, and reopen the decision before production. Then choose the model that fits.