Closed-Network RAG Preprocessing Methods – On-Premises Deployment Guide

Closed-network RAG (Retrieval-Augmented Generation) preprocessing is an early-stage challenge for teams in finance, public sector, and defense looking to adopt AI in network-segmented environments. To use documents as evidence for AI-generated answers, you must first parse and preprocess them—but calling external cloud APIs creates the risk that documents or embedding data will be transmitted to external servers. In physically segmented network environments in particular, external API use may be restricted, making on-premises approaches—which complete preprocessing inside the internal network without sending documents outside—a practical choice.

Why RAG Preprocessing Is Restricted in Closed Networks

RAG preprocessing is restricted in closed networks because the external cloud APIs commonly used for preprocessing send documents and embedding data to external servers. In network-segmented environments, this kind of external communication is often blocked.

RAG (Retrieval-Augmented Generation) retrieves documents relevant to a question and uses them as evidence for LLM-generated answers. This requires tasks such as document parsing, OCR (Optical Character Recognition), and embedding. Some organizations handle these steps via external APIs, but in closed networks, external API calls may be blocked or subject to separate security review.

South Korea’s financial sector formalized physical network segmentation following the 2013 IT outage. After branch terminals and internet banking servers were paralyzed, regulations requiring physical separation of business and internet networks took hold. Public-sector and defense organizations with high security requirements also strictly control external communication and the removal of sensitive documents.

With external communication restricted, closed networks become environments where cloud-based generative AI and SaaS are difficult to use. RAG requires documents to be parsed and preprocessed before moving to the retrieval and answer-generation stages. For closed-network teams, preprocessing is not simply a technical choice—it is a challenge that must be solved before RAG can be adopted.

Three Challenges of Closed-Network RAG Preprocessing

When building RAG preprocessing in a closed network, three key points must be addressed: the inability to use external preprocessing APIs, the need to build the entire preprocessing pipeline directly within the internal network, and the fact that structured and unstructured documents are mixed and cannot be handled by a single method.

External Preprocessing APIs Cannot Be Used – The Problem of Documents Leaving the Network

Most cloud-based document parsing, OCR, and embedding APIs process documents by transmitting them to external servers. In closed networks, sending documents outside in this way may violate security policies and compliance requirements, and is often blocked at the network level.

Many cloud services handle document parsing, OCR, and embedding, but in closed networks, calling external APIs itself can be a problem. The moment sensitive internal documents are transmitted to external servers, organizational security policies or regulatory requirements may be violated. Ultimately, in closed networks, it is more important to establish a structure that can process documents within the internal network than to select a high-performance external service.

The Burden of Building the Entire Preprocessing Pipeline Within the Internal Network

If external APIs are difficult to use, it is advisable to configure document parsing functions such as OCR, DLA (Document Layout Analysis), and TSR (Table Structure Recognition) directly within the internal network.

Since subsequent RAG pipeline steps such as chunking and embedding must also be connected, assembling open-source tools one by one can lengthen the build time and increase maintenance burden.

OCR, which reads text from documents; DLA, which distinguishes title, body, and table regions; and TSR, which reconstructs row and column relationships in tables, are each distinct technologies. Connecting chunking and embedding with different tools can easily lead to version conflicts and integration errors, and operational management burden can grow. Bundling document parsing and structuring functions into a single pipeline helps reduce build and operational burden before moving to the chunking stage.

The Problem of Mixed Structured and Unstructured Documents That Cannot Be Processed by a Single Method

In environments where structured and unstructured document types are mixed, it is difficult to process all documents with a single extraction method.

Structured documents such as official letters, contracts, and application forms have consistent fields and formats, so extracting required fields using schema and rule-based methods is faster and more stable. In contrast, documents with complex tables, images, and hierarchical structures require OCR, DLA, and TSR to be used together to preserve structural information.

In particular, converting documents such as HWP and HWPX—where the original structure is important—to PDF and then extracting again can result in the loss of table structure and hierarchical information. Hancom’s analysis also explains that converting to PDF and then to training data can damage table structure, causing text to become jumbled and the original document structure to be lost.

Therefore, closed-network RAG preprocessing must divide extraction methods according to document type and be able to handle document parsing and structuring within the internal network. The approach to consider here is on-premises deployment.

How to Build On-Premises RAG Preprocessing

On-premises refers to installing and operating servers and software directly within the customer’s internal environment. Building RAG preprocessing on-premises allows documents to remain within the internal network, and the entire search preparation process—from document parsing and structuring through chunking, embedding, and vector DB storage—can be configured inside the internal network.

When designing RAG preprocessing on-premises in a closed network, two things must be confirmed first. One is to establish a structure that completes processing within the internal network so that documents do not leave. The other is to divide processing methods according to document type.

Internal-Network-Complete Structure Where Documents Do Not Leave

An internal-network-complete structure is a configuration in which the RAG preparation process—document parsing, structuring, chunking, embedding, and vector DB storage—is handled on internal network servers, so that documents and their embeddings are not transmitted externally.

Herever, an easily overlooked point here is that the object to be protected is not only the original document text. Privacy-Aware RAG research, which treats embeddings as encryption targets, holds that not only the original document text but also the corresponding embeddings must be protected together before storage. This is because even if only embeddings are leaked, sensitive information from the original document can be inferred. Therefore, in closed-network RAG preprocessing, not only external transmission but also storage methods and search environments must be managed together.

Structured Documents – Efficient Processing with Schema-Based Methods

Structured documents, such as official letters, legal documents, and medical records, have consistent fields and formats. Extracting them using rule-based methods according to a predefined schema yields structured data quickly and reliably.

Applying complex AI models to every document with a repeating format is inefficient. Since field positions and formats are fixed, extracting required fields using rule-based methods is faster and produces consistent results.

Unstructured Documents – Precise Processing with AI OCR and Document Layout Analysis

Unstructured documents mix images, tables, and graphics, and their formats are not consistent. Text must be read with OCR, and title, body, and table regions—as well as table structure—must be extracted together using DLA and TSR, so that document structure can be used in the subsequent chunking stage.

Table headers and values, and the relationship between titles and body text, must remain intact so that context is not broken in subsequent chunking and retrieval. Conversely, if hierarchical structure is lost and only text is listed, it becomes difficult to know which table or section a given sentence belongs to, and its value as search evidence may decline.

On-premises is the solution for closed networks, but not every organization needs to build on-premises from the start. Deployment methods should be compared and chosen according to the situation.

Comparison of On-Premises and SaaS API Deployment Methods

On-premises installs directly on internal servers and does not send documents outside, while SaaS API reduces installation burden and is used on a per-API-call or usage basis. Closed-network and sensitive-data environments are suited to on-premises; rapid pilots or small-scale tests are suited to SaaS API.

Comparison table of on-premises and SaaS API deployment methods

Comparison Item	On-Premise	SaaS API
Data Security	Internal-network-complete, operates without external transmission	Processed via external API calls
Initial Cost	Server infrastructure construction required	Used without server build costs
Billing Method	Solution implementation cost	Charged based on usage
Implementation Speed	Built to fit internal environment after container installation	Quick start via API integration
Suitable Environment	Public sector, large enterprises handling sensitive data	Pilots, small-scale tests, rapid deployment

If testing closed-network internal documents directly with SaaS API is difficult, there is also a path to first verify preprocessing quality with de-identified samples or documents that can be removed externally, then consider on-premises. SaaS API is charged per page, reducing pilot-stage burden, and if sensitive data is processed regularly, on-premises—which is complete within the internal network from the start—is appropriate.

Hancom Data Loader’s Closed-Network On-Premises Preprocessing Approach

Hancom Data Loader is a container-based on-premises document parsing solution installed on the customer’s internal servers. It converts HWP, HWPX, PDF, and OOXML documents into structured data, and because document data is not transmitted externally, it can be used safely even in closed-network environments.

👉 Go to Hancom Data Loader Live Demo

On-Premises-Centered Deployment with SaaS API Option

Hancom Data Loader offers a choice between on-premises and API SaaS deployment depending on the adoption environment. The on-premises approach is installed and operated on the customer’s internal servers, so documents do not leave, and it can operate even in internet-restricted closed networks, making it suitable for high-security environments such as public sector and finance.

In addition, there is no need to build OCR, DLA, and TSR separately; they are integrated in a single pipeline, reducing inter-tool integration errors and management complexity. Building directly with open source can result in problems where table header-value and title-body relationships are broken, and search quality does not improve even when the vector DB or embedding model is changed.

In this way, DLA and TSR preserve these relationships to create structured data, which is extracted as input data that can be used in the subsequent chunking stage even in closed-network environments.

Structured Data Conversion Tailored to Document Characteristics and Public-Sector Use Cases

Hancom Data Loader flexibly applies the necessary processing methods according to document format and characteristics, converting extraction results into structured data such as AI-optimized JSON.

The processing methods applied also differ according to document format. HWP and HWPX are parsed directly from the original without converting to PDF; PDF and images are processed with AI OCR, DLA, and TSR; and OOXML is processed with a focus on text extraction.

Direct parsing of the original also makes a large difference in speed. According to Hancom’s test results, extracting directly from HWPX (9.5 seconds) versus converting to PDF and then extracting (150.3 seconds) took approximately 15.8 times longer. The structured data secured in this way captures document hierarchical structure and coordinate information, as well as complex tables such as tables within tables and merged cells.

There are also public-sector use cases. According to ZDNet Korea reporting, Hancom Data Loader was supplied to the Ministry of the Interior and Safety’s ‘Government-Wide Hyperscale AI Common Infrastructure Project’ through the Samsung SDS consortium, playing an extraction and structuring role by converting public documents into structured data so that government ministries and local governments can use generative AI without security concerns.

The key to solving RAG preprocessing in closed networks is one thing: parsing and structuring documents within the internal network without sending them outside. By choosing on-premises or SaaS API according to the situation and dividing structured and unstructured documents by type for processing, the RAG preparation process can be reliably built even within the constraints of a closed network. The first step in turning internal-network documents into data that AI can use is to start by reviewing document parsing.

🖥️Hancom Data Loader

The first thing to confirm when building closed-network RAG is whether documents can be parsed and structured within the internal network without sending them outside. Hancom Data Loader is a document parsing solution that converts HWP, HWPX, PDF, and OOXML into structured data, and can be installed on-premises on the customer’s internal servers to establish a document preprocessing foundation even in closed-network environments.

The extracted structured data can be linked with Hancompedia as needed and used in the RAG pipeline that extends through chunking, embedding, retrieval, and answer generation. If you are reviewing RAG preprocessing methods in a closed network, you can first verify parsing results with actual documents.

👉 Verify parsing results in the Hancom Data Loader live demo

👉 Request a consultation on closed-network RAG preprocessing

Closed-Network RAG Preprocessing FAQ

---

References

1. News Way, “AI Adoption in the Financial Sector Blocked by Network Separation Regulations: Financial Innovation Going Astray,” 2025
2. Korea Capital Market Institute, “Current Status and Improvement Directions for Network Separation Regulations in Financial Companies”
3. arXiv, Zhou et al., “Privacy-Aware RAG: Secure and Isolated Knowledge Retrieval,” 2025
4. Hancom Tech, “Hangul Documents for the AX Era: Analysis of Open Source Ecosystem Status and Activation Strategy”