ChatGPT & Copilot at Work: When Standard Products Are Enough
ChatGPT or Copilot is not the first architecture decision
ChatGPT and Microsoft Copilot are not blanket-banned at work. Whether either is suitable depends on the concrete use case, contract, configuration, data access and permission model. Consumer use is not the same as centrally managed Business or Enterprise use.
A blanket ban does not remove the productivity problem people are trying to solve. It often moves work into private accounts and therefore into shadow AI, where it is neither visible nor governable. A sanctioned route with clear boundaries is the more useful response.
The more important question follows: Does this task need a standard product, a controlled extension, or a custom AI application? Not every company needs its own platform. A standard product remains a good decision when data, identity, permissions and integrations stay within its intended boundaries.
For the legal assessment of data flows, hosting and transfers, see GDPR-compliant AI for companies. This article addresses the earlier architecture and adoption decision.
When a standard product really is enough
Standard products work well for general knowledge work: drafting, summarising, research, meeting preparation and office support. They are particularly suitable when work already happens in a centrally managed product environment.
That can mean a writing assistant, a summary of available documents, or support in Teams, Outlook and Office. The task remains assistance: the AI proposes, a person decides, and there is no separate execution path changing business systems.
The question is not whether a product can theoretically offer a connector or an agent feature. It is: Can the specific use case be delivered reliably within the available data, identity and integration boundaries? If it can, a custom application often adds needless complexity.
The four decision blocks before choosing a product
A. Use case and data
Start with the actual task and the data the AI must see to complete it. A general writing assistant handles different information from a system that brings together internal knowledge, customer records or operational data.
That distinction prevents two common mistakes: overbuilding a custom solution for simple assistance, or choosing a standard product for a use case whose essential data it cannot reach under control.
B. Integrations and permissions
Where does the relevant data live: Microsoft 365 and SharePoint, a DMS, CRM, or several internal APIs? And must a person continue to see only the data they are entitled to see across each of those systems?
A single data environment with an established identity can make a standard integration plausible. Several sources with different roles, tenants or ACLs change the task. Making content technically reachable is not enough; permissions must survive in the actual query path. RAG permissions and security trimming covers this in depth for retrieval systems.
C. Assistance or system action
An AI that drafts a response or researches information has a different risk boundary from one that creates a ticket, changes a record or triggers a workflow. With suggestions, a person can make the final decision. With actions, it must be clear which identity and permissions apply, and under what conditions a system may be changed.
Once AI changes systems, the architecture requirement rises sharply. Bounded tool permissions, traceable handoffs and a controlled execution path matter more than a polished chat interface.
D. Process logic and operating boundary
Some processes need deterministic rules, explicit approvals or a traceable audit path. Others need to keep several models or providers replaceable, assess their own quality criteria, or operate within a specific hosting and operational boundary.
These are not arguments for custom work for its own sake. They show that responsibility can no longer disappear entirely into product configuration. Private AI vs. public cloud covers operating-model trade-offs in more depth. Once an integrated or custom solution is needed, evaluation, observability and operations become part of the work.
The choice follows the use case, not a maturity ladder
- 01
General assistance
Writing, summarising and research within a clear work context.
- 02
Company data & integrations
Relevant sources sit in M365, a DMS, CRM or internal APIs.
- 03
Permissions & process logic
Identity, ACLs, rules and system boundaries need to hold end to end.
- 04
Operational actions
The AI may change tickets, records or workflows only through a controlled path.
- 05
Appropriate target model
Standard product, controlled extension or custom application—depending on the answers above.
Three target models
Model A: Standard product
A standard product is enough when general assistance is the priority, the existing product environment already covers the required data sensibly, and the current identity and administration model fits. Complex multi-system integration, critical system actions and custom process logic are not required.
ChatGPT Business or Enterprise and Microsoft 365 Copilot can be sensible options in that setting. The decision is deliberately small: a centrally provided tool for clearly bounded work, not an invisible new line-of-business application.
Model B: Standard product plus a controlled extension
This model fits when the existing product environment remains useful but selected additional sources, defined connectors or limited retrieval are needed. The extension stays behind a deliberate boundary: it connects selected sources or a narrowly defined process without pretending to be a complete application platform.
The standard product remains the primary interface and work environment. Identity and permissions remain in the existing product context wherever possible, while a clear integration path limits which extra source or function is added. It does not become a full line-of-business application with its own execution, evaluation and operating model. When retrieval or data connection becomes central to the task, RAG implementation and AI integration is the appropriate next step.
Model C: Custom AI application
A custom application becomes relevant when several internal systems need to work together, its own process logic is required, or permissions need to be finer-grained than a standard product can represent for the use case. The same applies to controlled tool and API actions, deterministic workflows, specific audit requirements or an intentionally separate operating boundary.
Custom is not a higher maturity level or a quality signal. It is a different answer to requirements that no longer fit cleanly within a standard product's boundaries.
ChatGPT and Copilot in their natural product contexts
Microsoft 365 Copilot is a particularly natural fit when Microsoft 365, Entra ID, Teams, Outlook, OneDrive and SharePoint already form the central work and identity context. It can use work data according to each user's existing permissions. That does not fix poor data quality or incorrect permissions: AI can make existing access boundaries usable; it does not make them correct.
ChatGPT is well suited to knowledge work, analysis, writing and research, but it is not limited to a general assistant without company context. ChatGPT Business can bring connected work sources—including Microsoft 365—into company context and respects existing permissions in connected apps. For company use, that context must be considered separately from consumer use.
The product ecosystem is therefore a factor, not the architecture decision itself. Several systems with their own integration logic, permissions that must be explicitly controlled across product boundaries, custom process logic, deterministic workflows, tool or API actions, and separate audit, evaluation, observability or operating requirements all need their own assessment. There is no winner: both products can be the right decision in the right context.
Typical mismatch situations
- A company buys Copilot even though its relevant knowledge mainly sits in a DMS, CRM and specialist systems outside Microsoft 365. The interface fits; the actual data path does not.
- ChatGPT becomes the frontend for a specialist process even though the required permissions, approvals and process rules exist only in internal systems.
- A standard product is expected to orchestrate several internal systems without a controlled execution path for API calls, failures and permissions.
- A team builds a custom application immediately even though a centrally managed assistance use case is fully covered within the existing product environment.
- RAG is added even though the real problem is poor data quality or unresolved permissions. An index does not replace an authoritative source or an access-control decision.
These situations rarely fail because a model is too weak. They fail because the product boundary and the actual use case do not match.
What a custom application consciously takes on
A custom application creates control because it designs its own boundaries. It also takes on responsibility for identity mapping, data and integration logic, process and workflow rules, tool execution, security boundaries and operating ownership.
Quality then becomes its own responsibility too. The company needs traceable evaluation, adequate observability and a responsible way to deal with changes, errors and outages. This is not an argument against standard products; it is the cost of having an AI application carry a distinct business process. For the questions that follow the architecture decision, see the enterprise AI architecture checklist.
The pragmatic decision: start small, keep boundaries explicit
If a standard product fulfils the use case within its data, identity and integration boundaries, use it. If a clearly bounded extension is enough, do not turn it into a hidden platform. Only when real integration, permission, process or operating requirements go beyond those limits does custom architecture become the smaller and safer decision.
The valuable decision is not "buy or build" in the abstract. It is: Which responsibility must this company control for this process, and which responsibility can deliberately remain in the product?
Note: This article offers technical and organisational orientation, not legal advice. The legal assessment depends on the specific use, data flows and operating model.
Deciding between a standard product, an extension and a custom AI application? AI consulting and solution architecture turns the use case, data, integrations, permissions and operating boundaries into a defensible target decision. → Request an initial conversation