What Production Engineering Teams Actually Lose With Google Document AI and Azure Document Intelligence at Scale

Google Document AI and Azure Document Intelligence cost teams more to run in production than they pay in API bills. At scale, teams absorb forced migrations, extra services, human review, unvalidated accuracy risk, and data-retention obligations that platform SLAs do not cover. A production alternative should be judged on those costs alongside extraction quality on a clean sample and the price of an API call.

Why the API-demo-to-production gap is wider for document workloads than for most AI tasks

Clean PDFs, single-document requests, and manual inspection make extraction look manageable. An accounts payable queue or mortgage lending pipeline in production handles thousands of documents of mixed quality per day, with less time for someone to check every result. The inputs change, and so do the consequences. Documents combine irregular structure, legal weight, and volume, so a missed field can be both a processing error and a compliance problem.

General AI experimentation often stops before deployment, when failure is still contained in a sandbox. Document workloads can fail in other ways after go-live, when more kinds of documents and edge cases hit limits that the sample never reached. This is a reason to separate an extraction benchmark from a production evaluation, because the latter must account for engineering work, review labor, and risk beyond the API response.

Google Document AI's forced processor migrations as a recurring engineering tax

Google Document AI release notes announced the deprecation of legacy processors on February 17, 2026, with a hard discontinuation date of June 30, 2026. The affected versions include the identity parsers pretrained-us-passport-v1.0-2021-06-14 and pretrained-fr-driver-license-v1.0-2021-06-14. Tax and finance examples include pretrained-1099misc-v1.1-2021-12-10, pretrained-1099r-v2.0-2022-07-25, and pretrained-w9-v2.0-2022-06-23. A production integration using an affected version has to move before that version stops serving it.

The scope extends beyond individual form parsers. The deprecated set also includes pretrained-mortgage-statement-v1.0-2021-10-17, pretrained-utility-v1.2-2022-12-15, pretrained-procurement-splitter-v1.2-2022-08-19, and pretrained-lending-document-split-v2.0-2021-12-09. The foundation model pretrained-foundation-model-v1.0-2023-08-22 is included too. That breadth changes the migration task. Teams may need to revisit both extraction and the splitting logic that prepares documents for it.

Google's recommended migration targets are also specific versions, including pretrained-ocr-v2.1-2024-08-07 for Enterprise Document OCR and pretrained-invoice-v2.0-2023-12-06 for the invoice parser. Other targets include pretrained-expense-v1.3.2-2024-09-11, pretrained-classifier-v1.5-2025-08-05, and pretrained-splitter-v1.5-2025-07-14. Changing the version reference is only the start. Each move takes integration work, new tests of accuracy against ground truth, and changes to downstream validation if it relies on the old output schema or confidence distribution.

The same release notes record new model versions on March 23, March 31, July 17, and September 21, 2026. Version turnover is an ongoing planning obligation, although a new release is not itself a forced migration. Teams that handle mortgage, tax, and payroll work also need a new compliance review of how the replacement behaves. A hard shutdown date removes scheduling freedom. The cost is engineering capacity committed on the platform's timetable.

Azure Document Intelligence's architectural constraints that compound under volume

Azure Document Intelligence exposes a different constraint through its polling-only architecture. The standard tier limits both POST requests that submit work and GET requests that poll for results. Because polling is mandatory, the GET allowance can become the bottleneck for parallel processing. A test with few documents may never put enough pressure on polling to show how it limits throughput.

Regional performance adds another variable under load. Some regions can run at normal latency while degraded regions take many times longer, and Azure's health dashboards do not reliably surface that degradation. Teams therefore depend on their own monitoring to detect it. Large files introduce a separate constraint. Documents that exceed the paid tier's hard page cap must be chunked before they are sent, which adds logic to prepare them and another place where the pipeline can fail.

File errors can be difficult to diagnose as well. PDFs that open in standard viewers can be flagged as corrupted, images that render can be rejected as invalid format, and encrypted PDFs can fail even after unlocking. Generic errors tell teams little about what went wrong. Meanwhile, results established in Document Intelligence Studio do not reliably reproduce through the API when defaults, versions, and parameters differ. Confidence in the demo surface is not proof of equivalent production behavior.

These are architectural trade-offs. Retry logic, multi-region routing, and chunking can address the limits, but teams have to build and maintain those workarounds. SDK upgrades can also introduce breaking changes that require codebase-wide migration and accuracy re-validation. The lifecycle burden therefore exists here too. Neither the API price nor the vendor SLA pays for the engineering needed to keep the surrounding system working.

How stitched-together service stacks emerge — and what they cost to maintain

A single enterprise PDF can contain digital-native text, scanned pages, photos, tables, charts, and irregular layouts. When one prebuilt processor cannot handle that mix at acceptable accuracy, teams route documents to different processors or combine services. One service handles layout detection, another OCR, and another table extraction. Each has its own API contract and latency. The integration layer must also handle the ways each service can fail and the cycle of its versions before the business workflow can use the output.

Routing then becomes a maintained system in its own right. A classifier must be trained, validated, and updated as new document varieties arrive. Extraction output also needs validation and a path for exceptions. Azure leaves production-level threshold logic, human-review queues, and correction workflows for the team to build. Google, by contrast, includes a native Human-in-the-Loop feature with configurable confidence thresholds, automatic review queuing, and correction workflows, so the two platforms do not impose identical assembly work.

A pipeline can automate most documents while leaving an expensive remainder for people to inspect and correct. That remainder can dominate total ownership cost more than per-page API fees. Adding more services means more migration work, because each has its own upgrade cycle. The claim that integration is a one-time expense fails when document varieties expand or an upstream service changes its schema, pricing, or availability.

What confidence scores from these platforms actually tell you — and what they do not

Both platforms return confidence scores, but those scores are model outputs rather than validated measures of production accuracy. A high score means the model assigned high internal confidence to an extraction. It does not establish that the value is correct. Unless the score has been tested against ground truth for the team's document types, it cannot stand in for field-level accuracy. A manually chosen cutoff can route work without proving that the accepted work is safe.

Clean, single-column digital text extracts more accurately than complex layouts and forms, yet confidence distributions do not reliably shift in proportion to the accuracy loss. High confidence can survive a wrong answer. In vision-based extraction, a model can even return a value that corresponds to no pixel on the page. Without a ground-truth comparison, the API response does not distinguish that hallucination from a correct extraction.

Multiple fields introduce another source of risk. Even with high per-field accuracy, a meaningful share of invoices can contain at least one incorrect field. A document-level metric alone does not reveal which fields fail or how often, while field averages alone do not establish that every field on a document is correct. The necessary evidence comes from independently annotated ground truth and field-by-field comparison. In mortgage lending, tax processing, or healthcare claims, a single undetected field error can trigger a compliance event regardless of its confidence score.

The data retention exposure neither platform's compliance certifications resolve

SOC 2 and ISO 27001 certifications, together with GDPR-compliant infrastructure, provide valuable evidence about platform controls. They do not mean zero data retention. Both platforms' compliance credentials must be read with their operating terms, because audited controls can coexist with permitted temporary storage. The distinction is between platform assurance and the organization's obligations for its documents. An SLA does not close that gap.

Google's batch processing stores documents encrypted with an ephemeral key for a short period before deletion, with a failsafe TTL of one day. “Typically deleted immediately” is not a zero-retention commitment. More broadly, standard API agreements that lack explicit zero data retention terms may let a provider keep data longer and have its trust and safety team review it internally. Those conditions are acceptable for the documents in scope only if the applicable agreement permits them, regardless of the certification alone.

The deployment also needs its own compliance review. The organization must choose the region, set up data-handling configuration, and settle sub-processor agreements itself, even when the platform has been audited. With LLM-based extraction, hidden PDF text creates another risk in how the pipeline is built. If the extraction layer fails to keep visual rendering separate from text-layer parsing, injected instructions can change how the model behaves.

How do teams size these costs before committing to or replacing a production platform?

The practical evaluation starts with the versions an integration will depend on. For Google, check each processor against the current deprecation schedule and estimate migration effort at the cadence suggested by the release history. Include the version update, accuracy re-validation, and downstream validation changes. Scheduling belongs in the estimate as well. A deadline set by discontinuation can take up time that teams have already set aside for other production work.

For Azure, load-test at target concurrency in the intended regions using the API as well as Studio. Measure submission and polling demand together, because GET limits can constrain throughput before the OCR engine does. Include degraded-region behavior in the evaluation rather than relying on a single-region proof of concept. Then inventory every required service and workaround. Classifiers, chunking, validation, and review queues each need a build estimate and an ongoing maintenance estimate.

Use a sample drawn from the document varieties the pipeline will actually receive, with two independent annotators establishing ground truth. Compare extracted fields against that ground truth and compute per-field accuracy. Then measure errors at each proposed confidence threshold. High-confidence errors show where the threshold fails as a quality gate, and the resulting exception rate lets teams work out the cost of human review labor.

Get explicit confirmation of what is retained, for how long, and under which conditions, then compare those terms with the regulatory obligations attached to the documents. Also review the region, configuration, and sub-processor arrangements for the deployment. This is work to budget before commitment. For a team already in production, the same review can expose obligations omitted from the original build-versus-buy decision.

A replacement evaluation should put these measured costs next to the quoted processing fee. Raw API pricing pays for calls, including calls whose output still needs correction, while migrations, validation, and exception handling remain separate expenses. Pricing on correctly extracted pages aligns incentives better than pricing on raw API calls, though migration risk still needs its own assessment.