Most AI document processing runs through a cloud API, and for most workloads that is the right answer. You pay per request, somebody else owns the hardware, and the model improves without you doing anything.
There are two situations where it stops being the right answer: when the per-request cost becomes the dominant cost of the process, and when the documents are sensitive enough that sending them to an outside service is a question rather than a formality.
The two reasons to move the processing in-house
Volume economics. A per-request price is excellent when you process a few hundred documents and poor when you process a great many. The cost grows with use, forever, and the processing is not getting cheaper as you get better at it. At some volume the arithmetic inverts and owning the hardware is less expensive than renting the inference.
Where that point sits depends entirely on your own volume and prices, both of which move, so it is worth doing the calculation with your own numbers rather than taking a general rule.
Data residency and privacy. Some documents carry an expectation that they stay inside the business. Legal files are the clearest case: data-residency and privacy considerations apply when legal documents are sent to outside services, and that is a constraint rather than a preference.
A US legal services provider we work with had both reasons at once. They needed to process documents with varying layouts, in batches of up to 100 pages, and cloud AI pricing and data residency were both working against it.
What we deployed
A physical AI server, installed at the client’s own office, sitting behind their own static IP. Not a cloud instance, not a VPS somewhere else, actual hardware in the building where the documents are.
That distinction is the whole point of the exercise, so it is worth being plain about it. “On-premises” sometimes gets used loosely to mean a dedicated cloud tenancy. Here it means a machine you could walk up to.
The flow around it has three parts. The client’s web application hands a document to n8n. n8n routes it to the on-premises AI server. A locally hosted model, Llama-class, processes the document and returns structured JSON, which n8n returns to the application.
No part of that path leaves the client’s own infrastructure, and there is no fee for every request as volume grows.
Why n8n is doing the orchestration
It would be possible to call the model directly from the application. Putting a workflow layer in between buys two things.
The first is that the application does not need to know how document processing works. It hands over a document and receives structured data. If the model changes, or the pipeline grows a pre-processing step, the application is unaffected.
The second is that new document types stop requiring new glue code. Automation workflows connect the application, the processing step and the structured output, and adding a variant is usually configuration in the workflow rather than a release of the main system.
That matters most for exactly the workload described here: documents with varying layouts and formatting, which need flexible extraction rather than a fixed template, and which keep producing new variants.
Structured output is the deliverable
The output that matters is structured JSON, ready to populate the application that needed it, not a PDF someone still has to read.
This sounds obvious and it is where document projects most often stop short. A pipeline that produces searchable text has moved the problem rather than solved it: a person still reads the page and types the values. A pipeline that produces an object matching your data model has removed the step.
On that engagement, documents with varying layouts and page counts are processed into structured JSON, which is what let the client’s own application consume the result directly.
The trade-offs, honestly
Owning the hardware is not free, it is differently priced, and the costs move from a monthly bill to places that are easier to ignore.
The hardware is a one-time investment, and after that the running cost is electricity and upkeep rather than a fee per request. Upkeep is real: the machine needs patching, monitoring and somebody who notices when it stops.
Availability becomes yours. A cloud API’s uptime is somebody else’s problem until you bring the inference in-house, and then it is yours, including what happens on a hardware failure.
Model choice becomes yours too, and it does not update itself. A locally hosted model is the model you installed until you decide to change it, which is a benefit for reproducibility and a cost in keeping current.
And capacity is fixed. A cloud API absorbs a spike; a server has the throughput it has. That is manageable when the workload is batch processing rather than interactive, which it usually is for documents.
None of these argue against the approach. They argue for choosing it on purpose, for a workload where the volume or the data genuinely justifies it, rather than as a default.
This is a different problem from a chatbot
Worth separating, because both get filed under AI. Document extraction is a constrained task with a checkable answer: the value is on the page or it is not. A model answering questions over your business data is an open-ended task where the failure mode is a confident wrong answer, and the engineering is mostly about preventing that. We wrote about that side in why our ERP chatbot gave wrong answers.
The practical consequence is that a smaller local model is often fine for extraction while being the wrong choice for open-ended reasoning over a database.
Where to start
Work out your per-document cloud cost at current volume and at the volume you expect, and see whether the curve crosses the cost of hardware within a period you care about. If it does not, use the cloud API.
If data residency is the driver rather than cost, the calculation is simpler: the question is whether sending these documents out is acceptable, and if it is not, the hardware is the answer regardless of the arithmetic.
We build this as AI and OCR document automation, on-premises where that is the right fit, as part of wider AI integration work. The deployment described here is set out in our on-premises AI document pipeline case study. If you are weighing the two options, get in touch and tell us what you are processing: is the constraint the cost per document, or where the document is allowed to go?
Common questions
Does an on-premises model match a frontier cloud model?
Not across the board. For constrained extraction work against your own documents it can be sufficient, which is the comparison that matters. Judge it on your documents rather than on general benchmarks.
What is the ongoing cost if there is no per-request fee?
The hardware is a one-time cost, and after that it is electricity and upkeep. The upkeep is real work: patching, monitoring and deciding when to move to a newer model.
What happens if the server fails?
You own that risk, which is the honest trade for owning the hardware. It needs to be planned for deliberately rather than discovered, because a cloud API's availability is no longer somebody else's problem.