AI document and ticket processing built inside your infrastructure: what the engagement looks like without an ML team
Short answer
A company without an ML team can have LLM document and ticket processing built inside its own infrastructure if it brings three things: a person who owns the process and decides what each field means, a set of real documents with the correct answers, and an owner for the system after launch. The engineering side decides where the model runs, builds the pipeline around it, measures accuracy per field on your documents, and hands over code, schemas and the evaluation set. The model is a small part of the work; review, validation and the audit record are most of it.
On this page
What gets built?
The pipeline has the same parts whether it reads claims, support tickets, invoices or KYC files. How each stage works, from intake to the audit record, is explained in an LLM pipeline for claims, tickets and KYC files inside your own infrastructure. What an engagement delivers is those stages as your system.
| Deliverable | What it is |
|---|---|
| Intake and classification | Routing of each document or ticket to a type, with unknown types sent to a person |
| Text and layout extraction | OCR or a layout model, run inside your network |
| Model serving or model access | A self-hosted model, or a contracted cloud endpoint, behind one internal interface |
| Output schemas | One versioned schema per document type, with explicit "not found" values |
| Validation rules | Your existing business checks written as code |
| Review queue | A screen where people confirm or correct the fields that need it |
| Evaluation set | Real documents with correct values, used to score every release |
| Audit record | Per field: source, model and prompt version, rule results and reviewer |
| Runbooks and dashboards | How to operate, monitor, roll back and upgrade the system |
Where does the model run?
"The data must stay inside" can be met in three ways, and each vendor states its data terms differently.
OpenAI states that "data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)", that "abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law", and that exclusion from those logs under Zero Data Retention is available to eligible customers and "subject to prior approval by OpenAI"[1].
Microsoft states that Azure Document Intelligence "temporarily stores data and results in Azure Storage in the same region as the request" and that the data "is then deleted 24 hours from the time that you submit an analyze request", with an API call to delete it sooner; its connected containers "don't send customer data, such as the image or text that's being analyzed, to Microsoft"[2]. Azure's pricing page adds: "Container pricing is the same as cloud service pricing"[3].
AWS's Textract FAQ states that "Amazon Textract may store and use document and image inputs processed by the service solely to provide and maintain the service and to improve and develop the quality of Amazon Textract and other Amazon machine-learning/artificial-intelligence technologies", with an opt-out through an AWS Organizations opt-out policy[4]. Google states: "At Google Cloud, we never use customer data to train our Document AI models"[5].
vLLM, "a fast and easy-to-use library for LLM inference and serving" under Apache-2.0, serves open-weight models on your own hardware behind an "OpenAI-compatible API server", so no model provider receives the documents[6][7].
| Option | Where documents go | What you manage |
|---|---|---|
| Model provider's API under contract | The provider's infrastructure, under its retention terms[1] | Contracts, approvals for retention controls, the provider's retirement schedule |
| Cloud document or model service | Your cloud provider's region, under its data terms[2][4][5] | Region and opt-out settings, quotas, private networking |
| Open-weight model on your servers | Nowhere outside your network[6][7] | Hardware, patching, security of the serving layer, upgrades, on-call |
The trade-offs of the three, with the compliance evidence each one produces, are in choosing an LLM deployment for a closed perimeter; the two serving stacks are compared on vLLM vs Ollama, and the API-or-self-host arithmetic on OpenAI API vs a self-hosted LLM. The choice can also be made per document class: public or low-risk documents can use a cloud endpoint, restricted ones stay on a self-hosted model.
What do you provide when you have no ML team?
- A process owner: the person who today decides what a correct claim, ticket category or KYC field is, and who signs off the rules.
- Real documents with answers: enough per document type to cover its variants, including scans, photos and the difficult cases; the answers can often come from records your back office already keeps.
- Reviewers: the people who will work the review queue, available during the shadow run.
- Security and data protection sign-off: which data classes the system may see, where each may be processed, and how long traces may be kept.
- Infrastructure access: a place to run it, including accelerators if the model is self-hosted; what that takes in practice is in AI on your own servers.
- An owner after launch: an internal team, a vendor under a support agreement, or both.
None of these requires machine-learning staff. They require the people who already run the process.
How does the engagement run?
| Stage | Output | Gate |
|---|---|---|
| 1. Inventory | Document types, volumes, channels, data classes, target systems | Scope and perimeter agreed with security |
| 2. Baseline | Today's handling time and error rate per document type | A number to beat, measured, not assumed |
| 3. First document type | Schema, rules, extraction and evaluation set for one type | Per-field accuracy on the frozen set meets the agreed mark |
| 4. Integration | Review queue, audit record, connection to the target system | End-to-end run on test data, including failures |
| 5. Shadow run | The system processes live documents; people still do the work | Agreement between system and people measured per field |
| 6. Production | Automated fields go live; the rest stay in review | Error rate in the sampled automated fields within target |
| 7. Next types and handover | More document types; runbooks, dashboards, training | Your owner operates a release without help |
Starting with one document type is deliberate. It produces a measured result early, rather than a platform that is judged only at the end, and it tests the review queue and audit record on real traffic before the scope grows.
Which trade-offs are decided early?
- Separate OCR or a vision model reading the page. OCR returns word positions and confidences that routing can use; a vision model can read difficult layouts but returns neither. Measure both on your documents.
- Buy a document platform or build. Platforms come with their own terms: ABBYY's subscription terms state that the term "shall automatically renew for an unlimited number of twelve (12) months renewal terms" unless a party gives written notice "forty-five (45) days prior to the expiration date", and that ABBYY "will charge Licensee for the subsequent amounts due for amounts in excess of the Volume Units purchased"[8]. Building avoids the subscription and adds the operating work; the managed services are compared on Amazon Textract alternative.
- Automation share against error rate. Every field has a threshold; a lower threshold sends more work to people and fewer errors downstream. The threshold is a business decision, taken with the process owner, not a model setting.
- One model or routing by class. Two models mean two quality levels to measure, and routing rules that must be enforced in code.
What should you ask a development company?
- 1.Which of your systems of this kind runs in production, and inside whose perimeter?
- 2.Where will the documents go during development: laptops, annotation tools, test environments?
- 3.How will accuracy be measured, per field and per document type, and who approves the pass marks?
- 4.What does the client need to staff after handover, and what does a normal week of operations look like?
- 5.What happens when the model in use is retired or a better one appears?
- 6.Who owns the code, schemas, prompts and evaluation set at the end?
Who is this not for?
- One standard document type at low volume, where documents may go to a cloud service: a managed document AI service with per-page pricing is simpler; what those services publish about price and data is on Amazon Textract alternative and Azure OpenAI alternative.
- Identity verification with liveness checks that must be certified: a specialised verification vendor fits better, with custom work only around it.
- A company with no one to own the process: without a process owner, rules and pass marks cannot be set, and the pilot will not reach production. The pattern is described in the AI pilot that never reached production.
About amBrain
- We have taken an LLM integration to production inside a client's FinTech perimeter: extracting and normalising unstructured broker and venue notices — corporate actions, instrument and margin changes — into structured records the trading system consumes.
- amBrain deploys private language models inside a client's own infrastructure and connects them to the systems the client already runs.
- amBrain builds retrieval-augmented generation (RAG) systems over a company's own documents.
- Three formats: full delivery, a dedicated team, or engineers embedded in your team.
- The client keeps full ownership of the product and the code, except our reusable components.
Frequently asked questions
Yes, if you provide a process owner, real documents with correct answers, reviewers and an owner after launch. The engineering team brings the model deployment, the pipeline, the evaluation and the handover; machine-learning staff on your side are not required.
Yes. An open-weight model served inside your network, for example with vLLM behind its OpenAI-compatible server[6], means no model provider receives the documents. OCR, the review tool, logs and the evaluation set must stay inside too, since each holds document content.
By measuring it per field and per document type on a frozen set of your own documents with known answers, and by sampling automated fields in production. One global accuracy figure hides the fields that fail.
For standard documents at modest volume, often yes. Building fits when documents may not leave your network, when your rules are specific, or when subscription and volume terms, such as ABBYY's automatic twelve-month renewals and overage charges[8], become the larger cost. Compare both on the same documents.
Either your own team, trained during handover with runbooks and dashboards, or a vendor under a support agreement, or both. Decide before the build starts, because it changes what is documented and automated.
Product and company names are trademarks of their respective owners and are used only to identify their products and published terms. No vendor named here reviewed or endorsed this page.
Sources
- [1]OpenAI, Your data (API guide) (training opt-in, abuse-monitoring retention, Zero Data Retention approval). Official documentation · checked Sep 23, 2026
- [2]Microsoft, Azure Document Intelligence FAQ (data retention, deletion API, connected and disconnected containers). Official documentation · checked Sep 23, 2026
- [3]Microsoft, Azure Document Intelligence pricing (container pricing statement). Vendor's own page · checked Sep 23, 2026
- [4]Amazon Web Services, Amazon Textract FAQs (use of inputs to improve the service and the opt-out). Official documentation · checked Sep 23, 2026
- [5]Google Cloud, Document AI data usage (training statement). Official documentation · checked Sep 23, 2026
- [6]vLLM project, vLLM documentation (self-description and OpenAI-compatible server). Official documentation · checked Sep 23, 2026
- [7]vLLM project, vllm-project/vllm repository (licence and one-line description). Official documentation · checked Sep 23, 2026
- [8]ABBYY, Subscription Terms (renewal, notice period and volume overage). Vendor's published terms · checked Sep 23, 2026
Related
- AWS Bedrock alternatives: other managed clouds, direct model APIs or a self-hosted LLM
- Azure OpenAI alternative: when the retirement clock and the PTU bill decide for you
- AWS Textract alternative: rent another OCR API or own the document pipeline
- An LLM Pipeline for Claims, Tickets and KYC Files Inside Your Own Infrastructure: Extraction, Validation, Review and Audit
- The AI Pilot That Never Reached Production: What Was Missing in Data and Operations
- LLM in a Closed Perimeter: What a Regulated Company Can Choose and What Each Choice Costs