Trust, privacy, and consent

The three commitments

Any AI product serving Nepali users should visibly commit to three things:

1. Honesty about what the product is. No pretending it’s more accurate than it is. No pretending it’s not AI.
2. Care about the data it collects. Minimum collection, secure handling, honest deletion.
3. A named human at the end of the pipeline. Not a support form. A person users can reach.

These aren’t compliance requirements — they’re what turns a suspicious first-time user into someone who tells their family to try the product.

Honesty about being AI

The single most-broken norm in AI products: pretending they aren’t. Do not do this.

Every AI-generated response should be labelled as AI-generated. In the UI:

• A small “AI assistant” tag alongside every response.
• On the landing page: “This is an AI assistant. It sometimes makes mistakes.”
• In the response tone: “Based on the documents I found, …” not “I know that …”

Nepali users are increasingly aware of AI tools (ChatGPT is widely known in Kathmandu). They are not confused about what AI is. What confuses and angers them is products that hide their nature — because the products that hide it are usually the ones being dishonest about accuracy too.

Honesty about accuracy

Nepal-facing AI products often deal with domains where a wrong answer causes real damage: legal information, medical triage, financial calculation, government procedure. Users trust these products because there’s no better alternative locally — and that trust deserves care.

The habit:

• Show confidence. If your system estimates confidence per answer (Course 04 Section 5.3), display it. “High confidence” vs. “Low confidence — please double-check with the source.”
• Cite sources. Every factual claim should link to the underlying document.
• Prescribe next steps. For anything consequential, tell the user where to go next (“consult a lawyer” / “verify with the DAO” / “check with your HR person”).
• Refuse when appropriate. Better to say “I don’t know this one” than to guess.

Consent — the specific asks

For a Nepal-facing AI product, what specifically requires consent?

Storing user queries in logs.

Users should know their queries are logged. In the landing page or ToS:

Your queries are stored for 90 days to help us debug and improve the service. Personal data is anonymised. You can request deletion at any time by emailing us at contact@example.np.

Using queries for model improvement.

If you plan to use user queries to train, fine-tune, or curate future eval sets, disclose it. If it’s a paid product, offer an opt-out.

Sending queries to a third-party API.

Most Nepal-facing AI products send queries to Anthropic, OpenAI, or another foreign provider. This is a technical detail users won’t understand — and mostly won’t care about — but for regulated domains (health, finance, legal), the fact that a Nepali user’s query leaves Nepal for processing may become a compliance question. Disclose the fact (“we process queries via Anthropic’s servers in Singapore”) in your privacy policy.

Handling PII embedded in queries.

If a user types their national ID number into your chatbot, it may enter your logs and the model provider’s logs. Reasonable practices:

• Warn users not to paste sensitive data (“Please don’t include national ID numbers, passport numbers, or account passwords”).
• Mask or redact recognisably sensitive fields at the boundary if possible.
• Have a policy for what to do if a user sends PII anyway (usually: delete the log entry on request, or scrub PII automatically before storage).

The privacy policy — one page, plain language

A Nepali AI product’s privacy policy should fit on one page and be written in language a curious teenager can read. Ideally in both Nepali and English.

Suggested outline:

1. What data we collect
   (Your questions, your account details, timestamps.
   We do not collect your location or contacts.)

2. Where the data goes
   (Stored on our servers in [region]. Some queries are sent to
   Anthropic's servers in Singapore for AI processing.)

3. How long we keep it
   (90 days by default. Longer if regulation requires.
   You can request deletion at any time.)

4. Who can see it
   (Only our engineering team, only when investigating an issue.
   We do not sell data or share with third parties.)

5. Your rights
   (You can request all your data. You can delete your account.
   You can opt out of any research use.)

6. How to reach us
   (Email: privacy@example.np. Phone: 01-4XXXXXX. We reply within 3 days.)

Six paragraphs. Actionable. In language your users read.

The trust-preserving refusal

For sensitive queries where you shouldn’t answer, refusal is a trust act. Bad refusals damage trust; good ones build it.

Bad refusal:

I cannot answer this question.

Good refusal:

This looks like a legal question about property inheritance. I'm not
qualified to give legal advice, but here's what I can do:

- Point you to the relevant Muluki Ain sections (linked below).
- Suggest you consult a registered lawyer for your specific case.
- If you need an advocate, the Nepal Bar Association has a directory
  at nba.org.np.

Is there anything specific about the general framework I can help with?

The good refusal:

• Explains what it is (a legal question).
• Explains why the AI is declining (not qualified).
• Provides genuine alternative paths.
• Offers to help within its actual scope.

Users leave feeling helped, even without an answer. That’s the trust act.

The named human

Every Nepal-facing AI product should have a named, reachable human at the end of the pipeline. Not support@example.np (which feels anonymous) but a real person:

If something goes wrong, or if you have questions about this service, email me directly: nishan@example.np. I reply within 24 hours. — Nishan Sharma, product lead

This is startlingly effective. Nepali users default to distrust of anonymous online services; a named human puts skin in the game and signals real accountability. It also naturally scales-limits your product — you can’t run an AI service for 100,000 users while personally answering emails, which forces honest thinking about growth.

Data breach — the policy in advance

Nobody plans for a breach; every serious product has a breach policy anyway. Write it now, before you need it:

1. Discovery. If we discover a leak or breach, we notify affected users within 24 hours.
2. Scope. We tell them exactly what was leaked and how.
3. Remediation. We take immediate technical action to close the vulnerability.
4. Follow-up. We publish a post-mortem within a week explaining what happened and what we’ve changed.

Publishing this policy up front is itself a trust act. Most projects don’t; the ones that do stand out.

The “unsexy” trust habits

Small, unglamorous things that compound:

• Answering user emails personally.
• Publishing a monthly changelog of what’s been improved.
• Attributing sources clearly on every AI-generated answer.
• Never sending marketing emails without an opt-in.
• Making unsubscribe / account deletion take one click, not five.
• Sending occasional short honest updates: “We had a bad day this week — here’s what happened and what we did.”

None of these are novel. All of them are absent from most Nepali digital products. The one that adopts them stands apart.

What comes next

Trust is your product’s brand. The next section is what’s less about brand and more about law: the legal and regulatory landscape for AI in Nepal as of 2026, the compliance thinking practitioners need, and where the rules are likely to go.