Ask an AI to find a work document, and it answers. Ask it to analyze some data, and it produces results. So is putting AI to work on real tasks just a matter of having a model ready?
On the ground, the story is a little different. The material you need is scattered across several systems, and departments often call the same thing by different names. In air-gapped environments cut off from the outside, general-purpose AI services can’t simply be used as they are. And what counts as a “correct answer” differs from one task to the next.
So even with a good model and solid infrastructure in place, AI can’t immediately understand and carry out the work at a given site. It has to be implemented and tuned for the customer’s data and work environment. NAVER Cloud’s forward deployed engineers (FDEs) do exactly that, on site with the customer. They study the customer’s work and data, structure vague requests into concrete technical tasks, build the AI system through a proof of concept (PoC) and a pilot, and then feed the problems found in live operation back into the next round of improvements.
This work is already under way at several customer sites. We’ve built cloud infrastructure and a generative AI platform inside the data center of Korea Hydro & Nuclear Power (KHNP), and we provide AI services for the internal network of Korea’s government-wide AI common platform. In defense, we’re working with partners on AI that connects different kinds of information to support commanders’ decisions. At each of these sites, NAVER Cloud FDEs are the ones who make sense of the customer’s work and data and turn them into a working AI system.
What problems do NAVER Cloud FDEs run into at these very different sites, and how do they solve them with AI systems? Let’s take a look.
NAVER Cloud FDEs: Engineers who embed with the customer
NAVER Cloud FDEs, or FDEs, are engineers who embed directly at the customer’s site and design, build, and operate AI systems on top of that organization’s data and working conditions. They work alongside the customer organization from defining requirements through validation, deployment, and post-launch improvement.
Here, “forward deployed” means more than being physically close to the customer. It means understanding what the customer actually does, grasping their needs in their own language, and being able to carry that through into a working AI system.
Plenty of companies have FDEs. But how much an FDE can actually do at a customer site depends on what technology the company itself owns. Solving a customer’s problem sometimes means deploying a model directly onto the customer’s infrastructure, and sometimes means building the application layer so the model’s answers actually get used in day-to-day work.
NAVER Cloud owns the whole stack, from data centers and infrastructure to AI models and applications. That lets FDEs connect whatever technology is needed into a single AI system the customer can actually use on site. Along the way, FDEs take on three main kinds of work.
- Solving problems across different domains with technology
FDEs experience each domain’s data, terminology, and business rules firsthand, whether in nuclear power, the public sector, or defense, and build those requirements into the AI system. - Building inside air-gapped networks
They deploy models on infrastructure installed inside the customer’s data center and build the applications within the customer’s own network. - Turning customer needs into applications
They assemble AI pipelines tailored to the customer’s work using retrieval-augmented generation (RAG), ontologies, agents, and other techniques.
An FDE’s job doesn’t end with handing the customer a good model. It’s to understand the customer’s work environment and build a system in which AI can actually do the work.
Four problems that come up at every site
Nuclear power, the public sector, and defense are very different settings, but the problems that surfaced when adopting AI were largely the same.
Data is scattered.
Only a fraction of a customer’s material is organized in a form AI can use right away. The rest is split across departmental systems and file servers. Security policies and cost make it hard to simply move everything into one repository, so we need a way to connect and organize the data where it already sits.
The same thing goes by different names.
What frontline staff call a “facility,” another department calls “equipment,” and the IT system tracks as an “asset.” Even when a search result is accurate, mismatched names can lead the AI to treat the same thing as several different things.
The network is air-gapped.
In an air-gapped network, training, inference, and operations all have to happen inside. External APIs can’t be called, and pipelines built in an external environment can’t simply be brought in. So not just the AI model but the entire process of connecting and processing data has to be designed around the customer’s internal environment.
The standard for a “correct answer” varies.
Even for the same question, different stakeholders want different things from the answer. Frontline staff may prize recency, audit teams the reliability of sources, and approvers brevity. The very definition of a “good answer” shifts with the task and the person.
These problems can’t be solved just by making the model or the infrastructure more powerful. Where the data lives, what it’s called, how the system will be operated, and what counts as a right answer all have to be worked out together, inside the customer’s site. That’s where the FDE’s role begins.
So how did we solve these problems in practice?
Turning on-site problems into systems where AI can work
The same AI needs to take a different shape depending on the customer’s work and data environment. At some sites, the first job is simply finding the right document accurately. At others, the AI has to connect different data sources and understand how they relate.
Rather than copying the customer’s request straight into a development ticket, FDEs pin down the features and technology the real work environment calls for and implement them as a single AI system. Here’s how FDEs have worked at three sites: nuclear power, the public sector, and defense.
KHNP: Turning decades of documents into data AI can understand
Korea Hydro & Nuclear Power (KHNP) now runs a RAG service grounded in its internal business data, running on HyperCLOVA X deployed in the company’s own data center. On that foundation, it rolled out Hy-NuRI, a company-wide platform that includes dedicated chatbots that hold each department’s working knowledge.
Figure 1. KHNP’s Hy-NuRI platform
Nuclear plants are places where procedures and technical standards have to be followed to the letter. So the first requirement was RAG: for every question, find the relevant documents, answer based on their contents, and show the source documents alongside the answer.
But when building RAG on site, the first problem to solve wasn’t the retrieval model. It was getting the documents into a form the AI could search in the first place.
Documents at a nuclear plant aren’t neatly organized text files. Decades of accumulated material mix PDFs, HWP files, scans, and even handwritten documents, each with its own structure. Simply loading all of this into a search system won’t surface what people need. FDEs tuned three things on site.
- Document ingestion and parsing: converting PDF, HWP, scanned, and handwritten documents to text while preserving table structure, and extracting metadata such as creation date and document type
- Chunking: setting different splitting rules for each document type, such as by section for procedures and by article and clause for technical standards
- Reranking: weighting search results by recency and source grade alongside relevance, to decide which documents to show first
What FDEs adjusted on site were the detailed settings that make up RAG. How each document is read, what unit it’s split into, and which search results carry more weight were all decided to fit the customer’s work environment. The same RAG behaves differently from one customer to the next because these settings differ.
Figure 2. The six stages of the RAG pipeline
Public sector: From AI that finds answers to AI that helps get work done
Korea’s government-wide AI common platform gives civil servants access to AI from inside the administrative network, which is separated from the internet. NAVER Cloud provides the AI services that run on this internal network.
Once people start using AI in their actual work, new demands emerge. At first, just being able to search for information and generate answers or drafts is helpful. But with use, the next question naturally follows:
“Instead of stopping at the answer, couldn’t it handle the next step of the work too?”
But before AI can be trusted with more, today’s answers have to be trustworthy. On site, even when someone reports that “the answer looks off,” it’s often hard to tell right away at which stage the problem occurred.
Working from real voice-of-customer (VOC) feedback, FDEs built a golden set, a reference dataset of correct answers that serves as the evaluation standard. They also built an analysis tool that shows responses, logs, and system status on a single screen, so that instead of a vague sense that “the answer looks off,” the team can see from the data exactly which stage the quality dropped at. These findings were shared with the planning and development teams and fed into real improvements.
Alongside checking and improving quality, FDEs put real effort into finding and building the AI each ministry actually needs. Every ministry handles different work, holds different data, and repeats different tasks, so FDEs start by going on site. Through interviews and surveys with the people doing the work, they pin down where the most time goes and which tasks staff would like to hand off to AI.
Those findings lead straight to deliverables. For frequently repeated tasks such as drafting reports, searching references and legislation, and answering civil complaints, FDEs build ministry-specific assistants in AI Studio, then review the results with civil servants to verify they’re good enough for real work. On top of this, they provide guides and training on using AI Studio, writing prompts, applying background knowledge, and adapting the tools to specific tasks, so that civil servants can use the tools themselves and build their own.
In the public sector, FDEs work with ministries to identify AI they can actually use, build it, and help staff take it from there. That’s how AI that started out finding answers is growing into AI that directly supports civil servants’ work.
Photo 1. An advanced AI training session for government staff
Defense: From information gathered in the field to information commanders can act on
Defense is where the FDE’s role stretches the widest. Information arrives in different forms, from drone footage and satellite imagery to radio audio and operational documents, and all of it is scattered. Communications can drop out, and real-world data is hard to come by. All of these conditions apply at once. NAVER Cloud is building a structure that analyzes this information together with an omnimodal model, turns it into information commanders can understand, and feeds it into decision-making.
The first thing to settle is who collects the field data and who analyzes it. In edge environments such as drones and tactical vehicles, data has to be captured and analyzed quickly on the spot. FDEs divide this work with a partner company that specializes in AI drone swarms.
- AI drone swarm company: relays the video and sensor data the drones collect in flight to the ground control station
- NAVER Cloud FDEs: analyze that data with the HyperCLOVA X omnimodal model, turn it into object and situational information, and connect it to an ontology-based knowledge system and agents
The drones see the field, and NAVER Cloud FDEs turn what they see into a form that can inform decisions.
Photo 2. On site with a defense customer
But analyzing video alone isn’t enough. For the output to be useful in real decisions, the AI has to go beyond identifying “what was seen” and understand how that information relates to what’s already known about the situation.
Say an enemy tank is spotted on the move. Beyond the bare fact that “a tank moved,” you need to see where the movement occurred, how it relates to indicators of an attack, how it connects to friendly defensive lines, and what judgments and responses doctrine calls for. FDEs use an ontology to structure the concepts and terms used on the battlefield, the relationships between them, and doctrine into a single knowledge system. This lets information observed by different systems be linked under the same meaning. Figure 3 uses an unidentified track as an example, showing how scattered detections pass through the ontology and connect into a single chain running from threat assessment to courses of action and commander approval.
Figure 3. Applying an ontology
There’s one more difficulty. In defense, real-world data is hard to obtain in sufficient quantity. So for drone footage, satellite imagery, and surveillance video analysis, FDEs build simulation environments and synthetic data themselves, validate the model on them, and then move it to the field.
Finally, defense systems include a point where a person reviews and approves, so that AI never makes the final call on its own. This is known as human-in-the-loop (HITL), and FDEs build it in from the design stage. AI can assist with detection and tracking, but a person always makes the final determination, and that approval is recorded in the system. FDEs also design these checkpoints into the harness—the structure in which an agent calls tools to carry out actual tasks.
Figure 4. Harness agent: From answers to actions
AI’s role isn’t to make the decision but to help commanders decide faster and more accurately. In defense, what FDEs do is closer to stitching different technologies and systems into a single flow, from capturing data in the field through AI analysis and knowledge structuring to decision support.
How FDEs work: The pattern behind all three sites
Nuclear power, the public sector, and defense were different sites, and the technology used at each differed too: RAG, ontologies, agents. But the way FDEs work follows a common pattern. They structure the customer’s requirements, validate on a small scale, evaluate in the real operating environment, and feed the results into the next set of requirements, in a continuous cycle.
- Requirements structuring: break the customer’s needs into concrete items and agree on what to tackle first
- Proof of concept (PoC): implement the core requirements at small scale and check them against quantitative criteria
- Pilot: run on real data in the users’ environment and gather feedback from frontline staff
- Productization: hand validated features over to the product team
- Observe, evaluate, improve: review operational logs and feedback to find improvements, and turn them into new requirements
Looking at this flow a little more closely makes it clearer what FDEs actually do at a customer site.
Figure 5. How FDEs work
Turning what customers say into requirements a system can understand
Customers speak the language of their work. A single sentence can bundle together where the data lives, how accurate the answer needs to be, and what security constraints apply. FDEs interview frontline, IT, and approval teams directly and break those needs down into six items.
- Domain: the terminology, rules, and document types of the business area
- Data location: which systems hold the data, and in what form
- Terminology gaps: names that differ across departments and systems
- Constraints: the shape of the air-gapped network, hardware resources, and regulatory and audit requirements
- Accuracy criteria: who judges what a “correct answer” is, and by what conditions
- Priorities: which requirements take precedence when they conflict
These items become the criteria for designing and tuning the actual AI system. Adjusting the ranking of search results at KHNP to account for recency and source, and linking concepts and terms from different systems through an ontology in defense, both came out of this process. It’s why the same technology ends up configured differently at every site.
Evaluating on two axes: Numbers and people
Working well in a demo and being used every day on the job are two different things. So separately from building the system, FDEs start by designing how to evaluate it, deciding what will count as “working well” and by what standard.
1. Quantitative evaluation
Quantitative evaluation measures quality with metrics. As with the golden set built from VOC in the public-sector case, the evaluation dataset is built from real questions. For RAG, RAGAS metrics measure whether answers stay faithful to the source documents, whether they address the question, and how well the necessary documents were retrieved.
Measured this way, evaluation doesn’t just say “the answers aren’t good”; it tells you which part to examine first: parsing, chunking, reranking, or terminology linking. For example, re-running the same dataset after applying an ontology shows how much context recall, previously dragged down by terminology gaps, has recovered, putting a number on the ontology’s effect.
Agents are evaluated by different criteria than RAG, because they produce actions rather than answers. Metrics track how much of the task was completed, whether the right tools were called correctly, and how efficiently each step ran. One metric worth watching is the checkpoint intervention rate: the share of cases where, at a human review point, the person in charge rejected or modified the agent’s proposal. A high value means the agent is proposing actions that don’t fit the customer’s business rules. If it’s too low, FDEs recheck whether the checkpoints are placed where they’re truly needed.
2. Qualitative evaluation
But metrics can’t catch every problem. Answers that run too long, draw on low-reliability sources, or are written only in one department’s jargon so that other departments struggle to read them are all examples. So FDEs run a qualitative evaluation with the customer’s frontline staff, reading and judging the answers directly, and add any problem types the metrics missed to the next evaluation dataset as new items.
When both evaluations point the same way, FDEs deploy the system. When they diverge, the gap becomes the lead for the next improvement. Evaluation datasets are built with the customer’s frontline staff inside the air-gapped network and never leave it. At sites like defense, where real data is hard to obtain, simulation data is also used to cover a range of scenarios in evaluation.
Figure 6. Quantitative and qualitative evaluation and the paths to improvement
Wherever the problem is, the path to a fix runs through NAVER Cloud
Sites keep changing after deployment. New procedures and legislation get registered, and when the organization changes, so can its terminology and ways of working. FDEs keep watching operational logs and frontline feedback, sort the problems they find by type, and address each accordingly.
- Problems solvable through pipeline settings: FDEs adjust them directly on site
- Problems that need improvements to the model itself: FDEs compile evaluation data and failure cases and pass them to the model team
- Requests that recur across multiple customers: FDEs write them up as product requirements and pass them to the product team
For example, if evaluation scores come in low because the model doesn’t adequately capture a domain’s terminology or regulatory framework, FDEs use the failed questions and evaluation data to isolate the cause. If adjusting settings on site will fix it, they make the change themselves. If the model itself needs improving, they compile the failure cases and domain material and hand them to the model team. Once a new model is deployed, running the same evaluation dataset again shows whether it has improved.
Earlier, we noted that how much an FDE can do on site depends on what technology the company itself owns. This is what that means in practice. Because NAVER Cloud owns everything from data centers and infrastructure to AI models and applications, whatever layer a problem found on site belongs to, it can be routed to the right team and technology, and improvement continues. FDEs request the improvement from that team and then verify the result back in the customer’s environment.
Figure 7. The FDE lifecycle and how it connects to internal teams
Before AI can work on site, it has to understand the site
Putting AI to work on real tasks doesn’t end with picking a good model and building a system. The problems to solve and the technology needed differed from customer to customer, as we saw at the nuclear, public-sector, and defense sites, but at the center of each was an FDE who understood the customer’s work and turned it into a working AI system. In the end, what FDEs build isn’t just an AI feature. It’s a structure in which AI can actually work within the customer’s data and work environment.
As AI moves into more and more kinds of work, implementing the technology for each site and continuing to develop it there will matter as much as the performance of the technology itself. NAVER Cloud FDEs understand on-site problems in the customer’s language, validate solutions in real work, and build that process together with the customer. NAVER Cloud FDEs will keep working with customers to shape how AI does its job on site. We hope you’ll follow along.