Turning piles of documents into clean data without typing it in

If you have used ChatGPT, you already know one thing it is good at. You paste in a wall of text, ask what matters in it, and it hands back the few facts you actually wanted. You did the reading for it by copying the text in. But what if the document is a scanned PDF, a photo of a paper form, or a stack of a thousand contracts nobody has time to open?

That is the problem the AWS post takes on. It shows a working setup where AI reads documents on its own and pulls out the useful facts, with no person typing anything in.

Two plain words come up a lot here, so it helps to pin them down before going further.

Data extraction means letting the AI read a document and pull out specific facts. Picture someone going through a lease, finding the county and the section number, and copying those into a spreadsheet. That copying is data extraction. The AI does the same job, just faster and without getting bored.

A pipeline is the path a document travels from start to finish. A file goes in one end, the system reads it and pulls out the facts, and clean data comes out the other end. No person stands in the middle. It is an assembly line for paperwork.

What the AI actually reads

The example in the post uses land lease documents. These are real estate records that describe a piece of land: which state and county it sits in, the survey it belongs to, the section, and so on. The kind of dense paperwork a person could read but would rather not, page after page.

Many of these arrive as scanned PDFs. A scanned PDF is just a picture of a page. There is no typed text hiding behind it for a computer to grab, only an image. So the setup does something clever and simple. It turns each page into an image, then has the AI look at the image and read it the way a person would.

The model doing the reading is Anthropic’s Claude Sonnet 4. It can look at an image and understand what is written on it, then return the facts. One real limit to know: the post notes this model accepts at most 20 images in a single request. Since each page becomes one image, a very long document has to be handled in chunks rather than all in one go.

What comes out the other end is not a paragraph of prose. It is a tidy list of facts, organized so another program can use it straight away. The land in the example came back broken into separate tracts, each with its own state, county, survey, and section filled in.

Two speeds: now, or cheaper later

Here is the part the post builds everything around. Not every document needs the same treatment. Sometimes you need one answer this second. Sometimes you have a huge pile and what you really care about is keeping the cost down. So the setup offers two speeds.

On-demand is the fast lane. One document comes in, the AI reads it, and the answer comes back within seconds. This is for the time-sensitive case, the moment someone is waiting on a result.

Batch is the slow, cheap lane. Instead of handling each document the instant it arrives, the system lets them collect into a big group and processes the whole group together on a schedule. The trade is patience for money. The post says the batch option costs 50 percent less than on-demand for the same work.

The analogy is laundry. If you need one clean shirt for tonight, you wash that shirt now. It costs a full cycle for one item, but you have it when you need it. If you can wait, you let a week of clothes build up and run one big load. Same machine, far less waste per item. On-demand washes the one shirt. Batch waits for the hamper to fill.

The speed numbers back this up. On-demand returns a single document in seconds. The batch path can run through 1,000 documents within 15 minutes by working on many at the same time. One is built for right now. The other is built for volume.

How the document finds the right lane

So how does a document end up in the fast lane or the cheap lane? The setup uses a waiting line, the kind of thing a computer person calls a queue. A queue is just a line where items wait their turn, like the rope line at a bank.

There are two lines here. One feeds the on-demand lane and is built to keep documents in strict order and moving quickly. The other feeds the batch lane and simply holds documents until enough have gathered and a scheduled time arrives to run them all. The post notes the batch job waits for a minimum of 100 documents before it kicks off, which makes sense. The whole point of batch is to gain from doing many at once, so it waits until there are many.

A document is placed in whichever line fits the need. Need it now, it goes in the fast line. Can it wait, it goes in the cheap line. The same AI reading happens in both. Only the timing and the cost differ.

Why this matters even if you never touch AWS

The names in the post, Bedrock, the various queues, the scheduling pieces, are Amazon’s particular plumbing. You can forget them and lose nothing. What is worth keeping is the shape of the idea.

The shape is this. A task that used to mean a person squinting at scanned paper and typing facts into a form is now an assembly line that runs on its own. And it is not one rigid line. It bends to the situation, fast and pricey when speed matters, slow and cheap when it does not, from the same underlying parts.

Almost every business has a version of this pain. Invoices that pile up. Forms that need someone to key them in. Contracts nobody has time to read. The post is one concrete answer to that pain, not a pitch deck about the future. It is a built thing that reads land leases today.

If you only take one idea from it, take this. The interesting question is no longer whether AI can read your documents. It can. The question is whether you want the answer in seconds or want it at half the price, and a setup like this lets you choose per document.

Sources: aws.amazon.com