这家医疗科技企业做了十多年，主营体外诊断试剂和配套检测设备，团队几百人。研发和销售是公司的核心部门，生产、质量体系则受到严格的行业监管。公司的信息化基础不错。但研发部门的实验数据和销售部门的客户数据长期各管各的，跨部门沟通主要靠邮件和微信群。一个问题涉及三个部门，往往就要拉三个群，文件发来发去，最后还得有人出来协调。

这几年，市场增长慢了下来。老板着急，管理层也着急，都在找新的增长空间。AI热潮起来后，公司动作很快。半年内采购了多套AI工具，组织了几轮全员培训，还引入了FDE，也就是派驻AI工程师，帮助业务部门把AI用起来。

该做的动作，基本都做了。半年后复盘，大家却有点说不清楚：AI到底给公司带来了什么？

研发部门说，文献检索快了，实验方案设计也有帮助，但产品注册证的取得周期没有明显缩短。销售说，竞品分析和客户提案做起来轻松了，投标中标率却没什么变化。质量部门觉得AI辅助分析有些价值，可不良事件处理和CAPA闭环还是慢。如果问员工有没有使用AI，答案大多是有。如果问这些应用到底改善了什么业务结果，回答就开始含糊。

这也是我们在AI组织转型辅导中经常会碰到的情况：企业花了钱投入了人力，可一到复盘，老板说得最多的还是“企业利润没啥变化，甚至还大幅增加了TOKEN成本”。我们和管理团队讨论时，建议先别急着找新的工具，先把已经做过的事情摊开，看看到底卡在了哪里。

一、AI用得起来，为什么组织效率提升不了？

先看研发和销售。

研发人员用AI查文献、分析专利，销售人员用AI研究竞品、投标、准备客户方案。两个部门都觉得工具不错，但各自使用各自的方法，提示词不一样，资料来源不一样，输出格式也不一样。碰到同一个产品问题，两边拿出来的分析甚至可能对不上。

这不奇怪。AI能够帮助员工更快处理手头的信息，却不会自动把研发和销售连接起来。两个部门原本怎么分工、怎么共享数据、怎么协调工作，基本还是什么样。

再看质量部门。

有一次，AI生成的不良事件分析报告出现了偏差。质量部门随即要求，所有AI生成的内容都必须经过人工逐份审核。

从质量管理的角度说，这个要求有它的道理。医疗器械相关的质量问题可能涉及患者安全和监管责任，谁也不愿意因为图快而留下隐患。

但这样一来，AI刚刚省下来的时间，又被审核流程吃掉了一部分。

我们在组织发展共创会上，多问了一句：质量经理为什么一定要逐份审核？这里面当然有风险控制的需要，也可能有对AI可靠性的担忧。除此之外，还有一个问题——如果AI承担了越来越多的初步分析工作，质量经理以后靠什么体现自己的专业价值？

一位质量主管私下说过这样一句话：“我担心的不是AI犯错，而是以后我的经验价值在哪里体现。”

对于一个做了多年质量管理的人来说，审核报告、发现问题、把住质量关，可能一直是他工作中最重要的部分。现在AI开始接手其中一些工作，他会担心很正常。如果公司只告诉他要拥抱AI，却没有说清楚他的工作以后会有什么变化，他当然会更愿意守住原来的做法。

生产和质量部门还有另一种顾虑：不敢用。

研发、销售的很多工作可以先试起来，质量和生产就没那么简单了。数据能不能放进去？AI给出的建议出了问题，谁负责？涉及产品质量和监管要求的事项，哪些可以让AI参与，哪些绝不能交给AI？

这些问题没有答案，员工最稳妥的做法就是少用，或者干脆不用。

我们把几类问题放在一起看，发现这家企业遇到的麻烦，已经超出了工具应用本身。

研发和销售之间，缺少围绕共同业务任务协作的机制；质量经理还在用原来的审核方式管理新的工作；生产和质量人员对使用AI的责任边界心存顾虑。与此同时，公司半年内一口气推进六个试点，每个都希望尽快拿出成果，大家忙得很，却很难说清楚哪些项目已经进入了业务流程。

二、我们是在证明自己也在做AI，而不是解决AI如何进入业务

在一次高管会上，创始人问了大家一个问题：“如果半年后回头看，我们真正改变了的事情是什么？”

会场安静了一会儿。这个问题不太好回答。工具买了，培训做了，试点也启动了，可如果不看这些动作，单说公司发生了什么变化，大家一时找不到特别有说服力的答案。

后来，创始人自己总结了一句：“过去半年，我们是在证明自己也在做AI，而不是解决AI如何进入业务。”

这句话说得很直接。企业不缺少意愿。老板重视，员工也在学，FDE也在帮助业务团队探索场景。问题是，大家都在做AI相关的事情，却没有把有限的精力集中到几个最值得解决的业务问题上。

我们给管理团队的第一个建议，就是先做减法。原来的六个试点，先砍掉一半，保留三个与核心业务关系密切、价值相对清楚、合规路径也比较明确的场景：

• 研发文献与专利智能检索；

• 销售AI辅助投标；

• 质量不良事件辅助分析。

这三个场景各有特点。研发检索相对容易从小处切入；销售投标有明确的重复性工作，员工很容易感受到效率变化；质量分析风险更高，边界也更难确定。

我们不要求三个项目同时交出漂亮的成绩单。先把它们做进真实工作里，解决真实问题。

三、先把红线画清楚，员工才敢往前走

在具体场景开始推进之前，我们先讨论了数据和合规。

公司已经有不少业务数据，但哪些数据可以输入外部模型，哪些只能在内部环境使用，哪些经过脱敏后可以用于特定场景，员工并没有一套足够清晰、容易执行的规则。

培训时告诉大家注意数据安全，当然有用。但如果员工每次使用AI都得自己猜测能不能输入某份材料，这种提醒很难转化为稳定的工作习惯。因此，我们建议企业先把数据使用边界写清楚。

研发数据、患者相关信息、客户资料、产品技术文件，分别按敏感程度和使用场景管理；明确哪些数据禁止输入未经批准的外部模型，哪些数据可以在企业批准的工具中使用，哪些经过脱敏、授权后可以用于特定任务。

同时，还要把AI输出的审核要求说清楚。哪些内容可以作为内部参考，哪些必须核对来源，哪些结果不能直接用于正式的质量判断和监管文件。

公司也需要给员工一个明确的信号：在遵守规则、使用批准工具的前提下，可以开展有边界的探索。发现问题要及时报告，组织应当根据问题完善工具、流程和规则；但涉及故意违规、泄露敏感信息或绕过必要质量控制的行为，仍然要承担相应责任。

这不是一句“鼓励试错”就能解决的事情。红线要明确，出了问题以后怎么办，也要提前说清楚。

一位研发工程师这样描述自己的感受：“以前每次用AI都提心吊胆，怕不小心把敏感数据贴进去了。现在红线画清楚了，反而敢用了。”

生产和质量部门的态度也开始发生变化。以前一听说要上AI，大家先问合不合规；有了更清晰的规则之后，讨论才逐渐转向具体工作：哪些可以试，哪些需要隔离，哪些必须经过专业审核。

这一步看起来不像什么技术突破，却是后面几个场景能够继续往前走的前提。

四、质量经理的工作，从逐份审核转向设计审核规则

质量部门仍然有一道坎要过。AI生成的不良事件分析报告偶尔会出现偏差，质量经理要求每份内容都人工复核。我们没有要求他们马上放宽审核，也没有把问题简单归结为管理者不愿意改变。

我们和团队讨论的是：能不能把审核要求分得更细一些？不同任务的风险不一样，审核方式也应该有所区别。

例如，一些低风险的信息整理、格式转换和历史记录检索，在工具经过验证、数据来源清楚、输出用途明确的前提下，可以考虑采用抽样检查等适当的质量控制方式。涉及产品技术参数、质量分析和专业判断的内容，需要根据风险设置人工复核要求。至于可能影响患者安全、重大质量风险判断、监管报告和关键纠正措施的事项，仍然必须由具备相应资质和责任的人员完成必要的专业判断与审核。具体怎么分，需要结合企业质量体系、适用法规、风险评估和实际验证结果，逐项讨论清楚。

这项工作花时间，但值得做。因为质量经理以后要负责的，不必是每一份报告的每一句话。他需要建立一套规则，让员工知道哪些事情可以借助AI，哪些事情必须人工复核，遇到什么情况要立即升级处理。他的专业经验依然重要，只是使用经验的方式会发生变化：从亲自检查每一份材料，逐渐转向设计和维护一套可靠的质量控制机制。

这个转变并不容易。原来一眼就能看见的工作量减少了，新的工作价值却需要通过规则质量、风险控制和整体流程改善来体现。组织还需要相应调整管理者的职责、评价方式和能力培养，不能只要求他们换一种做法，却仍然用旧标准考核他们。

这也是AI组织进化中容易被低估的一点：流程改了，人的工作和价值评价也要跟着调整。

五、先从销售投标下手，让员工看到AI到底能帮什么忙

三个场景中，我们把销售AI辅助投标作为优先突破的场景。原因很简单：这项工作重复性高，耗费时间，而且业务人员自己就能说清楚哪里麻烦。

每次投标，销售人员都要查找大量资质文件、核对产品技术参数、整理商务条款，还要确认文件是否在有效期内。按案例设定的情况，准备一份投标材料，通常需要两到三天。资料分散，型号容易混淆，文件也可能漏掉。

这类工作不需要一开始就追求复杂的智能体。先把常用资料整理好，让AI能够准确找到资料、生成初稿，就已经有实际价值。

企业于是开始梳理有效资质、产品参数和合同条款，对文件进行结构化整理，补充型号、版本、有效期等必要信息。销售人员输入招标项目编号后，系统可以匹配相关材料，并辅助生成标书初稿。试点推进后，材料准备速度明显提高。

销售人员很快就能感受到差别：以前花大量时间翻文件，现在可以把更多时间用在客户沟通、方案调整和投标策略上。AI不再是一项额外要求，而是帮他们解决了每天都会遇到的麻烦。

不过，问题也很快出现了。AI偶尔会把某个型号的技术参数套用到另一个型号上。销售人员仍然需要逐项检查，尤其是关键技术指标，不能因为初稿生成得快就直接提交。继续追查后，团队发现，产品参数散落在不同系统和文件里，格式不统一，部分资料的版本更新也不及时。

这个发现说明，单靠更换模型或者不断修改提示词，无法彻底解决问题。企业得先把自己的产品数据管好，AI才能稳定地调用正确的信息。

我们建议下一步把重点放在产品参数的统一管理上：明确唯一的数据来源，维护型号与参数的对应关系，管理版本和有效期，并尽可能在生成标书时增加自动校验。对于关键技术参数，仍然需要由业务人员复核。

投标场景因此带出了一个原本就存在、但一直没有被充分解决的问题：企业的数据治理基础还不够扎实。

很多企业在AI项目中都会遇到类似情况。以前数据散落在不同系统里，员工靠经验也能勉强把工作做完；AI开始调用这些数据时，数据不一致的问题就会集中暴露出来。

这类问题看起来是AI不够准确，往深处看，往往需要企业重新整理自己的数据、业务知识和管理规则。

六、研发场景进展最好，因为员工把经验留下来了

研发文献与专利检索的试点，取得了较好的阶段性效果。按照案例设定的项目统计口径，立项前的文献调研时间从平均三天缩短到半天。AI能够帮助研发人员检索和归纳相关文献，也能提示哪些研究方法可能与已有专利存在潜在冲突，供专业人员进一步核查。

这里需要说明，AI提供的是线索，不能替代正式的专利检索、法律判断或自由实施分析。研发人员仍然需要核实文献来源，并由相应专业人员作出判断。

这个场景还有一个值得关注的变化。最初，员工只是把AI当作自己的工作工具。随着使用次数增加，一些研发人员开始整理哪些提示词更有效、哪些资料适合输入、怎样核对引用来源，以及怎样把检索结果整理成便于团队使用的格式。后来，这些经验被整理成了一套标准操作手册，并在研发中心内部共享。

我们很看重这个变化。如果一个员工用AI把工作时间缩短了一半，收益首先体现在他自己身上。如果他愿意把方法整理出来，其他人也能使用，组织才开始积累一项可以持续复用的能力。当然，手册也需要随着模型、工具和业务要求变化而更新，不能整理一次就束之高阁。

七、质量场景推进最慢，讨论却没有白费

质量不良事件辅助分析，是三个场景中最难推进的一个。

质量部门担心的事情很具体：不良事件可能涉及患者安全、产品质量和监管责任。如果AI把原因分析错了，或者提出了不合适的纠正措施，后果可能远比一份普通文档写错严重。因此，质量团队坚持把AI的使用范围限定在辅助整理事实、检索历史记录、归纳相关信息等环节。根本原因分析、纠正措施制定以及需要承担正式责任的结论，必须由人来完成。

这个边界经过了多轮讨论。从进度看，它不如研发和销售场景顺利。但我们不认为这段时间白费了。因为企业终于开始认真讨论一件以前容易被忽略的事情：AI到底可以参与到工作流程的哪一步？

这不是一个单纯的技术问题。它涉及工作怎么拆分、哪些决策依赖专业经验、错误可能造成什么后果，以及谁有资格作出正式决定。经过讨论，团队逐渐接受了一种更实际的协作方式：AI帮助整理资料、查找关联、提示可能的风险，让质量人员更快获得需要的信息；专业人员负责分析原因、权衡风险、确定措施，并对正式结论承担责任。这个分工还需要通过实际验证不断完善，不能一次讨论就定型。但它已经让大家对AI参与质量工作有了更清晰的认识。

对于强监管行业来说，推进AI不必从完全自动化开始。有些环节可以自动处理，有些环节适合人机协作，还有一些环节必须保留严格的人工控制。把边界划清楚，项目才有可能持续推进。

八、三个月之后，公司还没有完成AI NATIVE，但已经知道下一步要解决什么

三个月下来，这家企业没有变成一家所谓的“AI驱动型公司”。三个场景的结果也不完全一样。研发检索取得了较好的效果，销售投标提高了材料准备效率，但暴露出产品数据管理的问题；质量分析推进缓慢，却让团队开始认真讨论专业判断、人工审核和责任边界。

对管理层来说，这些结果比简单地宣布三个项目全部成功更有参考价值。有几件事开始发生变化。

第一，管理层复盘AI项目时，不再只问做了几个项目、覆盖了多少员工，也开始问：这个应用有没有进入日常工作？哪些指标发生了变化？还有什么问题没解决？

第二，部分中层管理者开始调整自己的工作方式。质量经理逐步参与审核规则和风险边界的设计，专业经验仍然发挥作用，只是工作的着力点有所变化。对于暂时无法适应新要求的人，公司还需要通过培训、职责调整等方式继续处理，不能指望所有人自然完成转变。

第三，生产和质量部门愿意参与AI场景讨论了。合规要求仍然严格，但大家开始把合规要求写进应用设计，而不是在项目开始之后才发现不能用。

第四，管理层开始重新审视企业自己的数据基础。产品参数是否统一、研发知识是否能够检索、客户数据是否能够在授权范围内被调用、不同系统中的信息是否一致，这些问题都逐渐摆到了台面上。

之前，管理层担心的是AI投入不够、应用不够多；现在，他们开始担心公司能不能把AI接进真正重要的业务流程。

这两种焦虑带来的工作方向很不一样。前一种容易让企业继续买工具、办培训、开项目；后一种会让企业开始梳理数据、调整流程、重新分配责任，也会迫使管理者重新思考自己的工作。这些变化还不能说明企业已经完成了组织AI进化，但它们让下一步的工作变得更清楚了。

九、从这个案例看组织AI适配的四个维度

在我们AI组织进化的方法论中，组织级AI生产力=个体AI能力×组织AI适配度×AI时代领导力

组织AI适配度是当下大多企业在完成AI技术落地后的下一个卡点。把这家企业遇到的问题放在一起，可以看到四个方面需要同步考虑。

组织结构。 研发、销售、生产和质量各自有明确的职责，但业务任务往往跨越多个部门。企业需要考虑怎样围绕具体任务组合专业能力，怎样让AI进入工作流程，同时保留必要的专业分工和责任边界。

协作机制。 各部门都有自己的系统和工作方式，数据共享与跨部门协调仍然存在障碍。AI应用需要与数据治理、流程调整和信息共享规则一起推进，否则局部效率提高了，整体工作还是可能卡在部门之间。

激励机制。 员工借助AI提高个人效率之后，还可能形成可复用的知识、方法和工作流程。企业需要考虑如何识别这些贡献，如何让知识共享和流程改善得到合理评价，同时避免把AI使用频率当成绩效。

决策机制。 AI可以辅助分析，却不能自动获得决策权。企业需要明确不同任务的风险等级、人工审核要求、授权范围和责任主体，让员工知道哪些事情可以自己处理，哪些需要专业人员确认，哪些必须履行正式的审批程序。

这四个方面互相影响。如果岗位和部门边界没有调整，跨部门任务就很难组织起来；如果信息共享和协作流程没有理顺，AI生成的分析就可能停留在各自部门；如果员工的知识贡献得不到识别，方法和经验就很难持续积累；如果授权与责任不清，员工就会因为担心风险而不敢使用AI。

所以，企业推进AI时，除了看模型和工具，还要检查自己的组织能否承接这些变化。这也是我们在ANO Lab特别关注组织AI适配度的原因。

AI项目能不能走得远，常常取决于企业有没有把数据、工作流程、管理角色和责任机制一起考虑进去。

我们在这家企业的阶段性陪跑经历，还算不上是一个已经完成的转型故事，它更像是一个陪伴创始人与高管团队开始看清问题的过程，并获得阶段性成功。

AI确实帮研发人员节省了检索时间，也帮销售人员减少了大量重复的材料整理工作。但在这些具体的应用之外，企业还需要处理数据不统一、部门协作不顺、管理角色变化和责任边界不清等问题。这些工作没有一个能靠采购新工具直接完成。

对于企业管理者来说，接下来需要做的，是把AI放进具体的业务任务和工作流里，弄清楚哪些工作可以交给AI辅助，哪些地方需要重新设计流程，哪些数据需要先整理，哪些管理职责和决策权限需要调整。这项工作往往比上线一个工具慢，也不太容易在短期内做成漂亮的展示。但它决定了AI究竟只是员工手边的一个新工具，还是能够逐渐成为企业的一项新的组织能力。

对ANO Lab而言，我们关注的就是这件事：陪企业把AI从工具应用带进业务流程，再从业务流程的变化，逐步推动组织结构、协作机制、激励方式和决策机制的调整，完成从AI工具应用到AI原生组织的重构。

企业不必一开始就完成所有改变。先把一个场景做扎实，把其中暴露出来的问题解决掉，再把有效的方法逐步推广，往往更有希望走得长远。毕竟，AI工具可以很快买来，组织能力需要在一次次具体的业务实践中慢慢建立。