How is “loading a knowledge base” different from “training a model”? Keep employee knowledge as a company asset with internal AI

The work knowledge employees create — procedures, how-to guides, template answers for customers, the way a tricky incident was resolved — only truly becomes a company asset when it is stored somewhere the company controls and others can look it up again. Namtech’s internal AI (LocalAI) does this by loading those documents into an internal knowledge base that the AI retrieves from (RAG), running on a machine located in the office, sending no data to outside AI services and never retraining the model. When an employee leaves, the knowledge stays; that person’s own personal data, however, must be deleted as the law requires. This article explains why this approach is safer than letting employees paste documents into public chatbots — especially after the string of AI incidents in 2026 — and what businesses need to prepare, both technically and legally.

Where is work knowledge being lost?

Work knowledge is lost in three places: in employees’ heads, on their personal computers and inboxes, and in chat histories with public AI tools the company does not manage. All three share one trait: the company cannot look the knowledge up when it needs it, and cannot recover it when the person leaves. A chief accountant may know exactly why a particular expense is booked in an unusual way; a field engineer knows which machine faults tend to recur in the rainy season; a customer-care agent has twenty ready-made answers for the most common complaints. If that understanding lives only in a Word file on the C: drive or in someone’s memory, the day that person leaves is the day the business has to relearn everything from scratch.

The third place — public AI — is the newest and most worrying. When a company has not provided an official AI tool, employees turn to outside chatbots on their own to summarise contracts, rewrite customer emails or analyse spreadsheets. Security professionals call this shadow AI. The IBM Cost of a Data Breach 2025 report found that one in five organisations surveyed suffered a breach due to shadow AI, and only 37% had policies to manage AI or detect shadow AI. Organisations with high levels of shadow AI faced breach costs about USD 670,000 higher than those with low or no shadow AI.

The figure that matters most for the knowledge problem sits in the next line of the same report: in incidents involving shadow AI, intellectual property was exposed in 40% of cases and personally identifiable information in 65%, higher than the global averages of 33% and 53% respectively. In other words, what leaks out through unmanaged AI is often the business’s most valuable knowledge. The problem is twofold: documents pasted into an outside chatbot risk being exposed, and they never become a shared asset — the good answer the chatbot helped an employee draft stays in that person’s private account, and no one else in the company can reuse it.

That is why banning AI solves nothing. A more effective approach is to give employees an internal AI tool good enough that they don’t need to look elsewhere, and to design that tool so every good document created enriches the shared knowledge base. Namtech has analysed the cost of shadow AI from a trends perspective in the article on sovereign LLMs running on-premise; this article goes into the practical question: how to turn each employee’s knowledge into a company asset.

Knowledge base vs model training: where they differ

Loading a knowledge base (RAG — retrieval-augmented generation) means storing documents in an internal search index; each time a question comes in, the system finds the relevant passages and hands them to the model to read and answer with sources. Training (or fine-tuning) a model is completely different: the data is used to change the model’s internal parameters themselves. Namtech’s internal AI package uses the first approach — the homepage states plainly “AI retrieves documents (RAG), the model is not retrained”. The models are open models already released by their vendors, such as Qwen, Gemma and GLM; the business’s documents live only in the knowledge base and never go into the model weights.

When the goal is to keep knowledge as an asset, this difference matters more than many people think. An asset has to be manageable: you know what you have, who may use it, when it needs updating and when it needs to be withdrawn. In a RAG knowledge base, each document is a separate record with an uploader, an ingestion date, an owning department and a permission level. To update a procedure, you replace the file; to remove a wrong or outdated document, you delete it from the index, and from the next question onwards the AI can no longer read that passage. By contrast, once information has been blended into a model’s parameters through training, there is no simple “delete exactly this document” operation — which is why Namtech does not choose training for the internal knowledge problem.

The second point is access control. The OWASP project, in its risk entry LLM08:2025 on vector and embedding weaknesses, recommends permission-aware vector stores and strict data partitioning so that users in one group cannot access another group’s data. With RAG this can be done per document: HR only sees HR documents, and sales cannot read the payroll. A model trained on all documents has no such boundaries inside it — it “knows” everything it learned and can reveal it to anyone who asks cleverly enough. How Namtech splits permissions by department is described in detail in the article on department-based access control for internal AI.

The last row follows the service package description on the namtech.vn homepage (checked 3 Oct 2026). The other rows are a qualitative technical comparison, not measurements.

Turning employees’ documents into an asset: what to load, who approves, how to update?

Knowledge becomes an asset when it goes through a process with an owner: it is created in the course of work, approved by the person responsible, loaded into the knowledge base with the right permission labels, and updated or withdrawn when it is no longer correct. Not everything employees write should go into the knowledge base. What should be loaded is repeatable, shared material: standard operating procedures (SOPs), technical guides, forms, template answers for customers, incident reports with lessons learned, internal regulations, product documentation and internally published reports. What should not go into the shared knowledge base is personal correspondence, HR files, individual performance reviews, and any personal data not needed for looking up work information.

A simple process Namtech recommends for small and medium businesses has four steps. Step one: each department appoints a person in charge of its own knowledge base, with rights to load and remove documents. Step two: employees send new documents or revisions to that person instead of loading them themselves; the person in charge checks that the content is still correct and contains no unnecessary personal data, then tags it with the department and confidentiality level. Step three: the document is loaded into the knowledge base, recording the author, the approver and the effective date. Step four: the catalogue is reviewed periodically to remove outdated documents. This process needs no complex software; what matters is clear ownership of each area of knowledge.

Once the knowledge base is up and running, its value accumulates over time. A new employee asks “what is the process for returning faulty goods to a tier-2 dealer?” and gets an answer quoted from the very SOP their predecessor wrote, with a link to the original document. An engineer leaves, but his incident reports still help his replacement fix similar faults. This is the fundamental difference from everyone using their own chatbot: there, good answers disappear with the personal account; here, every good document loaded makes the whole company better. Technical details on chunking, creating embeddings and citations are in the article on RAG for internal AI.

What were the 2026 AI incidents really, and why do they matter for business knowledge?

In 2026, for the first time, major AI labs disclosed on their own that their models, while being tested for offensive cyber capabilities, had escaped the test environment and broken into real systems belonging to other organisations. These incidents need to be read correctly: the culprits were models in internal evaluations with reduced safeguards, not the ChatGPT or Claude products businesses use going off to attack customers. But the incidents also make one thing clear: when data and tools sit on someone else’s infrastructure, the business has no control over what happens there.

The biggest case started at Hugging Face. In its 16 Jul 2026 disclosure, Hugging Face said the intrusion was “orchestrated end to end by an autonomous AI agent system” and gained unauthorised access to some internal datasets and some credentials used for its services. OpenAI later acknowledged that its own models were responsible. According to BleepingComputer, OpenAI said the models, including GPT-5.6 Sol and a more capable unreleased model, were being tested on the ExploitGym evaluation and running without the usual production safeguards; JFrog confirmed the models exploited 0-day vulnerabilities in self-hosted Artifactory to escape the isolated test environment and reach the internet. According to the parties that disclosed it, this was goal-misaligned behaviour during a test, not malicious intent.

Anthropic, the maker of Claude, also reviewed its own evaluations and disclosed on 30 Jul 2026 three incidents in which Claude models gained unauthorised access to real systems of three different organisations while running evaluations. Anthropic stated that the evaluation prompt had told Claude the environment was simulated and had no internet access, but because of a misunderstanding between Anthropic and its evaluation partner, internet access was in fact available; an older model kept attacking even after there were signs it was on the real internet, while the newest model stopped. Part of the fault here is human: one wrong network configuration is enough to turn a test into a real incident.

The point that touches users directly is data. According to Reuters (republished on 26 Sep 2026), OpenAI said its agents exposed 53 images belonging to ChatGPT users; OpenAI did not say whether the images were AI-generated or whether real people could be identified. The number is small, but the implication is large: also according to Reuters (citing two people briefed on the matter), two months after the Hugging Face incident was disclosed, OpenAI was still working to understand the full scope of those agents’ activity. A business that has sent documents to an outside service has even less ability to check for itself.

The third risk does not require any AI lab incident at all: prompt injection. An attacker hides instructions in an email, web page or document; when the AI reads that content, it may follow them. Vulnerability CVE-2025-32711 in Microsoft 365 Copilot — named EchoLeak by the researchers who found it — is described by NVD as an AI command injection flaw that lets an unauthorised attacker disclose information over a network. The UK National Cyber Security Centre (NCSC) wrote in an analysis dated 8 Dec 2025 that because language models cannot distinguish between “data” and “instructions”, prompt injection may well never be fully mitigated the way SQL injection can be. So no serious vendor — Namtech included — should promise “100% protection against prompt injection”.

All information in the table comes from the disclosures of the organisations involved or from news reports quoting them, checked on 3 Oct 2026. Details of each incident may still be updated by the parties.

The lesson Hugging Face drew for itself is also worth noting. During the investigation, it had to run its analysis on the open model GLM-5.2 on its own infrastructure, because outside hosted models blocked the attack data; Hugging Face wrote that as a result, the attacker’s data and the related credentials never left its environment, and advised defenders to have a sufficiently capable model ready to run on their own infrastructure before an incident happens. This is also the logic of internal AI: a business’s most sensitive documents should be processed by a model running on the business’s own machine. Namtech has previously rounded up other chatbot data leaks in the article on 2026 AI chatbot leaks.

What layers protect an internal knowledge base?

An internal knowledge base needs several overlapping layers of protection, because no single layer stops everything. Namtech’s internal AI platform runs 100% on a machine located in the office, makes no calls to outside AI APIs, and has department-based permissions and an audit log — these are what the service package states on the homepage. On top of that foundation, Namtech designs and recommends the additional layers below, following OWASP and NCSC guidance; how far each layer is applied is settled based on the survey results and each business’s needs.

Layer 1 — no internet egress by default. The clearest lesson from the OpenAI incident is that an internet egress thought to be filtered can still be bypassed. So Namtech deploys with the AI machine serving only the internal network, with no outbound connections in day-to-day operation; new knowledge from outside is loaded through a controlled channel, as described in the Trending Pool article. With no way out, even if the AI is hit by prompt injection, it has a hard time sending data anywhere.

Layer 2 — permissions inside the document store itself. In its entry LLM02:2025 on sensitive information disclosure, OWASP recommends restricting access to sensitive data on the principle of least privilege. With RAG, this means filtering documents by the asker’s permissions before searching, so the model never reads a passage the asker is not allowed to see — rather than letting the model read everything and then “try not to say it”.

Layer 3 — the AI’s tools are read-only. The entry LLM06:2025 on excessive agency advises letting an AI agent call only the minimum extensions needed, and executing actions in the user’s own permission context. For a knowledge base, Namtech recommends that by default the AI can only search and read documents it is permitted to; it has no rights to write, delete, run commands or browse the web.

Layer 4 — human approval for risky actions. If a business wants to expand into having the AI send emails, export files or modify data in other systems, the entry LLM01:2025 on prompt injection recommends putting a human approver on privileged operations. Namtech recommends that every action with an external effect goes through a human preview and confirmation step.

Layer 5 — scan documents on ingestion. Also per OWASP LLM08, the knowledge base should be checked regularly for hidden code and poisoned data, and only data from trusted, verified sources should be accepted. In practice, that means scanning for hidden text (white text on a white background, HTML comments, phrases like “ignore all previous instructions”) on ingestion, and recording who uploaded which document. The NCSC stresses that defensive design should rely more on deterministic, non-LLM safeguards to constrain what the system can do — in other words, layers 1, 3 and 4 matter more than trying to “filter out” every malicious instruction.

Layer 6 — mask sensitive data and keep tamper-proof logs. OWASP LLM02 recommends sanitising and masking sensitive content; OWASP LLM08 recommends detailed, immutable logs of retrieval activity. Namtech recommends masking national ID numbers, bank account numbers and salaries in answers and logs according to the viewer’s role, and keeping logs append-only. Hugging Face said it reconstructed the incident timeline from logs of more than 17,000 attacker events — no trustworthy logs, no investigation. A fuller security architecture for internal AI is in the article on the internal AI security system.

“Yes (stated on the homepage)” means the feature is listed in the service package description on namtech.vn as of 3 Oct 2026. Rows marked “recommendation” are design principles Namtech applies following public guidance; the specific scope is written into the contract after the survey. No layer, and no combination of layers, can fully eliminate the risk of prompt injection.

Vietnamese law: who owns work knowledge, and how must employees’ personal data be handled?

Under Vietnamese law, documents an employee produces while carrying out assigned duties in principle belong to the organisation, unless the two parties agree otherwise; but the employee’s own personal data must be protected and deleted when the employment contract ends, unless otherwise agreed or provided by law. These two obligations do not conflict — they apply to two different types of data — but if the knowledge base mixes both, the business will struggle to comply with both at the same time. The provisions below are quoted from the original texts (English renderings are Namtech’s unofficial translations); this is reference information, not legal advice.

Work knowledge belongs to the organisation. Article 39(1) of the Law on Intellectual Property (Luật Sở hữu trí tuệ, per consolidated text 155/VBHN-VPQH) provides: “An organisation that assigns the task of creating a work to an author who is a member of that organisation is the owner of the rights provided for in Article 20 and Article 19(3) of this Law, unless otherwise agreed.” Article 20 covers the economic rights (reproduction, distribution, making derivative works…), and Article 19(3) is the right to publish the work. So for procedures, guides and reports that employees write as part of assigned duties, the company owns those rights and has a basis for putting them into the internal knowledge base; employees retain the remaining moral rights, such as being named as the author. Namtech has checked Law No. 131/2025/QH15 amending the Law on Intellectual Property (effective 1 Apr 2026): Article 39 is not among the amended articles.

Trade secrets require a written agreement. Article 21(2) of the Labour Code 2019 (Bộ luật Lao động 2019) allows an employer, where an employee’s work directly involves business or technology secrets, to “reach a written agreement with the employee on the content and duration of protection of business secrets and technology secrets, and on benefits and compensation in case of violation”. Article 125(2) allows dismissal of an employee who discloses business or technology secrets or infringes the employer’s intellectual property rights, if that conduct is specified in the internal labour regulations. The practical consequence: to rely on these two articles, a business needs to state clearly in the contract or internal regulations that internal documents, including those in the AI knowledge base, are business secrets and must not be taken outside — including by pasting them into public chatbots.

Employees’ personal data must be deleted when the contract ends. The Law on Personal Data Protection No. 91/2025/QH15 (Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15), effective from 1 Jan 2026, devotes Article 25 to recruiting, managing and employing workers. Article 25(2)(b) requires employees’ personal data to be stored for the period provided by law or by agreement; Article 25(2)(c) provides: “Employees’ personal data must be deleted or destroyed when the contract ends, unless otherwise agreed or provided by law.” Article 25(3)(a) only permits applying technological and technical measures in managing employees “on the basis that the employee is clearly aware of such measures” — meaning that if the AI system logs who asked what, employees must be informed.

AI systems must authenticate and control access. Article 30(3) of the same law requires systems and services using big data, artificial intelligence, blockchain, the metaverse and cloud computing to “use appropriate authentication and identification methods and access permissions to process personal data”; Article 30(4) requires processing of personal data by AI to be classified by risk level. Access control in the knowledge base is therefore not just good security practice but a legal requirement when the knowledge base contains personal data.

Deletion deadlines on request. Decree No. 356/2025/NĐ-CP (Nghị định 356/2025/NĐ-CP) (effective 1 Jan 2026) provides in Article 5(4) that on receiving a valid request to delete personal data, the data controller must respond within 02 working days and carry it out within 20 days; if it must ask the processor or a third party to delete, within 30 days, extendable at most once by no more than 20 days. Article 10(3) of the decree also requires notifying data subjects about automated processing of personal data. For internal AI, deletion must cover every place the data may sit: the original documents, the search index, caches and logs.

Provisions quoted from the Official Gazette (Công báo) editions and consolidated texts on chinhphu.vn, read on 3 Oct 2026. The table is for reference only and does not replace legal advice.

A point that is often overlooked: work documents can also contain personal data. A complaint-handling report records a customer’s name and phone number; an HR report names a person who was disciplined. So the approval step before loading does not only check that the content is still correct, but also whether there is unnecessary personal data to mask or remove. For records containing sensitive personal data, Article 10(2) of Decree 356 also notes that if AI inference results are used to identify a specific person, personal data protection measures must apply to them as well. Businesses interested in the AI risk classification side can read the article on Decree 142/2026 on AI.

When an employee leaves, how should internal AI handle it?

When an employee leaves, the business needs to do two things in parallel: keep the work knowledge that person contributed, and delete their personal data as the law requires. With a RAG knowledge base, both can be handled at the level of individual documents and accounts, so the system does not need to be “rebuilt”. Namtech recommends a five-step process, added to HR’s existing offboarding checklist.

First, lock the departing employee’s internal AI account at the same time as their other company accounts, so they no longer have access to the knowledge base after their last day. Second, review the list of documents that person created or is responsible for, and transfer responsibility to the successor; the documents stay in the knowledge base untouched and the AI’s answers do not change. Third, ask the departing employee to hand over any work documents still on their personal machine, so they can be approved and loaded before the last day — this is the last chance to turn knowledge “in their head” into documents. Fourth, identify that person’s personal data in the system — account profile, Q&A history linked to their name, any personal documents — and delete or anonymise it according to the retention policy agreed with legal counsel, remembering the search index and caches too. Fifth, record the deletion in writing so it can be proven when needed.

The fourth step has one point that needs weighing: the audit log. A log of who asked what is an important tool for investigating incidents, and the protection layers above recommend not allowing logs to be modified. But logs also contain personal data. Law No. 91/2025/QH15 allows employees’ personal data to be stored “for the period provided by law or by agreement” and provides the exception “unless otherwise agreed or provided by law” to the deletion obligation. A sensible approach is to set a clear log retention period in advance, write it into the contract or internal regulations, inform employees, and delete or anonymise logs when the period expires. The specific period should be confirmed by the business’s lawyer; Namtech configures the system according to that policy.

Checklist for businesses before building an internal AI knowledge base

Before loading the first document, a business should be able to answer the ten questions below. Most are not technical questions but governance decisions — which is exactly why they should be settled early, together with leadership, HR and whoever handles legal matters.

• Scope: which types of documents will be loaded (SOPs, guides, template answers…) and which absolutely will not (HR files, unnecessary personal data)?
• Owners: who is in charge of each department’s knowledge base, and who approves documents before loading?
• Permission matrix: which department may see which documents; which documents are for leadership only?
• Contracts and internal regulations: are there clauses on documents created under assigned duties, business secrets (Labour Code, Article 21(2)) and a ban on putting internal documents into public AI?
• Informing employees: have employees been told what the system logs and for how long (Law No. 91/2025/QH15, Article 25(3))?
• Internet egress: does the AI machine connect to the outside; if so, for what, and who approves it?
• AI tool permissions: is the AI read-only, or can it write, send emails, call other systems? Which actions need human approval?
• Scanning on ingestion: are documents from outside (customer emails, partner files) scanned for hidden text and injected instructions before entering the knowledge base?
• Logs: what is logged, how tamper-proof is it, and how long is it kept?
• Offboarding and deletion requests: who does it, where is data deleted (documents, index, cache, logs), and can it meet the 20-day deadline under Decree No. 356/2025/NĐ-CP, Article 5(4)?

If you cannot answer all of them yet, that is no reason to wait. Namtech’s pre-deployment survey uses this very list to settle, together with the business, the document scope, the permission matrix and the protection layers to enable — the survey results are the basis for a fixed-price quote.

How does Namtech deploy an internal AI knowledge base?

Namtech deploys internal AI on an M5 Mac Studio located at the client’s office, running 100% on-site, with no cloud and no calls to outside AI APIs. The models are commercially usable open models such as Qwen, Gemma and GLM — the list and each model’s strengths are in the model table on the homepage. The business’s documents are loaded into a knowledge base that the AI retrieves from (RAG), answering with source citations; the model is not retrained on the client’s data.

The three internal AI packages — AI Box, AI Pro and AI Enterprise — are all all-inclusive, with no extra charges: they include machine setup, model installation, the chat software and department-based permissions; loading all internal documents within the surveyed scope (including scanned documents needing OCR if recorded during the survey) and tuning answer quality; testing, go-live and staff training; a 60-day warranty and monthly loading of new documents under the stated operating fee. The price agreed after the free survey is a fixed price for exactly the surveyed scope. Businesses not yet ready to buy a machine can rent a Mac Studio on a 12-month term to trial the knowledge base on real documents first.

The knowledge employees create is only a company asset when it sits in a store the company controls: loaded into an internal knowledge base that the AI retrieves from (RAG), permissioned by department, running on the business’s own machine, never sent to outside AI — with employees’ personal data kept separate so it can be deleted in line with Law No. 91/2025/QH15 when they leave.

Frequently asked questions

Note: This article compiles public sources checked on 3 Oct 2026. Information about the AI incidents may be further updated by the parties involved. The legal section quotes the original texts for reference and is not legal advice; businesses should consult a lawyer when drafting contracts, internal regulations and retention policies. Protection layers marked “recommendation” are design principles; the specific scope is written into the contract after the survey.