租户隔离
不同客户、不同组织、不同业务主体的数据边界清晰，避免跨租户、跨组织的数据混用。
安全底座
先把权限、数据和操作边界管清楚
文旅系统长期运行，不能只看功能是否完整，更要看组织、角色、数据和操作是否可控、可追溯。
角色权限
按老板、财务、业务、计调、销售、门店、管理员等岗位配置可见、可操作范围。
数据权限
围绕组织、部门、门店、员工、客户、订单和财务数据进行权限控制。
操作日志
关键操作留痕，记录谁在什么时间做了什么，方便问题排查和责任追溯。
审计追踪
对涉及订单、合同、收付款、成本、结算、权限调整等关键动作保留审计记录。
备份恢复
围绕业务连续性，支持数据备份、异常排查和恢复策略设计。
数据边界
客户数据有边界，AI 和公开展示也有边界
金跳动重视客户业务数据、客户资料和经营信息的边界管理，按照授权范围、最小必要原则和脱敏规则处理数据。
客户数据不用于大模型训练
客户业务数据、订单数据、财务数据、客户资料和经营数据，不作为通用大模型训练数据使用。
敏感数据按授权范围处理
涉及客户资料、交易明细、合同、财务和经营数据时，按客户授权范围进行使用和展示。
不擅自公开客户信息
官网案例、宣传资料和对外展示内容，不擅自公开客户名称、内部数据和商业细节。
支持脱敏展示
案例、数据和业务结果可按公开口径进行脱敏表达，保留业务问题、系统介入和结果变化。
最小必要原则
系统展示、权限配置、接口对接和数据使用，尽量控制在业务所需范围内。
资金与合规边界
系统跑信息流，资金流交给持牌机构处理
金跳动系统记录订单、应收应付、收付款状态、账单和结算信息，但真实支付、清分、分账、代付和资金处理，应由持牌第三方支付机构或银行完成。
业务信息流
系统记录产品、订单、合同、游客、团队、供应商、成本、应收应付和经营结果。
财务管理信息
系统记录收款状态、付款状态、账单、对账、结算规则和经营报表，帮助企业管理财务信息。
真实资金处理
真实支付、清分、分账、代付和资金结算由持牌第三方支付机构或银行处理。
不沉淀客户资金
系统不替代支付牌照，不作为资金池，不沉淀客户资金，不承诺替代金融或支付合规资质。
部署与运维
不同客户，可以选择不同部署与运维方式
根据客户规模、数据敏感度、内网要求和交付周期，可选择 SaaS、私有化、本地化等部署方式，并配套备份、日志和运维支持。
SaaS 部署
适合标准化程度较高、上线周期较短、希望快速使用系统的客户。
私有化部署
适合集团客户、国企客户、政府/园区项目或对数据边界有更高要求的客户。
本地化部署
适合有内网、专线、机房或本地服务器要求的项目。
备份策略
根据项目情况设计备份周期、备份范围和异常恢复方式。
运维支持
围绕系统运行、异常排查、版本升级和使用问题提供运维支持。
日志排查
通过操作日志、系统日志和业务记录辅助定位问题来源。
采购关注点
采购系统时，真正需要问清楚这些问题
安全与合规不是一句口号。企业采购更关心权限、数据、部署、运维、责任和合规边界是否清楚。
数据是否能隔离？
不同组织、门店、员工、客户和业务主体的数据边界是否清晰。
权限是否能控制？
不同岗位是否只看到和操作自己职责范围内的数据。
操作是否能追溯？
关键操作是否有日志，出现问题能否定位到人、时间和动作。
部署是否能匹配？
是否支持 SaaS、私有化、本地化等不同部署方式。
服务是否有响应？
上线、培训、运维、异常处理是否有明确服务流程。
合规边界是否清楚？
系统做什么、不做什么，资金、数据、AI、接口和责任边界是否明确。
合规表达原则
合规表达要克制，边界清楚比口号更重要
金跳动在官网、产品资料、方案沟通和客户交付中，尽量避免模糊承诺，用清晰边界说明系统能力和服务范围。
不写绝对化承诺
避免“绝对安全”“保证合规”“永久安全”等不严谨表述。
不替代客户内部制度
系统提供工具、流程和记录能力，客户仍需结合自身制度、岗位职责和业务管理执行。
不替代持牌机构职责
涉及支付、清分、分账、代付和真实资金处理的业务，应由持牌支付机构或银行完成。
不擅自扩大公开范围
客户案例、数据结果和项目经验对外展示，应遵循授权、脱敏和公开口径。