Every organization has a paper problem wearing a PDF costume: invoices, contracts, IDs, receipts, forms, arriving by email and portal upload, keyed into systems by humans. Azure AI Document Intelligence is the extraction engine that ends the keying, and building with it well is mostly about confidence handling and pipeline design rather than the models themselves.

Choosing the Model Layer

Three tiers. The prebuilt models cover the universal documents, invoice, receipt, ID, tax forms, returning typed fields (vendor, totals, line items, dates) with confidence scores, and they should be your first attempt because the training you skip is the maintenance you never do. The layout model is the universal preprocessor: text, tables, selection marks, and structure from any document, and it has a second career as the document cracker feeding the chunking pipeline from yesterday’s AI Search post, tables preserved as tables instead of scrambled text, which fixes a whole class of RAG failures on structured documents. Custom models handle your proprietary forms: neural models trained on labeled samples generalize across layout variations, and composed models route mixed streams by classifying then extracting, the pattern for the inbox that receives everything. Train with genuinely representative samples, the bad scans and the phone photos included, because models meet production documents, not curated ones.

The Pipeline Pattern

The reference shape assembles from this series’ parts: documents land in blob storage, Event Grid announces arrival, a function or Logic App calls Document Intelligence, and the result forks on confidence. High confidence fields flow straight to the ERP or database; low confidence or validation failing extractions route to a human review queue, and the human’s corrections are not just fixes, they are training data for the next model version, the loop that makes the system improve instead of decay. Set thresholds per field by cost of error, an invoice total is not a memo subject line, and wrap business validation around the extraction (does the total match the line items, is the vendor known, is the date plausible), because the model reads what the document says and only your rules know what it should say. Idempotency and dead lettering apply exactly as the messaging posts prescribed; a document pipeline is an event pipeline with pictures.

Operating Notes

The invariants: private endpoints and managed identity from callers, keys disabled, diagnostics and per model latency plus page volume metrics into Log Analytics, and the FinOps tagging since page based billing on a busy intake adds up and belongs to a cost center. Data handling deserves an explicit paragraph in your design doc: documents transit the service for analysis and results contain their content, so the retention of source blobs, the review queue, and the extracted data all fall under the classification and lifecycle rules from the storage and Purview conversations, especially for IDs and financial documents. Measure the system by the business number it exists to move, straight through processing rate, the percentage of documents needing no human touch, and report it monthly beside the error rate on what went straight through; the first number funds the project, the second keeps it honest. Paper does not disappear, but with the pipeline above it stops being anyone’s job to read it twice.

Cheers
Osama