20 August 202610 min readConsulting workflows

Which workflows should run on local models? A four-axis scoring method for on-prem vs cloud AI

TL;DR

  • Score each recurring workflow 0–3 on four axes — volume and regularity, sensitivity and residency, stability, and latency and availability — for a total out of 12.
  • Eight or more goes local by default, four or less stays on a cloud API, and five to seven is the hybrid zone where a local model takes the routine share and an API or a person takes the exceptions.
  • Two overrides beat the total: special-category data under GDPR Art. 9 goes local regardless, and a rare, open-ended task stays on an API regardless.
  • On typical scores, invoice extraction lands at 10 of 12, email triage and internal search at 9, contract review at 6 with the sensitivity override, and sales drafting or ad-hoc research at 0–2.
  • The mapping produces three artifacts: a routing map, a hardware plan (one A100-class GPU at about 1,200 pages an hour covers most departments), and a cost line against your API export.

Questions people ask

Which workflows should run on a local LLM?
Workflows that are high-volume, repetitive, sensitive, and need to keep running without an external dependency: invoice and receipt extraction, claims and forms, support and AP inbox triage, internal knowledge search, and routine translation. Scored 0–3 on volume, sensitivity, stability and availability, these typically total 8 or more out of 12, which is the threshold for local by default.
When should I use a cloud API instead of on-prem AI?
When the task is rare, open-ended, low-sensitivity, or so small that a GPU would idle: proposal drafting, one-off research and analysis, and unusual customer correspondence. These score 4 or less on the four axes. A cloud API is also the right home for seasonal spikes beyond a local GPU’s floor, provided personal data is stripped and a processing agreement is in place.
Should contract review run on a local model or on OpenAI?
On the total score, contract clause review usually lands in the hybrid zone at about 6 of 12: low volume and high variability pull it toward an API, while sensitivity pulls it local. The sensitivity override decides: contracts run on a local long-context model, and a frontier API sees only a redacted excerpt when the local answer is uncertain — never the data room.
How much hardware does a local-model workflow need?
Less than most teams expect. A compact document model on an A100-class GPU processes about 1,200 pages an hour, so 60,000 pages a month is roughly 50 GPU-hours — a couple of hours a day on one card, with capacity left for triage and search. Most mid-sized organizations need one GPU, rented in the EU at about €600 a month or owned as an RTX 4090-class workstation.
What does a workflow routing map contain?
One row per recurring workflow with its execution tier (local model, mini API, frontier API or human), the model class, the confidence threshold, the fallback below that threshold, and the data-flow rule stating whether any data may leave the network and in what form. It is the document a DPIA under GDPR Art. 35 and a CFO’s cost line can both reference.
Can a local model handle a workflow that is difficult?
Yes, if the difficulty repeats. The scoring axis is stability, not difficulty: a dense multi-column customs form is hard, but it is hard the same way every day, and a local specialist model that has seen 500 of them handles the 501st. What local models handle poorly is novelty — a different task every time, or one that needs broad world knowledge and long reasoning.

Want this worked out on your documents?

We will price a real sample against OpenAI or Anthropic and tell you whether Local AI consulting or a local model on your hardware is the cheaper first step.