# AI Reporting: How to Automate Reports Without Losing Trust

> A guide to AI reporting for SaaS: the tool landscape, the trust problem, and the MCP-native way to render charts from your query results inside an agent.

Your data team spends 40% of their time building reports. Weekly revenue summaries. Monthly board decks. Quarterly business reviews. Customer-facing usage reports. Each one requires pulling data, checking the numbers match last month's methodology, formatting it, and sending it out.

AI reporting tools promise to automate this. Ask for a report in natural language and get charts, tables, and summaries in seconds. The problem: the AI generates the queries from scratch each time. This month's revenue calculation might differ from last month's. The board deck numbers might not match the customer report. Automation without governance creates reports nobody trusts.

## What is AI reporting?

AI reporting uses large language models to automate parts of the reporting workflow: querying data, generating visualizations, writing narrative summaries, and scheduling delivery. Instead of an analyst manually pulling numbers and building slides, the AI handles the mechanical work.

The tools range from simple (ChatGPT generating a summary from a CSV) to sophisticated (enterprise BI platforms with AI-powered report builders). What they share: the AI interprets your data on every run. There's no guarantee that "revenue" means the same thing in this week's report as it did last week.

## Why AI-generated reports break trust

### Inconsistent methodology

The AI generates SQL from your schema context. This week it calculates revenue as `SUM(amount)`. Next week, with slightly different prompt context, it adds a `WHERE status = 'completed'` filter. The CEO compares the two reports and asks why revenue dropped 8%. It didn't drop. The calculation changed. Nobody noticed because the SQL is generated on the fly.

### No audit trail

When the CFO asks "where did this number come from?", the answer should be a versioned metric definition, not "an LLM wrote some SQL." Automated reports need the same auditability as manual ones. If you can't reproduce a number from a specific report, the report is useless for compliance, board materials, or customer-facing delivery.

### Metric drift across reports

The weekly ops report, the monthly board deck, and the quarterly customer report all show "revenue." Without a shared definition, each report calculates it independently. The numbers diverge. Stakeholders compare reports and lose confidence. The data team gets pulled into reconciliation instead of building.

## The governed approach to AI reporting

The fix isn't avoiding AI. It's separating what AI is good at (generating natural language summaries, choosing visualizations, scheduling delivery) from what it's bad at (defining business metrics).

### Define metrics once

```yaml
cubes:
  - name: revenue_metrics
    sql_table: analytics.monthly_revenue
    measures:
      - name: total_revenue
        sql: "CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END"
        type: sum
        description: "Finance-approved revenue (excludes refunds and trials)"
      - name: mrr
        sql: monthly_amount
        type: sum
        description: "Monthly recurring revenue from active subscriptions"
      - name: net_revenue_retention
        sql: "current_mrr / previous_mrr"
        type: avg
        description: "NRR: current period MRR / prior period MRR for the same cohort"
    dimensions:
      - name: plan
        sql: plan_name
        type: string
      - name: region
        sql: region
        type: string
      - name: period
        sql: period_date
        type: time
```

Every report, whether generated by AI or built manually, references these definitions. The methodology is fixed. This month's "revenue" uses the same calculation as last month's.

### Let AI handle presentation, not calculation

The AI's job shifts from "calculate revenue" to "present the governed revenue number." It queries the [semantic layer](/glossary/semantic-layer), gets a trustworthy number, and wraps it in a narrative: "Revenue grew 12% QoQ, driven primarily by Enterprise plan expansion in EMEA."

This is a better division of labor. The data team defines what's true. The AI makes it readable.

### Charts in the agent, from your query results

When the report lives inside an AI agent, the customer often wants a chart in the conversation, not only a narrative. That's a separate surface from the governance layer, and it's where `@bonnard/mcp-charts` fits.

`@bonnard/mcp-charts` is not a reporting tool or a BI platform. It is a `visualize` tool you add to your MCP server that renders interactive charts from your query results, inside the agent.

```typescript
import { addCharts } from "@bonnard/mcp-charts";

addCharts(server, {
  runSql: async (sql) => db.query(sql),
});
```

`addCharts` registers a `visualize` tool (and `visualize_read_me`). The agent calls `visualize`, your `runSql` returns rows, Bonnard infers the chart from the typed result, and it renders an interactive `ui://` widget in Claude or ChatGPT. Chart types: line, bar, area, pie, scatter, funnel, waterfall, and table. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own `runSql`. Bonnard never touches your database.

Axes, formatting, and gap-fill are determined automatically, so the same typed result produces the same chart every run. The tool returns compact summaries, row caps with completeness flags, and instructive errors with a `next_step`, so the agent can reason about the result. For the design principles, see [how Bonnard builds agent-friendly MCPs](/blog/how-bonnard-builds-agent-friendly-mcps).

## AI report generators: what's available

AI report generators automate the mechanical parts of building reports. Here's what exists and where each approach fits.

**General-purpose LLMs as report generators.** Upload a CSV to ChatGPT or Claude and ask for an analysis. Good for one-off reports. No governance, no scheduling, no multi-tenancy. The report is as good as the prompt. Ask the same question next month and you might get a different methodology.

**Dedicated AI reporting tools.** Narrative BI, Rath, and similar tools generate automated dashboards and written insights from your data. They connect to your warehouse and produce reports on a schedule. The limitation: they define metrics at report generation time, not in a governed layer. Different reports can calculate the same metric differently.

**BI tools with AI features.** Power BI Copilot, Tableau AI, Domo AI. The AI helps you build reports inside the BI tool. Better than general-purpose LLMs because the data stays in your warehouse. Limited to whatever the BI tool supports.

**Semantic layer + AI.** Define metrics once in a governed layer. Use AI to generate narrative summaries, choose visualizations, and schedule delivery. The AI handles presentation. The semantic layer handles correctness. This is the approach that produces trustworthy automated reports.

## AI reporting tools compared

| Tool | Approach | Governed metrics | Multi-tenant reports | Audit trail |
|------|----------|-----------------|---------------------|-------------|
| **ChatGPT / Claude** | Upload data, ask for analysis | No | No | No |
| **Power BI Copilot** | AI in Power BI | DAX measures (PBI only) | Complex | Within PBI |
| **Tableau AI** | AI in Tableau | Tableau model only | Enterprise | Within Tableau |
| **Domo AI** | AI in Domo platform | Within Domo | Within Domo | Within Domo |
| **Automated BI tools** (Narrative BI, Rath) | AI-generated dashboards | No | No | No |
| **Charts in agent (Bonnard)** | `visualize` tool on your MCP server | N/A (your `runSql`) | N/A (your DB) | N/A |

## When to use AI reporting

**Use AI reporting with a semantic layer when:**
- Reports go to the board, customers, or regulators (trust matters)
- Multiple reports use the same metrics (consistency matters)
- You're automating B2B customer reports with per-tenant data
- The data team is spending too much time on report generation

**Use raw AI reporting tools when:**
- One-off ad-hoc analysis for internal consumption
- Exploring a new dataset where methodology isn't established
- Speed matters more than consistency

## Getting started

If you want charts rendered inside an AI agent from your own query results, install the package and register the tool on your MCP server:

```bash
npm install @bonnard/mcp-charts
```

```typescript
import { addCharts } from "@bonnard/mcp-charts";

addCharts(server, {
  runSql: async (sql) => db.query(sql),
});
```

That registers the `visualize` tool (and `visualize_read_me`). Connect your server in Claude or ChatGPT, and the agent can render charts from your query results. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own `runSql`.

Repo: [github.com/bonnard-data/mcp-charts](https://github.com/bonnard-data/mcp-charts). Full walkthrough: [MCP charts](/blog/mcp-charts). For background: [What Is a Semantic Layer?](/blog/what-is-a-semantic-layer).

## Frequently asked questions

### What is AI reporting?

AI reporting uses large language models to automate report generation: querying data, creating visualizations, writing summaries, and scheduling delivery. The AI handles the mechanical work that analysts currently do manually. The risk: without governed metric definitions, the AI generates different calculations on each run.

### Can AI replace my reporting team?

No. AI can automate the mechanical parts (pulling data, formatting charts, writing summaries). It can't define what metrics should mean, decide which numbers matter for a specific audience, or judge whether an insight is actionable. The best approach: data teams define governed metrics, AI automates the delivery.

### What is automated reporting?

Automated reporting is any system that generates reports without manual intervention. This includes scheduled dashboard refreshes, programmatic report generation via API, and AI-generated narrative summaries. The key question isn't whether to automate, but whether the automated reports use governed metric definitions.

### How do I make AI reports trustworthy?

Separate metric definition from report generation. Define each metric once in a [semantic layer](/glossary/semantic-layer) with a fixed calculation. Let the AI query those definitions instead of generating SQL. Every report references the same versioned definitions. When someone questions a number, you point to a Git commit, not "the AI decided."

### What is the best approach to AI reporting for SaaS?

Govern the numbers first so methodology stays fixed across runs. Then pick the surface where the report lands. If your customers read reports inside Claude or ChatGPT and want a chart in the conversation, `@bonnard/mcp-charts` adds a `visualize` tool to your MCP server that renders interactive charts from your query results. Your `runSql` runs the query, so Bonnard never touches your database. Install with `npm install @bonnard/mcp-charts`. Repo: [github.com/bonnard-data/mcp-charts](https://github.com/bonnard-data/mcp-charts).