AI use & data policy

Last updated: 2026-04-25 · Pre-launch

How Jubi uses AI models, what data flows through them, the lines we won't cross, and the responsibilities that stay with you as the customer. Applies to both Mode 1 (your AI, gated by Guardian) and Mode 2 (agents built on Jubi).

1. Our AI governance principles

1. Grounded over generative. When an answer can be grounded in the customer's data or Atlas, we ground it. When it can't, the system is designed to say so rather than guess.
2. Permission-first. AI access is bound to the requesting user's identity and the permissions Atlas/Guardian apply. The AI is not a privilege escalation.
3. Auditable end to end. Every AI exchange is logged: prompt, policy decision, data accessed, response. Replayable.
4. Customer data is not training data. We do not train or fine-tune our own models on customer data, and we use provider endpoints configured to disable training and retention beyond inference.
5. Human in the loop. Jubi is decision-support tooling. Material decisions about people, money, or compliance should be reviewed by a human before action.

2. Models we use

Jubi runs large language models from third-party providers. The current default providers are Anthropic and OpenAI. We may add or substitute providers as the model landscape evolves; material changes that affect customer behaviour are surfaced to customer admins.

Routing between providers is decided by capability, cost, and policy at the platform level, not by user choice. If your engagement requires a specific provider be excluded, raise it during scoping and we will document the exclusion in the engagement.

3. Customer data and model training

• We do not train, fine-tune, or otherwise improve our own models using customer data.
• We use enterprise endpoints from our model providers that are configured for no-training and no-retention beyond inference, as confirmed by the provider's commitments at the time of integration. If a provider materially changes those terms, we will update this page and, where the change is adverse, notify customer admins.
• Customer prompts and AI responses are processed for inference and then retained only in your tenant's audit log under the retention configured in your engagement.

4. Inference residency and data transfers

• Today (pilot). Inference may route to provider regions outside your home jurisdiction; the operational default is U.S. provider regions.
• On the roadmap. In-region inference (Malaysia or Singapore), via either provider regional endpoints or self-hosted open-weights models for sensitive workloads. Available subject to scoping.
• Transfers. Where customer data leaves your home jurisdiction for inference, the transfer relies on Standard Contractual Clauses or another permitted mechanism, and on the model provider's representations about data handling. The customer is responsible for assessing whether its own use case requires in-region inference and for raising that requirement during scoping.

5. What goes to the model

• The user's question.
• A scoped subset of your data the user is permitted to see: dashboards, query results, and Atlas definitions.
• The system prompt and the conversation history within the session.

What does not go to the model:

• Raw warehouse credentials.
• Data outside the user's permission scope.
• Other tenants' data.

6. Sensitive use cases (we won't sell or support)

Jubi will not knowingly support, and the AUP prohibits, deployment of the platform for the following:

• Real-time biometric identification of individuals in publicly accessible spaces.
• Social scoring of natural persons by public authorities.
• Manipulative or exploitative profiling of vulnerable groups (minors, persons with disabilities, persons in vulnerable economic situations).
• Generation of CSAM or other illegal content. AI-assisted harassment of identifiable individuals.
• Untargeted scraping of facial images for face-recognition databases.
• Autonomous targeting in weapons systems.
• Deceptive deployment that misrepresents AI-generated output as human-authored to consumers, customers, or regulators.

This list is not exhaustive. We may decline or terminate engagement for any deployment we consider to fall within prohibited or unduly high-risk categories under the EU AI Act, our values, or the AUP.

7. EU AI Act framing

In its default configuration, Jubi is general decision-support tooling for enterprise data analysis. We track the EU AI Act and Jubi is positioned to support the obligations that fall on AI providers and deployers in our value chain.

Whether a particular customer use case constitutes a high-risk AI system under Annex III of the EU AI Act, or otherwise falls within a regulated category, depends on the use case (recruitment, credit scoring, education access, essential public services, law enforcement, etc.) and on how the customer deploys Jubi. The customer is responsible for assessing applicability and meeting the obligations that fall on it as the deployer.

What Jubi provides to support customer compliance:

• Transparency. Users interacting with the assistant are informed they are interacting with AI.
• Logging. Tenant-level audit log capturing prompt, policy decision, data accessed, and response. Designed to support post-market monitoring and incident reporting on the customer side.
• Human oversight hooks. Read-only AI access by default. Material write actions require explicit user confirmation.
• Documentation. Architecture, security model, and AI use documentation provided to support the customer's risk-management and conformity-assessment work.

8. GDPR Article 22 (automated decisions)

Jubi does not, on its own, make decisions producing legal or similarly significant effects on individuals. Jubi is decision-support: it surfaces information for a human user.

If a customer chooses to use Jubi as part of a workflow that produces solely automated decisions with legal or significant effect on natural persons, the customer is responsible for meeting its Article 22 GDPR obligations, including providing the data subject's right to obtain human review, to express their point of view, and to contest the decision. Customer engagements involving such workflows require additional scoping; we will not silently ship a deployment that crosses this line.

9. Accuracy, hallucinations, and grounding

Large language models can produce plausible but incorrect content. Jubi's design — Atlas-grounded answers, output validation, citation requirements — reduces that risk for queries about your data. It does not eliminate it.

• If the AI cannot ground an answer in your data or your Atlas, the system is designed to say so. Output validation at Guardian flags ungrounded claims before they reach the user.
• Atlas reflects what your team has defined. If a metric formula in Atlas is wrong, Jubi will return a wrong answer. The customer owns the accuracy of Atlas.
• Web search results, file uploads, and any external content the AI may consult during a session are sourced as best-effort and are not warranted by Jubi.

10. Bias, fairness, and explainability

We work to reduce bias in two places: in how we use models (we don't put protected-class data into prompts unless the customer explicitly does so as part of an analysis) and in how we present results (citations, source attribution, ability to drill into the data behind any answer).

We do not warrant that AI outputs are unbiased or fair. Bias detection and correction in the customer's source data and Atlas definitions is the customer's responsibility. We will engage in good faith on bias issues raised under an active engagement.

11. Model evaluation and red teaming

We periodically evaluate the models and the platform together against:

• Prompt-injection patterns (direct and indirect, including injection through tool outputs and uploaded files).
• Jailbreak attempts targeting Atlas grounding, Guardian policy enforcement, and audit evasion.
• Sensitive-data extraction attempts (PII, credentials, masked fields).
• Quality regressions when providers update model versions.

Findings inform Guardian's input/output validation. Test cadence and results are not published in detail to avoid arming attackers; summary results are available to customers under NDA.

12. Customer controls

• Provider exclusion. Customers may request that specific model providers be excluded from their tenant's routing.
• Region pinning. Customers may request inference be pinned to specific provider regions, subject to availability of those regions for the chosen model.
• Audit retention. Customers configure how long the AI audit log is retained.
• Workspace scoping. Customers control which data and Atlas definitions are reachable from each workspace.
• Web search and file upload toggles. Customers can disable these at the tenant level if their use case does not permit them.

13. Prompt-injection and abuse defence

Guardian inspects inputs for known prompt-injection patterns and validates outputs against Atlas grounding. We catalogue and test against known evasion techniques. No defence is perfect; the customer should treat AI output as untrusted input to its own systems unless the customer has independently validated it.

14. Changes to this policy

We may update this page as the model landscape, regulation, and our environment evolve. Material changes are reflected in the "Last updated" date. For binding commitments — what we promise to a specific customer — see the engagement, not this page.

Privacy & AI policy questions: privacy@jubi.my · Security: security@jubi.my