Does AWS Textract Store My Documents?

It can, and by default it may. AWS states that its AI services "may use and store customer content for service improvement, such as fixing operational issues, evaluating service performance, debugging, or model training", and that it "might store such content in an AWS Region outside of the AWS Region where you are using the service". You can stop this with an AWS Organizations AI services opt-out policy. That policy is not enabled by default.

This is one of the most commonly misreported facts in document processing, and the misreporting runs in both directions. Some articles claim Textract never retains anything, quoting a promise that actually covers something narrower. Others imply AWS is doing something underhanded, which is not fair either, because the behavior is documented openly and a real control is provided. The accurate version is more useful than either, so here it is with the sources.

What AWS actually says

The load-bearing sentence lives in the AWS Organizations user guide, in the section on AI services opt-out policies. It applies to AWS AI services as a category, and Amazon Textract is one of them:

"AWS AI services may use and store customer content for service improvement, such as fixing operational issues, evaluating service performance, debugging, or model training. For this purpose, we might store such content in an AWS Region outside of the AWS Region where you are using the service. You can opt out of use of your content for service improvement by using the AWS Organizations opt-out policy."

Read that twice, because it answers two separate questions. The first is retention, and the answer is that content may be stored beyond what serving your request requires. The second is data residency, and the answer is that the stored copy might not stay in the region you called. For a team that chose us-east-1 specifically to satisfy a residency requirement, that second sentence is the one that matters, and it is easy to skim past while looking for the first.

The promise that does not mean what people think

There is a much stronger statement in the Textract developer guide, and it gets quoted constantly as a general retention promise. It is not one. In the data protection section, discussing Custom Queries adapters, AWS writes that content used for generating adapters "is processed internally within Amazon Textract for the duration of the training" and "is deleted once training completes", and that customer content in that context "is not logged or retained even for debugging purposes".

That is an excellent commitment and it is genuinely narrow. It covers the training images, prelabeling results and annotations you supply when you build a Custom Queries adapter. It does not cover the ordinary analyze calls your production pipeline makes every day. Quoting it as though it did is the single easiest mistake to make on this topic, and a large share of third-party articles make it. If someone tells you Textract never retains your documents and cites the developer guide, this is almost certainly the sentence they are citing.

How the opt-out actually works

The control is real and you should use it, but two details determine whether you can.

First, it is an AWS Organizations policy, not a checkbox inside the Textract console. That is a meaningful obstacle for a team running a single standalone account, because you have to be enrolled in Organizations to set an Organizations policy at all. Plenty of small engineering teams have never touched Organizations, which means the practical answer to "have you opted out" is very often no, and nobody involved made a decision about it.

Second, opting out reaches backward as well as forward. AWS states that when you opt out, "that service deletes all of the associated historical content that was shared with AWS before you set the option", with the qualifier that the deletion "is limited to content stored that is not required to provide service functions". So setting the policy is not only a change to future behavior; it triggers a cleanup of what came before, within that limit.

How this compares to Azure and Google

The comparison is what makes this interesting, because all three hyperscalers charge exactly $1.50 per 1,000 pages for basic OCR and give three completely different default answers.

Azure's position is specific and easy to plan around: Microsoft states that data and results are "stored temporarily in Azure Storage in the same region as the request" and that "your data is then deleted 24 hours from the time that you submit an analyze request", with a Delete Analyze Result call in the v4.0 API if you want it gone sooner. Google's is the strongest of the three on training, stating plainly on the product security page that "we never use customer data to train our Document AI models", and that online request data "is processed in memory, encrypted in flight, and not persisted to disk".

The Azure row that says "not addressed" deserves a caveat rather than a checkmark. It does not mean Microsoft trains on your documents. It means the Document Intelligence data privacy page and FAQ describe storage, region and deletion in detail and say nothing either way about model training, so the commitment you would rely on lives in your Azure agreement rather than in the product documentation. We put all three side by side, with the full quotes, in the OCR API data retention comparison.

Is Amazon Textract HIPAA eligible?

Yes. Amazon Textract appears on the AWS HIPAA Eligible Services Reference, the published list of services "eligible to create, receive, process, maintain, or transmit electronic protected health information (ePHI)". Eligibility is not the same as coverage, though. You still need an executed Business Associate Addendum with AWS, and you still have to configure the service correctly, because a service being eligible does nothing for you if the surrounding architecture leaks.

What to do about it

If you are running Textract on documents that carry any obligation at all, the sequence is short. Confirm whether your account is in an AWS Organization, because that determines whether the opt-out is even available to you. Set the AI services opt-out policy if it is. If it is not, decide deliberately whether enrolling is worth it rather than leaving the question open. Then write down the residency answer separately from the retention answer, because those are two different findings from the same paragraph and only one of them is usually recorded.

The broader habit worth building is treating a third-party model endpoint as a boundary your data crosses rather than a function you call. The same instinct that makes teams careful about what an autonomous agent is allowed to touch, which is the problem enforcing tool and data boundaries around AI systems exists to solve, applies just as well to a document pipeline: the useful question is not only what the vendor promises, but what you sent them in the first place. A classification step that keeps your most sensitive document types out of a third-party endpoint entirely is a more reliable control than any retention setting layered on top.

And if the answer to all of this is that the documents genuinely cannot leave your network, no cloud vendor here satisfies that, including us. The honest options are a self-hosted model or a vendor container, and we worked through what those actually cost on on premise OCR software.

All quotes on this page were read off the vendors' own documentation in July 2026. Vendor policies change, so re-read the source before you put any of this in a compliance document.