The most widely deployed AI in the world is a seat on somebody else's system, and for a great deal of work that is the correct purchase.
A SaaS AI assistant and a bundled suite copilot are the same purchase in two wrappers: capability delivered per seat, running on the vendor's systems, governed by the vendor's controls. This page makes the case for them properly, then says exactly where that arrangement runs out and what replaces it.
A seat-based assistant is usually a very good product, built by large teams with more model access than we will ever have, and for most of the writing, summarising and searching that happens in an organization it is the sensible answer. Three conditions make it the right call, and when all three hold we will say so in the assessment rather than sell you something heavier.
Drafting, rewriting, summarising a meeting, turning a rough note into a paragraph. This is high-volume, low-consequence work where the value is the convenience and the content would not trouble anyone if it were read aloud. Paying per seat for it is efficient, and building it yourself would be absurd.
Material you would put in a public tender, a newsletter or an internal wiki that everybody can already read. If the honest answer to "what happens if this ends up somewhere it should not" is "very little", the data boundary is not the deciding question and you should not pay for one.
A copilot bundled into a suite you have already bought is a sunk cost with an installed footprint. Switching that work elsewhere buys you very little. Turn it on for the content it suits, do the permissions work it demands, and spend your governance budget on the part of the estate it cannot cover.
None of these four is a defect. They are consequences of the model: a shared service, priced per seat, run by a vendor whose controls are designed for every customer at once rather than for yours in particular.
The most common failure with a bundled copilot is not a breach. It is a discovery. An assistant that retrieves what the signed-in person is already allowed to retrieve turns years of accumulated over-sharing into a searchable index. The permissions were always wrong. Nobody could find anything before.
A survey of 132 IT leaders, about half of them at organizations with more than 10,000 employees, found that concerns about data over-sharing caused 40% to delay a bundled copilot rollout by three months or more. Around 64% said information governance and security risks took significant time and resources, and 57% managed the risk by limiting the rollout to low-risk or trusted users. Reported by Computerworld, 27 September 2024, from a Gartner survey conducted in 2024.
The mechanism is documented by the suite vendor rather than alleged by us. Its readiness guidance states that the assistant and its agents retrieve data and respect existing permissions, sharing settings and policies, that the default sharing setting is the most permissive option, and that those controls directly affect what the assistant can surface in a response. A whole step of the preparation guidance is headed "Prevent accidental oversharing". Vendor administrator documentation, last updated August 2026.
We are not exempt from this. Everything loaded into a deployment's knowledge base is readable by every user of that deployment, so you load only what everyone in the organization may see. Per-user and per-document permissions on retrieval are not built. The difference is that the boundary is your own account, the grant model is administered by your own people, and the limit is written on the product page rather than discovered in a review. Read it on chat and knowledge.
"It has a SOC 2 report" ends more security conversations than it should. A SOC 2 report is an attestation: a CPA firm examines a service organization's own controls against the Trust Services Criteria and issues an opinion about them. It describes the vendor. It does not certify you, it does not transfer your obligations, and it says nothing about whether your data flow can be scoped by your own reviewer. Source: AICPA and CIMA, System and Organization Controls.
A compliance obligation cannot be satisfied by somebody else's certificate.The line we use in every security review
Real evidence that a vendor operates a control environment somebody independent has examined. That is worth having, and a vendor who has one has done work a vendor without one has not.
Your configuration, your permissions, your retention election, your residency, the decisions your administrators make on a Tuesday. Those are your controls in your environment, and an examination of somebody else's organization has never covered them.
Technical controls designed to align with SOC 2 and ISO/IEC 27001, expressed as posture tiers, with a 17-row controls matrix carrying an enforced, partial or not-enforced verdict per row. We hold no third-party attestation, and we say so. Read the matrix.
| Question | A SaaS AI assistant | A bundled suite copilot | orgOS on a cloud you own |
|---|---|---|---|
| Who holds the data at rest | ✕The vendor | ✕The suite vendor | ✓You, in your own account |
| Can the data flow be scoped | △To their documentation | △To your sharing settings | ✓Architecture, posture, exceptions |
| Policy enforcement | △Vendor settings | △Tenant settings | ✓A deny in cloud identity policy |
| Custom business capability | ✕Their roadmap | ✕Their roadmap | △Modules, mostly not AI at all |
| Time to first use | ✓Same day | ✓Already installed | △Weeks. We quote no fixed number of days |
| What you keep if it ends | ✕Export files | ✕Export files | ✓The platform and its source |
Two of these rows go against us and we have left them that way. A seat you already pay for will always beat a deployment on time to first use, and often on polish. The question is whether those two rows are the ones that decide your sensitive work.
No, and most organizations should not. Keep the seats for ordinary drafting and put the sensitive, the regulated and the custom work inside a boundary you own. The failure mode is not running both. It is running both without deciding what belongs where, so the classification lives in each person's judgment.
It is a fair worry and it is the most common reason people call us. Rollouts usually disappoint for two reasons: the permissions were not ready, so the answers were either useless or alarming, and nothing was built against the organization's own processes. Our answer to the first is that the boundary and grants are yours to administer. Our answer to the second is modules, most of which do not call a model at all.
Probably the same family. We do not compete on the model and would not win if we tried: the catalogue is generated from the provider's live list, 104 active models from 18 labs as at 5 September 2026, and you choose from it. We compete on where the request runs, what is enforced around it, and who owns the account afterwards. See model access.
On our deployments, prompts are not used to train models and are not shared with model vendors, per the managed model service's terms. The one exception is disclosed: the newest frontier tier from one vendor requires provider-side data sharing with retention of up to 30 days, and those models are shown as unavailable until you elect that explicitly. It is never a silent upgrade. Details on model access.
Bring the seats you already pay for. The assessment maps which work belongs on them and which belongs inside a boundary you own.