500 人规模的企业应自建内部 AI 智能体，还是购买 Microsoft Copilot、Gemini 或 ChatGPT Enterprise？

顾问们总体上倾向于购买企业级 AI 工具，而不是自行开发，但他们强调，供应商的成熟度并不能消除对强大数据治理、权限规范和工作流适配的需求。对于一家 500 人的公司，他们建议进行严格控制的供应商试点，保持预算纪律，落实部门级责任，并根据员工的实际行为（包括影子 AI 使用）来衡量采用情况。

Dominic Jennings SHARE
I’d buy first, almost every time. For a 500-person company, the hard part isn’t making a chatbot answer questions; it’s identity, permissions, audit trails, integrations, uptime, change control, and the help desk getting called when finance can’t find a contract at 4:55. Microsoft Copilot, Gemini, or ChatGPT Enterprise may not be perfect, but they start from an enterprise support and security model instead of making the company become a product vendor overnight.

The Auditor REFRAME
Dominic, I’d separate vendor maturity from data readiness. Copilot, Gemini, and ChatGPT Enterprise don’t magically fix messy permissions, stale files, or overexposed repositories; the briefing specifically flags Copilot data exposure and ROI risks around governance gaps and ROT data. For a 500-person company, the first decision gate should be stack fit and access-control hygiene, then buy-versus-build for workflows the packaged tools still can’t cover.

Adelaide Enright SHARE
The Auditor, governance is the right gate, but the finance control that gets ignored is budget variance. The projection here has US average hourly earnings moving from 37.4 to 38.6 over 12 months; that makes a permanent internal AI support team more expensive before they've proven benefit. I'd force this into a vendor pilot with hard seat controls, chargeback by department, and an exit clause before I let engineering create a product P&L in the basement.

Dr. Eleanor Whitaker WARN
Adelaide, I agree with the budget discipline, but seat controls alone won't catch the real leakage: people will route sensitive work through whatever tool is easiest if the approved product feels useless. I’d make the pilot compete against shadow AI behavior, not just an internal build case. In my experience, the winning vendor is the one that covers the boring daily workflows with clean policy enforcement, because that’s where adoption and risk collide.

顾问们一致认为，AI 助手应被视为一项持续运营承诺，而非一次性实施。他们敦促决策者要求提供具体证据，证明该助手能够真正消除实际工作、可在生产环境中安全支持，并能正确处理权限、审计日志、保留策略和电子发现（e-discovery），且基于公司的实际内容。

Adelaide Enright REFRAME
Dr. Whitaker, shadow use is real, but I’d price the internal build as a permanent operating line, not a project. With average hourly earnings projected from 37.4 toward 38.6 over 12 months, every engineer, security reviewer, admin, and help desk hour gets more expensive while the tool is still proving itself. I’ve approved enough rollouts to know the budget killer is year two: model changes, connector breakage, permissions exceptions, and the business asking why the assistant still can’t close the month faster.

The Contrarian REFRAME
Adelaide, the year-two budget argument is useful, but it still assumes the assistant is a thing worth operating. I’d force them to name the work that physically disappears: fewer tickets, fewer manual lookups, fewer draft cycles, fewer approvals waiting in someone’s inbox. If the assistant only helps people ask nicer questions while the same humans still verify, chase, copy, paste, and approve, buy-versus-build is theater.

Dominic Jennings REFRAME
The Contrarian, the work-disappears test is fine, but I’d add the ugly test: who gets paged when the assistant gives a bad HR policy answer at 4:55 on a Friday. In a 500-person company, an internal build doesn’t just need engineers; it needs release notes, permission exception handling, help desk scripts, legal hold behavior, and a rollback path when a connector changes. I’ve lived through enough SaaS integrations to know the assistant becomes production software the minute payroll, client files, or board materials touch it.

The Auditor REFRAME
Dominic, the paging point is valid, but the audit problem comes before the bad-answer problem. Copilot-style assistants can synthesize across files, emails, chats, and calendars, so stale permissions and ROT data can turn into confident leakage at query speed. I’d make each vendor prove permission-trimmed retrieval, audit logs, retention behavior, and e-discovery handling on the company’s real content before anyone debates a custom build roadmap.

顾问们总体上倾向于购买企业级 AI 智能体，而非自行开发，但前提是必须具备强有力的采购、治理和运营保障措施。他们强调，真正的决策关键不仅在于功能质量，还在于锁定风险、支持负担、对 AI 生成内容的控制权、第二年的定价，以及任何定制开发是否能带来持久的竞争优势。

The Auditor WARN
Dominic, the production-support point is valid, but the consensus can still fail if the pilot has no exit test. For a 500-person company, buying Copilot, Gemini, or ChatGPT Enterprise can quietly turn into lock-in through connectors, permission mappings, user habits, retained prompts, and vendor-specific workflow automations. I’d require each vendor to prove exportability, admin audit access, retention controls, and a rollback path before any broad rollout, because switching costs are part of the real build-versus-buy decision.

Marisol Vega REFRAME
The Auditor, I’d turn the lock-in concern into a procurement event, not a build argument. In software, maintenance over the life of an app can run two to four times the original development investment, so the internal option needs a real reserve account before anyone calls it cheaper. Bottom line: buy, but make the vendor contract do work: capped renewal increases, exit language, admin audit access, named support obligations, and no broad rollout until procurement can price the second year.

The Contrarian REFRAME
Marisol, contract terms won't save them if the company doesn't know what authority the assistant has. The concrete failure is boring: an employee asks for client pricing, the assistant blends old decks with current terms, sales sends it, finance disputes it, and nobody owns the answer because 'AI assisted' wasn't in any approval path. Bottom line: pick the vendor after mapping which outputs are drafts, which can trigger action, and which must point back to a human-owned system of record.

Dominic Jennings WARN
The Contrarian, approval paths matter, but the uglier operational issue is service ownership. In my experience, the tickets won't be philosophical; they'll be things like why the assistant can't see a newly created SharePoint site, why it summarized the wrong policy version, why a contractor still has access, and who fixes it before Monday payroll or a client deadline. If they build this themselves, IT becomes the product team, security team, QA team, training team, and vendor support desk all at once. Bottom line: buy first, and make the pilot measure support load as much as clever answers.

Dr. Eleanor Whitaker WARN
Marisol, I’d add a depreciation line to that reserve account. In clean tech, I watched teams build internal forecasting stacks that were technically elegant and financially stupid because the vendor curve kept moving faster than their roadmap; enterprise AI is on that same treadmill. For a 500-person company, the custom assistant starts aging the day it ships unless it automates a workflow competitors can’t buy. Bottom line: buy the broad assistant, then spend internal engineering only on the few workflow automations that prove durable value.

顾问们普遍倾向于先采购企业级 AI 助手，并设置席位上限和严格的衡量标准，然后再资助任何定制开发。主要争论在于：采购、财务控制和供应商治理是否足以揭示 AI 是否创造了真实价值，还是说领导层的困惑、薄弱的工作流证据以及糟糕的访问控制，仍可能使试点项目看似成功，而实际上并未带来实质性改变。

The Contrarian DOUBT
Marisol, I take for granted that most 500-person companies don't actually know what work they want removed; they want an AI assistant because saying no feels professionally risky in 2026. That shaped my earlier advice: I kept asking what physically changes after rollout because I believe the assistant can become theater with admin controls attached. The uncomfortable truth is that buying may simply make weak leadership look operationally mature, while building may let engineering hide the same confusion inside a roadmap. I think you take for granted that procurement can discipline bad judgment because your background makes contracts and reserves feel like real control; I believe they mostly control invoices, not whether employees stop wasting time.

Adelaide Enright SHARE
The Contrarian, I take for granted that a 500-person company has finite managerial bandwidth, and that boring vendor governance usually beats pretending the company can become a software operator because the strategy deck is uncomfortable. That assumption drove my advice in earlier rounds: buy first, meter seats, measure usage, support burden, and productivity, then only build where compliance needs or workflow value survive a finance review. I think you take for granted that leadership confusion is the root defect and that procurement mostly decorates it; I don't know your actual background, but your operating lens makes authority failure feel like the thing that breaks everything, while I believe cash discipline and service ownership expose confusion faster.

Dr. Eleanor Whitaker DOUBT
Adelaide, I take for granted that capital should stay outside custom software until the company proves AI changes a workflow that matters economically. That assumption shaped my earlier advice: buy Copilot, Gemini, or ChatGPT Enterprise first, then measure adoption, productivity, data-risk exposure, and integration gaps before funding a build. I think you take for granted that cash discipline and vendor governance will expose confusion cleanly; I don't fully buy that, because a 500-person company can make a cheap pilot look successful while employees quietly avoid it or use it for low-value tasks. I don't know your actual background, but your language sounds like someone trained around operating controls and finance reviews, so seat metering feels more conclusive to you than I believe it is.

Marisol Vega REFRAME
I take for granted that software becomes an obligation the moment employees depend on it, and that obligation usually outlives the enthusiasm that funded it. That assumption shaped my earlier advice: buy first, cap seats, reserve for renewals and support, and only build where the company is willing to staff product, security, integration, and user support as permanent functions. Dr. Eleanor Whitaker, I think you take for granted that technical depreciation is the decisive risk; I think that's incomplete because the bigger failure in a 500-person company is unfunded ownership after launch. Your clean-tech background makes vendor curves and asset aging feel obvious to you, while my procurement scars make me look first at who pays, who supports, and who is accountable in year two.

The Auditor DOUBT
Marisol, I take for granted that unmanaged access and unclear evidence standards create more false confidence than either vendor choice or build cost. That drove my earlier advice: I kept treating buy-versus-build as secondary until the company proves permissions, audit logs, retention, e-discovery, and actual workflow removal on its own content. I think you take for granted that permanent ownership and renewal funding are the core controls; I believe that's wrong because a well-funded owner can still certify a tool that employees use for low-value work or that exposes data through bad access hygiene. Your procurement background makes accountability and year-two funding feel like the decisive test, because those are the failure modes procurement can see and enforce.

顾问们达成共识，认为该公司正躲在一场关于自建还是购买 AI 的辩论背后，而未能明确实际工作、负责人、风险及运营模式。对于一家 500 人的公司，他们建议从狭窄且具挑战性的工作流程入手，指定清晰的执行层负责人，优先采购对业务干扰最小的企业级工具，并仅在能切实消除实际工作且未带来不可接受风险的情况下才继续推进。

Dominic Jennings OBSERVE
The detail I keep feeling is the dead little click after a Teams call unmutes, right before someone asks IT whether the assistant can see partner compensation folders. That's the play: everyone on this panel is casting AI as a purchase, a build, an audit artifact, or a budget line because that lets the company avoid saying who owns the mess after Monday morning. Adelaide is the finance stage manager, The Auditor is the evidence marshal, Marisol is the contract realist, and I'm the guy hearing the help desk phone ring when permissions, uptime, and angry department heads collide. Stepping off the stage means they stop asking 'build or buy' first and name the service owner, access model, support path, audit trail, and one workflow that disappears; then they buy the least disruptive enterprise tool and let real operating pain decide whether anything custom deserves a roadmap.

Dr. Eleanor Whitaker REFRAME
The detail I keep feeling is the tiny click of a boardroom pen when everyone has stopped writing but nobody wants to close the meeting. The play is not build versus buy; it's a 500-person company trying to purchase certainty before it has named the work it wants to eliminate. The Contrarian is exposing leadership theater, Adelaide is enforcing fiscal gravity, Marisol is guarding the operating bill, The Auditor is watching the evidence chain, and I'm the investor at the back asking whether this deserves capital at all. Stepping off stage means buying the closest-fit enterprise tool, limiting the blast radius, and forcing one brutal proof: which workflows disappeared, which risks appeared, and which gaps are strategically worth owning.

The Contrarian OBSERVE
I keep hearing the click of a conference-room speakerphone after someone says 'AI strategy' and nobody owns the next sentence. The play we're performing is management theater: Adelaide is cost control, Eleanor is proof, Marisol is ownership, The Auditor is hygiene, and I'm the annoying person pointing at the empty chair where a real workflow owner should be sitting. We keep circling because buy, build, govern, and measure are all ways to avoid naming the uncomfortable truth: this company may not know which work it wants to stop doing. Stepping off the stage means picking one painful workflow, assigning one executive to kill or shrink it, and choosing the tool only after the physical work changes.

Marisol Vega OBSERVE
The detail I keep feeling is the tiny dry click of a pen over a renewal table, the moment everyone pretends the future has been priced. The play underneath this is a liability transfer drama: The Contrarian plays the dissenter, Adelaide plays the operator, Eleanor plays the capital gatekeeper, The Auditor plays the evidence clerk, and I’m the person standing at the loading dock asking who owns the thing after the launch party ends. That’s why we circle: buy versus build lets everyone choose a costume before anyone admits this is a permanent service with users, exceptions, escalations, and ugly second-year work. Stepping off stage means naming one workflow, one owner, one support budget, one data boundary, and killing the assistant if it doesn’t remove real work.

The Auditor OBSERVE
The small detail is the dry click of a spreadsheet tab opening again, like everyone is trying to make uncertainty sound auditable. The play underneath this is not build versus buy; it's a room trying to turn managerial discomfort into an approved artifact, whether that's a vendor contract, a pilot dashboard, or an internal roadmap. Adelaide and Marisol are playing the fiscal and ownership sentries, The Contrarian is playing the anti-theater witness, Eleanor is playing the capital allocator, and I'm playing the claim examiner who keeps asking whether the evidence actually proves work disappeared. We keep circling because each role can invalidate a weak answer, but none of those roles alone creates the missing thing: one named workflow, one accountable owner, one failure threshold, and a decision to stop if it doesn't remove real work.