业务人员自交付应用：权限与预算怎么管

让业务人员自己搭建应用，能解决需求排队问题，但会带来新的管理问题：他们能访问哪些数据、能调用哪些资源、成本算谁的。这些问题如果没有事先约定，自助建设很快会从效率优势变成管理负担。关键在于把边界定义清楚，而不是限制建设本身。

权限边界要前置定义而不是事后收紧

自助建设最容易出的问题是权限蔓延。业务人员为了完成需求，会申请尽可能大的数据访问范围，而审批者往往不了解具体用途，倾向于放行。

可行的做法是按应用场景预定义权限模板。把常见的应用类型与所需的数据范围对应起来，业务人员选择场景即获得对应权限，超出模板的范围需要单独申请并说明用途。

模板的设计需要业务与数据管理部门共同完成。技术团队无法判断某类业务需要哪些字段，数据管理部门也无法判断业务的实际需求，两者配合才能定出合理的范围。

数据访问要区分读取与使用

业务人员搭建应用时会接触到数据，但「能读」与「能用于这个用途」是两件事。授权时应明确用途限制，而不是给出无条件的读取权。

具体可以通过几种方式实现。字段级授权，只开放完成该任务必需的字段；结果级授权，允许访问统计结果但不允许导出明细；脱敏授权，敏感字段以脱敏形式提供。选择哪种方式取决于业务需求与数据敏感度的组合。

使用过程同样需要约束。数据不能被复制到其他用途，应用的输出范围要有界定。这些要求需要通过技术手段落实，仅靠承诺难以保证。

预算归属要明确

自助建设带来大量的资源消耗：模型调用、存储、算力。如果不明确成本归属，会出现两种极端：要么集中承担导致总量失控，要么完全切割导致业务方不敢用。

较合理的做法是按部门核算，同时设定额度上限。额度内自主使用，超出部分需要说明理由并申请。这样既保留了自助的灵活性，也让成本可见。

成本可见本身就有约束作用。当业务方能看到自己搭建的应用消耗了多少资源，会自然做出更合理的取舍，比如选择更小的模型处理简单任务。