A fluent answer is easy to demo. Production requires the system to know which document, version, and context it should trust.
The problem looks like AI. Look upstream first.
A claims officer needs to confirm which policy wording was in force on the date of loss. The base policy is a scanned PDF from 2014. Two endorsements were filed separately, with different effective dates. The claim evidence sits in one repository, the internal claims procedure in another. The officer asks an AI assistant a simple question, and the assistant answers with confidence and a citation.
The model may be excellent. But if the retrieval step hands it the base wording instead of the endorsement that later amended it, the answer is grounded in the wrong context. It looks correct. It is wrong.
This is often where a promising document AI pilot meets its production constraint. They do not stall because the model cannot write a fluent answer. They stall because the layer beneath the model cannot reliably tell the system which document, which version, which context, and which source of authority to trust. [3]
| DEHA’s Take It is rarely the model first. In insurance document AI, the harder production problem is deciding what the model is allowed to treat as evidence. |
The document AI pipeline
Before a model generates anything, a document has to travel through a pipeline:
Raw documents → extraction → structure → version and authority → context and relationships → retrieval → generation.
Generation sits at the end. Everything before it decides what the model is even able to see. A better model cannot fix a document the retrieval pipeline failed to understand. [1]
An insurer’s estate makes this concrete. The policy layer holds wording, schedules, endorsements and historical versions. The claims layer holds forms, first notice of loss, correspondence, photos, repair estimates, adjuster reports and supporting evidence. The operational layer holds claims procedures, underwriting manuals and internal rules. [2] These are not independent files. The meaning of an endorsement depends on which policy it amends, from which date, and whether a later endorsement has superseded it.
The hard part is not the number of PDFs. It is that the meaning of one document often depends on another. The pipeline is where that meaning is either preserved or lost.
Five ways the data layer fails
Five failure modes explain much of the gap between a working pilot and a production workflow. They map onto the pipeline above, and the rest of this piece uses only this framework.
1. Format. The system cannot reliably read or normalize the document. Scanned PDFs, tables, multi-column layouts, headers, handwritten fields and image-based evidence all resist plain text extraction. Plain OCR may recover text without preserving the layout, tables, or hierarchy needed downstream. [4] If structure is lost during extraction, retrieval inherits the loss.
2. Version and authority. The system finds the right document, but the wrong version, or the wrong source of authority. Authority here means which document governs the workflow: current wording, an applicable endorsement, or another approved source. A single corpus can hold original wording, amended wording, endorsement A, endorsement B, an archived copy and an internal draft. If the only metadata is a filename and an upload date, retrieval has no way to reason about effective dates, supersession or applicability. A citation to the base policy is still a citation. It can still be the wrong one.
| DEHA’s Take A cited answer can still be wrong if the citation points to the wrong version. In insurance, the right clause in the wrong endorsement is still the wrong answer. |
3. Relationships. Related documents are stored, but not connected. Many pilots ingest each document as an independent object. Insurance reasoning runs along a chain: policy to endorsement to claim to evidence to procedure. Without identifiers that link the same insured, claim number, policy number and effective period, search can find each document and still fail to reconstruct the case. Search finds documents. Production workflows need document relationships.
4. Metadata and context. Relationships tell the system that an endorsement belongs to a policy. Context tells it whether that endorsement was in force on the date of loss. The content exists, but it lacks the context needed to retrieve it correctly. Retrieval can be technically grounded and operationally wrong at the same time: the right clause, but the wrong policy, the wrong customer, the wrong date, or a document that is no longer current. When the retrieved evidence is not the applicable evidence, the generated answer can be fluent, grounded, and still unusable. [5]
5. Evidence boundary. Production has two boundaries: whether there is enough trusted evidence to answer, and whether this user is allowed to use that evidence. A pilot runs on cleaned sample data, broad access and a static document set, for one team. Production runs under access boundaries, retention rules, audit, monitoring and human oversight, and it has to withhold an answer when the evidence is incomplete rather than treat a partial set as complete.
Before and after: the answer changes when the data layer changes
Return to the 2014 policy. Two endorsements stored separately. A scanned base PDF. A claim filed years later.
Before. A naive retrieval setup indexes all three documents, retrieves the clause that is semantically closest to the question, generates an answer and cites the base policy. The problem is that one of the endorsements later modified exactly that wording. The citation resolves to a real document. It resolves to the superseded one.
After the data layer is prepared. Each document carries its policy identifier, document type, effective date, supersession relationship, claim linkage and current status. Retrieval can now filter on those attributes before it ranks text by similarity.
This does not guarantee a correct answer. It changes what the answer is built from. The system now has enough context to retrieve the applicable evidence, not merely the most similar text.
What production readiness actually requires
A production-ready insurance document layer is not a sixth idea. It is the point at which each of the five failures has been closed: documents are read with structure intact, versions and authority are resolved, relationships are encoded, retrieval is scoped by context, and the system can both decline when evidence is insufficient and enforce who sees what. Evaluation runs across known queries, expected sources, version correctness, retrieval quality and abstention, before anyone calls it production.
| DEHA’s Take Grounded does not mean usable. An answer is usable only when the evidence behind it is the right version, in the right context, under the right controls. |
Why this matters in regulated insurance
These are not only engineering concerns. The underlying issues are also appearing in supervisory guidance.
Korea’s revised financial-sector AI guidelines emphasize credible data and models, human supervision, accountability and security, and are self-regulatory for now. [6][7] Singapore’s final AI Risk Management Guidelines similarly extend AI risk management across the lifecycle, with insurers explicitly in scope. [8]
For a document AI workflow, those principles eventually become operational questions: what evidence may be used, whether it is sufficient, who can see it, and who remains accountable for the decision.
Production-readiness check
Five questions, one for each failure. If a workflow cannot answer them, it is not production yet.
- Format: Can scanned and digital documents both be parsed with tables and sections intact?
- Version and authority: Can the system distinguish current, historical and superseded documents, and resolve effective dates?
- Relationships: Can a claim retrieve its related policy, endorsements and evidence, scoped to the correct case?
- Metadata and context: Does the expected source appear, for the right policy, customer and date?
- Evidence boundary: Does the system decline when evidence is missing, and respect who may see which documents?
Where Oriene AI and Oridex fit
Two ideas carry the product mapping. A citation makes an answer inspectable. A prepared data layer makes the cited evidence trustworthy and usable.
Oriene AI is the grounded knowledge layer for a scoped workflow. It returns answers with references to the source material available to it.
Oridex is the document-intelligence layer for ingestion, extraction, structuring and indexing, for when the raw document environment needs preparation before retrieval. Version, applicability and workflow context still need to be defined as part of the implementation.
Some workflows need only Oriene, because the documents are already usable. Some need Oridex and Oriene together, because the document layer has to be prepared first. The order is set by the state of the documents, not by a default. If the documents are already usable, the problem may sit at the knowledge layer. If they are not, preparing the document layer comes first.
Before you call it production
Before changing the model, inspect the evidence path. Can the system identify the right document, the right version, the right relationship and the right access boundary before generation begins? If it cannot, changing the model does not fix the evidence path.
| DEHA’s Take Production asks whether the system should answer, not only whether the model can answer: for this user, from these documents, under these controls. |
References
- Databricks — Quality data pipeline for RAG. https://docs.databricks.com/en/ai-cookbook/quality-data-pipeline-rag.html
- AWS — Intelligent document processing with AWS AI services in the insurance industry (Part 1). https://aws.amazon.com/blogs/machine-learning/part-1-intelligent-document-processing-with-aws-ai-services-in-the-insurance-industry
- McKinsey — A data leader’s technical guide to scaling gen AI (https://www.mckinsey.com.br/capabilities/tech-and-ai/our-insights/a-data-leaders-technical-guide-to-scaling-gen-ai); Deloitte — Future-ready claims management (https://www.deloitte.com/us/en/dbriefs-webcasts/future-ready-claims-management-taming-complexity-boosting-effectiveness-ai.html).
- Google Cloud — Use Document AI layout parser with Vertex AI RAG Engine. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/layout-parser-integration
- arXiv — Classifying and addressing the diversity of errors in retrieval-augmented generation systems. https://arxiv.org/pdf/2510.13975
- Korea FSC — Revised AI guidelines for the financial sector, announced 18 June 2026, effective 22 June 2026 (self-regulation). Press release: https://www.fsc.go.kr/eng/pr010101/87140 . Coverage: https://www.insurancebusinessmag.com/asia/news/technology/south-korea-makes-humans-accountable-for-financialsector-ai-decisions-579996.aspx
- Korea AI Basic Act (high-impact AI obligations), overview: https://law.asia/korea-ai-basic-act-characteristics-significance/
- Singapore MAS — Final AI Risk Management Guidelines, issued 7 October 2026, with effect from 7 October 2027 (scope includes insurers). Coverage: https://www.insurancebusinessmag.com/asia/news/technology/singapores-ai-governance-rules-what-brokers-and-insurers-must-know-before-2027-592870.aspx