Should a 500-person company build its own internal AI assistant or buy Microsoft Copilot, Gemini, or ChatGPT Enterprise?

The advisors generally leaned toward buying an enterprise AI tool rather than building one, but emphasized that vendor maturity does not eliminate the need for strong data governance, permission hygiene, and workflow fit. For a 500-person company, they recommended a tightly controlled vendor pilot with budget discipline, department-level accountability, and adoption measured against real employee behavior, including shadow AI use.

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.

The advisors agreed that an AI assistant should be evaluated as an ongoing operating commitment, not a one-time implementation. They pushed the decision-maker to demand concrete proof that the assistant eliminates real work, can be supported safely in production, and handles permissions, audit logs, retention, and e-discovery correctly on actual company content.

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.

The advisors broadly favored buying an enterprise AI assistant rather than building one, but only with strong procurement, governance, and operational safeguards. They emphasized that the real decision is not just feature quality, but lock-in risk, support burden, authority over AI-generated outputs, second-year pricing, and whether any custom engineering creates durable advantage.

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.

The advisors broadly favored buying an enterprise AI assistant first, with capped seats and disciplined measurement, before funding any custom build. The main debate was whether procurement, finance controls, and vendor governance are enough to reveal whether AI is creating real value, or whether leadership confusion, weak workflow evidence, and poor access controls can still make a pilot look successful while changing little.

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.

The advisors converged on the view that the company is hiding behind a build-versus-buy AI debate instead of defining the actual work, owner, risks, and operating model. For a 500-person company, they favor starting with a narrow, painful workflow, assigning clear executive ownership, buying the least disruptive enterprise tool first, and continuing only if it demonstrably removes real work without creating unacceptable risk.

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.