Amazon Quick推出Live Data in Apps：AI生成应用可实时查询受治理数据集
Amazon Quick的AI构建应用现在能在每次打开时实时查询Quick Sight数据集，查询以查看者身份执行，行级和列级安全自动生效。
AI解读：关键变化在权限执行方式：查询以查看者本人身份运行，已有的行级安全和列级安全自动套用，查看者只看得到自己有权看的行。数据管理员不需要学新的权限模型。
使用有硬性门槛——查看者必须是已认证的Quick用户，不支持匿名或公开访问；每个查看者首次使用某个数据集时要单独同意。这些限制把实时查询圈在了企业内部。
当前支持SPICE和Direct Query两种数据集模式，但同一条数据源可以混用，不同数据源的Direct Query数据集不能放进同一个应用。查询结果过大时应用会提示收窄查询，而不是返回截断数据。
对一线团队来说，好处是不用等IT排期。文中销售负责人的例子此前要花一个月拉数据，现在自己用自然语言描述应用、让agent找数据集写SQL，再分享给同事即可。
Amazon Quick推出Live Data in Apps，让AI生成的应用在每次打开时实时查询受治理的Quick Sight数据集，而不是依赖构建时固化的静态快照。
据AWS Machine Learning博客介绍，此前Quick Apps已经能从连接器、内容源和网络搜索引入实时数据，但受治理的结构化数据集——即存放业务指标的SPICE和Direct Query表——无法被应用实时查询，应用里显示的数字是agent构建时烤进去的快照，发布那一刻就冻结了。
新功能的核心是查询以查看者本人的身份执行。因此每个用户看到的数据，正是他被允许看到的那部分，已有的行级安全和列级安全规则自动生效。
构建流程：自然语言描述，agent发现数据集并写SQL
在Amazon Quick中，构建者从左侧导航选择Apps，在提示框中用自然语言描述想要的应用。示例提示为：“创建一个应用，列出本季度和未来 6 个月的客户续约。当我选择某个客户时，我想看到SaaS Sales数据中的客户收入和利润率。”
agent会自行发现相关的SaaS Sales数据集和Customer Renewals数据集，编写SQL，并逐一按名称请求构建者批准每个数据集。文中示例因为发现了两个数据集，所以分别请求了两次同意。批准后agent构建应用并加载预览。
构建者可以快速迭代，逐步验证每个功能。示例中销售负责人最终搭出了一个完整的续约工作流，包含筛选器；选择某笔交易时显示该笔交易收入，并可向客户发送关于该交易的邮件。之后该负责人还用提示把企业产品战略文档和企业数据结合起来，在弹窗中生成AI摘要，判断是否推进交易、是否提供额外折扣等。
查看流程：每人看到的数据取决于自己的权限
应用发布后，查看者首次访问时会被提示为应用访问数据集提供同意。每个用户看到的是同一个应用，但数据按各自的行级和列级安全规则过滤。
文中用两位区域销售经理演示：一位只有AMER区域权限，看到的只有AMER数据；另一位同时有EMEA和AMER权限，看到两个区域的数据。如果用户对底层数据集没有权限，应用会显示访问错误。
前置条件与已知限制
使用Live Data in Apps需要满足以下条件：数据集已创建，可以带或不带行级安全和列级安全；支持SPICE内存模式和Direct Query模式，Direct Query支持的数据源有单独列表。每个查看者首次使用某个数据集时必须单独同意，构建者在构建过程中批准数据集。查看者必须是已认证的Quick用户，不支持匿名或公开访问，这一限制在多层强制执行。构建者和查看者的最低角色要求是Reader Pro（Professional）。
另外还有若干操作细节：同一数据源的SPICE或Direct Query数据集可以在同一个应用中使用，但来自不同数据源的Direct Query数据集不能放在同一个应用里。重命名或删除列需要重建应用中的查询。构建阶段有初始行数限制，需要让构建agent在应用加载时通过多次分页调用取回全部数据。数据集发现时agent会拉取相关列，如果漏掉某列可以直接在提示中指定。如果构建者的行级安全返回空数据，应用无法用该数据集构建，需要联系应用所有者或安全团队取得行级访问权限。如果agent没有发现想要的数据集，可以缩小搜索范围或直接提供数据集名称或ID。
查询保护和数据权威
因为查询是实时运行的，应用始终显示数据集中的最新数据。如果数据集使用SPICE，刷新数据集会更新应用显示的数据；如果使用Direct Query，则无需刷新。
查询和结果大小设有保护措施：如果查询返回的数据超过传输容量，应用会显示“收窄查询”的明确提示，而不是交付截断或不完整的数据。用户可以修改提示获取聚合数据，或让应用实现分页。
按照博客的说法，数据权威保留在一处：Quick Sight查询引擎针对每个查看者的身份强制执行授权，因此应用、前端和代理都不处理访问决策。每次查询都在服务端重新验证权限，并处于每个查看者的同意门槛之后。