What the term really means, how the architecture works and why “build or buy” is the wrong question.
A typical case: Miriam from purchasing asks her new company assistant which per diem rates apply to business trips to the Czech Republic. The answer is correct, complete with a source reference. Except that it does not come from the travel expense policy but from a spreadsheet in accounting: the evaluation of all business trips settled in the previous year, with names, destinations and individual amounts. Miriam should never have had access to that file.
The retrieval layer had found the most relevant source in terms of content, which is exactly what it is built for. The language model had processed it correctly. The error lay one level deeper: relevance had been checked, permission had not.
This layer is what this article is about.
The Key Points Up Front
- An enterprise GPT is not a language model and not a single piece of software, but a layer made up of seven building blocks between employees and systems.
- “GPT” is a type of language model, not a product category. If a provider calls its product “Company GPT”, that says nothing yet about the scope of its functions.
- A custom GPT and an enterprise GPT sit at different levels; they are not alternatives.
- The six providers examined here are converging in their scope of functions, not in their architecture.
- For knowledge-based assistants, the retrieval architecture matters more than the choice of model.
- “Build or buy” is the wrong way to put it. 78.3 percent of those surveyed by BCG run a hybrid approach.
- The price per token is falling, the price per completed task is not necessarily.
- Of ten documented practical cases, exactly one has an external impact measurement.
The article follows three questions: What is it? How do you build it properly? And do you have to build it yourself? It builds on our comparison of the AI building blocks from OpenAI, Anthropic, Google and Microsoft.
I. What an Enterprise GPT Is
An enterprise GPT is a centrally provided AI working environment governed by the company. Through it, employees reach general AI capabilities, internal company knowledge and, depending on the stage of development, company systems, tools and agents. Existing identities and permissions are taken into account. The language model underneath can, but does not have to, come from OpenAI.
“Governed” rather than “controlled” is deliberate. An enterprise GPT delivered as SaaS is not under the technical control of the company, but it is under the company’s steering when it comes to users, data sources, policies and approvals.
A self-trained model or a simple document chatbot is not yet such a platform in its own right. In the market, however, the term “Company GPT” is also used for these simpler stages of development, see the table further below. Also not a knock-out criterion: an enterprise GPT does not have to be developed in-house, nor run in your own data center.
It Is Not Software, but a Stack of Seven Layers
| Layer | Content | Typical question |
|---|---|---|
| 1 Interface | Chat, Teams, browser, mobile, Office | Where do people encounter it? |
| 2 Identity & Access | SSO, SCIM, RBAC, user and agent identity | Who is this, and what is the person allowed to see? |
| 3 Assistants & Skills | Roles, instructions, process knowledge | How does our company work? |
| 4 Enterprise Knowledge | Retrieval, index or live retrieval, life cycle | What does our company know? |
| 5 Tools & Connectors | MCP, APIs, ERP, CRM, M365 | What can it query and trigger? |
| 6 Agents & Workflows | Planning, actions, approvals | What is it allowed to do on its own? |
| 7 Model Layer | GPT, Claude, Gemini, Mistral, local | Which model does the computing? |
Running across all of them are governance, security, logging, cost, quality measurement and the ability to exit.
Briefly explained: an API is a programming interface. A token is the providers’ billing unit, roughly a word or a syllable. RAG (retrieval-augmented generation) means searching for matching excerpts from sources and passing them to the model so that it can base its answer on those sources. MCP (Model Context Protocol) is the open standard for connecting tools and data sources, developed by Anthropic and handed over to the Linux Foundation in December 2025, with AWS, Google, Microsoft and OpenAI as platinum members. Skills are reusable work instructions or capability packages; Anthropic describes them as file-based via Markdown, other providers solve it differently.
In simple architecture sketches, the interface, knowledge, connectors and model usually take center stage, that is layers 1, 4, 5 and 7. Identity, reusable work logic and the governance of agents are easily underestimated. That is precisely where the development lies in 2026, and precisely where problems arise that are hard to retrofit later.
Five Stages of Development
| Stage | Capability | Focus |
|---|---|---|
| 1 Secure AI | handle general tasks securely | Enterprise Chat |
| 2 Know | know the company | Retrieval, Enterprise Search |
| 3 Connect | query live systems | Connectors, MCP, APIs |
| 4 Act | carry out actions in systems | Tools, Function Calling |
| 5 Work | work in several steps and correct itself | Agents, Workflows, Skills |
With every stage, the integration, security and governance effort rises considerably. How such an ascent plays out in reality is shown by the Hostinger case further below.
Why the Term Is Confusing Nonetheless
GPT stands for generative pre-trained transformer and denotes a type of language model. That is not a clearly delimited product term. Both the US trademark office and the European trademark office have classified the designation as descriptive; the proceedings are in part not finally concluded. For buyers, something more practical than the legal situation follows from this: “Company GPT” initially says almost nothing about the product.
Five Meanings, One Word
| Variant | What is actually meant | Documented example |
|---|---|---|
| Simple | secure internal ChatGPT | ONTEC, Vienna: “your private GPT, like ChatGPT, but your data stays inside your organization” |
| Knowledge | chat plus company documents | numerous small providers |
| Platform | several models, permissions, connectors | codecentric c4 GenAI Suite, Apache 2.0 |
| Advanced | additionally tools and company systems | Langdock, Berlin |
| Agentic | additionally agents, workflows, actions | CompanyGPT from innFactory, Rosenheim |
Custom GPT and Platform Sit at Different Levels
A custom GPT is a configuration layer inside ChatGPT. It stays on the platform: OpenAI runs the infrastructure and the model layer, the creator configures instructions, knowledge files and, where applicable, tools and actions. An enterprise GPT, by contrast, denotes the platform itself. The one can be a component of the other.
Those who run the platform themselves typically assemble it from five components: interface (Chainlit, Streamlit, LibreChat, Open WebUI), backend with application logic and authentication, database for configuration, histories and vector search (MongoDB, Qdrant, Weaviate), a mediation layer to the models (LiteLLM, Portkey) and the language model itself.
Licensing notes that matter when choosing building blocks: since version 0.6.6, Open WebUI is no longer pure BSD-3; from 50 users onward the branding may no longer be removed. LibreChat is under MIT and is therefore the most straightforward white-label option. Dify prohibits multi-tenant operation on the basis of the source code. Flowise was discontinued in the summer of 2026.
We broke down the differences between assistants, skills, tools, connectors and agents in the provider comparison.
The Starting Position in Figures
Bitkom, 604 companies with 20 or more employees, field period calendar weeks 27 to 32 of 2025:
| Metric | Value |
|---|---|
| Companies using AI | 36 percent (2024: 20 percent) |
| with direct GenAI access for employees | 26 percent, a further 17 percent are planning it |
| with rules for AI use | 23 percent (previous year 15 percent) |
| that suspect private AI use | 4 out of 10 |
| shadow AI “widespread” | 8 percent (2024: 4 percent) |
On the employee side, Bitkom from 5 May 2025, n=1,005: 45 percent use generative AI at work with their employer’s knowledge, 10 percent without. That is the actual trigger for most projects. Not an innovation strategy, but the observation that the workforce has long since started.
The benefit at stake here is well quantified. For “State of Teams 2025”, Atlassian surveyed 12,000 knowledge workers in six countries and 200 executives from Fortune 1000 companies. The finding, verbatim: “leaders and teams waste 25% of their time just searching for answers”. A quarter of working time goes on searching for information that has long been available inside the company.
What the Providers Deliver
| Provider | Put simply | Product names and distinguishing feature |
|---|---|---|
| OpenAI | ChatGPT plus company knowledge plus apps | Company Knowledge; apps can write: “moving beyond read/search … including write/modify actions” |
| Microsoft | Copilot plus work context plus agents | M365 Copilot, Work IQ, Copilot Studio, Entra Agent ID, Agent 365. Work IQ is “a workplace intelligence layer that enables agents to access and reason over organizational data, context, and tools”, in Copilot Studio explicitly preview |
| Anthropic | Claude plus enterprise search plus MCP | “Ask Your Org”. No central index: “Search results are generated by making MCP calls. No data from connected services are indexed in our systems for serving queries” |
| Gemini plus connectors plus agents | Gemini Enterprise, Agent Platform, A2A integration | |
| AWS | central work assistant plus automation | Amazon Q Business “is no longer open to new customers”, successor Amazon Quick |
| Mistral | enterprise assistant flexible in model and operation | since 28 May 2026 Vibe, formerly Le Chat. Serverless, dedicated VPC or self-hosted |
The stacks are converging in their core scope of functions. The architectures behind them are not: central index versus live retrieval, suite-bound versus model-agnostic, seat price versus consumption-based billing.
II. How the Layer Is Built
Type 0: When No Retrieval Is Needed at All
Before it comes to architectures, the question that precedes them. Modern models have context windows of up to one million tokens. With a small, clearly delimited set of documents, a single contract for example or a one-off data extraction, direct processing in the context window can be simpler and often also more accurate than an additional retrieval pipeline.
Anthropic handles it that way in its own product. From the help page on Projects, as of 11 September 2026: “When possible, projects will use in-context processing for optimal performance” and “RAG automatically activates when your project approaches or exceeds the context window limits”. If the project content later falls back below the threshold, it switches back.
Rule of thumb: only when the material grows, the same kind of question recurs or the knowledge changes continuously does retrieval gain considerably in value. A large context window does not mean, however, that models reliably find everything in it. File format, tool limits, latency and the choice of model also come into play.
The Architecture Decision: Three Retrieval Designs
For knowledge-based enterprise assistants, the retrieval design is often more important than the choice between GPT, Claude or Gemini.
| Type | How it works | Permissions | Currency |
|---|---|---|---|
| A, synchronised index | documents are split, embedded, centrally indexed | access rights have to be carried along as metadata and maintained | state of the last index run |
| B, federated search | query to the search index of the source system | source system decides | currency of the source system |
| C, live retrieval | no index, retrieval at runtime via tools or MCP | user authenticates against the source system | no additional index delay |
Evidence: AWS on type A, “connectors index access control list (ACL) information that’s attached to a document along with the document itself”. Microsoft on type B with synchronised and federated patterns. Anthropic on type C, without an index for answering.
Running across these, two extensions. Agentic retrieval, documented at AWS since August 2025: “Intelligently deconstructs complex queries into simpler ones”, several search passes, quality check. And the structured query, that is a database query instead of a document search, when the answer is in a table.
With periodic indexing, contents and rights potentially remain out of date until the next synchronisation run, so with a nightly run for up to 24 hours. Type C avoids that, but it does not solve retention periods, caches, log data or the quality of the source data.
Why Retrieval Works Badly in Practice
The design decides where the permission check sits. The quality of the hits is decided by two other levers, and both are frequently underestimated in simple in-house builds.
Hybrid search. Pure semantic search is strong on meaning and weak on proper names, article numbers and technical terms. That is why a classic keyword search runs in parallel, technically usually BM25, and the two hit lists are merged into one. If somebody searches for an article number, the correct hit quickly lands in third place semantically and thus drops out of the answer. With hybrid search it is in first place.
Reranking. After that, a separate reranker model assesses each preselected text passage once more against the original question and sorts it anew. Twenty rough hits become three precise ones. Models like these are bought in, not developed in-house.
With questions that connect several logical steps, for instance “which employee looked after customer X in 2023, where a contract with a force majeure clause was used”, pure similarity search quickly reaches its limits. One possible answer is knowledge graphs, which store knowledge as a network of entities and relationships. Other routes are metadata filters, structured data queries or several retrieval steps in sequence. Knowledge graphs are powerful and expensive to maintain, so for most use cases they are the second step, not the first.
Permission Before Relevance
That is the point from Miriam’s case, and at the same time a data protection topic that the German data protection supervision addresses explicitly. In October 2025, the Data Protection Conference published a guidance document on RAG. The key sentence: “By comparison, it cannot be controlled within the language model (LLM) itself which information particular users may access.” In the retrieval subsystem, by contrast, “established technical and organisational measures, such as tenant separation/functional separation and the rights and roles concept”, are applicable, and are to be examined “already as part of the design”.
All the large providers formulate the same principle. AWS places the access rights next to every indexed document, Microsoft and OpenAI refer to the rights of the source system, and Anthropic delivers only “data you have permission to access in the original systems”.
Two documented pitfalls:
- Microsoft Copilot connectors can be set to “Visible to everyone”, with an explicit oversharing warning. Changing the rights afterwards is currently not supported.
- For cleaning up overly broad shares, Microsoft has a guide of its own, purpose verbatim “remediating oversharing”.
AI Does Not Invent Oversharing, It Makes It Visible at Scale
What an enterprise GPT makes visible first of all is one thing above all: permission problems that had long been there. That is why cleaning up the shares is a precondition of the project and not rework.
But it does not stop there. Indexes, caches, tools and agents add new risks: outdated copies of access rights, information that only becomes sensitive in combination, overly broad tool permissions and prompt injection via indexed content.
Documented incident: EchoLeak, CVE-2025-32711, disclosed on 12 June 2025, CVSS 9.3, zero-click against Microsoft 365 Copilot. A prepared email was indexed; on any later user question the payload smuggled context data to the outside. Fixed in the June patch day.
Risk model: Simon Willison calls the combination of access to private data, contact with content controlled by others and the ability to communicate externally the “lethal trifecta”. As soon as a system combines these three properties, it is vulnerable. With the Connect and Act stages, exactly this scenario becomes increasingly realistic.
When the System Acts
As long as it answers, the worst risk is a wrong or overly permissive answer. As soon as it acts, the question becomes: what damage can it do? The workable answer is a ladder of autonomy on which it is defined per process how far the system may go:
read → analyze → propose → prepare action
→ human approval → execute → autonomousA reference implementation is documented by the Rosenheim-based provider innFactory for its Microsoft 365 integration. Every tool call runs with the identity of the signed-in user, writing actions are deliberately designed to be restrained, and verbatim: “Emails are created exclusively as drafts; sending always remains a conscious decision by the user.”
Connected with this is a topic that tends to be overlooked in Germany. A self-operated system logs user IDs, prompts and histories. On 16 January 2024 (24 BVGa 1/24), the Hamburg Labour Court denied a co-determination right under Section 87(1) no. 6 BetrVG, because the employees used ChatGPT via private accounts and the employer had no access to the data collected. With a system of your own, precisely this precondition falls away. No decision on that exists, but co-determination should nevertheless be factored into project planning.
As soon as agents run alone at night or call each other, the user identity is no longer enough. Then you need machine identities of their own, short-lived credentials, minimal rights and traceable attribution. Microsoft has offered Entra Agent ID and the control plane Agent 365 for this since May 2026; work on open standards has been under way at the W3C and the IETF since the spring of 2026. None of it is finished.
III. Do You Have to Build It Yourself?
What the Surveys Say
| Source | Finding |
|---|---|
| BCG and Kore.ai, April 2025 | Question “Which best describes your organization’s AI strategy?”: hybrid 78.3 percent, build in-house 5.0 percent, buy third-party 16.7 percent. Sample size not stated |
| BCG, September 2025, 1,250 CxOs | “11% of firms rely primarily on in-house development, and just 4% depend on a single, end-to-end vendor” |
| McKinsey, August 2026, n=1,719 | Counter-finding: “Nearly a third of respondents (32 percent) report that their organizations have decided against purchasing at least one software product or feature because they were able to build the functionality in-house using agentic coding tools” |
| Gartner, June 2025 | “Over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls” |
Careful with the 95 percent figure. A study by MIT from July 2025 is reproduced everywhere as “95 percent of AI projects fail”. Something else was measured: in the sample, externally developed solutions reached production roughly twice as often as ones built internally, around 67 versus 33 percent. Around 80 percent of the organisations surveyed never had a custom pilot, yet count towards the 95 percent. The basis is 52 interviews and 153 questionnaires, the success criterion is not defined, there was no peer review, and all four authors commercialise agentic systems.
Three Axes Instead of One Alternative
The options do not lie on a single line:
- Sourcing form: buy, compose, build. The implementation can be no-code, low-code or classically programmed
- Operating model: shared SaaS, dedicated VPC, own tenant, on-premises or sovereign cloud
- Stage of development: the five stages from above
The implementation method is often confused with the sourcing form. Low-code platforms such as n8n or Make are not a fourth option alongside buy, compose and build, but a way of implementing compose or build. They are particularly suited to assembling first workflows quickly from existing APIs, models and data sources, including a retrieval pipeline. n8n can also be self-hosted, other offerings such as Make are primarily SaaS. As process complexity grows, however, maintenance and governance effort rises quickly, and low-code does not make a poorly defined process any better either.
The axes can be combined freely. Mistral Vibe exists serverless, in a dedicated VPC and self-hosted. The German CompanyGPT is purchased software in the customer’s own tenant. Merck is compose in sourcing form and SaaS in operation. The equation “in-house equals sovereign” does not hold on these axes.
Ten Practical Cases, One Measured Benefit
| Case | Approach | Documented result / usage | Evidence |
|---|---|---|---|
| Bayer myGenAssist, since 09/2023 | Compose on GPT-4 Turbo, hosted by Bayer | JMIR study 03/2025, 122 pharmacovigilance cases, 22.25 to 16.97 minutes per case, “23.3% (95% CI 13.8%-32.8%; P<.001)”. “more than 40k employee users” | peer-reviewed |
| Otto Group ogGPT, since 09/2023 | Build on Azure OpenAI | “More than 10,000 active monthly users … more than 420,000 messages per month” (12/2025) | operator statement |
| Merck myGPT Suite | Compose, own chatbot plus Langdock | Start 10,000, after six months more than 25,000 users, “more than 3,000” agents. Not for clinical, regulatory or GxP data | vendor case study |
| Deutsche Telekom AskT, since 2024 | Buy, switched platform partner from Glean to UnifyApps | no user numbers published | operator statement |
| Cisco AI Assistant | Build, with agent and MCP registry | more than 100,000 users, more than 45 million interactions, 73 percent report higher productivity. CIO.com gives diverging figures of 96,000 users and 72 percent | operator statement |
| Hostinger DEX | Build, evolution through the stages | Started as a chatbot with handbook search, early 2026 “roughly 30 systems”, May 2026 “182 custom agents”, usage tripled from February to May to more than 10,000 answers per week | operator statement |
| Deloitte PairD, 01/2024 | Build on GPT-3.5 | available for “Deloitte’s 5,900+ Belgian employees” | operator statement |
| LLMoin, Hamburg and Dataport, since the end of 2024 | Build, public sector, model-agnostic | “More than 92,000 users” in seven federal states | operator statement |
| F13 Baden-Württemberg | Build, public sector, open source since 07/2025 | beta for around 79,000 teachers | operator statement |
| FEHRMANN Materials X, Hamburg and Lüneburg, unit since 06/2023 | Build, the internal tool became a product | matGPT and matOPT for alloy development and industrial knowledge. Company statement: “Development cycles that used to take months can now be reduced to just weeks or even days” | operator statement |
Two remarks. For none of the cases examined is a self-trained foundation model documented; what is built is in each case the layer above it. And F13 does not run on Aleph Alpha: on 23 July 2025, the State Ministry of Baden-Württemberg wrote that “after the expansion of the software into a full product, the startup Aleph Alpha is no longer involved in the full version of F13”. The full version was developed by InnoLab_bw and PD.
Two cases are particularly instructive. Hostinger makes the stages visible: first handbook search, then system integration, then self-built agents from engineering, marketing, QA, product and design.
FEHRMANN shows that the calculation does not have to end at efficiency. In June 2023, the Hamburg aluminium specialist founded a unit of its own in order to accelerate alloy development with AI, turned it into a customer solution and today runs it as a separate GmbH with an enterprise platform. An internal tool became a line of business.
The case is only comparable with the others to a limited extent: it addresses specialised materials and development knowledge, not a company-wide employee assistant. But precisely for that reason it shows how an external product can emerge from an internal AI layer. Two clarifications: the figure doing the rounds, “from five years to two to four weeks”, appears in no traceable source; only vague variants are documented. And matGPT today is the knowledge system; the alloy optimisation is called matOPT.
What It Costs, in Brief
Four pricing logics are on the market, and the choice between them matters more than the list price:
- Seat price, fixed per user and month. Microsoft 365 Copilot, 30 US dollars paid annually, on top of the existing M365 licence.
- Seat price plus consumption. Claude Enterprise, 20 US dollars per seat, at least 20 seats, plus usage at API rates.
- Purely consumption-based, by actions, credits or tokens. Copilot Studio, 200 US dollars per 25,000 credits; one agent action costs five of them.
- Project plus operation, without a user fee. CompanyGPT from innFactory, 14,990 euros setup, 399 euros per month, infrastructure 500 to 5,000 euros.
Two sentences worth remembering. The price per token has been falling dramatically for years, the price per completed task has not: in March 2026, MIT shows that the operating costs of the respective best models rise by a factor of 3 to 18 per year, because reasoning models consume far more tokens for the same task. And in July 2026, McKinsey formulates the consequence: “The unit of governance should be the completed business outcome, not the token cost.”
Which pricing logic fits depends on the type of usage, and the same calculation comes out in opposite ways for four types: for occasional users, bundled or consumption-based offerings are attractive; for intensive human users, a fixed seat price can be cheap; for automated agents, consumption dominates, because what counts is the number of runs and not the number of heads; and with constant high load, running it yourself can become interesting on paper.
Measuring Quality, at Four Levels
| Level | Question | Metric |
|---|---|---|
| Retrieval | Does the system find the right sources? | Recall@k, share of answers without a solid source |
| Answer | Is the answer correct, complete, compliant? | Factual fidelity against a gold standard, source grounding |
| Tool and agent | Does it choose the right tool in the right order? | Selection accuracy, number of steps, impermissible actions |
| Business outcome | Does the work change measurably? | Cycle time, rework rate, cost per case |
The fourth level explains the most striking pair of figures in recent research. McKinsey, August 2026: 80 percent of respondents report higher personal productivity, 37 percent a positive contribution to operating results. Access to AI can increase personal productivity. Company value only arises when the process improves.
The 70 Percent This Article Was Not About
Everything described so far is technology and architecture. BCG has examined how successful AI transformations distribute their effort. Verbatim, from “From Potential to Profit”, January 2025: “They dedicate 10% of their efforts to algorithms; 20% to data and technology; and 70% to people, processes, and cultural transformation.”
Ten percent algorithms, twenty percent data and technology, seventy percent people, processes and cultural change. The split often circulates the wrong way round, hence the original attribution.
This is not a progress bar. You cannot conclude from it that thirty percent of the project is done once the technical work is finished. The point is a different one: even a technically excellent platform solves only the smaller part of the problem. The greater effort lies with processes, roles, training, adoption and change management, and this article does not deal with it.
In brief: the AI Act. The Digital Omnibus is Regulation (EU) 2026/1744 of 8 July 2026, in force since 27 July 2026. The prohibitions under Art. 5 and the AI literacy requirement under Art. 4 have applied since February 2025, the GPAI obligations since August 2025, the transparency obligations under Art. 50 since August 2026. The high-risk obligations under Annex III were postponed to December 2027, those under Annex I to August 2028. A purely internal knowledge assistant typically does not fall into the high-risk categories. If HR applications under Annex III no. 4 are added, a case-by-case assessment under Art. 6(3) applies: the system does not count as high-risk if it “does not pose a significant risk of harm to the health, safety or fundamental rights”, for instance in the case of a narrow procedural task or preparatory activity. Counter-exception: it remains “always … high-risk where the AI system performs profiling of natural persons”. Art. 6(4) requires a documented assessment.
Decision Sequence
- Measure the current state. Who uses what today, with which accounts? Without that figure you are planning against a phantom.
- Assess use cases with a profile sheet. Required data, volatility, target group, measurable benefit, technical prerequisites. For every knowledge-based case, a data owner responsible for the subject matter should be named.
- Clean up permissions, before the technology. A precondition of the project, not rework.
- Define the stage of development. With every stage, the integration, security and governance effort rises considerably.
- Choose the retrieval design. Index, federated or live.
- Decide sourcing form and operating model separately. Check the pricing logic against the type of usage, not against the list price.
- Define the degree of autonomy per process. From read to autonomous, with a defined approval point.
- Build a test set before rolling out. Four eval levels, versioned, compared against the previous version with every change.
Outlook: One Shared Layer Under Many Interfaces
Two developments are running in parallel. One is the central AI interface in front of all systems: Glean, Amazon Quick, Anthropic’s Ask Your Org, LLMoin. The other is embedded AI inside the business applications. In August 2025, Gartner expected that by 2026 up to 40 percent of enterprise applications would contain built-in task-specific agents, compared with under 5 percent at the time.
The providers do not treat this as an either-or. Microsoft builds both: Copilot in the applications, Work IQ as the shared context layer underneath, Agent 365 as the control plane above. SAP embeds Joule and at the same time builds an interface of its own with Joule Work. Salesforce positions Slack as “the conversational interface for humans and agents to work together”.
What is emerging, then, is probably not a single new interface, but a shared AI layer beneath several interfaces. That shifts the decision. It is not which enterprise GPT to buy, and not build or buy either, but:
Which AI layer should come into being between employees and systems, and which parts of it have to remain permanently under your own control?
So far no provider delivers a solid answer. The working assumption that holds up best is this: what a company must own permanently is its own domain logic, its governance, the yardsticks of its quality measurement and the ability to switch providers. Which technical layers are operated in-house is a question of the use case, not of principle.
In our example, Miriam’s tip led to three weeks of cleaning up shares. The assistant did not get any better for it. The company did.
FOUNDIC.org is ad-free and has no paywall. If you got something out of this article: 
Treat us to a coffee