At the WeAreDevelopers World Congress 2026 in Berlin, I spoke with Luca Mancinelli (Solutions Engineer, Apryse), about a part of the AI stack that tends to receive far less attention than models themselves: the document pipeline.

As companies move more of their knowledge into AI applications, PDFs, scans, reports, and invoices are becoming key data sources. The real challenge is preserving enough structure and context for AI systems to understand them properly.

Document extraction is becoming key in AI applications

For much of the history of enterprise software, documents typically sat at the end of a process. An application generated a report, invoice, or contract, and the PDF was the finished product. Mancinelli believes AI is changing that relationship:

Documents used to be the output – for example, a PDF you’d print or send out. Now they’re also a structured input that powers AI systems.

More precisely, the challenge for developers is turning documents that are often unstructured or semi-structured into structured information that downstream systems can use.

An LLM can ingest raw text, but simply extracting characters from a file does not always preserve what makes the original document meaningful. A heading has a different role from a paragraph. A value in a table depends on its row and column. A number beside “Total” means something different from the same number appearing somewhere else on the page.

That is why document extraction is becoming an important preprocessing layer in AI applications. The goal is not just to recover text, but to give models cleaner, better-organized context.

Bad PDF parsing can lose information that even a stronger model cannot recover

Anyone who has tried to build a production pipeline around real-world PDFs quickly discovers that documents are far less predictable than API responses or database records. Mancinelli points to three recurring problems:

First are complex layouts: you can have headers, tables, and different formats in the same document, and that creates a huge challenge for systems. Second is poor OCR, which can produce messy output. Third is the loss of context.

This distinction becomes especially important with RAG systems and other LLM-powered applications. If a document is badly parsed before it reaches a model, a more powerful model cannot necessarily recover information that was lost earlier in the pipeline.

For developers, that means data quality becomes an architectural issue rather than simply an AI-model issue.

Document processing depends on the use case

Where document processing happens is another architectural decision that becomes more important as AI moves into regulated and data-sensitive environments.

Mancinelli argues against treating cloud and self-hosted processing as an either-or decision. The right model depends on the application, its infrastructure, and the type of data involved.

For organizations working with particularly sensitive documents, processing files within their own environment can reduce the amount of data that has to move outside their infrastructure. Cloud services, meanwhile, can lower the infrastructure burden and make experimentation easier in some projects.

It’s not one or the other; each solution has its own merit. It depends on the use case.

That may sound obvious, but it becomes a meaningful engineering trade-off once document pipelines start handling contracts, financial records, healthcare documents, or other sensitive enterprise information. Privacy requirements, latency, scalability, and operational complexity all have to be considered alongside extraction accuracy.

A powerful SDK is useless if developers struggle to integrate it

There is also a more familiar developer problem: integration. No matter how sophisticated a document-processing engine is, developers eventually have to put it into a real application, maintain it, and debug it.

For Mancinelli, good documentation is therefore one of the most important characteristics of a production-ready SDK. Practical examples matter as well: developers should be able to see realistic implementations and adapt them instead of building every integration from scratch.

He also points to higher-level APIs as a way of reducing unnecessary implementation complexity:

The point is particularly relevant as AI infrastructure becomes more fragmented. Developers already have to connect models, vector databases, data sources, evaluation systems, observability tools, and application logic. Adding another complicated layer to the stack can quickly increase both development and maintenance costs.

A useful document SDK therefore has to solve two problems at once: the difficult underlying document-processing problem and the developer-experience problem surrounding it.

Data pipelines will become increasingly important

Predicting what software development will look like several years from now is difficult, and Mancinelli avoids picking a single technology that will dominate.

Instead, he expects data pipelines to become increasingly important as companies process larger and more complex collections of information.

One thing is sure: the complexity of the data is going to increase, and the amount of data is going to increase as well. That means data management pipelines will become even more critical.

For developers working with AI, that may be the more practical takeaway.

“The industry tends to focus heavily on what happens inside the model: larger context windows, new reasoning capabilities, faster inference, and increasingly capable agents. But production AI systems also depend on everything that happens before a prompt reaches the model”, Mancinelli said.

If the input is incomplete, badly extracted, or stripped of its structure, even an advanced LLM starts from a disadvantage.

As enterprise AI matures, document processing may become less a peripheral PDF problem and more a core part of the AI data stack, one where developers have to think carefully about structure, privacy, deployment, and, above all, context.