# AI for ERP in South Korea: On-Prem AI for Electronics and Battery Manufacturers > Source: https://netray.co/erp-ai/ai-for-erp-south-korea-manufacturing > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer South Korean manufacturers running SAP, Oracle, or a domestic ERP add AI by keeping the model and the ERP data it reads inside their own network or a Korea-based private instance, satisfying PIPA's strict cross-border transfer rules while giving planners, quality engineers, and procurement staff a faster way to work with production and supply chain data. This matters most in electronics, semiconductor, and battery supply chains where component traceability, yield, and supplier risk questions come up constantly and a slow answer has a real cost. ## Kind region ## Erp Family multi-erp ## Erp Products - SAP S/4HANA - Oracle E-Business Suite - Oracle Fusion Cloud ERP ## Industries - Electronics - Semiconductor - Battery Manufacturing - Defence ## Region South Korea ## Persona CIO ## Eyebrow ERP + AI for Korean manufacturing ## Intro Korean manufacturing runs at a pace that most AI vendors built for slower-moving industries do not fully appreciate. Electronics assemblers, semiconductor suppliers, and battery makers operate on tight yield targets, frequent engineering changes, and supply chains that stretch across multiple tiers of component suppliers, often with SAP or Oracle at the core and a mix of domestic MES and quality systems layered around it. An AI initiative has to speed up decisions inside that pace, not add a new system that slows anyone down while they learn it. PIPA, South Korea's Personal Information Protection Act, is stricter on cross-border data transfer than many CIOs expect coming from a GDPR-oriented compliance background. Transferring personal information overseas generally requires specific consent or another defined legal basis, and the Personal Information Protection Commission (PIPC) has been active in enforcement. An AI system that routes ERP data containing employee or customer personal information through a foreign-hosted model API creates exactly the kind of transfer question a compliance team would rather not have to defend after the fact. A second, faster-moving pressure is defence and dual-use export growth. Korean defence manufacturers and their electronics and precision component suppliers have expanded export activity substantially in recent years, and that growth brings the same technical-data handling scrutiny that established defence exporters like the US and Europe apply, even where Korea's own export control regime differs in its specifics. Suppliers entering this market for the first time often find that customer security expectations arrive faster than their own security programme was built for. The practical answer holds together across both pressures: an open-weight model served on infrastructure the company controls, on-prem or in a Korea-based private cloud instance, reads SAP, Oracle, or the domestic ERP through the interfaces those systems already expose, and any write-back still goes through a human review step. That keeps personal information inside Korea by default and gives a growing defence-adjacent supplier an architecture that does not need to be rebuilt as customer security requirements ramp up. ## Pain Points ### PIPA cross-border transfer restrictions **Detail:** Sending ERP data containing employee, customer, or supplier personal information to a foreign-hosted model API raises a PIPA cross-border transfer question that most compliance teams would rather avoid than resolve after deployment, particularly with PIPC enforcement active. ### Rapid pace of engineering changes in electronics and battery lines **Detail:** Frequent BOM and routing changes driven by component substitutions, yield improvements, or customer-specific variants mean planning and quality staff spend real time manually tracing what an engineering change actually touches downstream. ### Multi-tier component supply chain visibility **Detail:** Electronics and battery manufacturers manage supplier risk and component traceability across several supplier tiers, and the underlying data is often split between the ERP, a separate quality system, and supplier portals that do not talk to each other cleanly. ### Fast-growing defence and dual-use export exposure **Detail:** Suppliers newly active in defence exports face customer and program security expectations that arrive quickly, often before an internal security programme, including how AI tools handle technical data, has caught up. ### Mixed ERP landscape across conglomerate affiliates **Detail:** Large Korean manufacturing groups often run SAP or Oracle at one affiliate and a domestic or legacy system at another following a merger or restructuring, which makes a single AI approach harder to design than a single-ERP company. ## Use Cases ### Engineering change impact assessment **Description:** Given a BOM or component substitution change, lists the open orders, affected routings, and downstream inventory it touches across the ERP, so engineering and production can sequence the change without a manual cross-check. **Erp Objects:** BOM and routing tables, open production and sales orders, engineering change records **Outcome:** cuts the manual impact-check time for a routine engineering change from hours to minutes ### Yield and quality exception triage **Description:** Surfaces which production lots or work orders have quality flags or yield deviations that actually need attention today, pulling from quality module data instead of a manual daily scan across lines. **Erp Objects:** quality notifications, lot inspection records, production order status **Outcome:** quality engineers work the real exception list in a fraction of the time spent scanning it manually ### Multi-tier supplier risk and component traceability queries **Description:** Answers where-used and supplier-origin questions on a specific component or lot instantly, referencing supplier master data and lot genealogy rather than a manual trace across the ERP and supplier records. **Erp Objects:** vendor master, lot and serial tracking, approved supplier list, component genealogy **Outcome:** cuts component and supplier traceability research from hours of manual cross-reference to a direct, sourced answer ### Purchase order and supplier confirmation follow-up **Description:** Handles routine follow-up on open purchase orders and supplier confirmations automatically, escalating only genuine delays that threaten a production schedule. **Erp Objects:** open PO reports, vendor confirmations, supplier delivery performance data **Outcome:** buyers spend follow-up time on the exceptions that actually threaten a production schedule ### Production and MRP exception triage **Description:** Surfaces which materials or work orders need planner attention today across MRP exception lists, instead of a planner reviewing every open order line by line across multiple plants. **Erp Objects:** MRP exception lists, planned orders, purchase requisitions **Outcome:** planners resolve the daily exception list in a fraction of the time spent on a manual scan ### Export control and technical data access review support **Description:** Helps compliance staff review who has access to export-controlled technical data in the ERP against the roles that should hold it, flagging discrepancies for human review rather than auto-remediating. **Erp Objects:** ERP role and authorization assignments, document classification metadata **Outcome:** a faster, more consistent periodic access review that a small compliance team can keep up with as export activity grows ### Natural-language reporting across affiliates **Description:** Lets a manager ask a question once and get an answer grounded in whichever ERP a given affiliate runs, without needing to know the underlying transaction codes or table structures at each entity. **Erp Objects:** SAP CDS views and BW, Oracle Fusion or EBS reporting tables, domestic ERP reporting extracts **Outcome:** fewer one-off report requests land on a stretched central reporting or BI function ## Architecture **Overview:** The architecture keeps ERP and quality data inside a boundary the company controls, in Korea by default, and reads each system through its own existing interfaces rather than requiring a single unified platform across affiliates that run different ERPs. **Layers:** #### ERP connectors **Detail:** OData/BAPI/IDoc for SAP, REST/SOAP APIs and interface tables for Oracle EBS or Fusion Cloud ERP, and API or database views for a domestic ERP, each read-only by default. #### Data and semantic layer **Detail:** A normalised semantic layer over whichever ERP and quality system a given plant or affiliate runs, plus a document index over work instructions, quality procedures, and supplier specifications. #### Model serving **Detail:** An open-weight model (Llama, Qwen, Mistral, or Gemma class) served with vLLM or Ollama on GPUs the company owns, on-premises or in a Korea-based private cloud instance, with no default outbound call to a non-Korea API. #### Retrieval and agents **Detail:** Retrieval-augmented generation grounds answers in current ERP, quality, and document data; any agent proposing a write, such as a PO follow-up message, stops for human confirmation before touching the ERP. #### Governance and audit **Detail:** Query and response logs mapped to ERP roles give IT and compliance a documented trail supporting PIPA accountability requirements and any customer supply chain security review. ## Deployment Options ### Air-gapped on-prem **Fit:** Defence-adjacent electronics and precision component suppliers handling export-controlled technical data **Detail:** The model, retrieval index, and ERP connectors run entirely inside the company's own network with no outbound internet path, giving a defensible answer in a customer or program security review as defence export activity grows. ### Private Korea-hosted cloud **Fit:** Manufacturers without in-house GPU operations who need to keep personal and production data inside Korea **Detail:** A dedicated instance hosted in Korea, outside any shared multi-tenant infrastructure, avoiding both the PIPA cross-border transfer question and the capital cost of owning GPU hardware. ### Hybrid across affiliates **Fit:** Conglomerate groups running SAP at one affiliate and Oracle or a domestic ERP at another **Detail:** A shared model-serving and governance layer with affiliate-specific connectors, so each entity's ERP is read through its native interface while the AI experience and audit trail stay consistent group-wide. ## Compliance ### Keeping model inference and data processing inside Korea by default avoids the cross-border transfer consent and disclosure requirements that a foreign-hosted model API would otherwise trigger for any personal information touched by the assistant. **Framework:** PIPA (Personal Information Protection Act) ### Full query and response logging, mapped to ERP roles, gives the company documentation to support its accountability obligations if the Personal Information Protection Commission requests evidence of how an AI system handles personal information. **Framework:** PIPC enforcement expectations ### Access to controlled technical data through the AI layer mirrors the ERP's own role-based restrictions rather than creating a new, broader access path, supporting the same access reviews the company already runs for export compliance. **Framework:** Export control on defence and dual-use technical data ### The audit trail on AI-assisted quality and traceability queries is designed to be reviewable by the same auditors who check ERP-based traceability today, not a separate, opaque log. **Framework:** ISO 9001 / IATF 16949 traceability ## Integration Notes SAP: OData services via SAP Gateway, BAPI/RFC, and IDoc, read-only by default with write-back requiring explicit human confirmation per transaction. Oracle E-Business Suite: interface tables and concurrent program outputs for transactional data, with API access where already exposed. Oracle Fusion Cloud ERP: REST APIs and OTBI/BI Publisher for reporting-style access, kept inside a Korea-hosted or on-prem retrieval layer rather than routed through a general-purpose cloud AI feature. Domestic ERP systems: API or database view access depending on what the specific platform exposes, following the same read-only-by-default pattern. A shared identity layer maps each user's existing ERP role to what the assistant can see, so access never exceeds what the user could already see directly in the ERP. Document sources such as work instructions, quality procedures, and supplier specifications are indexed inside the same boundary as the ERP data, not in an external SaaS document tool. All model inference and retrieval run on infrastructure inside Korea with no default outbound call to a non-Korea API for any part of the pipeline, including secondary functions like embeddings. ## Product Fit ### ERPray **Why:** For a group running SAP at one affiliate and Oracle or a domestic ERP at another, ERPray's connector-based, read-only question-answering approach gives a consistent AI experience across the estate without forcing a single-platform migration. ### DataRay **Why:** Where supplier specifications, quality manuals, and engineering documents sit outside the ERP as file shares or a document store, DataRay extends the same on-prem, Korea-hosted approach to those sources. ### Custom build **Why:** Engineering change impact assessment and multi-tier supplier risk queries usually need logic tailored to how a given plant's BOM structure, quality module, and supplier data are configured. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of ERP and quality systems in use across plants or affiliates and how each exposes data today - PIPA cross-border transfer review and export control scope assessment for the planned use cases - Use case shortlist ranked by effort and impact per plant - On-prem GPU or Korea private-instance sizing estimate ### Pilot **Duration:** 6-8 weeks **Deliverables:** - One use case live in read-only mode at a single plant or affiliate - Model evaluation against real ERP and quality data from that site - Draft PIPA documentation covering the pilot's data handling - User feedback loop and adoption metrics reviewed with IT ### Production **Duration:** 6-10 weeks **Deliverables:** - Hardened deployment with role-based access tied to each affiliate's ERP roles - Full audit logging integrated with existing security monitoring - Finalised PIPA and export control documentation - Runbook covering model updates and incident response inside the Korea boundary ### Scale **Duration:** Ongoing **Deliverables:** - Rollout to additional plants or affiliates, including different ERPs under the shared governance layer - Additional use cases from the original shortlist - Periodic access review process handed to the compliance team as export activity grows - Quarterly review of model options as the open-weight landscape evolves ## Buyer Questions - Where exactly does the model run, and can that location be confirmed for a PIPA or customer security review? - Does any part of the pipeline call a non-Korea API by default, including for a secondary function like embeddings? - Can we produce PIPA-relevant documentation from the vendor's own record of how the system handles personal information? - How does the tool respect our existing export control access segregation rather than creating a new access path? - If we run this across SAP, Oracle, and a domestic ERP, is the governance and audit experience consistent across all three? - What is the fallback if the on-prem GPU or Korea-hosted private instance is unavailable for a day? - What happens to our data, models, and configuration if we end the engagement? ## Faq ### Does PIPA prevent us from using AI on our ERP data at all? **Answer:** No, PIPA does not prohibit AI on ERP data, it restricts how personal information can be transferred across borders without proper consent or another legal basis. Keeping the model and the data it processes inside Korea, on-prem or in a Korea-based private cloud instance, avoids the cross-border transfer question entirely for most use cases rather than requiring a case-by-case consent process. ### Can this work across SAP at one affiliate and Oracle or a domestic ERP at another? **Answer:** Yes. Each ERP is read through its own native interface, SAP via OData/BAPI/IDoc, Oracle EBS or Fusion via interface tables and APIs, a domestic system via whatever API or database access it exposes, with a shared semantic and governance layer sitting on top so users get a consistent experience across affiliates. ### Is on-prem AI realistic for a mid-size Korean component supplier, not just a large conglomerate? **Answer:** Yes, and the deployment scales down cleanly. A single-plant, single-ERP supplier can run a modest on-prem GPU setup or a small Korea-hosted private instance, with the same architecture principles, Korea-only processing, read-only by default, human approval on writes, applying regardless of company size. ### How does this help with growing defence and dual-use export scrutiny? **Answer:** As Korean defence and dual-use exports have grown, customers and programs increasingly expect suppliers to demonstrate how technical data, including anything an AI tool touches, is controlled. An on-prem or Korea-hosted architecture with role-based access mirroring the ERP gives a supplier a documented answer to that expectation before it becomes a blocker in a customer security review. ### Does using an open-weight model from outside Korea, like Llama or Qwen, conflict with PIPA goals? **Answer:** No, provided the model weights are downloaded and run entirely on infrastructure you control inside Korea, with no outbound calls to the model's original provider. PIPA is concerned with where personal information is processed and who can access it, not the nationality of the organization that originally trained the model. ### What is the realistic first use case for an electronics or battery manufacturer? **Answer:** Engineering change impact assessment and yield or quality exception triage tend to show value fastest, since engineering changes and quality flags are frequent, well-understood tasks with a clear existing process that the assistant speeds up rather than replaces. Multi-tier supplier traceability queries are a close second once lot genealogy data is well indexed. ### How is this different from the AI features SAP or Oracle already offer natively? **Answer:** Native vendor AI features typically depend on the vendor's own cloud AI service, which raises the same cross-border transfer question this architecture is built to avoid, and are usually scoped to that single ERP. An on-prem or Korea-hosted private model reads across SAP, Oracle, and domestic systems in one governed layer and keeps processing inside a boundary the company controls end to end. ## Search terms AI for ERP South Korea, AI for SAP Korea, on-prem AI Korea manufacturing, PIPA AI compliance ERP, AI for Oracle EBS Korea, AI electronics manufacturing Korea, AI battery supply chain Korea, sovereign AI manufacturing Korea, private LLM Korea manufacturing, AI semiconductor supply chain Korea, Korea defence export AI compliance, AI ERP integration Korea --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json