From the Campus Operations edition of October 28, 2026
Jeju National University pilots a staff-built AI clerk on Korea's shared university ERP, running on its own GPU-hosted LLM
Jeju National University · Higher education administration (ERP, finance, HR) · Jeju, South Korea
- Publisher
- Jejudomin Ilbo
- Original publication
- 28 October 2026 (Jejudomin Ilbo)
- Source retrieved
- 2026-10-29
- Event date
- 2026-10-28
What happened
Jeju National University began piloting an AI assistant layered onto KORUS, the shared resource management system for Korean national and public universities. Administrative staff built it alongside regular duties with no separate budget, adding features over the user interface instead of modifying the shared system. It summarizes, proofreads and drafts replies in the e-approval window, triages incoming documents by urgency, translates, and offers HR, payroll and finance chatbots grounded in manuals and laws. Generative AI runs on a university-owned GPU server rather than external services. Wider rollout to 36 universities is under consideration.
Why it matters
U.S. campuses on shared or system-wide ERPs face the same constraint: they cannot change the core system quickly. An overlay approach with self-hosted models is a transferable pattern, though Korean public-sector context and data rules differ.
Evidence and measured results
Newspaper report of the university announcement and 27 October staff demonstration; no measured results.
Limitations and uncertainty
Pilot with no performance data; self-reported by the university; Korean regulatory and shared-system context limits transfer.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-28; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Shared ERP systems are hard to change, leaving staff with manual lookups and slow document handling.
- Stakeholders
- System office IT
- Campus administrative leaders
- HR and payroll
- Finance and accounting
- Information security
- Discovery questions
- Which shared systems can you not modify?
- Do you have self-hosted model capacity?
- Which document workflows consume most staff time?
- Value hypothesis
- Interpretation: an overlay assistant could reduce manual lookups without core ERP changes; no gains are measured.
- Potential engagement
- A bounded overlay feasibility study on one administrative workflow.
- Unsupported claims
- Time savings
- Answer accuracy
- Readiness for multi-campus rollout
Pre-sales engineering
Role takeaway
- Fit
- Fits institutions on shared or legacy ERPs with access to GPU capacity.
- Architecture and integration
- Browser or desktop overlay on the ERP interface, self-hosted LLM on a university GPU server, chatbots grounded in manuals and law, on-device translation.
- Prerequisites
- GPU server and model hosting
- Curated manuals with sensitive data removed
- Permission to overlay the ERP interface
- Constraints
- Overlay may break on ERP updates
- Korean data rules differ
- Self-hosted model quality unknown
- Security
- No external AI services; manuals scrubbed of sensitive data; translation stays on the PC.
- Proof of value
- Test answer accuracy against manuals
- Measure triage agreement with staff
- Test overlay after an ERP update
Delivery
Role takeaway
- Work
- Pilot and then scale an ERP overlay assistant with support and change control.
- Dependencies
- GPU capacity
- Shared-system operator agreement
- Staff feedback process
- Ownership
- Campus administrative IT, with the shared-system operator if expanded.
- Skills and adoption
- Staff-led development; demonstrations to all staff before pilot.
- Governance checkpoints
- Security review of overlay
- Accuracy review of chatbot answers
- Decision gate before multi-campus rollout
- Acceptance criteria
- Proposed: chatbot answers match manuals in a sampled review
- Proposed: named owner and support process before expansion
- Risks
- Overlay fragility
- Unsupported staff-built code
- Model errors on legal or payroll questions
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
UI overlay on a shared ERP rather than core changes; on-premises GPU LLM; local translation on the PC.
Governance
Who approves, reviews and stays accountable for outcomes?
Staff-built tools on a shared national system raise questions about review, support and change control before wider rollout.
Security and privacy
What data, permissions and controls need testing?
Sensitive information removed from chatbot manuals; translation kept on device; no external AI services.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Built by administrative staff themselves; aims to reduce manual lookups and phone queries to other offices.
Procurement
What should contracts, pricing and exit terms secure?
No separate budget reported; relies on existing GPU capacity and staff time.
Operating model
Which teams own the service once it runs?
Shows a staff-led development model for administrative AI that may later need central ownership if shared across 36 universities.
Publication history
- 2026-10-28Campus Operations · Issue 515 resources
Stable resource ID: jeju-national-university-korus-ai-clerk-onprem-llm-20261028