Question 1

What is AI Sandbox?

Accepted Answer

AI Sandbox is an **On‑Prem Tamed AI** solution for making enterprise AI truly deployable (Secure • Smart • Simple). The core idea is to turn “AI is powerful, but enterprises fear incidents” into a delivery that is **governable, auditable, and verifiable**.

#### Three keys (deployable • integratable • extensible)

- **Deployable (Secure)**: Runs in your intranet, works offline, and supports audit-ready access control. Data stays inside the intranet.
- **Integratable (Simple)**: OpenAPI and enterprise APIs bridge your website and existing systems—no rip-and-replace—so systems can start “understanding human language”.
- **Extensible (Smart)**: Import documents/images/videos; AI automatically builds structure and indexes (knowledge graph / vector index) into a maintainable knowledge base (“import and ask”). It also supports multimodal knowledge ingestion (PDF/Word/SOP, Excel/financials/KPI, BI/Dashboard, legal clauses/contracts/cases, recordings/transcripts, etc.).

#### One box can run enterprise AI

- Optional NVIDIA DGX Spark integration: **1,000 TOPS** enterprise-grade inference performance at **240W** low power, designed for **24/7** stable operation.

Question 2

How is AI Sandbox different from a typical chatbot?

Accepted Answer

A typical chatbot often stops at “conversation”, while enterprise deployment gets stuck on four questions: traceability, accountability, cloud data risk, and whether deployment means rebuilding systems / how to operate long-term. AI Sandbox turns those concerns into a governable delivery:

- **Traceable**: Cited answers and auditable access—know what was asked, which sources were used, and what was produced. User identity mapping (“who asked”) relies on your existing SSO/IAM.
- **Verifiable**: Knowledge bases can be regression-tested and continuously improved; it is not just “chatting”, but an acceptance-ready delivery.
- **Integratable**: No rip-and-replace; OpenAPI/enterprise APIs help existing systems start “understanding human language”.
- **Operable**: Supports long-term operations (support/security updates) and appliance rebuild flows (export/import).

Question 3

How is AI Sandbox different from typical public cloud AI tools? (Enterprise checklist)

Accepted Answer

AI Sandbox is not “a better chat UI”—it is a delivery that makes security, compliance, and accountability explicit:

- **Data boundary (data residency)**: Supports On‑Prem / Private deployment; data stays inside your intranet (offline-capable).
- **Governance & audit**: Identity and permissions follow your SSO/RBAC and network controls (AI Sandbox is not your IAM/account SoT); configurable guardrails/policies; cited answers; traceable operations (when, what was asked, which sources; “who” depends on your SSO—agreement/config govern).
- **Enterprise knowledge base (Knowledge Documents)**: Import internal PDFs/Word/Excel and build a maintainable knowledge base (indexing/permissions/regression tests) so teams share the same acceptance-ready answers.
- **Contractable risk boundary**: For production, define data boundary/retention/audit responsibilities via NDA/DPA and Enterprise Agreement (agreement governs).

In contrast, typical public cloud AI tools are often optimized for individual accounts and one-off chats; enterprises usually need to fill in governance, auditability, and compliance on their own.

Question 4

Who is it for?

Accepted Answer

Best for high-volume, repetitive workflows whose data must stay inside the company. Most customers start with one of these:

- **Repeat orders**: order lines are no longer re-keyed into the ERP one by one; AI prepares them and hands only the mismatches to people. Customer result: 240 minutes → 5 minutes per order.
- **New orders and design drawings**: before tooling, AI compares 10,000+ design drawings to find designs you can reuse; engineers decide what to change.
- **Contract review**: AI reads the whole contract against your review criteria and flags high-risk clauses first; legal edits in the original Word file.

Not sure where to start? Bring your most painful order or document—a 30-minute assessment tells you whether it can be done, how it will be accepted, and how soon it goes live.

Question 5

Evaluation: What is the biggest difference between on‑prem AI and cloud AI?

Accepted Answer

The core difference is not “which model is stronger”, but **data boundary, governance accountability, and auditability**:

- **Data boundary (data residency)**: Cloud AI often implies data egress and cross-border processing; on‑prem/private deployment keeps data inside your intranet (offline-capable), reducing leakage and compliance risk.
- **Access control and audits**: Cloud AI is often centered on personal accounts and one-off chats; on‑prem AI can reuse SSO/RBAC and keep audit trails (what was asked, when, and based on which sources). User identity mapping (“who asked”) must rely on customer SSO/IAM.
- **Verifiability and operability**: Cloud tools optimize for “usefulness”; enterprise deployment requires “governable, regression-testable, continuously improvable”.
- **Contractable responsibilities**: On‑prem delivery makes it easier to define data retention, audit responsibilities, operations, and boundaries in NDA/DPA and Enterprise Agreements (agreement governs).

Question 6

Evaluation: What is the biggest difference between AI Sandbox and a typical on‑prem AI deployment?

Accepted Answer

AI Sandbox is not just “running a model inside the intranet”—it is a governable, auditable, and acceptance-ready delivery (**On‑Prem Tamed AI**):

- **Governable**: Reuse SSO/RBAC; configurable guardrails/policies; key flows can be “confirm before execute”.
- **Auditable**: Cited answers; traceability (what was asked, based on which sources, and what was produced). User identity mapping (“who asked”) must rely on customer SSO/IAM.
- **Verifiable**: Supports regression question sets and continuous improvement; quality becomes acceptance-ready delivery.
- **Integratable**: OpenAPI / enterprise APIs connect to existing systems—no rip-and-replace.
- **Operable**: Export/import rebuild flow (backup/replacement), support and security updates (agreement governs).

Question 7

(Security & compliance) Evaluation: Will data leave the intranet? Is offline operation supported?

Accepted Answer

Production delivery supports On‑Prem / Private deployment so **data stays inside the intranet**; offline capability depends on the delivered configuration (agreement/environment govern). For the online demo (trial/POC), do not submit any personal/confidential data.

Question 8

(Security & compliance) Evaluation: Will our data be used to train models?

Accepted Answer

- **On‑Prem / Private (production delivery)**: data and logs are typically stored in your environment. Unless you explicitly authorize it in the contract, we do not use your data to train public models or for external reuse.
- **Online demo**: for security and troubleshooting, we may log necessary inputs/outputs, but we still do not use them to train public models (unless you explicitly consent or the contract provides otherwise).
- **Third-party providers (if you enable them)**: whether data is used for training depends on the provider’s terms and your configuration; verify via DPA/procurement documents.

Question 9

(Security & compliance) Evaluation: Do you support PII masking?

Accepted Answer

Yes—PII masking can be enabled based on your policy to detect and mask/replace identifiers in inputs (agreement/config govern).

Question 10

(Security & compliance) Evaluation: Do you support encryption (in transit/at rest) and de-identification strategies?

Accepted Answer

If a scenario requires cross-system transmission, we recommend **encryption and de-identification** with audit trails for evidence. The exact encryption/key management approach is aligned with your security requirements (agreement/config govern).

Question 11

(Security & compliance) Evaluation: How are access control and network boundaries defined? Can we restrict who can use it?

Accepted Answer

AI Sandbox does not replace your IAM: reuse your SSO/RBAC or existing identity/permission systems, and you decide who can access what (agreement/config govern).

Question 12

(Security & compliance) Evaluation: Do you provide security updates and a controlled upgrade mechanism?

Accepted Answer

Production delivery includes security updates and an upgrade approach under the maintenance agreement (MA) and shipped version (agreement governs). We recommend validating upgrades with regression question sets to reduce risk.

Question 13

(Security & compliance) Evaluation: Can you support security audits (vulnerability scanning / penetration testing) and vendor due diligence?

Accepted Answer

We can align with your security process, including deployment/network boundary explanations, versioning and patching policy, and an agreed audit collaboration approach. The exact audit artifacts and scope depend on your requirements and the Enterprise Agreement.

Question 14

(Security & compliance) Evaluation: How long are logs/chats/knowledge data retained? Can customers decide?

Accepted Answer

In On‑Prem / Private deployments, data and logs are typically stored and configurable in your environment. Retention should align with your internal control/audit requirements (agreement/config govern).

Question 15

(Security & compliance) Evaluation: If an incident happens (wrong answer/leakage risk), how do we trace and respond?

Accepted Answer

We reduce risk via **citations, audit trails, and guardrails**. If an incident occurs, logs can trace “what was asked, when, based on which sources, and what was produced”; user identity mapping (“who asked”) must rely on customer SSO/IAM. You can then remediate via governance rules and regression test sets (agreement/process govern).

Question 16

(Security & compliance) Evaluation: What are the data and usage limitations for the online demo?

Accepted Answer

The demo is for evaluation/POC only—do not submit personal data, credentials, payment info, or confidential materials. If you need real-data validation, use On‑Prem / Private delivery and complete NDA/DPA first.

Question 17

(Governance & auditability) Evaluation: Do you support SSO and RBAC? Can we reuse existing permissions?

Accepted Answer

Yes—AI Sandbox can reuse your existing SSO/RBAC, and features/logging follow your authorization results (agreement/config govern).

Question 18

(Governance & auditability) Evaluation: Do you provide audit trails? What can we trace?

Accepted Answer

We can trace “what was asked and when, which sources were used, what output was produced, and whether it was approved/executed”. User identity mapping (“who asked”) must rely on customer SSO/IAM (agreement/config govern).

Question 19

(Governance & auditability) Evaluation: Are answers cited? Can source access be permissioned?

Accepted Answer

Answers can include citations, and access can be controlled by your IAM rules so different roles only see approved sources and answer scopes (agreement/config govern).

Question 20

(Governance & auditability) Evaluation: Can we configure guardrails/policies (e.g., do-not-answer, sensitive terms, formatting)?

Accepted Answer

Yes—governance guardrails and output templates can reduce risk and enforce consistent response styles (agreement/version govern).

Question 21

(Governance & auditability) Evaluation: Do you support “confirm before execute” to reduce action risk?

Accepted Answer

Yes—flows can follow “confirm before execute”, turning natural-language requests into reviewable, controllable steps and keeping traceable records (agreement/integration scope govern).

Question 22

(Governance & auditability) Evaluation: Can the knowledge base be versioned? How do we avoid answer drift after updates?

Accepted Answer

Use “source lists, version governance, and regression test sets” to control quality: after updating sources, validate key questions so answers do not drift (agreement/version govern).

Question 23

(Governance & auditability) Evaluation: Do you support regression question sets and quality gates?

Accepted Answer

Yes—regression question sets support acceptance and continuous improvement, turning quality into verifiable delivery (agreement/version govern).

Question 24

(Governance & auditability) Evaluation: Do you support Human-in-the-Loop review?

Accepted Answer

Yes—use review flows with guardrails and regression tests to route high-risk outputs to human confirmation and continuously improve (agreement/version govern).

Question 25

(Governance & auditability) Evaluation: What can admins govern?

Accepted Answer

Admin governance scope (examples): scenario settings, knowledge sources/KB management, guardrails/policies, regression test sets, output formats and response tone templates (agreement/version govern).

Question 26

(Governance & auditability) Evaluation: How do we measure impact after rollout (hit rate/handoff rate/quality)?

Accepted Answer

Use metrics like hit rate, handoff rate, top recurring questions, and error taxonomy; validate quality via regression tests (agreement/acceptance govern).

Question 27

(Integration & deployment) Evaluation: How do we integrate the website support assistant? Do we need to change the website?

Accepted Answer

No site changes: a simple embed snippet (1‑Line Script) enables the assistant. Answers come from your public/approved knowledge base, with optional handoff to human support/tickets.

Question 28

(Integration & deployment) Evaluation: How do we integrate with existing systems? Do we need a rebuild?

Accepted Answer

No rip-and-replace: connect via OpenAPI / enterprise APIs so users can query and run workflows in natural language. Execution rights and access control remain on your side.

Question 29

(Integration & deployment) Evaluation: What are the recommended low-risk first steps for integration?

Accepted Answer

Start with read-only integration (search/summary/explanation), then add controlled writes/actions (“confirm before execute”) with audit trails.

Question 30

(Integration & deployment) Evaluation: What is the typical ERP integration path?

Accepted Answer

“Knowledge first, integration second”: turn ERP docs/SOP/specs into a searchable knowledge base, then integrate with ERP interfaces (API/report export) in phases (ERP vendor/version/security policies govern).

Question 31

(Integration & deployment) Evaluation: What data types do you support for ingestion? (PDF/Word/Excel/media)

Accepted Answer

We support multimodal ingestion: PDF/Word/SOP, Excel/financials/KPI, BI/Dashboard, legal clauses/contracts/cases, recordings/transcripts, etc. AI builds structure and indexes into a maintainable knowledge base.

Question 32

(Integration & deployment) Evaluation: How do you handle permission tiers and cross-team isolation for documents?

Accepted Answer

Reuse your IAM rules to tier knowledge sources by org/role, and enforce permissioning at retrieval/answer time with auditability (agreement/config govern).

Question 33

(Integration & deployment) Evaluation: What is included in delivery and how do we estimate the timeline?

Accepted Answer

We deliver a production-ready, verifiable environment with onboarding/implementation support. Timeline depends on scenario alignment, data readiness, and acceptance criteria (quotation/order/Enterprise Agreement governs).

Question 34

(Integration & deployment) Evaluation: Do you support multilingual UX? Can multiple languages share one knowledge base?

Accepted Answer

Multilingual UX can be supported. Whether and how knowledge is shared across languages (including citations/quality gates) should be aligned during rollout and validated with regression tests (agreement/config govern).

Question 35

(Integration & deployment) Evaluation: How do we evaluate performance and scale (concurrency/latency)?

Accepted Answer

Capacity planning should reflect your use case: concurrency, data size, latency, and availability. We recommend load testing and tuning as part of acceptance (agreement/delivery config govern).

Question 36

(Integration & deployment) Evaluation: If we want to add new scenarios (Agents) later, what is the process?

Accepted Answer

Start with the one workflow that hurts most; to add new scenarios later, you provide task/data boundary/acceptance, eGroupAI evaluates feasibility and ships via version delivery (agreement/scope govern).

Question 37

(Quality & acceptance) Evaluation: How do we make it “acceptance-ready” instead of just “usable”?

Accepted Answer

Define a high-frequency question set and observable outputs (including citations, format, traceability), then validate via regression tests so quality becomes measurable acceptance criteria (agreement/version govern).

Question 38

(Quality & acceptance) Evaluation: How do you reduce hallucinations and errors?

Accepted Answer

We reduce risk via “citations + guardrails + regression tests + review flows”. A maintainable knowledge base and multimodal ingestion improve accuracy (agreement/config govern).

Question 39

(Quality & acceptance) Evaluation: What if citations are insufficient or sources conflict?

Accepted Answer

Remediate by fixing sources/versions, tuning indexing, and validating via regression tests so key questions have consistent sources and answers; route high-risk items to review (agreement/config govern).

Question 40

(Quality & acceptance) Evaluation: Can we enforce output formats (tables/JSON/structured summaries)?

Accepted Answer

Yes—use output templates to require consistent structures (bullets/tables/structured outputs) and validate with regression tests (agreement/version govern).

Question 41

(Quality & acceptance) Evaluation: How do we build regression question sets and who maintains them?

Accepted Answer

Build from FAQ/SOP/tickets and critical workflows. You provide business/process knowledge and acceptance criteria; eGroupAI helps build and optimize (agreement/rollout govern).

Question 42

(Quality & acceptance) Evaluation: Do you support error taxonomy and continuous improvement workflows?

Accepted Answer

Yes—use error taxonomy with regression tests to identify causes (missing data, wrong citations, permission issues, misunderstanding) and iterate (agreement/version govern).

Question 43

(Quality & acceptance) Evaluation: Can demo outputs be treated as production quality?

Accepted Answer

No—the demo is for evaluation/POC and differs from your production data/config. Customers can try the demo self‑serve; our consultants will reach out to help with online final tuning and validation, but production quality must be verified in your AI Sandbox (On‑Prem / Private) with your data boundary, permissions, and regression acceptance.

Question 44

(Quality & acceptance) Evaluation: Can we deploy in high-risk domains (legal/credit/audit)?

Accepted Answer

Yes—these domains benefit from auditability and governance, but should use review flows and regression acceptance, and define responsibility boundaries in the agreement (agreement/config govern).

Question 45

(Quality & acceptance) Evaluation: Can customers tune or swap models? How does that affect consistency?

Accepted Answer

No end-user model swapping/tuning: models are optimized by eGroupAI and pre-installed to ensure governance and consistency. For specific needs, propose a scenario and we ship via version delivery (agreement governs).

Question 46

(Quality & acceptance) Evaluation: What scenarios should not be delegated to AI? How do we manage risk?

Accepted Answer

For irreversible or high-stakes actions, use “confirm before execute” and Human-in-the-Loop review with guardrails and regression tests to reduce risk (agreement/config govern).

Question 47

(Operations & TCO) Evaluation: How does licensing and pricing work? What does the one-time purchase include?

Accepted Answer

AI Sandbox is sold as a one-time purchase (software + hardware) with a production-ready environment; pricing and scope are governed by quotation/order/Enterprise Agreement.

Question 48

(Operations & TCO) Evaluation: What are the warranty and annual maintenance (MA) terms?

Accepted Answer

Warranty/maintenance summary: the first year is included; from year 2, annual maintenance keeps both software and hardware warranty active, and any hardware failure is replaced with a new unit (support and security updates included; agreement governs).

Question 49

(Operations & TCO) Evaluation: What are support and SLA terms? How fast do you respond?

Accepted Answer

During an active maintenance/support agreement, eGroupAI provides technical support and service responses under the agreed terms, including issue assessment, troubleshooting and progress tracking. Service hours, incident severity and response arrangements follow the quotation or maintenance agreement. Confirmed software issues are addressed through fixes and security updates within the agreed scope.

Question 50

(Operations & TCO) Evaluation: How do exports, backups, and recovery work (replacement / failure)?

Accepted Answer

You must export and back up regularly. Appliance replacement typically reformats and does not include data recovery; restoration depends on your backups. Exportable assets include scenario settings, knowledge source lists, guardrails, regression tests, templates, prompts, and conversation logs (agreement/version govern).

Question 51

(Operations & TCO) Evaluation: Will upgrades break existing workflows? How do we reduce upgrade risk?

Accepted Answer

Use regression tests before/after upgrades and plan upgrades within a controlled window with a rollback plan to minimize impact (agreement/process govern).

Question 52

(Operations & TCO) Evaluation: Does hardware replacement include data recovery? What are the limitations?

Accepted Answer

Replacement does not include data recovery from the failed appliance (repair often reformats). Recovery depends on your backups and import-based rebuild flow (agreement/inspection govern).

Question 53

(Operations & TCO) Evaluation: Who runs day-to-day operations after rollout? What does eGroupAI handle?

Accepted Answer

eGroupAI provides support and version updates; you own data boundary, access control, and backup policies. Responsibilities are defined in Enterprise Agreement and MA.

Question 54

(Operations & TCO) Evaluation: If we need disaster recovery (DR) and offsite backups, how should we plan?

Accepted Answer

Plan based on internal control/audit requirements: export/backup cadence, storage/access control, recovery drills, and acceptance regression tests. Align during rollout and include in acceptance (agreement/config govern).

Question 55

(Operations & TCO) Evaluation: How do we avoid “only a few people use it after rollout”?

Accepted Answer

Prioritize high-frequency scenarios, validate with regression acceptance, provide role-based entry via SSO/RBAC, and iterate using hit rate/handoff and top questions to improve content and flows.

Question 56

(Operations & TCO) Evaluation: If we need to exit or replace the solution later, can we take our data and configs with us?

Accepted Answer

You can export portable assets and store them; rebuild in another environment depends on your backups and import flow. We recommend documenting export scope and handover responsibilities in the Enterprise Agreement.

Question 57

How do we integrate the website AI support assistant?

Accepted Answer

> Add a simple embed snippet (1‑Line Script) to your website to enable an AI support assistant. Answers come from your public/approved knowledge base, with optional handoff to human support/tickets.

- **Step 1 | Define entry & UX**: where to show it (site-wide or selected pages), languages, and branding.
- **Step 2 | Prepare approved knowledge**: FAQ, product docs, policies, and standard processes; validate with a regression question set before go-live.
- **Step 3 | Go-live & iterate**: embed and run; optimize with answer-hit rate, handoff rate, and top recurring questions.

> Note: For production use involving internal data, we recommend On‑Prem / Private deployment and defining data boundaries with your access and audit requirements (agreement/config govern).

Question 58

How do we integrate with existing systems?

Accepted Answer

> No rip-and-replace: connect AI Sandbox through OpenAPI / enterprise APIs so users can query data and follow processes in natural language. Execution rights and access control remain on your side.

- **Start with read-only integration**: search/summary/explanation (e.g., SOP lookup, customer status, report summaries).
- **Add controlled write/actions**: for writes or workflow triggers, use “confirm before execute” and keep audit trails.
- **Reuse your IAM**: keep SSO/RBAC; you define who can access what.

Question 59

How do we integrate with ERP?

Accepted Answer

> A typical approach is “knowledge first, integration second”: turn ERP module docs/SOP/field specs into a searchable enterprise knowledge base, then integrate with available ERP interfaces (API/report export, etc.) in phases.

- **Phase 1 (quick value)**: ask in natural language: “what does this field mean, how to run this process, what does this report mean?”
- **Phase 2 (data queries & summaries)**: connect to ERP query/report outputs to generate and interpret reports faster.
- **Phase 3 (workflow assistant)**: with your authorization, package high-frequency operations as verifiable steps (agreement/version govern).

> Note: the exact integration method and automation scope depend on the ERP vendor/version/interfaces and your security policies; we align during implementation.

Question 60

What do we need to change to embed it on our website?

Accepted Answer

In most cases, you don’t need to change your website architecture or backend. Typically you add a **1‑Line Script** to selected pages. If you enforce strict security policies (e.g., CSP), you may need to align allowlists (script-src / connect-src, etc.) before go-live (your security policy governs).

Question 61

What does “No Site Changes” mean?

Accepted Answer

“No Site Changes” means you don’t need to rebuild your website system just to adopt AI Sandbox. In many cases it’s “embed snippet → approved knowledge → go live”, and you can add deeper API integrations later if needed (scope and acceptance govern).

Question 62

What parts of the website assistant can be branded?

Accepted Answer

Common branding items include logo, primary colors/button styles, greeting and tone, language, and where the widget appears (site-wide or selected pages). Deeper UI/interaction customization depends on the delivery scope (agreement governs).

Question 63

Can we hand off to human support or a ticketing system?

Accepted Answer

Yes. A typical approach is to define handoff triggers (high risk, needs review, complaints, no-answer cases) and send the necessary context (question, conversation context, citations, user identifiers / ticket fields) to your existing support or ticketing system, with auditability (integration scope governs).

Question 64

For enterprise API integration, how do auth and permissions work?

Accepted Answer

The principle is to **reuse your SSO/RBAC**: who can access what and whether actions are allowed is governed by your IAM and workflows. AI Sandbox calls your enterprise APIs within the permissions and boundaries you define, and keeps traceable records (architecture/agreement govern).

Can I use real data in the online demo?

If we like the demo, how do we move to on‑prem AI Sandbox?

What if we need to validate a scenario using trade secrets?

Do we need an account or installation for the online demo?

What data sources does the demo use? Can we use our own data?

Is the demo rate-limited?

How long are demo inputs/outputs retained?

Can we apply our branding in the demo?

Is there support during the demo?

After the demo, what are the next steps for a POC?