作为独立开发者，这些安全义务已经适用于你

独立开发者中普遍存在一种看法，认为安全与隐私监管是只会发生在公司身上的事情——义务始于你注册公司、聘请DPO或签署企业合同之时。这并不属实，而且多年来一直如此。如果你是处理客户数据的自由职业者或独立开发者，多项义务已经在今天、以你目前的规模，直接适用于你个人。本文将逐一梳理这些义务，指出其来源的法规，并以真正重要的实际问题收尾：你的账户上，此刻究竟暴露着什么？

本文不会做的一件事，是告诉你有哪条法律要求你购买某款安全工具。没有任何法律这样规定。法律真正要求的是，你要清楚自己在如何处理所经手的数据，并对其进行适当的安全防护——而这一切诚实的起点，是弄清楚你的客户工作所存放的账户上，究竟存在着哪些访问权限。

根据GDPR，处理客户数据的自由职业者即为处理者——负有直接义务

如果欧盟境内的客户（或用户位于欧盟的客户）向你交付个人数据——需要迁移的用户数据库、需要调试的生产系统、需要分析的导出文件——你几乎总是在GDPR意义上扮演数据处理者（data processor）的角色；在某些项目中（当你自行决定收集何种数据及收集目的时），你甚至扮演数据控制者（controller）的角色。这两种身份都不要求你以公司形式存在。GDPR第4条对相关定义所限定的对象是“自然人或法人”——一个带着笔记本电脑的人，同样符合条件。

这一身份带来了直接的、针对个人的义务：

• 第28条要求你为客户所做的处理活动，必须受合同约束——你的企业客户不断寄来的数据处理协议（DPA）并非官僚形式主义；它是对双方的法律要求，并使你承担具体的安全承诺。
• 第32条要求你实施“适当的技术和组织措施”，以保护你所处理的个人数据——这种适当性应与风险相称，其中包括控制谁、以及什么系统可以访问这些数据。
• 第33条要求处理者在得知发生个人数据泄露后“不得无故拖延”，向控制者作出通知——这一要求的前提是，你本就处于能够察觉泄露发生的位置。
• 第82条赋予数据主体权利，可就违反本条例的处理活动所造成的损害，向处理者索赔；第83条则以行政罚款为整个框架提供支撑，对最严重的违规行为，罚款上限可达两千万欧元或上一财年全球年营业额的百分之四，以较高者为准。

没有人是在暗示，监管机构针对自由职业者的第一步行动就会是法定最高罚款。问题的关键更简单：这些义务是真实存在的，它们直接附加在你身上，而“我只是一个人”在该条例的文本中，找不到任何可被承认的豁免依据。

欧盟《人工智能法案》为AI系统的部署者增加了义务

如果你的客户工作现在包括将AI嵌入产品——为客户应用添加助手功能、构建自动执行工作流的AI代理、让某个模型做出影响他人的决策——那么欧盟《人工智能法案》（EU AI Act）与你相关。该法案不仅监管训练模型的公司；它同样对部署者（deployers）——即在专业场景下以自身权限使用AI系统的人——施加义务。

第26条规定了高风险AI系统部署者的义务，包括按照使用说明使用系统、确保适当的人工监督，以及监测系统运行。第4条要求提供者和部署者均须确保代表其操作这些系统的人员，具备充分的AI素养。第99条则以行政罚款为该框架的不合规行为提供支撑。具体某一项目适用哪些义务，取决于该系统的功能及其所属的风险类别——但“我只是做了集成，不是我开发的”，恰恰正是“部署者”这一类别所设计针对的情形。

这里存在一个我们在AI代理治理领域经常见到的现实讽刺：独立开发者是AI编程代理和自动化机器人最重度的采用者——却也是最不可能清点这些代理究竟能触及哪些资源的人群。如果某个AI代理能够推送代码到你名下的每一个仓库，无论是否有监管机构问起，这都是关于你安全态势的一个事实。

你的企业客户本身已受监管——其义务会向下传导至你

即便你从未触碰过欧盟的个人数据，也从未部署过AI系统，仍存在第三种安全义务来源，几乎适用于每一位与任何规模企业合作的自由职业者：合同。企业客户在SOC 2报告、ISO 27001认证、GDPR第28条处理者要求以及供应商管理项目的约束下运营，而这些项目会受到其审计人员的实际核查。这些项目并不会区分500人规模的供应商与单人供应商。供应商就是供应商。

这正是为什么安全问卷总是先于合同送达。你的客户被要求——出于其所遵循的框架、其审计人员，或其自身客户的要求——向他们交付数据的对象收集安全证据。这其中也包括你。那些能够可信作答的自由职业者（“这是我的开发环境当前拥有哪些访问权限，这是我如何控制它们，这是相关证据”），会比那些临场发挥的人更快地拿下合同。我们在2026年审计人员对AI治理的要求一文中，讨论过这一动态的企业方版本；而供应商方的版本，落到你桌面上，就是一份问卷。

一次数据泄露，对独立开发者的实际代价

以下是就风险而言、诚实的表述：客户项目中的一次安全事件，可能意味着依据合同赔偿条款所产生的直接财务责任，可能意味着若涉及个人数据，则依据GDPR第82条产生处理者责任——而对自由职业者而言最具体的是，可能意味着客户关系的终结，以及随之而来的推荐机会的丧失。对于一人咨询公司而言，声誉本身就是全部业务资产。这一切都不是纸上谈兵的极端假设，而是当一个被攻陷的凭证或权限过度的集成，演变为客户数据事件时，最普通不过的连锁后果。

那么，你的账户上，此刻究竟暴露着什么？

这里给出这个问题的具体而令人不安的答案。你的客户工作几乎肯定存放在一个个人GitHub账户上。多年的项目积累下来，这个账户上已经堆积了：

• 已安装的GitHub Apps——部署机器人、CI工具、AI助手——每一个都持有你曾经批准、但很可能从未再审查过的权限授权。其中一些对你名下的一切拥有写入或管理员权限。有些则属于早在2024年就已结束的项目。
• 部署密钥（Deploy keys）——静置在服务器上、无人值守的SSH凭证，其中一些原本只需读取权限，实际却拥有对仓库的写入权限。一旦该服务器被攻陷，一个具有读写权限的部署密钥，就成了一条通往客户产品的代码注入路径。
• 协作者（Collaborators）——你在某次早已结束的协作中添加的人员，至今仍持有写入权限，其中包括对某些公开仓库的写入权限。
• 仓库暴露情况——你的哪些仓库是公开的，其中包含什么内容，这本身就是一个大多数开发者凭记忆无法回答的清点问题。

以上每一项，都可以通过GitHub自身的API以机器可读的方式获取，这意味着每一项都是可核查的——不是依靠对记忆的信任，而是通过枚举当下究竟有哪些权限在实际生效。这正是8200.dev的GitHub连接器如今为个人账户（而不仅仅是组织账户）所提供的清点结果：连接你自己的GitHub登录账号，扫描便会列出已安装的应用及其权限授权、部署密钥及每一个是否为只读、每个仓库的协作者，以及从这张关系图中浮现出的具体发现——被遗忘却拥有管理员权限的机器人、具有写入能力的部署密钥、一年无人touch过的陈旧应用。

免费的个人版会运行完整扫描，并展示最严重的发现；付费的个人版——定价堪比一款代码补全订阅，而非企业软件——则解锁完整清单、持续监控与告警。而当你成长为拥有组织账户的代理机构时，同样的扫描、同样的规则、同样的证据链，会随你一同扩展——这就是该产品的组织版，使用的是同一个连接器。

上述义务无论你是否运行扫描，都已适用于你。扫描所改变的，是你能否回答这些义务所隐含的那些问题——什么拥有访问权限、为什么拥有，以及对那些无法被证明合理的访问权限，你采取了什么措施。从免费版开始，看看你的账户上悄然积累了什么，再据此决定下一步——定价公开透明，自助注册，起步价为零。

*本文是关于通常适用于独立开发者的相关法规的一般性信息；不构成法律意见，且每项法规如何适用于你的具体情况，取决于扫描工具无法获知的事实。就此，请咨询律师。*