ARTICLE · 1215514
商业地产做 AI,最难的不是技术,而是业务规则
商业地产做 AI,最难的不是技术,而是业务规则最近，商业地产行业聊 AI，越来越多地从“用 AI 写文案、做报表”，转向一个更实际的问题： 能不能让 AI 直接连接企业业务系统，让管理层张嘴就能问经营数据，让运营和招商少做一些重复劳动？ 比如，运营总监问：“上周哪些楼层销售额下降了，原因是什么？” 招商负责人问：“哪些商户即将到期，哪些品牌值得重点跟进？” 管理层问：“本月租金收缴为什么没有达到预算？” 这些需求，我完全理解。 作为商业地产公司的 IT，我太清楚业务人员每天要经历什么：登录不同系统、导出 Excel、合并数据、核对口径，再把结果整理成一份经营分析报告。很多时间消耗在数据准备上，而不是经营判断上。 所以，让 AI 直接连接 ERP、合同系统、招商系统和经营数据平台，确实有吸引力。 但我真正担心的，不是技术上能不能接通，而是接通之后，AI 查到的数据是否准确、看到的信息是否合规，以及它给出的结论究竟由谁负责。 AI 接入业务系统，难的不是打通接口，而是建立一套可信、可控、可追责的业务机制。 在我看来，至少要先过五道关。 我在工作中经常遇到一种需求：“能不能把 AI 接进系统，让它自动分析经营情况？” 问题是，“分析经营情况”到底指什么？ 是找出销售额下降的商户，还是识别租售比异常的铺位？是统计即将到期的合同，还是预测未来一个月的租金收缴风险？ 这些事情看似接近，背后的数据、规则和实现方式却完全不同。 例如，运营部门希望 AI 找出经营不佳的商户。如果只看销售额，可能会把新开业、正在装修或受季节性影响的商户也列入异常名单。 更合理的需求应该是： 每周识别连续数周销售额下降、租售比持续恶化的商户，排除新开业及特殊经营状态，生成异常清单并交给对应运营人员核实。 目标明确了，才知道需要哪些数据、采用什么规则、如何判断结果是否有效。 而且，并不是所有问题都值得用 AI 解决。固定口径的经营报表，用 BI 就可能足够；跨系统数据不通，首先要解决的可能是数据集成；只有当自然语言理解、复杂信息整理或辅助分析确实能够创造价值时，才有必要引入大模型。 不要先问 AI 能做什么，要先问业务究竟卡在哪里。 商业地产有一类数据，尤其需要谨慎处理：租户经营数据与合同数据。 单看一份销售报表，可能只是普通的经营信息；单看一份合同台账，也只是租赁面积、租金和合同期限。 但当两者关联起来，就能计算租售比、判断租金承受能力，甚至为后续租金谈判提供参考。 如果再叠加租金减免、历史谈判记录等信息，这些数据的敏感程度就更高了。 问题在于，AI 一旦获得了数据库访问权限，究竟能看到什么？ 招商经理、楼层运营人员和项目总经理的权限本来就不应该完全相同。不能因为 AI 需要回答问题，就把所有数据一股脑交给它。 我不赞成为了快速验证效果，直接给 AI 一个权限过大的数据库账号。 更合理的方式，是通过受控的数据视图或查询服务，让 AI 只能访问完成任务所需的字段和指标，同时落实独立账号、权限隔离、查询日志和随时撤销访问的机制。 这里还有一个容易被忽略的问题：只读不等于安全。 只读权限可以降低数据被修改的风险，却不能阻止敏感信息被不当读取，也不能避免查询结果被复制到不合适的群聊或文档里。 因此，权限控制不能只看 AI 能不能改数据，更要看它能看什么、能把结果交给谁，以及整个过程能否追溯。 这是商业地产 AI 最容易出现隐性错误的地方。 一个商铺可能经历多次租户更换，一个品牌可能经营多个铺位，一份合同可能跨越多个经营周期。 如果 AI 没有正确理解合同有效期、商户与铺位的对应关系，就可能把历史销售额与当前租赁面积错误关联，最终算出一个看似合理、实际却有偏差的坪效。 更麻烦的是，这个错误可能继续进入楼层排名、业态分析和经营决策。 商业地产还有大量容易混淆的业务口径： 合同租金、应收租金和实收租金不是一回事。 建筑面积、租赁面积和计租面积不能随意替换。 销售额、租售比和坪效都需要明确统计范围与计算规则。 这些定义不能指望 AI 自己猜对。 在我的理解中，AI 可以负责理解问题、组织分析和解释结果，但具体指标应该由经过验证的数据服务统一计算，业务规则则由企业明确维护。 如果管理层问“哪个楼层的坪效最高”，AI 应该调用统一的坪效指标，而不是临时拼接字段、现场发明一套算法。 当数据缺失、统计口径冲突或关联关系不明确时，也应该明确提示，而不是为了回答而强行得出结论。 大模型能够理解语言，不代表它天然理解一家购物中心的经营规则。 很多企业验证 AI 时，使用的都是相对简单的数据和测试环境。演示过程中，查询流畅、回答迅速，很容易让人产生一种感觉：技术已经成熟，可以直接上线。 但测试环境里的成功，不代表生产环境里没有风险。 商业地产核心系统承载着日常业务。营业高峰期，租户数据处理、合同操作、收缴核对等工作都需要稳定运行。如果 AI 随意执行大范围查询，即使没有修改任何数据，也可能消耗大量数据库资源，影响正常业务。 因此，我更倾向于采用分层访问： 有条件的企业优先使用经过治理的数据仓库或分析平台；暂时没有数据平台的企业，可以根据现有架构考虑只读副本、数据库视图或受控查询服务。 同时，要明确查询频率、执行时间、返回行数和高峰时段的限制，避免 AI 为了回答一个问题，就对生产系统造成不必要的压力。 还有一点很重要：不要让自然语言请求直接变成一条可以自由执行的 SQL。 AI 可以理解问题、选择允许使用的查询工具并解释结果；真正执行查询的服务，则负责校验权限、约束参数和控制资源消耗。 这不是增加技术复杂度，而是把不可预测的自然语言交互，限制在可管理的执行范围内。 假设前面四关都过了。 现在，AI 每天自动分析商户销售数据，发现某个楼层有三家商户连续数周销售额下降，并生成异常清单，推送给对应运营经理。 技术上，项目已经跑通了。但接下来，才是真正考验业务机制的地方。 销售额下降，是客流减少、商户经营不善，还是数据上报不完整？是否需要联系商户？是否需要调整营销资源？谁来跟进，多久给出反馈？ 这些都不是生成一份报告就能解决的。 因此，在项目设计阶段明确异常处理流程：AI 负责识别异常、整理数据依据、生成待办并推送给责任人；业务人员负责核实原因、判断风险和制定措施；处理结果再回流系统，作为后续分析和规则优化的依据。 涉及合同变更、租金调整、财务处理等重要事项，则必须保留相应的人工确认和审批机制。 这里还有一个容易被忽略的问题：AI 的建议如果没有人接手，就不应该被视为任务已经完成。 所以，项目验收除了检查查询准确性，还要看异常是否被及时核实、责任人是否完成处理，以及整个过程能否追溯。只有这些环节真正跑通，AI 才算进入了业务流程，而不只是停留在技术演示阶段。 如果现在让我负责推进商业地产 AI 项目，我不会一开始就建设一个连接所有系统的“全能助手”。 我更愿意从商户经营异常识别、合同到期预警这类边界清晰的场景入手，先把数据口径、业务规则和访问权限理顺，再逐步扩大应用范围。 这也是我对商业地产 IT 角色的一点理解：过去，我们更多是在解决系统之间如何连接；到了 AI 时代，还需要进一步回答，系统中的数据应该如何被理解、业务规则应该如何被执行，以及技术能力应该如何嵌入实际经营。 接口打通只是技术起点，业务理解才是应用的分水岭。 对商业地产企业来说，AI 不应该只是一个新的技术入口，而应该成为现有经营体系的一种能力延伸。 而对 IT 来说，真正值得投入的工作，不是让 AI 接入尽可能多的系统，而是找到那些长期消耗业务人员、又能够被可靠解决的问题，并把解决方案做扎实。
