WPS用户文档训练AI相关讨论

数据合规是一个比较新的领域，很多问题都难以通过公开渠道检索到答案。此时，实务人士间的思想碰撞、交流就显得尤为珍贵。
CONTENT
「公众号隐私政策」
「苹果禁止APP摇一摇跳转」
「B端大模型备案」
「俄罗斯数据本地化存储要求落实」
「债务人信息披露」
「有赞与电商商户的关系」
「WPS用户文档训练AI」
公众号隐私政策
-问：搜索到一些微信公众号在发布专属于公众号的隐私政策，这个有什么动因吗？珠海华润银行佛山分行微信公众号隐私政策
-答1：新的监管要求，监管核查要求扩展到公众号了。
-答2：你可以选择不收集信息，就不用写。
-答3：公众号后台，只要关注就能看到follower的昵称，如何做到不收集？好像还可以看到地域信息？
-答4：虽然有人说自己不收集，“陕西移动高清电视公众号”隐私政策。
-答5：这个隐私政策好离谱。说自己不收集和使用个人信息，那为啥要履行告知义务，不是自相矛盾吗。
-答6：这里有个处罚案例，案例 | 停车场缴费违法违规收集个人信息被处罚，“该公众号申请获取消费者相关个人信息时，未见告知用户协议、个人隐私协议。在该公众号内显著位置亦未见用户协议、个人隐私协议链接。”
​-答7：有一种可能是公众号开通和搭建插件的人压根就不知道还获取这些权限​。就像有的微信投票还要获取地理位置，拿来也没用的，就是发出来的那方压根不知道。当然啦，不知≠豁免。
-答8：这个的重点还是在透明度和必要性吧，我理解这几句的关系，在公众号里明显的地方放置相关条款是一个兜底，即当你在获取信息过程中没有展示相关条款的时候，至少得要在公众号明显的地方展示以便让用户知情，但这并不是说必须要在公众号明显的地方展示，不展示就是违规。（但“公众号内显著位置”在公众号版式固定的情况下怎么实现呢，菜单栏？置顶文章？）
-答9：公众号菜单栏放隐私政策。

总结：​​感觉公众号和小程序还是应该区分对待，不要太过了。
苹果禁止摇一摇跳转
-问：大家怎么看？

​
-答1：工信部26条早就有说这个，感觉整改效果相当一般（来自一个经常被导流的客户端）。
4.窗口关闭用户可选。开屏和弹窗信息窗口提供清晰有效的关闭按钮，保证用户可以便捷关闭；不得频繁弹窗干扰用户正常使用，或利用“全屏热力图”、高灵敏度“摇一摇”等易造成误触发的方式诱导用户操作。
公众号：中国政府网
26条措施！工信部印发进一步提升移动互联网应用服务能力的通知
-答2：去年双十一说了要狠狠打击，今年双十一变本加厉。
-答3：摇一摇在过去一段时间里是默许的存在，大厂一直在跟工信讨价还价。甚至带头整改其它部分。
-答4：是的，第一年本来就要被干掉的，大厂不同意。
-答5：记得去年有一个团标还规定了摇一摇的敏感度，从今年双十一现实看起来团标效力确实有限（或者说还有很多可以在边缘反复试探的技术手段。

​
-答6：弱弱问一句，摇一摇的广告界面难道不是被导流的App自己设置的摇一摇吗。最后落地还是广告运营公司在对应投放平台上选择最终的展示内容及方式吧？ 投放平台没有管控权吗？
-答7：严格来说，不完全是，也有一些代投的。有很多种投放的方案，比如你投图文、投视频，然后结算方式各有所不同，一些是需要CPC/CPA/CPT结算之类的，就会衍生出来很多很离谱的唤起方式。毕竟跳转了才有钱。摇一摇确实效果不错，还有那种倾斜的，专治躺着玩手机。
投放的形式有很多，如果是公司直接投，确实有一些是可以选择你投放的形式的。
但是代投的话，如果没有约定，代投公司一般会按照结算条款来考虑投放的形式，顶多约定一下（有一些可以排除掉特定的投放形式之类的，或者保证投放合法合规之类的），那代投就是会选择更高效的（对于代投公司来说比如更高的触发、跳转的可能的情况）投放的形式。
广告平台能挣钱就行，而且有些是直接上整个联盟的，才不管这么多，有人投，有消耗，有钱挣就行。
投放平台也没有收到消息说违法呀，而且上面大佬也说了，大厂在拉扯（毕竟是挣钱的生意，谁不想广告效果好，多投投呢）。
-答8：因为有钱赚，广告主出价高，或者广告平台要完成业绩好拿年终奖，无利不起早。
-答9：可能我表达的不清楚。就摇一摇为例，投放平台如果启用了摇一摇，投放其他家的广告，是投放平台自己来控制整个摇一摇的设计和流程 ，调整跳转灵敏度？还是接什么外部Sdk了。
-答10：广告联盟有sdk给你接的，接了就可以恰饭了。
-答11：看看这张图。

​
总结：摇一摇跳转可耻但能赚钱。
B端大模型备案
-问：问大家，如果是提供给b端企业的大模型，目前规模较小，需要履行算法备案那些要求吗？
-答1：我看到Meta的llama2已经在国内某平台上架了，应该是没有备案的。平台在产品页面提了一句，如果是使用者对公众提供服务，需要遵守中国法律。它这个产品可能定位就是2B，感觉是认为自己不需要备案。但不同律所说法不一样。有的认为2B也属于对公众提供服务。
-答2：2B后面可能还是2C，有2B的大模型备案了。
-答3：垂直to B不算，面向不特定行业企业的不排除。比如医疗、金融都属于垂类。
-答4：
2C去做大模型备案的时候，得透露用了哪个2B大模型，结果发现这个2B大模型没有大模型备案号就有点尴尬。
-答5：都要提供备案号的，很多人给算法备案号忽悠，被我打回去了。
-答6：是这样的，如果是 B2B2C的是要备案的。
-追问：感谢大家，如果是纯b端企业使用，但客户行业不固定，但境内使用的体量也很小，也是需要备案？目前的感觉还没有足够达到具有舆论属性和社会动员能力的标准。
-答7：是否具有舆论属性或者社会动员能力的定义很模糊，不能单纯以自己 tob 来定义，举个例子，tob 场景下如果大模型出现了内容安全问题最后被截图爆到网上，据说会有大额罚款。
-答8：不知这里的罚款多是来自哪个部门?
-答9：内容安全是网信吧。
-答10：也会涉及公安或国安。
总结：有点玄学，垂直类2B可以不备案，但通用行业不行，而且还要排除最终集成后2C的情况。
俄罗斯数据本地化存储要求落实
-问：跟各位大佬们请教个问题，大家是怎么解决俄罗斯当地要求的数据本地化要求的呀？业务有产品想卖到俄罗斯，俄罗斯法律上要求数据本地化，但是aws/阿里云/腾讯云均无俄罗斯节点。
-答1：可以考虑再让采购问问他们几家有没有。
-答2：有一种方式是数据收集（写入环节）做本地化，因为俄罗斯是允许海外镜像的，是个成本比较低的方式。可以跟技术聊聊针对你们的场景好不好实现。因为成本比较低，所以也许有其他大厂节点之外的替代性方案，比如当地租服务器。不过我们做的时候还没有战争，现在情况也许不一样了，我就提供个思路，看是不是一个可以摸索的方向。技术应该更懂。
-答3：一些境内云服务商会在俄罗斯当地找合作伙伴。另外也可以用俄罗斯本地的VK和yandex。
总结：多问问会有能提供服务的。
助贷APP金融资质
-问：请教下各位大佬，工信部要求的APP备案，应用市场有对助贷类APP提出什么金融资质要求么？

​
-答1：网络接入商是对营业执照里面经营范围关键字看的。在他的关键字名单内的，就要对应牌照。我倒是没细问他们这个关键字清单是不是工信部给的。我们去年就把app软著和知识产权迁移了。迁到有金融许可证的主体公司下了。否则这次app备案也碰到你一样麻烦。
-答2：说到这个，想起个神奇的投诉，有个无聊的人投诉到市监局说，网站上发布虚假信息，因为网站备案主体跟宣传内容的主体不是同一个 ，关键市监还真查了。
-答3：工信部不会也无权介入金融监管要求，实践中科技公司和金融机构都可以；但是开展金融业务必须要有金融牌照等文件，发布主体运营主体起码得占一样。
-答4：但是助贷类机构到底需要什么金融牌照/资质，目前并不明确。市场上很多APP都在做助贷，比如某打车软件，他们也没有金融资质？我们战略研究过，他们关联方都没有。
-答5：助贷不是金融业务，这个蛮搞的，应用市场会看合作协议，我们当时给苹果发过合作协议解释。
-答6：看应用市场了，例如我之前经手的切换主体，App Store不能变还是小贷公司，安卓们都变更为科技公司了。使用科技公司，填坑时风险会小一点。使用金融牌照，那平时的合规成本就会高很多，填坑时候伺候的爸爸也会多。大厂头部不一定有借鉴价值，因为都是经历了变化的，旧人旧办法。现在新人新办法，一个平台有可能只是做从事引流的广告业务。只不过是给金融机构或者其他助贷平台引流。现在市场上有金融牌照和“纯”科技公司的都存在。理想状态，科技公司控股/持股持牌机构。科技公司是App发布主体，运营主体。
-答7：是的，苹果，华为严格，其它稍微好一点。
总结：存量案例，不一定有借鉴意义。
债务人信息披露
-问：债权人可以将债务人的个人信息披露给担保公司吗？一些银行借贷项目里面，担保公司对其中一部分借款人的借款进行担保，现在担保公司需要追偿，银行向担保公司披露个人信息是否有合规风险？
-答1：没啥风险，履行合同必要。
-答2：《银行业金融机构与融资担保公司业务合作指引》，第三章第三十、三十四条，供参考。《融资担保公司监管条例》的四项配套制度之一，银保监发[2018]1号。
第三十条授信业务持续期间，银担合作双方应当按照要求对客户实施贷（保）后管理，及时共享客户运营情况及风险预警信息，共同开展风险防范和化解工作。
第三十四条 担保公司代偿后，银行应当积极配合其对客户的债权追索。银担合作双方约定风险分担的，任何一方追索债权获得的资金，应当在扣除追偿费用后按约定的风险分担比例进行分配。
《银行业金融机构与融资担保公司业务合作指引》
总结：履行合同所必须的典型场景（前提是三方合同），此外也有履行法定义务的依据。
有赞与电商商户的关系
-问：有人了解有赞与使用有赞SaaS服务建电商小程序的经营者之间的法律关系不？但这批电商小程序和有赞的账号有绑定嫌疑，截图里的更换手机号提示也挺可疑。AB两个使用有赞saas服务建的电商小程序，在A修改绑定的手机号，结果会同步到B。如果有赞是受托人，这怕是超越处理目的了。

​
-答1：有赞是个品牌（处理者），并不等于有赞建站小程序（委托处理的角色），有赞旗下还有有赞云，有赞小程序技术搭建，有赞支付。这样可以说服你吗？
-追问：我想追问下在建站场景下有赞要求小程序/app用户注册有赞账户，有什么法律上的合理性吗？用户是否可以拒绝小程序/app将个人信息提供给有赞，用于注册有赞账号呢？实际操作体验是，有赞和app/小程序的账号注册是捆绑的，必须同时注册。除捆绑注册外还有一个问题：不仅建站服务委托方A需要把个人信息提供给有赞用于注册，A的个人信息变更还会传导至B，这就完全不在建站服务的委托处理关系内了。
-答2：法无禁止即可为。合同，意思自治，授权。跟捆绑注册还有一点点不太一样，为啥呢，捆绑注册是可以拆分的， 可以只注册一个且不会影响另一个使用，但有赞那套不行，不行的原因是底层技术架构决定的，就是SaaS服务，并不是私有云啊，更不是本地化部署，账号啊，存储啊都是在有赞的公有云上，咋切割呢。 一旦切割会面临一个SaaS技术难题，就是我用123245去A的小程序上注册了一个账号，过几天我再用12345去B的小程序上注册一个账号，后台怎么去区分这两个账号呢，可以区分，就会很怪。如果说是独立部署的话好解决，但现在是通用SaaS,就会设计的无比复杂，所以最后干脆，系统判断触发账号合并。
-答3：最近我也是遇到了这个问题。一个客户和一家类似有赞的SaaS服务商（创客匠人）合作，服务商给她搭建小程序店铺。我问服务商：用户在A店铺注册的账号，是不是你的平台账号？对方就跟我绕，说进A店铺就在A店铺注册，进B店铺就在B店铺注册。
-答4：可以理解为一个saas账号逛遍AB店铺么？
-答5：那也得注册，不是默认 A 店通 B 店通 C 店。前面你的疑问：也是做了隔离的，不会发生我在 A 店修改了手机号，就自动更新了 B 店的手机号。
​答：历史问题，很复杂。
WPS用户文档训练AI
-问：如何评价WPS隐私政策披露使用用户文档训练AI后的回复？

​
-答1：这个甩锅给写隐私政策的人了？说实话，写隐私政策的人已经很卖力了，尽量避免训练行为不要太扎眼。
-答2：这种尽管可以找到一个背锅人，但是往往是一个系统性问题。但凡有一点自研成分的AI产品，很多应该都拿数据训练吧，只不过写不写的区别。我想问，如果隐私政策写了，也提供了单独的用于训练开关，还会被喷吗？如果大家都不能有一个积极的看法，确实很难做。这本不应该是一块遮羞布？
-答3：谁发布，谁负责，系统发的，运维背。
-答4：低成本，优质的数据，很难的，要考虑用户体验，落地成本。合规上，确实应该这样，需要放一下傲慢或者愿意接受这个成本和难度，放低架子，愿意接受低效。来做这个事情，还得有 社会责任那块的加持。
-答5：如果确实需要用户真实数据来训练模型（有的模型可能真的不需要），在隐私政策里告知、允许用户拒绝（例如，基础版的就让用户发邮件行权；高配版的，提供一个opt out面板），现在阶段就可以了。如果仅仅为了安抚舆情， 让企业都不敢用或者用了都不敢写，那对产业和用户都不是好事儿。但这依然是中国法下的（目前）解决方案，如果落入GDPR，那就得另解了。
-答6：这个事情还是得感谢同业们“流血”，让我们 battle 的时候可以更理直气壮，做到高级版真的不容易。
-答7：是啊。Chat GPT一开始也木有那个开关，好像今年才加上的吧。其他面向C端的头部大模型也普遍没有跟进。
-答8：训练绝不单纯是个《个保法》的问题。
-答9：WPS和一般的数据还是不一样，除了个人信息外，可能还有大量的商业秘密甚至国家秘密（考虑公务人员使用情况）。不用于训练是合理的，即使只是从用户安全感出发。进一步讲，如果即时通讯软件，把聊天记录用于训练，会给用户的感受带来多大影响。
-答10：这个视角很重要。WPS多是B端业务，客户和终端用户对于数据用于大模型训练没有合理隐私期待。大厂们面向B端的mass服务也多是明确不用用户数据进行底座模型训练的。
-答11：确实，另外还有著作权法上的问题 很多用户未必是著作权人。
-答12：训练数据的使用是否落入著作权法保护范围，也是个有很大争议的著作权法问题（中国法小），也很头大。
不知以后咋继续，是不是业务真的就不敢用、不能用、不需要用了。
反正写涉ai训练条款的隐私政策好难，得真诚写……然后再真诚道歉？
-答13：基础模型训练过程中的个人信息权益和著作权保护暂时没有简洁的解决方案。欧盟等相关立法谈判里也是硬骨头。沿袭同意/授权或许各方都不满意。探索前置整合差分、合成等正在成熟的技术，协同架构和部署层面的设计，应该是一个方向。
-答14：那个隐私政策中对于AI训练处理活动的“透明性原则”还是在真诚地尽力落实的。但舆情一出来，就变得“不正确"了。
-答15：嗯嗯，就怕这种情况太多，顾虑太大，反而会破坏了透明原则。
-答16：倒不存在不正确，只是用户有用脚投票的权利。后面甩锅给政策，这才是“不正确”。
总结：我也非常担心，这次的舆情会导致其他机构直接横下一条心，就不披露了，悄悄弄。