AI 生成应用很快，但如果应用使用的是构建时复制的数据快照，业务人员看到的内容可能已经过期，数据权限也容易与原系统脱节。Amazon Quick 的 Live Data in Apps 改变了这一模式：应用在运行时查询受治理的 Quick Sight 数据集，并以当前查看者的身份执行查询，让行级安全和列级安全继续生效。
从“把数据装进应用”转向“让应用访问数据”
静态快照模式通常在构建或发布应用时复制数据。它实现简单，却会带来三个问题：
- 时效性有限：源数据更新后，应用需要重新构建或刷新快照。
- 权限容易固化：构建者能看到的内容，可能被无意间打包给所有用户。
- 治理链路断裂：原数据集中的行级、列级规则不一定自然延续到副本。
Live Data 的关键不是“刷新得更频繁”，而是根本不把构建时快照当作应用的数据边界。用户打开应用并发起查询时，应用直接读取受治理的数据集，因此展示的是查询当下可用的数据。
这尤其适合销售看板、库存查询、运营异常分析等场景：数据持续变化，而且不同人员允许看到的记录和字段并不相同。
查看者身份决定查询结果
Live Data 查询以正在查看应用的人为执行主体。这意味着安全控制不是只在发布时检查一次，而是在每次查询时按查看者重新计算。
假设同一个销售应用连接到订单数据集：
- 华东区域经理只能看到华东订单；
- 华南区域经理只能看到华南订单；
- 普通销售人员看不到
gross_margin等敏感列； - 财务人员可以查看利润字段，但仍受组织范围限制。
这里要区分三层权限：
- 应用访问权：用户能否打开已发布的应用。
- 数据集访问权：用户能否查询应用背后的数据集。
- 数据可见范围：行级安全决定能看到哪些记录，列级安全决定能看到哪些字段。
分享应用并不等于分享全部数据。上线前应使用多个真实角色验证结果，而不能只用应用构建者或管理员账户测试。
用自然语言描述应用，而不是绕过治理
可以在 Amazon Quick 中使用自然语言描述要构建的界面和交互。下面是一段可按实际字段修改的构建提示词：
创建一个销售运营应用，连接到受治理的 sales_orders 数据集，并使用实时数据而不是构建时快照。
页面包含：
1. 本月订单金额、订单数量和平均客单价；
2. 按区域和产品类别分组的趋势图；
3. 可按日期、区域和销售负责人筛选的订单明细表；
4. 一个“异常订单”视图，显示金额超过 100000 且状态仍为 pending 的订单。
所有查询都必须以当前查看者身份执行。不要在应用中复制或硬编码用户可见区域，也不要推断或展示数据集中对当前用户隐藏的字段。无数据时显示明确的空状态。
字段名、阈值和页面结构需要替换成自己的业务定义。自然语言负责表达应用意图，真正的数据访问边界仍应配置在受治理的数据集上，而不是只写在提示词里。
本地模拟“按查看者查询”
下面的示例不是 Amazon Quick 的官方 API，而是一个可直接运行的本地模型，用来帮助团队理解运行时身份、行级过滤和列级隐藏如何共同工作。生产环境应由 Quick 和 Quick Sight 的身份与治理机制执行这些控制，不能信任客户端随意提交的用户标识。
将以下内容保存为 live_data_demo.py：
from http.server import BaseHTTPRequestHandler, HTTPServer
import json
USERS = {
"alice": {"region": "east", "can_view_margin": False},
"bob": {"region": "south", "can_view_margin": True},
}
ORDERS = [
{"id": 101, "region": "east", "amount": 120000, "gross_margin": 24000},
{"id": 102, "region": "east", "amount": 38000, "gross_margin": 5700},
{"id": 103, "region": "south", "amount": 86000, "gross_margin": 17200},
]
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path != "/orders":
self.send_error(404)
return
username = self.headers.get("X-Demo-User")
viewer = USERS.get(username)
if viewer is None:
self.send_error(403, "Unknown viewer")
return
rows = []
for order in ORDERS:
if order["region"] != viewer["region"]:
continue
visible = dict(order)
if not viewer["can_view_margin"]:
visible.pop("gross_margin", None)
rows.append(visible)
body = json.dumps({"viewer": username, "rows": rows}).encode()
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
HTTPServer(("127.0.0.1", 8080), Handler).serve_forever()
启动服务并分别模拟两个查看者：
python3 live_data_demo.py
在另一个终端执行：
curl -s -H 'X-Demo-User: alice' http://127.0.0.1:8080/orders
curl -s -H 'X-Demo-User: bob' http://127.0.0.1:8080/orders
Alice 只能收到 east 区域的数据，而且结果中没有 gross_margin；Bob 只能收到 south 区域的数据，但可以看到利润字段。这正是应用发布前需要覆盖的权限测试矩阵。
发布前不要只检查页面是否能打开
实时查询让数据更及时，也把数据源性能和治理配置带入了应用运行路径。建议发布和分享前逐项确认：
- 应用明确使用实时数据，而不是构建时快照；
- 查询确实以当前查看者身份执行，没有退化为共享服务账户；
- 至少用两个权限范围不同的读者验证行级规则；
- 用可见列不同的角色验证列级规则；
- 未授权用户得到拒绝或空结果，而不是部分敏感数据；
- 常用筛选和聚合查询的延迟可以接受；
- 数据集字段变化后，应用能被及时回归测试；
- 分享范围、数据集授权范围和审计要求保持一致。
Live Data 的价值不只是让 AI 生成的应用“看到最新数字”，更重要的是让这些应用继续生活在既有的数据治理边界内。采用时应把身份传递和权限测试视为核心设计，而不是发布后的补充检查。