（AI算力出境与Token出海_系列普法02_商业篇）
编者按：上一篇（认知篇）我们厘清了"算力出境/Token出海/模型出海"的边界，并钉死了"Token不是加密货币"的红线。本篇进入系列核心诉求之一——指导商业模式设计。模式选择决定了数据怎么流、技术是否出境、钱怎么收，是后续一切合规动作的起点。本文系统拆解三种主流业务模式、Token计费的三种变现路径、架构选型决策框架，并单列"转售API"这一高发风险场景。阅读本文不能替代针对具体业务的合规评估，但能帮你在起步阶段就选对监管档位。
一、为什么"模式选择"是合规的第一决策
很多团队先做产品、再补合规，结果架构定型后才发现某条监管线根本跨不过去，此时推倒重来的成本远高于事前设计。正确的顺序应当相反：先选模式，再定架构，后补合规。
原因在于，不同业务模式触发完全不同的监管组合：
- 只做"API推理调用"，主要面对数据与支付两条线；
- 一旦把模型权重部署到境外，立即叠加技术出口线；
- 若引入"离岸数据加工"，则数据闭环与试点边界成为关键。
一个常见的误判是认为"档位选错也不过是多花点咨询费"。现实远非如此。监管档位的实质差异，体现在准入门槛、审批周期与违规处罚幅度三个层面。例如，一旦业务被认定为涉及重要数据出境，所需的安全评估周期以月计，且评估不通过将直接禁止该数据流动，等于业务停运；而轻档模式可能仅需标准合同备案，数周即可完成。把"档位"理解为"费用高低"是危险的——它首先是"业务能否开展"的开关。
模式不是商业部门的孤立决定，而是法律风险的"总开关"。它像一栋建筑的承重结构——封顶之后再想改户型，代价惊人。下文逐一拆解主流模式，并给出可操作的选型框架。
二、三种主流业务模式
1. API跨境交付（MaaS，模型即服务）
这是最轻量、最常见的形态。境内主体将训练好的模型部署在境内节点，境外用户通过API传入提示词或文档，境内完成推理后返回结果，按Token或调用量计费。
从服务贸易视角，这类"自一成员境内向其他成员境内提供服务"的情形，可类比WTO《服务贸易总协定》（GATS）项下的"跨境交付"模式，本质为技术服务的国际贸易。这也是为何跨境支付合规（第④篇）对此类业务尤为关键——它销售的是服务，而非货物。
合规要点：
- 数据流向：境外数据入境处理、结果回传，须判断是否满足"数据出境"认定及豁免条件（详见第③篇）；
- 支付路径：境外收款须走持牌通道并完成ODI与外汇登记（详见第④篇）；
- 角色定位：境内主体通常兼具"服务提供者"与"数据处理者"双重身份。
示例：A公司是一家国内大模型企业，向东南亚客户提供中文客服推理API，按Token计费。其架构为纯境内推理、境外调用，未整体输出模型，因此重点在数据与支付合规，暂不涉及技术出口。这是轻档模式的典型样本。
需要提示的是，MaaS模式虽轻，但"轻"的前提是推理实时发生、数据不落地沉淀。若为了性能把客户数据批量缓存于境内用于迭代，实际已超出"纯调用"范畴，数据合规档位可能被动上调。因此，轻档不是靠声明获得的，而是靠技术实现持续维持的——任何"为了体验而留存"的工程决策，都应同步经过合规复核。
2. 离岸数据加工（"来数加工"闭环）
该模式面向"数据在境外、算力在境内"的场景。境外数据临时入境，在境内完成加工/推理后，结果出境，但数据本身不在境内留存，形成"入境不存储、出境可追溯"的闭环。
部分地方（如汕头、韶关等）探索的"来数加工"试点，正是为这类业务提供制度试验空间。其核心价值在于：在可控前提下，让境内算力处理境外数据，而不触发完整的"数据出境"常规监管负担。需强调的是，此类试点的底层逻辑常被概括为"数字保税区"——境外数据在物理隔离专区加工后原路返回，不进入境内公共数据流通体系。
合规要点：
- 闭环可审计：必须实现全流程留痕、数据不落地存储，否则试点保护将失效；
- 试点边界：试点具有地域性与阶段性，不能视为普遍豁免，具体业务须逐案评估；
- 与MaaS的区别：离岸数据加工处理的是客户自有境外数据，而MaaS处理的是客户实时请求；二者数据法理定位不同。
实务中常被忽视的一点：即便数据"不落地"，只要加工结果中嵌入了可识别的个人信息或可还原的重要数据线索，仍可能被认定为实质出境。闭环的有效性不取决于"有没有写盘"这一技术动作，而取决于"数据是否在境内形成了可独立利用的价值"这一法律判断。换言之，形式上的"不存储"不能替代实质上的"不可还原"——这才是试点保护真正关心的边界。
3. 境外节点部署+境内算力调度
这是最"重"的形态。企业将模型权重部署至境外节点（如海外云），由境外本地完成推理；同时通过境内算力为境外节点提供训练、微调或调度支持。
合规要点：
- 技术出口风险陡增：模型权重、核心算法向境外提供或部署，可能落入禁止或限制出口技术目录，须履行许可或备案（详见第④篇）；
- 数据双向流动：境外节点产生的数据回传境内训练，可能再次触发数据出境评估；
- 域外法域叠加：境外节点直接受当地监管（如欧盟GDPR、AI Act），见第⑤篇。
该模式适合已具备较强合规能力与境外实体的成熟企业。公开报道中也提示一种认知偏差：将模型简单部署到海外服务器、底层算力却仍在境外，本质上出口的只是"模型权重文件"这一软件IP，真正的算力消耗与数字服务收入留在了海外；而"来数加工"式的境内闭环，才把价值链留在国内。两种"模型出海"路径的经济与合规含义截然不同，选型时需清醒区分。
三、Token计费的三种变现路径
无论采用上述哪种交付模式，"怎么收费"都绕不开Token计费。以下三种变现路径，合规关注点各不相同。
1. TaaS（推理即服务，Token-as-a-Service）
按Token消耗或调用次数向企业客户收费，是最常见的B端变现。其合规底座是"跨境技术服务对价"，须通过持牌支付机构收取并履行外汇申报。重点防范的是把Token包装成可交易资产——这一点在认知篇已反复强调。此外，Token计费涉及计量口径（如中英文混合文本的切分规则差异、缓存命中是否计费等问题），建议在合同中明确计量标准与争议处理机制，避免因"算多算少"引发跨境服务纠纷，也便于外汇申报时形成清晰对价凭证。计量越是透明，跨境结算与税务核查的摩擦越小。
2. 海外C端应用
以大模型能力支撑面向海外个人的应用（如写作助手、翻译工具），通过订阅制或增值服务收费。除支付合规外，还须关注目标市场对面向消费者服务的特殊要求（如隐私政策、未成年人保护、应用商店审核、消费者保护法规）。
3. 开源模型+生态出海
将开源或自研模型向境外开放，通过授权、企业支持、定制微调等生态服务变现。常见误解是"开源即自由"，但开源不等于免于技术出口评估，当涉及受管制核心算法时仍须依法判断；同时，若模型曾履行境内算法备案，境外部署还可能牵动备案口径。
四、业务架构选型决策框架
面对具体业务，可按下述四步快速定位：
第一步——界定交付物：纯推理API、离岸数据加工、还是模型整体部署？这决定监管档位（轻/中/重）。
第二步——摸清数据属性：是否处理境外个人信息？是否可能涉及重要数据？数据是否实际出境？据此预判数据合规成本。
第三步——判断技术出境：模型权重、算法是否向境外提供？若是，启动技术出口评估，并预留许可/备案周期。
第四步——设计收款与实体：选择持牌收款通道，规划ODI与外汇登记，必要时设立境外经营主体以匹配域外合规。
以A公司为例：其选择"纯API推理+境外调用"，第一步定为轻档；第二步数据主要为客户请求、规模可控；第三步不涉及模型出境；第四步通过持牌机构收款并完成登记——整体落在最低监管组合，合规成本可控。反之，若A公司改为"境外节点部署模型"，第二步与第三步将同时升级，第四步也需增设境外实体，监管权重显著上移。
为便于记忆，可把框架浓缩为一句话：交付物定档、数据定线、技术定出口、资金定通道。四步任一判断失误，都可能让后续整改成本翻倍。
五、关键角色识别：处理者、控制者与服务提供者
不同架构下，境内主体的法律角色会漂移，而角色决定义务：
- 数据处理者：受控制者委托处理个人信息，须按约定处理、保障安全，不得擅自另作他用；
- 个人信息处理者（控制者）：自主决定处理目的与方式，承担告知、单独同意、出境合规等主责；
- 服务提供者：对外提供技术服务的合同主体，须确保资质、支付与税务合规。
实务中，一个境内主体常同时扮演多种角色。例如A公司在MaaS模式下，对自家模型是控制者，对客户传入数据可能又是处理者。角色识别不清，往往导致义务"漏项"——以为"只是技术代理、不算处理者"，但只要数据经过己方服务器并发生收集、传输，就可能构成法律意义上的处理。建议在架构设计阶段即绘制"角色—义务"对照表，逐项打勾，避免盲区。可用三步法锁定角色：第一，问"谁决定处理目的"——决定者即控制者；第二，问"谁实际触碰数据"——触碰者即处理者；第三，问"谁对外签合同收钱"——签约方即服务提供者。当三步结论不一致时（例如签约方既不决定目的也不触碰数据），往往意味着存在隐名代理或转售链条，须回到第六节的警示重新评估，而不能简单以"我只是通道"免责。
六、高发警示：转售第三方API
这是商业篇必须单列的高风险场景，也是公开报道中讨论最密集的"灰色地带"。
部分团队自身并无模型能力，却转售第三方（如境外大模型厂商）的API，赚取差价，业内常称"Token中转站""API中转"。此类操作至少蕴含三重风险：
合同风险：未经授权转售可能违反与上游厂商的许可协议，面临违约与下架；若上游来源本身不合法（如批量注册套取额度、逆向获取接口），风险进一步升级。
合规风险：若上游为境外模型，转售链条可能实质构成"模型出境"或"境外服务境内落地"，触发技术出口与数据合规义务；同时，面向公众经营互联网信息服务通常需增值电信业务许可，无证经营可能面临罚款乃至非法经营罪的风险。
数据与支付风险：用户提示词、代码、商业资料均经中转服务器，存在被截留、转卖而致数据"裸奔"的风险；资金经多层中转，易触碰反洗钱审查，甚至被误认为虚拟货币结算通道。
张某曾运营一家"AI中转站"，未经授权批量转售某境外模型API，后因上游封禁导致客户损失，并因资金链路不清、数据留存不当被监管约谈。该案提示：转售不是"无本买卖"，而是把上游风险与合规义务全部承接到了自己身上。公开报道中已有大量关于此类业态法律红线的讨论，本文不再赘述细节，但强调一项原则——凡涉及转售，必须能向上追溯每一笔调用的授权来源、发票与结算凭证；追溯不到，就是风险。
七、常见商业模式误区
误区一："只做技术中立，不碰数据。" 即便声明技术中立，一旦实际处理用户数据，仍可能构成数据处理者并承担责任。
误区二："用境外主体签约就和中国法无关。" 我国相关保护法已确立域外适用效力（相关域外管辖条款建议核实），且目标法域也会反向适用本地法。
误区三："开源模型随便出海。" 开源不等于免于技术出口与算法备案评估。
误区四："先跑量再合规。" 模式一旦定型，整改成本远高于事前设计。
误区五："有营业执照/ICP就万事大吉。" 增值电信许可解决不了"上游模型来源是否合法"，资质不等于监管背书。
误区六："规模小可豁免。" 法律并无此一般豁免，规模大小不影响违法认定。
八、不同阶段企业的选型建议
- 初创团队：优先纯API推理（MaaS）模式，避免模型出境与境外实体负担；把精力放在合规收款与数据最小化上。
- 成长型企业：可在合规评估后试点离岸数据加工，但须守住数据不落地闭环，并提前规划ODI与外汇登记。
- 成熟企业：具备境外实体与法务能力后，再考虑境外节点部署，并配套"四合一"评审（数据/出口/支付/境外，见第⑤篇）。
需要提醒的是，选型不是一锤定音。随业务从东南亚试水走向欧美市场，或从业余推理走向核心算法输出，监管档位会动态上移，应建立定期复盘机制。
九、模式组合与合规叠加示例
前述三种模式并非孤立，实务中常以组合形态出现。理解组合，才能预判合规义务的"乘数效应"。
组合一：纯MaaS轻组合（API推理+按Token收费）
适用：初创团队、单一境外市场试点。合规焦点为数据（境外请求处理）与支付（持牌收款）。无技术出口线，监管最轻。A公司的样本即属此类。
组合二：来数加工+API中组合
适用：拥有境外客户数据、希望境内算力加工的企业。在轻组合基础上，叠加"数据闭环可审计"义务，须确保入境不存储、出境可追溯，并守住试点边界。若数据涉及重要数据或大规模个人信息，仍可能触发出境评估。
组合三：境外节点部署+境内调度重组合
适用：成熟企业、全球多节点服务。模型权重出境触发技术出口线，境外节点触发域外法域线，数据双向流动再触发数据线，三线与支付线全面叠加。此类架构应配套"四合一"评审与境外实体。
需要强调的是，组合的合规成本不是简单相加，而可能"跳档"：例如轻组合一旦加入"模型权重部署"，便从数据+支付两线直接跃升至含技术出口的四线，监管权重呈非线性上升。因此选型时，应优先评估"是否必须让模型出境"——能不出去，就不出去；能用境内闭环满足的需求，不轻易外移节点。这一"境内优先"原则，既是合规考量，也是把价值链留在国内的战略选择。
需特别警示一种倾向：个别团队试图通过刻意拆分合同、设立多层境外壳公司来"降低档位"，将本应整体认定的业务人为切分为"看似轻档"的片段。这种做法在跨境监管中属于典型的规避安排，主管机关在认定时会"穿透"交易结构、按实质重于形式原则归并处理。结构游戏省下的不是合规成本，而是把风险推迟到被穿透的那一天——届时不仅档位回弹，还可能因刻意规避被加重认定。真正的降本之道，是选对模式、做实数治，而非在纸面上做监管套利。
十、系列导航
第③篇（数据篇）将详解数据如何合法跨境；第④篇（管制与资金篇）展开技术出口与跨境支付；第⑤篇（综合篇）以域外法域与十大Q\&A收口。本篇的"模式—数据—技术—支付"四步框架，将与后续篇章一一对应。
结语
商业模式的本质，是在"能跑通"与"守得住"之间找到平衡点。选对模式，合规成本可预期；选错模式，再强的技术也可能被监管线拦下。下一篇，我们进入数据篇，把"数据怎么合法出去"讲透。
免责声明
本系列文章由【东衡知产AI】整理发布，旨在行业普法与经验交流，不构成针对任何具体业务或个案的正式法律意见。文中涉及的法规名称与条文序号，部分因法规修订频繁，具体适用请以最新官方文本为准，并在正式方案中咨询专业律师。案例与主体一律采用"A公司""张某"等代称，如有雷同纯属示例。技术出口目录、数据跨境规定与相关试点政策处于动态调整中，请以主管部门最新发布为准。
如需针对具体业务模式出具合规方案，欢迎关注【东衡知产AI】并联系专业律师团队。