A manufacturer of industrial equipment was discussing adding an AI presenter to their online 3D showroom: visitors open a link, walk into the hall, and a humanoid character walks beside the exhibits and answers questions. Halfway through the conversation, they paused and asked one question — "Where do my product specs, pricing guidelines, and customer chat records actually live?"

That question comes up far more often than "is the AI smart enough?" This article breaks it down: why data ownership surfaces before features when enterprises adopt AI, how three integration approaches differ mechanically on data ownership, and what a self-hosted 3D virtual-world base specifically answers here. What is implemented and what is not are kept separate throughout.

I. Why the data question surfaces first

When an enterprise considers an AI presenter or AI concierge, the concern is usually not model capability — models get stronger every year. What stalls the meeting is typically three things:

1. Product material leakage: spec sheets, pricing logic, and internal guidelines fed to a third-party hosted agent means putting your business cards on someone else's server;
2. Uncontrolled chat logs: if records of what customers asked and what the AI answered live on a platform side, auditing and retention are out of your hands;
3. Shutdown risk: if the platform changes policy or shuts down, the AI roles running on it and the accumulated conversation data go with it.

All three share one trait: they are not "does the feature exist" but "who holds the data." Features can iterate; ownership is not negotiable.

II. Three approaches, data lands in three places

The first two each have their use cases; this article only unpacks the third, since it is the path under discussion.

Self-hosted means the entire 3D world runs on your own server. World assets, accounts, and the admin console are in your hands; AI access goes through a dedicated channel — the server only sends structured data (spatial radar, object descriptions, event streams), and the visuals are rendered by each visitor's browser. The AI's "brain" does not sit on the platform side: it is driven by your own AI client. Which LLM you call, how prompts are written, where the knowledge base lives — all yours.

What the platform provides is a body and presence: a character with a humanoid form, coordinates, visibility to real people, and a voice channel.

III. Where each of four data types lives in this architecture

Item by item — this is the checklist enterprises actually evaluate:

One note on platform-side governance: every AI character enters with a Key issued from the admin console, revocable at any time; chat logs sit in your own database for audit; and AI identity is always explicit — an entry notice and an AI prefix over the head — so real people always know they are talking to an AI.

IV. What landing looks like

Before integration: inventory which materials may enter the knowledge base and which stay internal — because the knowledge base is yours, you draw that line yourself. Decide which AI client will drive the character (the official repo ships a zero-dependency Node example client that runs the full pipeline).

During integration: three steps — place the discovery file (.well-known/virtual-world-agent.json) on your server, exchange the Key for a 15-minute token, connect to the dedicated channel. Your chosen model then starts driving the humanoid character: walking to exhibits, answering questions, greeting visitors who come near.

After integration: material updates happen in your own knowledge base, with no platform review in the loop; chat logs archive under your retention policy; when a role must be retired, disable it or revoke its Key from the console.

V. Honest limits: what this architecture does not do

Clear data ownership comes at the cost of the platform doing less for you. Know these in advance:

• No hosted knowledge base: how well it answers depends on how clearly you organize your materials;
• No ready-made "presenter template": staffing any of these roles requires a code-capable AI client (a templated presenter is on the roadmap, marked as planned);
• Speech recognition and synthesis are not on the platform side: your own client handles transcription and voice;
• It cannot see the screen: only structured spatial radar, no camera-like vision.

In one sentence: the data is in your hands, and so is the work. Those are two sides of one coin — weigh them before signing, not after launch.

VI. What to prepare

• Your own server (capable of running Node 18+ and a database);
• A code-capable AI client (or start by modifying the example client in the repo);
• A set of organized product materials — which, fittingly, stay on your own machine. That is precisely this article's subject.

VII. What it does not suit

• Teams that want a turnkey presenter and refuse to write any code — not a fit today (a templated presenter is planned, not shipped);
• Teams with nobody maintaining the knowledge base — the AI's answer quality is capped by material quality; without curation, hold off;
• Teams indifferent to data ownership who just want to launch fast — a hosted option may suit you better; this article does not rank them.

VIII. FAQ

Q: Do chat records really never touch a third party?

A: Visitor browsers talk to your server over the normal network, and so does the AI character — no hosted-knowledge platform sits in the chain. LLM calls originate from your client; which provider and how much data goes out is decided by your code.

Q: What if we want to migrate the AI character away later?

A: The discovery file, Key mechanism, and example client are public standard practices in the repo; the knowledge base and chat logs are already in your own database. Migration cost is mostly your own client code — which you already hold.

Q: How much resource does one AI character use?

A: Measured, each agent pushes roughly 1 KB/s; one hundred in the same world total about 0.8 Mbps, and server load is roughly 1% of a single core. For the cost concern behind "keep data on my own server," that is a direct answer — self-hosting does not mean expensive.

IX. Source code and repositories

All three mirrors hold identical content; the first two are faster for visitors in mainland China. The repos include deployment guides and a demo entry.

• Gitee (faster in mainland China): https://gitee.com/miduoxinxijeji/miduo.git
• GitCode (mirror): https://gitcode.com/qq_35054471/virtual-world
• GitHub: https://github.com/miduo100/3d-virtual-world

About Genesis

Genesis is a self-hosted 3D virtual world system built on Three.js + WebGL, helping individuals and businesses build their own 3D spaces. Accessible directly from a browser, compatible with both PC and mobile, it supports multiplayer online, federated teleportation, a shop system, and Agent integration—where an AI can enter your world as an embodied character. Your data runs on your own server, never passing through a third-party platform—so every world truly belongs to its owner.

Want an AI presenter running on your own server? Genesis (the Genesis Virtual World CRM System) is a self-hosted Three.js 3D virtual-world base — the world on your server, chat logs in your database, the knowledge base in your hands, and AI walking in as a humanoid character. The official site (search "Genesis Virtual World CRM") has a demo world you can walk through.

About the name: Genesis in this article refers to the Genesis Virtual World CRM System — the same self-hosted 3D virtual-world product. If searching "Genesis" does not find us, search "Genesis Virtual World CRM" directly.