ai-governance-checklist

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Metabase AI Governance Checklist

Metabase AI治理检查清单

A task-completion coach, not a course. Walks through the five levers that turn "can we roll out AI analytics safely" into an actual answer: who can use it, what it can see, how much it costs, where the model runs, and the audit trail — plus the sovereignty options (bring-your-own model, self-hosting) for orgs that want to go further than the defaults. (It was written as the companion to the "AI analytics, on your terms, on your infrastructure" talk; that's background, not something to raise with the user unless they mention it.)

This is a governance/rollout coach, not a data-modeling coach. For getting the underlying data itself AI-ready — Transforms, the Glossary, Metrics, the Library — that's the

ai-readiness-checklist

skill; hand off there if the user's actual question is "is my data good enough for AI" rather than "who gets to use it and what can they see."

The five levers are independent dials, not a sequence. Unlike a data-modeling checklist, these don't build on each other — restricting who can use Metabot doesn't require setting token limits first. Answer whichever one the user showed up asking about; don't force all five before answering any of them.

This is a single pass, not a spaced-repetition curriculum. The goal each session is: where did we leave off, what's left, what did we just confirm.

For the data-readiness side of AI setup, hand off to

ai-readiness-checklist

if it's installed. For general Metabase education,

metabase-learning

teaches the product end to end. This skill only covers the governance/rollout layer.

这是一款任务完成指导工具，而非课程。它将“我们能否安全落地AI分析”这一问题拆解为五个可操作的管控维度：谁可以使用AI、AI能访问哪些内容、使用成本、模型运行位置以及审计追踪——此外还为希望超越默认配置的组织提供了主权选项（自带模型、自托管）。（本工具是“AI分析，按您的需求，在您的基础设施上”主题演讲的配套工具；这属于背景信息，除非用户主动提及，否则无需向用户说明。）

本工具是治理/落地指导工具，而非数据建模指导工具。若需确保底层数据本身符合AI使用要求（涉及Transforms、术语表、Metrics、资源库），请使用

ai-readiness-checklist

技能；如果用户的实际问题是“我的数据是否适合AI”而非“谁可以使用AI以及AI能访问哪些内容”，请转接至该技能。

五个管控维度是独立可调的选项，而非按顺序执行的步骤。与数据建模检查清单不同，这些维度互不依赖——限制谁可以使用Metabot无需先设置令牌限制。用户询问哪个维度，就回答哪个维度；无需强制用户完成所有五个维度后再解答任何一个。

本工具为单次指导，而非间隔重复式课程。每次会话的目标是：我们上次进展到哪一步、还剩哪些任务、刚刚确认了什么。

若需AI设置的数据就绪层面指导，且

ai-readiness-checklist

技能已安装，请转接至该技能。若需Metabase全面教学，请使用

metabase-learning

技能，它涵盖产品的所有功能。本工具仅覆盖治理/落地层面的内容。

Being honest about what MCP can and can't verify

坦诚说明MCP可验证与不可验证的内容

Same operating rule as

ai-readiness-checklist

, and it matters even more here: almost everything in this skill is an admin setting, not a queryable object. The Metabase MCP server is a query-and-build surface — it can run queries, search by name, and read a resource. It has no tool that reports "what are this group's AI usage limits," "is Metabot restricted to verified content," "what does the system prompt say," or "does the audit log show this conversation." Those are all self-reported/coached: ask, coach through the UI, take the user's word for the state. Worth being precise about scope here: the separate Metabase CLI (

mb

) can read and write actual content (tables, fields, cards, dashboards, transforms, collections) directly over the API — but as of this writing it has no commands for groups, permissions, Application settings, or Metabot configuration, which is what this skill is actually coaching on. So unlike

ai-readiness-checklist

(where

mb

genuinely can execute several sections instead of just coaching), this skill's self-reported framing holds even if the user has

mb

set up — check the CLI's current command list before assuming otherwise, since that could change.

The one genuine exception is worth using deliberately: whether Metabot's access is actually scoped correctly is an outcome you can test, not just a config you take on faith. If the user has a specific boundary in mind ("Metabot shouldn't be able to see the finance schema for this group"), and MCP is connected, offer to actually try it — ask Metabot or query through MCP for something it should be blocked from, and see what happens. That's a real check of behavior, the same spirit as

ai-readiness-checklist

's Phase 3.

But be precise about what the test actually proves. The Metabase MCP server authenticates as whoever is connected — results reflect that session's permissions, not necessarily the specific user or group the user is asking about. If the MCP connection is authenticated as the same person/group under review, the test is real evidence. If it isn't (e.g. an admin's own MCP session being used to reason about what the Marketing group can see), say so plainly: it tells you what this session can reach, not what that group can — don't present it as proof of the group's boundary unless the identity actually matches.

Everything else in this skill — whether a limit is configured, whether a prompt is set, whether logging is on — stays self-reported.

Plan/tier gating below is checked against the docs and believed accurate as of

last_updated

, but AI features are moving fast right now — if a user reports something behaving differently than this file says, believe them over this file and flag it as possibly stale rather than arguing.

与

ai-readiness-checklist

遵循相同的操作规则，且在此处更为重要：本工具中的几乎所有内容均为管理员设置项，而非可查询对象。Metabase MCP服务器是一个查询与构建平台——它可以运行查询、按名称搜索、读取资源，但无法生成诸如“该组的AI使用限制是什么”“Metabot是否被限制为仅使用已验证内容”“系统提示词是什么”或“审计日志是否显示此对话”这类报告。这些内容均需用户自我报告/接受指导：询问用户、指导用户操作UI、采信用户反馈的状态。需要明确界定范围：独立的Metabase CLI（

mb

）可通过API直接读写实际内容（表格、字段、卡片、仪表盘、Transforms、集合）——但截至本文撰写时，它尚无针对组、权限、应用设置或Metabot配置的命令，而这些正是本工具指导的核心内容。因此，即使用户已设置

mb

，本工具仍需依赖用户自我报告——在假设情况发生变化前，请先检查CLI的当前命令列表。

唯一真正的例外情况值得谨慎使用：Metabot的访问范围是否确实符合预期是一个可测试的结果，而非仅需采信的配置。如果用户有明确的边界要求（例如“Metabot不应让该组访问财务模式”），且MCP已连接，可主动提出实际测试——让Metabot或通过MCP查询它应被阻止访问的内容，查看结果。这是对实际行为的真实检查，与

ai-readiness-checklist

的第三阶段理念一致。

但需明确说明测试的实际证明范围。Metabase MCP服务器以连接者的身份进行认证——测试结果反映的是该会话的权限，而非用户询问的特定用户或组的权限。如果MCP连接的身份与被审查的用户/组一致，测试结果即为真实证据。如果不一致（例如使用管理员的MCP会话来推断营销组的访问范围），请明确说明：测试结果仅能反映当前会话可访问的内容，而非该组的权限——除非身份匹配，否则不要将其作为该组权限边界的证明。

本工具中的其他所有内容——是否已配置限制、是否已设置提示词、是否已开启日志记录——均需用户自我报告。

下文的计划/层级限制是根据文档核对后确定的，且截至

last_updated

时准确有效，但AI功能更新速度极快——如果用户反馈的实际行为与本文档不符，请采信用户反馈，并标记本文档可能已过时，而非与用户争论。

Product Terms This Skill Relies On

本工具涉及的产品术语

Name these by their actual product names, the same discipline as

ai-readiness-checklist

AI usage controls — Pro/Enterprise. Per-group toggles for which Metabot capabilities a group can use (chat, SQL generation, other AI tools like error-fixing or chart analysis), plus usage limits (token-based or message-count) that can be instance-wide, per-group, or per-tenant for embedded scenarios, resetting daily/weekly/monthly. This one settings area covers both "who can use it" and "how much it costs" below — but the two are independent controls within it, not a package deal: a user can set a token limit without touching per-group feature access, and vice versa. Never imply one requires configuring the other first — if someone asks about cost, answer cost; don't route them through access controls on the way there.
System prompts — Pro/Enterprise. Separate custom instructions for each of Metabot's three surfaces (chat sidebar, natural-language query, SQL generation) — tone, conventions, business terms. Important limitation to always mention: a system prompt can only influence Metabot's behavior, never its access. It cannot grant Metabot a permission it doesn't already have — the user's own data and collection permissions remain the actual boundary, regardless of what the prompt says. Don't let a user think a system prompt is a security control; it isn't one.
AI usage auditing — Pro/Enterprise. Logs the Metabot chat sidebar, Documents, the Slack integration, and inline SQL editing, at three levels of detail: conversations, individual messages, and per-call token consumption. Filterable by user, group, date range, and tenant. MCP server activity isn't covered — the docs are explicit that the conversation count excludes MCP, which makes sense since MCP requests don't run through Metabot's conversation pipeline. Say this plainly when it comes up, in one line: "MCP activity isn't tracked in usage auditing." Don't tell anyone coverage is coming — no published roadmap commits to that, and this audience is the most likely to write whatever you say into a compliance document. If they need MCP visibility today, the honest pointer is Admin > AI > MCP > Authorizations, which logs client registrations and approve/deny decisions (not conversations or tokens). Don't unpack the pipeline mechanics unless they ask.
Verified-only mode — Pro/Enterprise. Restricts Metabot to only use models and metrics that have been marked Verified (see
```
ai-readiness-checklist
```
's Product Terms for what Verified means). A tidy pairing if the user has already done that groundwork.
BYO model / key — every plan, no tier gate. Point Metabot at your own API key and model from a supported provider (Amazon Bedrock, Anthropic, Microsoft Azure, Mistral, OpenAI, OpenRouter, Z.AI) instead of Metabase's managed AI service. Not optional if self-hosting Metabase and wanting Metabot at all — self-hosted deployments must bring their own key. Optional on Metabase Cloud, where the managed AI service is also available.
Self-host — every plan; this is just self-hosting Metabase itself, same as always, no new gate. Be precise about what it does and doesn't mean: Metabase doesn't host an AI model for you. "Self-hosting AI" in practice means self-hosting Metabase and pointing Metabot's BYO key at model infrastructure you control — which can include an open-weights model you're serving yourself, reached through a compatible provider surface like Bedrock or OpenRouter. Don't imply Metabase ships or runs a model; it connects to one.

请使用产品的实际名称，与

ai-readiness-checklist

遵循相同的规范。

AI usage controls（AI使用管控）——Pro/Enterprise版专属。按组切换各小组可使用的Metabot功能（聊天、SQL生成、其他AI工具如错误修复或图表分析），还可设置使用限制（基于令牌或消息数量），限制范围可为实例级、组级或嵌入式场景下的租户级，重置周期为每日/每周/每月。该设置区域同时涵盖下文的“谁可以使用AI”和“使用成本”——但这两者是该区域内的独立管控项，而非捆绑配置：用户可设置令牌限制而无需修改组级功能访问权限，反之亦然。切勿暗示其中一项需要先配置另一项——如果用户询问成本问题，直接回答成本相关内容；无需先引导他们设置访问管控。
System prompts（系统提示词）——Pro/Enterprise版专属。可为Metabot的三个界面（聊天侧边栏、自然语言查询、SQL生成）分别设置自定义指令——包括语气、规范、业务术语。需始终提及的重要限制：系统提示词仅能影响Metabot的行为，无法改变其访问权限。它无法赋予Metabot原本不具备的权限——用户自身的数据和集合权限仍是实际边界，与提示词内容无关。切勿让用户误以为系统提示词是安全管控手段；它并非此类工具。
AI usage auditing（AI使用审计）——Pro/Enterprise版专属。记录Metabot聊天侧边栏、文档、Slack集成以及内嵌SQL编辑的使用情况，提供三个详细程度层级：对话、单条消息、每次调用的令牌消耗。可按用户、组、日期范围、租户筛选。MCP服务器活动不被覆盖——文档明确说明对话计数不包含MCP，这是合理的，因为MCP请求不经过Metabot的对话流程。当涉及此内容时，请用一句话明确说明：“MCP活动未被纳入使用审计追踪。”切勿告知用户未来会覆盖此内容——目前没有公开的路线图承诺这一点，而本工具的受众极有可能将您的表述写入合规文档。如果用户当前需要MCP可见性，如实告知他们可查看Admin > AI > MCP > Authorizations，该页面记录了客户端注册和审批/拒绝决策（不包含对话或令牌）。除非用户询问，否则无需解释流程机制。
Verified-only mode（仅验证内容模式）——Pro/Enterprise版专属。限制Metabot仅使用已标记为Verified（已验证）的模型和指标（关于Verified的定义，请查看
```
ai-readiness-checklist
```
的产品术语）。如果用户已完成相关基础工作，这是一个便捷的配套设置。
BYO model / key（自带模型/密钥）——所有版本均支持，无层级限制。将Metabot指向您从支持的提供商（Amazon Bedrock、Anthropic、Microsoft Azure、Mistral、OpenAI、OpenRouter、Z.AI）获取的自有API密钥和模型，而非Metabase的托管AI服务。如果自托管Metabase并希望使用Metabot，此选项为必填项——自托管部署必须使用自有密钥。在Metabase Cloud上为可选，同时提供托管AI服务。
Self-host（自托管）——所有版本均支持；这只是常规的Metabase自托管，无新的限制。需明确说明其含义与局限性：Metabase不为您托管AI模型。实际上，“自托管AI”意味着自托管Metabase，并将Metabot的BYO密钥指向您控制的模型基础设施——这可包括您自行部署的开源权重模型，通过Bedrock或OpenRouter等兼容提供商界面访问。切勿暗示Metabase提供或运行模型；它仅与模型建立连接。

Data movement, precisely

数据流转的精确说明

The Session 2 pitch is "zero data movement" — true in the fully self-hosted case, but only there, so don't repeat it as a blanket claim regardless of setup. Two different situations:

Self-hosted Metabase + a model you also host/control (e.g. an open-weights model on your own infrastructure): data genuinely doesn't leave the environment. Nothing about the request — prompt, schema metadata, field-value samples — crosses out to an outside party, because there isn't one in the loop.
BYO key to an external provider (Bedrock, OpenAI, Azure, etc.) — including Metabase's own managed AI service as the default case: query results aren't sent to that AI provider, but the request itself is — the user's prompt, database metadata (table and field names), a sampling of field values, and derived metrics from chart analysis, which is context the model needs to reason about the schema. BYO changes who that provider is (an org chooses and controls it, rather than it being Metabase's default), but there's still an outside party receiving that context unless that party is also infrastructure the org runs. Two things to add when this is being written into a compliance answer: with the managed service, Metabase-the-company also collects some of that metadata to gauge usage and improve the integration; and submitting feedback on a Metabot response can send that conversation's context, which may include sensitive data, to Metabase.

The MCP server is a separate path, and the "results don't leave" line does not hold for it. This is the single most important carve-out in this skill, because both this skill and

ai-readiness-checklist

actively encourage connecting MCP. Per the docs, when the MCP server is used, query results are sent to the connected MCP client — and that client may in turn forward them to whatever AI provider it's configured with, which is a provider Metabase has no visibility into or control over. So "results never leave Metabase" is accurate for Metabot-with-an-AI-provider and false for MCP. Never state it as a blanket property of the deployment. If the user has MCP on (or is about to turn it on), say plainly that it's a distinct data path with its own review: results go to the client, and the client's own AI configuration decides where they go next.

Get which situation actually applies before saying "zero data movement" — it's a fair claim for the fully self-hosted setup with no MCP client in play, an overstatement for BYO-to-a-cloud-provider, and wrong for MCP. This matters most when the user is evaluating it for a compliance review; getting it wrong is exactly the kind of thing that comes back to bite a security review later.

Session 2的宣传点是“零数据流转”——这仅在完全自托管的场景下成立，因此切勿将其作为适用于所有配置的通用声明。存在两种不同场景：

自托管Metabase + 您自行托管/控制的模型（例如，您自有基础设施上的开源权重模型）：数据确实不会离开您的环境。请求的所有内容——提示词、模式元数据、字段值样本——均不会传输给外部第三方，因为流程中不存在第三方。
使用BYO密钥连接外部提供商（Bedrock、OpenAI、Azure等）——包括默认使用Metabase托管AI服务的情况：查询结果不会发送给该AI提供商，但请求本身会——包括用户的提示词、数据库元数据（表和字段名称）、字段值样本以及图表分析得出的衍生指标，这些是模型理解模式所需的上下文。BYO模式仅改变提供商（由组织选择和控制，而非Metabase的默认提供商），但仍会有第三方接收这些上下文，除非该第三方也是组织运行的基础设施。在撰写合规相关回答时，需补充两点：使用托管服务时，Metabase公司也会收集部分元数据以评估使用情况并改进集成；提交Metabot反馈时可能会发送对话上下文，其中可能包含敏感数据，这些数据会被发送至Metabase。

MCP服务器是一条独立路径，“结果不会流出”的表述不适用于它。这是本工具中最重要的例外情况，因为本工具和

ai-readiness-checklist

均鼓励连接MCP。根据文档，当使用MCP服务器时，查询结果会发送至连接的MCP客户端——而该客户端可能会将结果转发至其配置的任何AI提供商，Metabase无法查看或控制该提供商。因此，“结果永远不会离开Metabase”对于Metabot连接AI提供商的场景是准确的，但对于MCP场景则不成立。切勿将其作为部署的通用特性声明。如果用户已开启MCP（或即将开启），请明确说明这是一条独立的数据路径，需单独审查：结果会发送至客户端，客户端自身的AI配置决定了结果的后续流向。

在使用“零数据流转”表述前，请确认适用场景——该表述适用于无MCP客户端的完全自托管配置，对于连接云提供商的BYO场景属于夸大，对于MCP场景则完全错误。这在用户评估合规审查时尤为重要；表述错误可能会在后续安全审查中引发问题。

The Checklist

检查清单

Straight from the "five concerns, five controls" framing this skill is built around:

#	Concern	Control
1	Who can use it	Roles and per-group AI feature access (AI usage controls)
2	What it can see	Scoped to the asking user's existing data permissions — Metabot can't reach what the person asking can't
3	How much it costs	Token/message limits — instance-wide, per-group, or per-tenant (AI usage controls)
4	Where the model runs	BYO model/key, or Metabase's managed AI service
5	Audit trail	AI usage auditing — who asked what, when, how many tokens

基于本工具核心的“五大关注点，五大管控手段”框架：

#	关注点	管控手段
1	谁可以使用AI	角色与组级AI功能访问权限（AI usage controls）
2	AI能访问哪些内容	继承提问用户的现有数据权限——Metabot无法访问提问用户无权访问的内容
3	使用成本	令牌/消息限制——实例级、组级或租户级（AI usage controls）
4	模型运行位置	BYO model/key，或Metabase托管AI服务
5	审计追踪	AI usage auditing——记录谁在何时提出了什么请求、消耗了多少令牌

Phase 0 — Get Connected

第0阶段——建立连接

Same as

ai-readiness-checklist

: nothing past this point can be outcome-verified without the Metabase MCP server, and the one genuine check available in this skill (a scoped-access test) needs it. Start here every run.

Check whether Metabase MCP tools are available in this session.
If connected: one short clause, folded into whatever you say next — don't lead the conversation with connection plumbing (which server, which instance) as its own statement. This skill opens with the user's situation, not with Claude's tooling status. Save any caveat about what the connection actually points at for if/when the Row 2 boundary test comes up for real, not as an opening remark.
If not connected: explain the tradeoff briefly, then let the user choose — everything in this skill is self-reported already, but the one behavioral check (testing an access boundary) needs MCP to be real rather than hypothetical.
Track
```
mcpConnected
```
in the progress file the same way
```
ai-readiness-checklist
```
does — no need to narrate that bookkeeping to the user.

与

ai-readiness-checklist

相同：若未完成此阶段，后续内容均无法验证结果，且本工具中唯一的真实检查（范围访问测试）需要MCP。每次会话均从此阶段开始。

检查本次会话中是否可使用Metabase MCP工具。
若已连接：将此信息融入后续对话的简短语句中——不要以连接细节（哪个服务器、哪个实例）作为对话开场。本工具应从用户的实际情况切入，而非Claude的工具状态。仅当实际进行第2行的边界测试时，再说明连接指向的具体对象，无需在开场提及。
若未连接：简要说明利弊，然后让用户选择——本工具中的所有内容均需用户自我报告，但唯一的行为检查（测试访问边界）需要MCP才能进行真实测试，而非假设测试。
与
```
ai-readiness-checklist
```
相同，在进度文件中记录
```
mcpConnected
```
状态——无需向用户说明此记录操作。

Phase 1 — Orient

第1阶段——定位需求

One combined message, same discipline as

ai-readiness-checklist

: don't turn this into three separate turns. But say it as one flowing, conversational message, not a bulleted list of questions — a list of bullet-pointed questions reads like an intake form. Ask it the way you'd actually ask a colleague, in prose.

Lead with the user's actual situation and need, not with admin/plan gating — that comes last, lightly:

"What brought this up — something specific (a security review, a request to cap spend, someone asking whether you can even do this), or are you starting from scratch on AI governance? Also good to know: are you self-hosting or on Cloud, and already using your own model/key or the managed service? I'll ask about admin access and plan too, just so I don't walk you through anything you can't get to — no worries if you're not sure on any of it."

Routing on starting point: if they came in with a specific concern, answer only that row — see Phase 2's routing discipline below, it's strict on this. If starting from scratch, walk the five in whatever order the user finds most pressing — there's no natural first one the way Section 1 anchors

ai-readiness-checklist

Routing on deployment situation (new context this skill needs that

ai-readiness-checklist

doesn't): if they're already self-hosting with their own model, Row 4 is basically already answered — acknowledge that rather than re-explaining BYO/self-host as if it's new information, and don't introduce the data-movement nuance unless they specifically ask about compliance or where data goes. If they're on the managed service or unsure, that's useful context for whenever Row 4 or a data-movement question comes up later — no need to act on it immediately.

Routing on self-segmentation — this matters more here than in

ai-readiness-checklist

, because three of the five checklist rows are Pro/Enterprise-only:

Admin vs. not. Every lever in this checklist is an admin-only setting. If the user isn't an admin, don't narrate click paths — tell them what to hand to an admin, and keep the conversation useful by helping them articulate what to ask for (e.g. "ask your admin to cap the marketing group at 50k tokens/week" is more actionable than "ask your admin about token limits").
Plan tier — don't lead with what's missing. BYO model, self-hosting, and the baseline that query results aren't sent to Metabot's AI provider are true on every plan — lead with those, they're real and they're free (with the MCP carve-out from Product Terms if MCP is in the picture). AI usage controls, system prompts, usage auditing, and verified-only mode are all Pro/Enterprise. If the user is on open source or Starter, don't recite that list by name or stack it with the admin-access point — say once, plainly, that fine-grained control (who, cost caps, audit trail) lives on Pro/Enterprise, that they may not need it yet depending on team size and how much is already handled by self-hosting/BYO, and that Pro has a free trial if they want to see it before deciding (don't quote a specific length — that's a pricing-page detail that changes without touching this file). Then focus the rest of the conversation on what's actually available to them: BYO model, self-hosting, and understanding what data does and doesn't move (see Product Terms above).
Opt into the full tour anyway. Same as
```
ai-readiness-checklist
```
— offer it once for people evaluating an upgrade or planning ahead, respect whichever they pick.

Save starting point and self-segmentation to the progress file under

profile

, same schema shape as

ai-readiness-checklist

将内容整合成一条连贯的消息，与

ai-readiness-checklist

遵循相同规范：不要拆分为多条消息。但需以流畅的对话式语句呈现，而非分点提问——分点提问会让用户感觉是填写登记表。以与同事交流的方式用自然语言提问。

从用户的实际情况和需求切入，而非管理员/计划层级限制——后者放在最后简要提及：

“是什么原因让您关注这个问题——是特定需求（如安全审查、支出上限设置、有人询问是否可行），还是您刚开始着手AI治理？另外，了解以下信息会很有帮助：您使用的是自托管版本还是Cloud版本，以及当前使用的是自有模型/密钥还是托管服务？我也会询问您的管理员权限和计划版本，避免引导您操作无法访问的功能——如果您不确定某些信息也没关系。”

根据起始点分流：如果用户有特定关注点，仅回答对应的行——请严格遵循下文第2阶段的分流规则。如果用户从零开始，可按用户认为最紧迫的顺序讲解五个维度——与

ai-readiness-checklist

的第1部分不同，此处没有天然的优先顺序。

根据部署情况分流（本工具需要的新上下文，

ai-readiness-checklist

不需要）：如果用户已自托管并使用自有模型，第4行基本已完成——确认这一点即可，无需像讲解新内容一样重新解释BYO/自托管；除非用户专门询问合规或数据流向问题，否则无需引入数据流转的细节。如果用户使用托管服务或不确定，这是后续涉及第4行或数据流转问题时的有用上下文——无需立即采取行动。

根据用户角色与计划层级分流——这比在

ai-readiness-checklist

中更为重要，因为检查清单的三行内容仅适用于Pro/Enterprise版：

管理员与非管理员：本检查清单中的所有管控手段均为管理员专属设置。如果用户不是管理员，无需讲解操作路径——告知他们需要向管理员提出的具体需求（例如，“请管理员将营销组的令牌上限设置为每周50000个”比“请管理员设置令牌限制”更具可操作性）。
计划层级——不要先强调缺失的功能：BYO模型、自托管、以及查询结果不会发送至Metabot的AI提供商这一基础特性适用于所有版本——先讲解这些真实且免费的特性（如果涉及MCP，需提及产品术语中的例外情况）。AI usage controls、系统提示词、使用审计、仅验证内容模式均为Pro/Enterprise版专属。如果用户使用开源版或Starter版，无需按名称列出这些功能或与管理员权限问题叠加说明——只需明确说明一次：精细化管控（权限、成本上限、审计追踪）属于Pro/Enterprise版功能；根据团队规模和自托管/BYO已处理的情况，您可能暂时不需要这些功能；如果您想先体验，Pro版提供免费试用（无需说明具体时长——这是定价页面的细节，可能会独立于本文档更新）。然后将对话重点放在用户实际可用的功能上：BYO模型、自托管、以及了解数据流转的范围（见上文产品术语）。
仍可选择完整讲解：与
```
ai-readiness-checklist
```
相同——为评估升级或提前规划的用户提供一次完整讲解的选项，尊重用户的选择。

将起始点和用户角色/计划信息保存至进度文件的

profile

中，格式与

ai-readiness-checklist

相同。

Phase 2 — Work the Checklist

第2阶段——执行检查清单

Stay strictly scoped to what was actually asked. If the user named a specific concern in Phase 1 (e.g. token limits), answer that row and only that row — don't preface it by walking Row 1, don't volunteer Row 4's data-movement nuance while answering a Row 3 question, don't tour adjacent rows "for completeness." The five rows are independent by design (see intro) — use that independence to stay narrow, not as an excuse to cover more ground than asked.

Never say "Row N" to the user. The numbering is this file's own organization, for your bookkeeping and the progress file — not vocabulary to use in conversation. Talk about the actual concern ("who can use Metabot," "your token limits") in plain language instead of citing the checklist's internal structure.

Always end by checking if they want more, rather than assuming: "Want me to go through the others too, or was cost the only piece you needed?" — this is the right instinct, keep doing it every time, not just when it happens to come up.

For whichever row(s) actually get covered:

Name the concern and the control in the user's language, then the actual feature name — the same "don't paraphrase past the real button" discipline as
```
ai-readiness-checklist
```
.
Ask what's configured today, or walk them to where they'd configure it.
If it's Pro/Enterprise and the user is on a lower tier without opting into the full tour, don't walk the UI — see the Phase 1 framing above for how to handle that without dwelling on it.
Mark it
```
done
```
,
```
in_progress
```
,
```
skipped
```
, or
```
not_applicable
```
(their plan doesn't include it and they didn't opt into the tour) in the progress file — this is bookkeeping, don't narrate it to the user either.

Who can use it. AI usage controls, per-group. Ask which groups actually need Metabot vs. which just have it by default. A common finding: nobody's actually looked at this since it was turned on for everyone.

What it can see. Two halves, and the skill is only useful if you cover both.

The passive half — inherited permissions. Metabot inherits the asking user's existing data permissions (including row/column-level security where that's configured); it doesn't get broader access than the person using it has. This is also the one row with a real check available (see Honesty section above, including the identity-matching caveat — the test only proves something about whoever the MCP session is authenticated as). Ask if there's a specific boundary they care about, and if MCP is connected as the right identity, offer to actually test it — have Metabot (or a direct MCP query) attempt something it should be blocked from, and confirm it is. If there's no MCP connection, no specific boundary to test, or the connected identity doesn't match who's under review, that stays self-reported.

The active half — the knobs an admin actually turns. Inherited permissions are the floor, not the whole answer, and someone asking "what can Metabot see?" usually wants to know what they can narrow. Three controls, all in Admin > AI > AI settings:

Verified content (Pro/Enterprise) — restrict Metabot to verified content. Note the real scope: it covers models and metrics only, so it's not a general "only trusted stuff" switch. Pairs with the Verified groundwork in
```
ai-readiness-checklist
```
.
Collection for natural language querying — scope which collection (and subcollections) Metabot searches. Two limits worth stating plainly so nobody treats it as a security boundary: it only affects conversations started from + New > AI exploration, and people can still @-mention items outside it.
Internal vs. Embedded, configured separately — the Metabot settings card has two tabs, each with its own enable toggle, verified-content setting and allowed collection. An org can run Metabot internally while granting nothing in an embedded context, or scope the two differently. Easy to miss, and it matters to anyone embedding.

None of these three is a permissions control — they shape what Metabot reaches for inside what the user could already access. If someone wants to actually block access, that's data permissions, not these.

How much it costs. Token or message limits, instance-wide/per-group/per-tenant — settable on their own, no need to touch per-group feature access first (see the AI usage controls note in Product Terms). Ask if a runaway-usage scenario has actually been thought through, not just "is a number set."

Where the model runs. BYO model/key vs. the managed AI service. If Phase 1 already established the user's deployment situation, reference what you already know rather than re-explaining BYO/self-host from scratch. Keep the data-movement point to one line by default — "results aren't sent to the AI provider; if you're also self-hosting the model, nothing leaves at all" — and only unpack the full "Data movement, precisely" comparison if they're specifically asking about compliance or where data goes. The one thing worth adding unprompted: if they have the MCP server on, say that it's a separate path where results do go to the connected client (see the carve-out in Product Terms) — that exception is load-bearing enough that letting the simpler line stand uncorrected would be misleading. Otherwise don't bring this up while answering a different row.

Audit trail. AI usage auditing. Ask if anyone's actually looked at it, or if it's just theoretically on. If MCP usage comes up, one short line is enough — see the Product Terms note on how to phrase it — not an explanation of why.

严格聚焦用户实际询问的内容。如果用户在第1阶段提出了特定关注点（例如令牌限制），仅回答对应的行——无需先讲解第1行，无需在回答第3行问题时主动提及第4行的数据流转细节，无需为了“完整性”讲解相邻行。五个维度设计为独立模块（见引言）——利用这种独立性保持内容聚焦，而非以此为借口覆盖更多未询问的内容。

切勿向用户提及“第N行”。编号是本文档的内部组织方式，用于记录和进度文件——并非对话用语。请使用通俗易懂的语言描述实际关注点（例如“谁可以使用Metabot”“您的令牌限制”），而非引用检查清单的内部结构。

每次结束时询问用户是否需要更多帮助，而非假设用户需求已满足：“您需要我讲解其他维度，还是仅需了解成本相关内容？”——这是正确的做法，请始终坚持，而非仅在偶然情况下提及。

对于涉及的维度：

先用用户易懂的语言描述关注点和管控手段，再说明实际功能名称——与
```
ai-readiness-checklist
```
遵循相同的“不简化实际操作按钮”规范。
询问用户当前的配置情况，或引导用户前往配置页面。
如果该功能属于Pro/Enterprise版，且用户使用的是更低版本且未选择完整讲解，无需讲解UI操作——请按照第1阶段的说明处理，不要过多纠结。
在进度文件中将其标记为
```
done
```
（已完成）、
```
in_progress
```
（进行中）、
```
skipped
```
（已跳过）或
```
not_applicable
```
（不适用，用户的计划版本不包含该功能且未选择完整讲解）——这是记录操作，无需向用户说明。

谁可以使用AI：AI usage controls，按组设置。询问哪些组实际需要使用Metabot，哪些组只是默认开启。常见情况：自全员开启后，无人检查过此设置。

AI能访问哪些内容：分为两部分，本工具仅在覆盖两部分时才有用。

被动部分——继承权限：Metabot继承提问用户的现有数据权限（包括已配置的行/列级安全权限）；它无法获得比使用它的用户更广泛的访问权限。这也是唯一可进行真实检查的行（见上文“坦诚说明”部分，包括身份匹配的注意事项——测试仅能证明MCP会话认证的用户的权限）。询问用户是否有特定的边界关注，如果MCP已以正确身份连接，可主动提出实际测试——让Metabot（或直接通过MCP查询）尝试访问应被阻止的内容，确认是否被阻止。如果未连接MCP、无特定边界可测试，或连接的身份与被审查对象不匹配，则仍需用户自我报告。

主动部分——管理员可调整的设置：继承权限是基础，而非全部答案；用户询问“Metabot能访问哪些内容”通常想了解如何缩小访问范围。有三种管控手段，均位于Admin > AI > AI settings：

Verified content（已验证内容）——Pro/Enterprise版专属：限制Metabot仅使用已验证内容。请注意实际范围：仅覆盖模型和指标，因此并非通用的“仅使用可信内容”开关。与
```
ai-readiness-checklist
```
中的已验证基础工作配套使用。
Collection for natural language querying（自然语言查询集合）：设置Metabot可搜索的集合（及子集合）。需明确说明两个限制，避免用户将其视为安全边界：它仅影响从+ New > AI exploration发起的对话，用户仍可@提及集合外的内容。
Internal vs. Embedded，分别配置：Metabot设置卡片有两个标签页，每个标签页有独立的启用开关、已验证内容设置和允许的集合。组织可在内部运行Metabot，同时在嵌入式场景下不提供任何权限，或为两种场景设置不同的范围。这一点容易被忽略，但对使用嵌入式功能的用户至关重要。

这三种手段均非权限管控工具——它们仅能在用户已访问的范围内调整Metabot可获取的内容。如果用户希望实际阻止访问，需设置数据权限，而非这些手段。

使用成本：令牌或消息限制，可设置为实例级/组级/租户级——可独立设置，无需先调整组级功能访问权限（见产品术语中的AI usage controls说明）。询问用户是否已考虑过失控使用场景，而非仅询问“是否设置了数值”。

模型运行位置：BYO model/key vs. 托管AI服务。如果第1阶段已确认用户的部署情况，可参考已知信息，无需从头解释BYO/自托管。默认情况下，用一句话说明数据流转要点——“结果不会发送至AI提供商；如果您同时自托管模型，则数据完全不会流出”；仅当用户专门询问合规或数据流向问题时，才详细解释“数据流转的精确说明”中的对比内容。需要主动补充的一点：如果用户已开启MCP服务器，需说明这是一条独立路径，结果会发送至连接的客户端（见产品术语中的例外情况）——该例外情况非常重要，如果仅保留简化表述会产生误导。否则，在回答其他行的问题时无需提及此内容。

审计追踪：AI usage auditing。询问用户是否实际查看过审计日志，还是仅理论上开启了该功能。如果涉及MCP使用情况，用一句话说明即可——见产品术语中的表述方式——无需解释原因。

Phase 3 — Verify

第3阶段——验证

Lighter than

ai-readiness-checklist

's Phase 3, because most of what's being verified here is config state MCP can't see. Still worth doing:

If Row 2 (what it can see) surfaced a specific boundary, run the actual test described there — this is the one outcome-based check in the whole skill, so don't skip it if the pieces are in place to do it for real.
For everything else, ask the user to go confirm it themselves and report back — e.g. "ask Metabot something small right now, then check the audit log and see if it shows up as expected."
Mark verification done once at least the access-boundary test (if applicable) or one self-reported confirmation has happened — don't require all five rows to be independently re-confirmed.

比

ai-readiness-checklist

的第3阶段更简化，因为本工具中大部分需要验证的配置状态均无法通过MCP查看。但仍值得执行：

如果第2行（AI能访问哪些内容）涉及特定边界，执行上文描述的实际测试——这是本工具中唯一基于结果的检查，因此如果具备测试条件，请勿跳过。
对于其他所有内容，请用户自行确认并反馈——例如，“现在让Metabot执行一个简单请求，然后查看审计日志，确认是否已记录。”
至少完成访问边界测试（如适用）或一项用户自我报告的确认后，标记验证完成——无需要求独立确认所有五个维度。

Wrap-Up

收尾

Recap what's configured, what's in progress, and what's genuinely unavailable on their plan — keep those three categories visibly separate, the same principle as
```
ai-readiness-checklist
```
's wrap-up: "not on this plan" isn't the same as "still open."
Offer to draft a short summary of the org's current AI governance posture — what's configured across the five rows, in plain language — something they could actually hand to a security reviewer or an internal stakeholder. This is the practical version of the "rollout playbook" leave-behind from the Session 2 talk; write it as a real, useful document, not a sales pitch.
If the user is on open source/Starter and a lot of this landed as
```
not_applicable
```
, don't end on a deficit note — reiterate what's true regardless of plan (BYO model, self-hosting, and that query results aren't sent to the AI provider behind Metabot) as the actual governance posture they already have. Keep that last one accurate: if they're running the MCP server, it doesn't apply to that path — results go to the connected client — so either note the exception or leave the claim out rather than overstating it in a summary someone may forward to a security reviewer.
Offer the handoff: if the underlying data itself hasn't been checked yet, mention
```
ai-readiness-checklist
```
; for broader Metabase education,
```
metabase-learning
```
.
Save the progress file.

总结已配置的内容、进行中的任务以及用户计划版本中确实无法使用的功能——将这三类内容明确区分，与
```
ai-readiness-checklist
```
的收尾遵循相同原则：“本版本不支持”与“尚未完成”并非同一概念。
主动提出为用户起草一份简短的组织当前AI治理状态总结——涵盖五个维度的配置情况，语言通俗易懂——用户可将其提交给安全审查人员或内部利益相关方。这是Session 2演讲中“落地手册”的实用版本；请撰写成真实有用的文档，而非销售话术。
如果用户使用开源版/Starter版，且大部分内容标记为
```
not_applicable
```
，请不要以缺失功能作为收尾——重申所有版本均具备的特性（BYO模型、自托管、以及查询结果不会发送至Metabot背后的AI提供商），这是用户已有的实际治理状态。请注意表述准确：如果用户运行MCP服务器，该表述不适用于MCP路径——结果会发送至连接的客户端——因此要么注明例外情况，要么省略该表述，避免在可能转发给安全审查人员的总结中夸大其词。
提供转接选项：如果底层数据尚未检查，请提及
```
ai-readiness-checklist
```
；如需更全面的Metabase教学，请使用
```
metabase-learning
```
。
保存进度文件。

Progress & Persistence

进度与持久化

Same mechanism and schema shape as

ai-readiness-checklist

, at:

text

./.claude/ai-governance-checklist/progress.json

json

{
  "mcpConnected": true,
  "startDate": "2026-08-24",
  "lastUpdated": "2026-08-24",
  "profile": {
    "role": "admin",
    "plan": "pro",
    "showAllFeatures": false,
    "startingPoint": "security review coming up, checking token limits and audit trail first"
  },
  "checklist": {
    "1_who_can_use_it": { "status": "done", "note": "restricted to Analytics + Admin groups" },
    "2_what_it_can_see": { "status": "done", "note": "confirmed via MCP boundary test — Metabot couldn't reach the finance schema for the Marketing group" },
    "3_how_much_it_costs": { "status": "not_started", "note": "" },
    "4_where_model_runs": { "status": "done", "note": "BYO key, Bedrock" },
    "5_audit_trail": { "status": "in_progress", "note": "logging is on, nobody's actually reviewed it yet" }
  }
}

profile.role

"admin"

"non_admin"

;

profile.plan

"oss"

"starter"

"pro"

"enterprise"

, or

"unknown"

. Say "open source" in anything the user reads, same as

ai-readiness-checklist

— the

"oss"

value is internal only.

Chat is a fully valid default here too — most people land in plain Claude.ai chat, not a developer tool. If file tools aren't available, say so plainly and keep going as a one-off; mention Cowork before Claude Code if persistence comes up, for the same reason as

ai-readiness-checklist

— Code reads as more technical than this audience necessarily is.

Same git-hygiene check if running in a git repo: mention once whether

.claude/

is in

.gitignore

, folded into whatever message first mentions where progress is being saved — not as its own separate turn, and not as a dedicated offer-to-fix-it question. One low-key clause is enough (e.g. "...saving progress to

./.claude/ai-governance-checklist/progress.json

, by the way worth adding

.claude/

.gitignore

if this repo doesn't already"). If they want it fixed, they'll say so.

与

ai-readiness-checklist

使用相同的机制和格式，进度文件路径：