“Why would we pay for Unstructured’s ETL+ platform, when our Cloud Service Provider [Azure/AWS/GCP] already offers access to foundation models and a lot of your same document processing capabilities?”

You're a technical leader. Your team is building AI features that process documents—loan applications, medical records, contracts, research papers. You need document extraction, and your cloud provider already offers it – both via access to the multimodal foundation models as well as via dedicated Document AI services.

Why add another vendor to the stack?

Last month, one of our senior sales engineers sat with three senior engineers from a major bank. They opened with exactly this objection: "We do it all with AWS right now and it works. Why would we bother with you?"

Forty-five minutes later, they were ready to move forward with a proof of concept – not because their current system was failing, but because mapping out their 12-month roadmap revealed complexity they hadn't anticipated.

This pattern repeats consistently across enterprise AI teams. Document processing starts simple and scales into one of the most intricate infrastructure challenges in the AI stack. Which is why we’ve just as often seen the reverse scenario: companies, unhappy with their current Cloud Service Provider’s document processing capabilities and all the infrastructure they’ve had to build around it, come to us for a clean replacement to what fast-evolved into a rat’s nest of homegrown capabilities, supplementing their CSP’s Document AI solution’s limited feature sets.

This guide examines why that happens and how to make informed architecture decisions before the complexity compounds.

Understanding the Document Processing Landscape

Before diving into complexity, it helps to understand where different approaches fit. The document processing landscape has three distinct document processing options or tiers, each suited for different use cases and production scenarios:

Tier 1: VLM Processing (either direct or via a VLM wrapper library)

Vision-enabled Large Language Models (VLMs) can extract structured data directly from certain types of documents – typically PDFs, images, and growing support for the standard Office Suite of documents. This approach works exceptionally well for:

• Prototyping and exploration
• Low-volume processing (< 1,000 documents/month)
• Documents requiring sophisticated understanding over speed

The limitations emerge at scale and with reliability:

• Cost: $0.01-0.05 per page adds up to $1,000-5,000 monthly at 100,000 pages
• Speed: 5-30 seconds per document creates user experience problems
• Reliability: Stochastic outputs make repeatability a challenge; this can create compliance issues when you need 99.99% accuracy
• Quality: Using VLMs directly can result in quality issues; models hallucinate; their OCR isn’t perfect; and they still suffer regularly from data omission issues when the information density of a document is high

Most mature production systems that operate at scale only use VLMs selectively for complex documents, and these systems are quite costly, slow, require extensive guardrails, fallback strategies, and validation to ensure parsing integrity, while processing routine content through faster, cheaper methods. There are a number of popular open source VLM-wrapper libraries like Docling (by IBM) or Markitdown (by Microsoft) as well as a number of popular commercial offerings in this category as well, e.g. Reducto, Unstract, and a whole host of others. Most of these simply wrap VLMs with a custom prompt to influence its parsing behavior.

Tier 2: Cloud Service Provider Document AI

AWS Textract, Azure Document Intelligence, and Google Document AI are specialized, managed services optimized for high-volume document processing. These excel at:

• Only 5-10 file formats typically, but can support massive scale (speed, throughput, concurrency)
• Forms and structured document processing
• Tight integration within a specific cloud ecosystem

Teams typically choose this tier when they have:

• Primarily PDF-based workflows or the more common office documents
• Deep commitment to a single cloud provider
• Engineering capacity to build surrounding infrastructure

Tier 3: Document Processing Platforms

There also exist a number of purpose-built platforms, like Unstructured ETL+ and LlamaParse, to handle the full document processing lifecycle for a much wider range of file formats and for a multitude of downstream use cases. This lifecycle can include file format normalization, data cleansing, intelligent chunking and embedding (for Retrieval Augmented Generation use cases), connector management, pipeline orchestration, and toolkits for enabling the use of unstructured data with AI agents and other types of AI applications. These make sense when:

• Processing diverse document types (most of these types of platforms support over 50+ formats)
• Requiring vendor flexibility across the AI stack (CSPs only enable their preferred set of partners and tools)
• Prioritizing engineering resources for product differentiation over infrastructure maintenance
• Supporting out of the box the full range of AI and agentic use cases leveraging unstructured data

How Scope Quietly Expands

On paper, a cloud provider’s document AI offering looks complete. PDFs in, structured data out. But in practice, the surface area of “documents” grows quickly. In that bank meeting, it took less than five minutes before PowerPoints, scanned images, and SharePoint repositories entered the conversation.

This is the reality for most enterprise AI teams: today’s “PDF extraction” project becomes tomorrow’s “end-to-end document intelligence” program. What looks manageable at the start gradually sprawls into new formats, new integrations, and new expectations from downstream teams.

When Pilots Meet Production

The first wave of scaling pressure shows up in performance and reliability. Many teams start with VLMs or CSP services, and that works fine for a pilot. But as volume rises, cost and latency catch up — and the cracks show.

When the bank engineers mentioned they were sending everything through a multimodal model, our engineer asked them if they were aware that there were much faster, cheaper alternatives that produced the same quality of output for the majority of documents for a fraction of the cost and latency–namely Unstructured’s “Fast” strategy. They weren’t aware. That’s not unusual. Most teams don’t think about the cost of document processing at scale or fallback pipelines until their retrieval results start to degrade or costs start to pile up.

What starts as a simple proof of concept becomes a set of engineering tradeoffs around speed, coverage, and quality.

Connecting to the Rest of the Stack

Then comes integration. No enterprise’s vendor software footprint lies exclusively within a single Cloud Service Provider. A 2025 Zylo report found that enterprises over 10,000 employees use on average over 660 SaaS applications. Many of those applications have business critical unstructured data that you will likely want to feed your AI applications. And then there’s also connecting to databases downstream outside of your CSP’s preferred databases. CSP’s don’t typically like to support your decision to pull data from our deposit data to systems of record outside of their offerings, so good luck finding a connector within their ecosystem to do so. What that means is that if you’re going with your Cloud Service Provider’s Document AI solution, that puts the onus of building and maintaining all of those data connectors on your developers.

One week it’s SharePoint, the next it’s Databricks, the next it’s a new vector database. Each new connector adds weight — often more than the document parsing itself.

At the bank, that’s when the laughter turned to a quiet acknowledgement: maintaining connectors, pipelines, and metadata management was already eating up more time than expected. Their “document AI” project was becoming an infrastructure project.

This isn’t an outlier. We consistently see teams underestimating how much of their roadmap will be spent not on core product feature development, but on building and maintaining glue code around their CSP’s narrow set of supported tools.

How This Plays Out in the Wild

The engineers in that room realized their next 12 months were already partially mapped out — not by choice, but by necessity. File formats beyond PDFs. Performance tuning. Pipeline maintenance. Integration sprawl.

That’s the tradeoff. Cloud providers are optimized for common cases at massive scale. But enterprises rarely live in “common cases.” The further your roadmap stretches, the more the gap widens between what CSPs provide and what your systems actually demand.

If You’re Here Now, Talk to Us

If this sounds familiar, you’re not alone. The lesson isn’t that going with CSPs are wrong — they’re excellent for what they’re built to do. It’s that enterprise document processing almost always grows beyond what they’re built to do.

That’s why dedicated document AI platforms exist: to absorb the complexity before it consumes your roadmap.

If you’d like to stress-test your own plans against what we’ve seen across dozens of enterprises, reach out . One of our AI experts can walk through your use case and share a demo of how a platform approach compares.