Data Readiness for AI: Document Limits and Scan Quality

Quick Answer: Data readiness for AI requires input checks. Google Document AI lists PDF, TIFF, JPEG, PNG and BMP, with 200 dpi scans, preferably 300 dpi ⁶. Microsoft Document Intelligence lists 500 MB on S0, 4 MB on F0, and 2,000 PDF/TIFF pages but two on F0; remove PDF password locks ⁵.

Summary in a mind map

Data Readiness for AI: Document Limits and Scan Quality
│
├─ Inventory · real source files
│   ├─ Log origin, version, format and intended processor
│   └─ Keep the exact submitted copy for review
│
├─ Google · image admission
│   ├─ PDF, TIFF, JPEG, PNG and BMP are listed
│   ├─ Scan at least 200 dpi
│   └─ 300 dpi or higher generally works best
│
├─ Microsoft · tier limits
│   ├─ S0: 500 MB; F0: 4 MB
│   ├─ PDF/TIFF: up to 2,000 pages
│   └─ F0 processes the first two pages only
│
├─ Prepare · protected PDFs
│   ├─ Remove password locks before submission
│   └─ Record who approved the submitted copy
│
└─ Decide · verify the output
    ├─ Review extracted fields against originals
    └─ Assign owners to missing or unreadable inputs

Google Document AI file formats

Data readiness for AI begins before model selection: inspect the documents the business actually uses. A regional logistics firm may still key delivery notes from paper. If a pilot is meant to read those notes, the starting inventory is not a list of possible AI products. It is a sample of original files and scans, with each file's origin and condition known. Google's cited Document AI page lists PDF, TIFF, JPEG, PNG and BMP among supported file types ⁶. That tells the team which common document and image formats can enter the documented path.

Format support is only the first test. A PDF may contain readable text or may be a poor image of paper; the filename alone does not tell the reviewer whether dates, quantities and signatures can be extracted correctly. The team should keep both the source file and the exact submitted version. If it converts a scan to another format, it should record that change so an unexpected result can be traced to the preparation step rather than attributed automatically to the processor. That record is a pilot method, not a claim that Google requires a particular internal form.

Google's page lists further file types and processor-specific notes beyond the five named here ⁶. The project should use the relevant processor's current requirements for any unusual source rather than infer that all files behave alike. The AI implementation roadmap can position this inventory as an early pilot task. The inventory itself should remain specific: the real delivery-note set, not a generic statement that the business has documents.

Google OCR scan resolution

Google recommends scans of at least 200 dpi for Document AI OCR and says 300 dpi or higher generally produces the best results ⁶. A dispatch office can use those figures to separate a scan-quality problem from a file-format problem. A low-resolution scan might be in an accepted file format yet still fail the recommended resolution check. A 300 dpi scan might pass that check while losing a field because the page was folded or the handwriting is unclear.

The pilot should therefore measure the scan, inspect the original paper and review the extracted fields. For each sample, record the dots per inch reported by the scanner or image metadata, whether the full page is present, and whether critical delivery values are readable. These are test observations. They should not be replaced by a blanket statement that higher resolution will always fix OCR. Google's wording is a recommendation with a generally better result at 300 dpi or above, not a performance guarantee for every note ⁶.

A useful test batch includes ordinary notes and known difficult examples. The reviewer can mark the fields needed for the intended workflow, then compare the processor's output with the original. If a field cannot be read by a person on the source scan, a model comparison is premature. The AI readiness assessment asks a broader organisational question; this article's scan check is a concrete input condition for one document pilot.

Microsoft file-size limits by tier

Microsoft's cited Document Intelligence input requirements list a maximum file size of 500 MB on the paid S0 tier and 4 MB on the free F0 tier ⁵. These are different limits for different test environments. The dispatch firm should avoid validating a process on the free tier using only its smallest notes, then assuming larger real files will behave the same way. File size needs its own column in the sample inventory, alongside the tier used for each submission.

Suppose the firm has a multi-page scan that is larger than 4 MB but smaller than 500 MB. The cited numbers suggest a tier admission difference, not an extraction-quality difference ⁵. The team can identify that before running the test and choose a test arrangement that corresponds to the intended deployment. It should also record whether any compression or splitting was used, because that creates a different input. A result from a modified file should not be presented as a result from the untouched original.

The two numbers do not say whether a submitted file is accurate, lawful to process or suitable for the chosen model. They are submission limits. A data-readiness sheet should report three separate outcomes: admitted by the service, text extracted, and critical fields verified by a person. Combining those into one “passed” mark obscures where a failed pilot needs repair. The AI opportunity assessment can help decide whether the workflow warrants further work after these input constraints are measured.

Microsoft PDF and TIFF page limits

For PDF and TIFF, Microsoft's cited requirements permit up to 2,000 pages, while the F0 free tier processes only the first two pages ⁵. This distinction is easy to miss when a test returns a plausible result. A multi-page delivery bundle can be accepted as a file but yield free-tier processing for the first two pages only. If the evidence needed by the business sits later, the free test cannot validate that part of the job.

The sample record should capture total page count, pages submitted and pages actually processed. A reviewer can then match extracted fields to the pages on which they appear. It should explicitly mark fields that were outside the processed range, because “not extracted” from an unseen page has a different cause from “not extracted” on a processed page. This makes the results interpretable when the team compares F0 experiments with a paid deployment ⁵.

Page count is not file size. A scan can have relatively few pages and still exceed a tier's megabyte ceiling; a large PDF can be within the size limit but contain more pages than the chosen test tier processes. Treat both as independent checks. The same sample may need a line for format, a line for megabytes and a line for page coverage. That separation is more useful than a broad “supported PDF” label.

Password locks and submitted files

Microsoft says password locks must be removed from PDFs before submission to Document Intelligence ⁵. The dispatch firm should identify locked files during intake rather than discovering them in a failed processing batch. Someone with authority over the document should prepare the test input without the lock. The project record should name the source file, the submitted copy without the lock and who approved that handling. The service prerequisite does not authorise the business to bypass access controls it does not own.

If the document cannot have its lock removed under the business's rules, mark it as an unresolved input gap rather than silently excluding it and overstating pilot coverage.

For documents containing personal data, input preparation also raises a separate question about whether the intended processing is appropriate. This article does not decide that question for a US firm. A data protection impact assessment may be relevant in a setting to which its legal framework applies. The Microsoft requirement is narrower: the submitted PDF cannot remain password-locked ⁵.

Record quality, origin and missing data

An input register should connect the technical test to a real business record. For each delivery note, the firm can list the source system or paper batch, scan date, file version, format, size, page count, scan resolution, processing tier, extracted fields, human corrections and unresolved gaps. The first five fields establish what was tested. The later fields show whether the output is usable for the intended task. This is a proposed pilot artefact, not a universal legal form.

This register is a practical pilot record for the firm's document test, not an EU compliance claim about a US business. The cited EU rules address data origin, preparation, quality, gaps, context and accountability only where their scope applies, while the later amendment changes the AI Act's Article 10 ^1,2,3. Eurostat's EU survey provides context on barriers to AI adoption, not a forecast for this pilot ⁴.

What the checks cannot decide

Passing format, size, page and dpi checks establishes only that the proposed files fit the cited technical conditions ^5,6. It does not demonstrate field accuracy, useful coverage, a business return or legal permission to process every document. The firm needs a reviewed sample of actual extraction outputs and a decision about what error rate the workflow can tolerate. That threshold belongs to the firm's task; neither vendor source supplies one for its delivery notes.

The cited Google page does not provide a universal file-size or page ceiling for every Document AI processor ⁶. A procurement sheet should leave that cell open until the specific processor and its current quota page are checked. Likewise, the EU provisions above should stay in a separate legal-scope column rather than being folded into a US vendor input checklist. This keeps technical facts, pilot observations and potential legal duties distinct.

What to do next

Select a sample of real delivery notes and create the input register. Measure format, megabytes, pages and scan dpi; identify locked PDFs; then run each file on the intended tier and processor ^5,6. Have a person compare the extracted values with the original notes. Log every unreadable field and every file that was excluded. The resulting artefact is a list of admitted inputs, verified outputs and unresolved gaps, ready for a decision on whether the pilot should proceed.