How to Embed an AI Analyst So Customers Can Ask Questions About Their Data

Embed an AI analyst by connecting your product's authenticated users to a permission-scoped analytics service, grounding its answers in approved metrics and customer-specific business context, and testing the complete answer and sharing flow before rollout. Start with one useful customer question and a small pilot; expand after the analyst gives correct, inspectable answers within each customer's access limits.

Last reviewed: October 1, 2026. Product documentation cited below was checked on that date.

What does embedded AI analytics mean?

Embedded AI analytics is an analytics experience inside another product that lets users ask data questions in natural language and receive analysis without leaving that product. A useful embedded analyst can support follow-up questions and explain its work. The product team remains responsible for choosing the questions, defining access, and deciding what can reach customers.

The interface is only one part of the implementation. A customer who asks “Why did active accounts fall?” needs the correct account definition, population, period, and comparison. An answer based on the wrong definition can be misleading even when every row belongs to the right customer.

Treat correctness and access as separate requirements. Customer isolation controls whose information is available. Metric governance controls which calculation is used. Business context explains how that calculation applies to the question.

Should you embed dashboards, a chat interface, or an analyst?

Choose the smallest experience that answers the customer need. These are product patterns, not a ranking of vendors; individual products can combine them.

Keep dashboards where they work. Add an analyst to a specific gap, such as helping an account manager investigate a renewal movement, rather than requiring every customer to adopt a new way of working.

For a broader product shortlist, see 14 Best AI Business Intelligence Tools and Platforms for 2026.

What must be scoped to each customer?

Design the request around an authenticated user, the customer account they can access, and the resources permitted for that task. Resolve those facts in trusted application code. A customer name typed into chat is a requested subject, not proof that the user may access it.

Review at least these boundaries:

• Data: databases, schemas, rows, columns, and permitted aggregations.
• Meaning: metric definitions, terminology, fiscal periods, and relevant exceptions.
• Work: conversations, projects, saved analyses, reports, and exports.
• Delivery: recipients, shared links, and destinations for finished answers.

A SaaS customer account and an analytics vendor's tenant are not necessarily the same object. A deployment may use separate vendor tenants, groups within a tenant, or another supported arrangement. Confirm that mapping before writing onboarding or access rules.

For example, Orion's Groups documentation describes groups that share projects, data sources, Knowledge Base pages, and integrations. It includes an end-customer use case within one Orion tenant. Tenant Admins retain visibility across groups, and tenant and group roles are independent. A group name or organizational prefix does not establish an inheritance relationship.

Do not assume that a warehouse service account knows which end customer is asking. Inspect the effective connection identity and the additional controls that apply the customer's scope. Snowflake documents row access policies that determine which rows a query can return. Whether a policy is sufficient for your embedded design depends on how the query session and its roles are configured. Test the actual connection path.

How do you keep dbt metrics and customer-specific context consistent?

Keep approved calculation logic in the governed data or metric layer. Add task-specific context around it instead of copying formulas into a second glossary and relying on the analyst to keep both versions aligned.

The dbt Semantic Layer centralizes metric definitions on existing models and handles joins through MetricFlow. That is a governed metrics capability. Additional context can explain terminology, ownership, targets, and dated events. A prose instruction should not silently replace an approved calculation.

If two customers legitimately use different calculations, give those calculations distinct approved identities and explicitly map each customer to the appropriate one. This is a recommended design pattern, not a claim that every embedding product provides automatic metric overrides.

Consider this hypothetical example:

• Customer A defines an active account as one with a completed transaction during the reporting period.
• Customer B defines an active account as one with a login during that period.
• The data team maintains separately named, approved measures for both definitions.
• Each customer's context identifies the applicable measure and explains the business reason for using it.
• An account owner approves a change before the new mapping reaches customer-facing answers.

The analyst should identify the definition used. If the user asks for a comparison between customers with different definitions, the answer should explain that the populations are not directly comparable rather than presenting an apparently uniform KPI.

Keep an effective date for a changed rule and agree how historical questions should be answered. Updating today's context does not, by itself, establish which rule applied last quarter. For the broader distinction, see Semantic Layer vs. Business Context.

What are the steps to ship a useful pilot?

These steps are an implementation and review workflow. They are not Orion API instructions or a promised delivery timeline.

1. Pick one customer question. Choose a question with a known answer and a real follow-up, such as “Which accounts stopped transacting this month?” followed by “Which product segment explains the change?” Define the business action that the answer should support.
2. Write the answer contract. Record the approved metric, grain, period, filters, allowed dimensions, data freshness requirement, expected evidence, and conditions that require clarification. Name a data owner and a customer-domain reviewer.
3. Map identity and access. Connect the signed-in product user to an allowed account and analytics scope. Verify what happens when access is revoked, a user belongs to multiple accounts, or an administrative user opens a customer view.
4. Connect governed data and scoped context. Use the approved metric interface supported by your stack. Supply only the customer's relevant operating knowledge. Review connection permissions, including shared service accounts, with the implementation team.
5. Choose the experience and sharing rules. Decide where questions appear, how follow-ups work, what evidence is visible, and who can receive an export or shared answer. Show an understandable message when data, access, or meaning is missing.
6. Run the acceptance checks below. Use separate test identities and intentionally different customer definitions. Review query results and the complete response, including citations and saved artifacts.
7. Release to a limited cohort and assign maintenance. Record failures, review consequential answers, and rerun affected checks when models, definitions, context, roles, or delivery rules change. Expand only after the team can explain and correct the failures it observes.

Building the analyst internally gives the team control over orchestration and product behavior, but also assigns it ongoing ownership of retrieval, authorization, evaluation, and support. Buying an embedded product can reduce the components the team builds; it still requires integration and customer-specific acceptance testing. Compare maintenance responsibilities alongside the initial implementation.

What should you test before customers can use it?

Use this tenant-and-metric acceptance sheet as a starting asset. The scenarios and pass conditions are recommendations, not results from a benchmark or a claim about a vendor's performance.

Have reviewers inspect explanations as well as numbers. A correct total paired with the wrong business reason is still an answer failure. Likewise, filtering the query is insufficient if a citation, saved report, or retrieved document exposes another customer's information.

Retain the question, test identity, applicable metric, context references, data timestamp, and reviewed output. Rerun relevant cases after a change. For broader buying criteria, use How to Evaluate an AI Analytics Agent Before You Buy.

Where does Orion by Gravity fit?

Orion by Gravity offers an embedded, white-label analytics experience for customers inside a product. Its published offering describes product sign-in, account-scoped data and business context, follow-up investigation, and reuse of existing semantic definitions. Evaluate that offering against your own identity, warehouse, and customer configurations.

Orion's data-source documentation describes dbt model-description and lineage enrichment for an existing warehouse connection. It documents a read-only GitHub repository connection and also lists dbt Cloud and manifest upload options. That documentation does not establish native execution through dbt's MetricFlow APIs. Confirm that distinction when evaluating how approved calculations reach answers.

Orion's Knowledge Base documentation describes business and analytical context organized into pages. Pages enabled for a project can inform chat and produce source citations in deliverables. That provides a documented place for operating knowledge around governed metrics.

Ask the implementation team to demonstrate your exact permission path and how conflicting or changed customer definitions are handled. Shared warehouse credentials require particular attention. The acceptance sheet above is a proposed rollout method; it is not a claim that Orion ships automatic inheritance of tenant-specific formulas, a metric-override registry, or a CI regression runner.

Orion is a candidate when customers need analysis and explanation over a maintained data foundation. A stable embedded dashboard may be sufficient when customers only need a fixed report. Teams choosing Orion still need owners for metrics, context, access, and review.

Frequently asked questions

Can customers ask questions without learning SQL?

Yes, a natural-language experience can remove SQL from the customer's workflow. The implementation still needs governed queries, access controls, and inspectable evidence. Start with questions whose answers your reviewers can verify.

Does an embedded analyst replace our dbt semantic layer?

It should preserve the approved metrics foundation. Use dbt for centrally maintained calculation logic where your stack supports it, and use additional context to explain which definition applies. Confirm the product's actual integration path rather than assuming native support for every dbt Semantic Layer API.

Can each customer use a different definition of the same KPI?

Design for explicit, approved mappings to distinct calculations. Document the scope, owner, and effective date of each mapping. Confirm how the chosen product implements this pattern; a shared glossary alone does not resolve conflicting customer rules.

Is row-level security enough for an embedded AI analyst?

It addresses access to rows. The complete experience also needs appropriate document retrieval, citations, conversations, exports, and sharing. Check all of those surfaces using actual customer identities and the production-style connection configuration.

Who maintains customer-specific business context?

Assign an owner for each kind of knowledge. Data teams maintain calculations and model logic; domain owners approve terminology, exceptions, and targets. Product and security owners review access and delivery. Record changes and rerun the affected acceptance cases before rolling them out.

How should a product team start evaluating Orion?

Bring one customer question, its verified answer, two differently scoped test accounts, and a real metric ambiguity to the demonstration. Ask Orion by Gravity to show the definition, source evidence, access behavior, and saved-answer flow. Discuss any unsupported workflow explicitly before committing to a rollout.