AI Embedded Analytics for SaaS: What Actually Works in 2026

Author's Note

Dashrendr is an embedded analytics platform, and we do not offer AI features today. There is no conversational query in our product, no natural language interface, and no automated insight generation. We are watching the space, and we have not shipped anything in it. Weigh everything below accordingly.

We wrote this anyway, because the topic comes up in nearly every evaluation conversation we have, and most of the available material is produced by vendors selling the exact feature they are describing. Our aim is for this to be useful even if you finish reading and conclude that you need a tool we do not sell. That is a perfectly good outcome, and we would rather you reach it quickly than slowly.

Do your own evaluation. Put the questions in this article to any vendor you are considering, including us, and trust what you see in a sandbox over what you read in a blog post.

The short answer

• AI in embedded analytics is three different products bundled under one word. Conversational query for your end customers, automated insight and anomaly detection, and AI-assisted dashboard authoring for your own team. They share a model, and very little else.
• They carry very different risk profiles. One of them can return the wrong tenant's data. One of them can be confidently wrong in an email your customer reads on a Monday morning. One of them can waste twenty minutes of an internal analyst's time.
• The customer-facing conversational one is by far the riskiest in a multi-tenant product, because the failure is visible to your customer, and the worst version of it is a data isolation breach rather than a bad chart.
• Most SaaS teams should adopt the third before the first. AI-assisted authoring for your own team has a small blast radius, a short feedback loop, and a human reviewer in the path by default.
• The decisive question for a vendor is not model accuracy. It is where tenant isolation is enforced relative to where the model operates.

If you are earlier in the process and still deciding what your analytics feature should do at all, our developer's guide to embedded analytics covers the groundwork this article assumes.

The three things vendors call AI

When a vendor says their embedded analytics product has AI, the honest follow-up question is which of these three they mean. The marketing page usually implies all of them. The product usually ships one well.

Capability	Who uses it	Worst realistic failure	Blast radius
Conversational query	Your end customer	Wrong number, or another tenant's rows, rendered inside your product	External, potentially a breach
Automated insights	Your end customer, often by email	A confident narrative about statistical noise	External, reputational
AI-assisted authoring	Your own team	A badly built chart that a human rejects before shipping	Internal, minutes

Conversational query for your customers

This is the demo everyone has seen. A text box sits above the dashboard, your customer types "show me revenue by region last quarter," and a model turns that into a query against their data. ThoughtSpot built a company on this interaction, and most of the established platforms now offer some version of it.

The user is your customer, not your analyst. That single fact changes everything. Your customer cannot read the generated SQL, cannot evaluate whether the join was reasonable, and has no way to sanity check the output beyond whether the number feels plausible. When the model is wrong, it is wrong inside your product, wearing your branding, and your support team owns the conversation. This is the only one of the three where a mistake is visible to your customer by default, and the only one where a mistake can be a data breach rather than an inconvenience.

Automated insights and anomaly detection

Here the system looks at the data without being asked and tells the user what changed. Signups dropped eighteen percent week over week. Churn is concentrated in one plan tier. This shows up in digest emails, in notification feeds, and as narrative text above a chart.

The accuracy problem here is subtler than it looks. Anomaly detection on small-sample tenant data produces a steady stream of findings that are statistically real and practically meaningless, and a language model asked to narrate those findings will produce a fluent, causal-sounding explanation for what is actually noise. The failure is not a security event. It is an erosion of trust, and it happens quietly, over weeks, until customers stop reading the emails.

AI-assisted authoring for your team

The least discussed and, in our view, the most immediately useful. Your own team describes a chart or a dashboard in plain language, and the tool drafts it. The user is an employee who knows the data model, the output is reviewed before anyone outside sees it, and the cost of a bad suggestion is that someone deletes it and tries again.

This is where the economics are clearly positive. Dashboard authoring is repetitive, it is a bottleneck in most product teams, and the review step is free because it was already happening. If you are going to adopt one of these three this quarter, adopt this one.

Why text-to-SQL is a security problem, not an accuracy problem

Almost every article about LLM-generated SQL frames it as a correctness question. Did the model pick the right table, did it get the join right, did it apply the right date boundary. Those are real questions, and in an internal BI tool they are close to the only questions, because the person reading the result is usually the person who can tell when the number looks wrong.

In a multi-tenant product the primary question is different, and it is rarely the one being answered in the demo. It is not whether the generated query is correct. It is whether the generated query is correctly scoped to the tenant that asked.

Here is the failure mode in concrete terms. Your data sits in shared tables with a tenant identifier column. A customer asks a question. The model receives a schema description and some instructions, and it writes SQL. If the tenant predicate is something the model is responsible for including, then you have made a probabilistic text generator the last line of defense for your data isolation. It does not matter that it gets it right the overwhelming majority of the time. It needs to omit that predicate once, on a query a customer can see the output of, and you are writing an incident report and notifying a customer that another customer's rows appeared in their dashboard.

The correct architecture enforces isolation below the layer the model operates on, so that no generated string can widen the scope of what is returned:

• Row-level security in the database. Policies are attached to the tables themselves and applied by the engine for every session. A query that forgets the tenant filter returns nothing extra, because the filter was never the query's responsibility.
• A per-tenant connection or credential. The connection the generated query runs on can only reach that tenant's data, whether through a separate database, a separate schema, or a role scoped to a view.
• A policy layer that injects the tenant predicate at query time. The generated SQL is parsed and rewritten, or the model is only allowed to emit a structured query object that a trusted compiler turns into SQL with the tenant filter attached. The critical property is that the injected predicate cannot be overridden, commented out, or unioned around by anything the model produced.

None of this is new. It is the same discipline that applies to any multi-tenant dashboard with row-level security, which is why we keep saying that AI did not create this problem, it just raised the cost of getting it wrong. Adding a natural language surface to an architecture where isolation is already enforced in the data layer is a feature decision. Adding one where isolation is enforced by application code assembling WHERE clauses is a rewrite.

There is a second vector that gets less attention. Prompt injection is real here, and it does not require a malicious user of your product. It requires customer-controlled text to reach the model's context, which it does constantly in analytics: record names, custom field labels, free text notes, campaign names, product titles. A row whose name field contains instructions is a row that can attempt to steer a model that was asked to summarize it. Treat any string that originated outside your team as untrusted input to the model, not as data.

A short list to put to any vendor on this specific point:

• If the model emits SQL that omits the tenant filter entirely, what does the system return?
• Is the tenant predicate injected by a trusted layer, or expected from the model?
• Can generated SQL reach any table outside the tenant's scope, under any circumstance?
• Does customer-controlled text ever enter the model context, and what is done about it?
• Is the generated query logged in a form we can audit after an incident?

A serious vendor answers these in a sentence each, because their architecture already decided them. A vendor who needs to get back to you has told you something useful.

Do you need a semantic layer?

Ask a language model "what was revenue last month" against a raw schema and it will cheerfully pick a column, decide for itself whether to use gross or net, choose its own treatment of refunds, pick a timezone, and present the result with total confidence. Ask it again tomorrow, phrased slightly differently, and it may make different choices. Two users in the same company get two numbers, both defensible, and now they are arguing in a meeting instead of making a decision.

A semantic layer fixes this by pinning the definitions. Revenue is defined once, as a specific expression over specific tables with specific filters, and the model's job is reduced from authoring logic to selecting from governed metrics and dimensions. That is a dramatically smaller and more testable surface. It also makes failure legible: the model either picked the wrong metric, which you can see, or it picked the right one, which means the number is as correct as your definition is.

We want to be balanced about this, because semantic layers are currently being sold as a prerequisite for everything. They are real engineering investment. Someone has to own the definitions, keep them current as the product changes, and arbitrate when two teams disagree. That work does not go away, it just becomes visible.

• It is the right call if you are exposing AI query to customers, or if you already have multiple teams disputing what a core number means.
• It is probably overkill if you have a dozen well-understood metrics, one team that agrees on them, and no AI query surface at all.

Looker's LookML is the reference example, and the newer standalone semantic layers are worth studying even if you do not adopt one, because they have thought harder about metric governance than most of us have. If you are comparing platforms on this dimension, our roundup of the best embedded analytics tools for SaaS in 2026 notes which ones bring a modeling layer with them.

What this costs you that nobody mentions

The pricing page shows a platform fee. The real cost structure of a customer-facing AI feature has four parts, and three of them are not on that page.

Per-query inference. Every question costs money, and a conversational interface is explicitly designed to invite follow-up questions. A customer who asks fourteen questions in an afternoon is using the feature correctly, and you are paying for all fourteen. A pre-built dashboard has a cost curve you can predict from your tenant count. A conversational feature has a cost curve that depends on how engaging you made it, which is an uncomfortable incentive.

Latency. A cached dashboard panel renders in a few hundred milliseconds. A natural language question involves at least one model round trip, query planning, execution, and often a second model call to narrate the result. Users forgive this for a few seconds. They do not forgive it when they wanted a number they already knew the name of, and the dashboard would have had it on screen before they finished typing.

Evaluation. This is the one that surprises teams. A dashboard is deterministic: you build it, you verify the numbers once, and it stays correct until someone changes the underlying data model. A conversational feature is non-deterministic, which means correctness is a distribution rather than a state. You need an evaluation set of real questions with known answers, you need to run it on every prompt change and every model version change, and you need someone who owns the result. A dashboard is a thing you test once. A conversational feature is a thing you test forever.

Support. When a customer says the AI gave them a wrong number, you have to be able to reconstruct what happened. Without logged queries and a reproducible path, that ticket becomes an open-ended investigation. This is also where the build versus buy calculation shifts: a buy decision that was already defensible for dashboards becomes more so once your alternative is maintaining an evaluation harness for a model you did not train.

How to evaluate a vendor's AI claims

Specific questions with checkable answers, in the order we would ask them. Bring these to the demo and ask for the sandbox afterward.

1. How is tenant isolation enforced relative to the generated query? Is it in the database, in a trusted policy layer, or in the string the model wrote? There is only one acceptable family of answers.
2. Can the model author arbitrary SQL, or only select from defined metrics? If arbitrary, ask what constrains it. If governed, ask who maintains the definitions and how long that takes.
3. What happens to our customers' data? Where does it go, how long is it retained by the model provider, and is any of it used for training. Get this in writing, not in a demo answer.
4. How are failures surfaced to the end user? Does the interface show the question it actually answered, the metric it used, and a path to the underlying rows, or does it present a number with no provenance?
5. What does it cost per query at our expected volume? Then ask what happens at ten times that volume, and whether there is a cap.
6. Can we turn it off per tenant? You will need this for a regulated customer, an enterprise security review, or a tenant whose data model is too messy for it to work well.
7. Can we see the logs of generated queries? If you cannot audit it after the fact, you cannot support it.

These slot into the broader embedded analytics requirements checklist we use with teams, which covers the non-AI half of the evaluation that still determines most of the outcome.

When to skip AI entirely

Being direct, because the industry currently is not. There are good reasons to not do this, and most of them are more common than the reasons to do it.

• Your customers want the same five numbers every week. Most embedded analytics usage is narrow and repetitive. If the real job is "tell me how my store did," a fixed, fast, well-designed dashboard serves that better than a text box that asks the customer to think of the question themselves.
• You are in a regulated vertical. If you cannot explain to an auditor how a number was produced, or reproduce it exactly a year later, a non-deterministic generation path is a liability rather than a feature.
• You have no capacity to evaluate a non-deterministic feature. If nobody on the team will own an evaluation set and run it on every model update, you are not shipping an AI feature, you are shipping an uncontrolled dependency.
• Your analytics feature is not used enough to justify it. This is the most common case by a wide margin. If engagement with your existing dashboard is low, adding a model on top does not fix it. We have written about why users never open the analytics tab, and the answer is almost always a design and placement problem rather than an intelligence problem. Analytics buried behind a nav item, disconnected from the workflow where the decision gets made, stays unused no matter how smart it becomes.

Where Dashrendr sits

Plainly: we do not offer conversational AI, natural language query, or automated insights today. We are not going to imply otherwise, and we are not going to promise you a date.

What we build is the deterministic layer underneath. Connectors for Google Analytics, BigQuery, PostgreSQL, MySQL, MongoDB, Google Sheets, and Xero, plus a REST API for pushing pre-aggregated data. A drag-and-drop visual builder, with charts rendered through ECharts. Scheduled email delivery of dashboards. Row-level security built in on every plan, including the cheapest one, because tenant isolation is not a feature we think belongs behind an upgrade. White-labeling from the Grow plan upward (Hobby and Starter carry a watermark), and embedding that a developer can ship in hours rather than sprints. Plans run from Hobby at $6 per month to Premium at $99 per month, with a 14-day free trial and no credit card required.

If customer-facing conversational query is a hard requirement for you right now, we are not the tool, and you should look at a platform with a semantic layer and a governed AI query path. We would rather tell you that in week one than in month three.

For a large number of teams, though, the honest sequence runs the other way. Get a fast, well-designed, correctly isolated dashboard in front of your customers first, watch what they actually do with it, and then decide whether a natural language layer answers a question they are really asking. An AI layer on top of analytics nobody opens does not fix anything. It just makes the unused thing more expensive.

Conclusion

This category has moved quickly, and the marketing has moved considerably faster than the engineering. That gap is where bad purchases happen, because a demo on clean sample data with one tenant tells you almost nothing about behavior on messy production data across hundreds of tenants.

The question that separates a serious vendor from a good demo is not how accurate the model is. It is how tenant isolation relates to the generated query, and whether the answer involves trusting the model at all. Everything else in an evaluation is negotiable. That is not.

And if you are deciding where to start, start where the blast radius is small. AI-assisted authoring for your own team pays off quickly and fails harmlessly. Customer-facing conversational query is a product with a security surface, an unbounded cost curve, and a permanent testing obligation. Both are reasonable things to build. They are not reasonable things to build in that order reversed.

If the deterministic foundation is what you need first, Dashrendr has a 14-day free trial with no credit card at app.dashrendr.com/signup. If your conclusion is that you need something we do not sell, we hope this was still worth the read.