Part 4: Decide Internal vs Client-Facing

Consultancies feel this earlier than ordinary companies.

A normal internal team might be fine with a shared assistant that drafts notes, summarises meetings or searches documents. A consultancy has extra pressure. Client boundaries matter. Reusable methodology matters. Review and sign-off matter. The quality of output is not just an internal convenience; it is part of the service being sold.

This is the difference between productivity and operating model. AI productivity tools help consultants move faster. Internal products help firms work differently.

There is another boundary that changes the decision completely: is this tool only helping our people, or is the client going to experience it directly?

That distinction matters. But it should not be misunderstood. Internal does not mean casual. Client-facing does not automatically mean custom. The better question is: who uses it, what data does it touch, and what happens if it is wrong?

An internal AI accelerator can often be rougher, faster and more experimental than a client-facing product. The users are colleagues. Training is easier. Support can start informally. If something is unclear, someone can explain it in Teams. If the workflow changes, the team can adapt.

But an internal accelerator may still need serious governance. If it touches client documents, proposals, commercial information, employee data, project files, legal material, source code or reusable firm methodology, it should not be treated like a harmless prototype. It may be internal in terms of audience, but high-risk in terms of data.

The middle category is easy to underestimate. A proposal assistant does not need to be client-facing. A deliverable QA agent does not need to be client-facing. A research synthesis workflow does not need to be client-facing. A methodology Skill does not need to be client-facing. But if those tools process client-confidential material, they still need governance, security and ownership.

Internal delivery accelerators still need a product boundary

An internal delivery accelerator sits in a dangerous middle ground. It may begin as a helpful workflow for one team. Then another team asks to use it. Then someone connects it to SharePoint. Then it starts using client documents. Then people rely on the output before sending work to a client.

At that point, it may still be internal, but it is no longer just a personal productivity tool. It has become part of the delivery system.

Security is different from polish. A client-facing product usually needs a more polished interface, clearer onboarding, stronger support and more explicit contractual terms. But an internal accelerator may need equal or stronger data security if it touches sensitive material.

A public FAQ agent on a website may be relatively low risk if it only uses public content. An internal proposal assistant using client credentials is higher risk. An internal QA app reviewing client deliverables is higher risk. A client portal for document review is also higher risk because the client operates the workflow directly. The control level follows the risk, not just the audience.

Where vendor agents can still work

A client-facing or semi-client-facing use case does not automatically require a bespoke React and FastAPI app. A governed vendor agent may be enough when the interaction is simple, the data is low sensitivity or already approved for that platform, the workflow does not need complex state, the agent mostly answers questions or guides users, the organisation can enforce authentication properly, and the use case is still a pilot.

Microsoft Copilot Studio, for example, can publish agents to channels including websites, mobile apps, Microsoft 365 Copilot and Teams.1 Microsoft also makes the security boundary clear: if you select no authentication, anyone with the link can chat with the agent, and authenticated patterns are recommended for organisational or specific-user use cases.2

That is the practical lesson. Vendor tools can be good enough, but only when the platform boundary matches the data boundary. If the agent is accessible to the wrong people, connected to the wrong sources, unable to enforce client-level separation or too hard to audit, the convenience is not worth it.

Client-facing deliverable is not the same as client-operated app

A consultant may use AI internally to produce a client-facing deliverable. That is not the same as giving the client access to the AI tool. The client may see the report, deck or recommendation, but not operate the workflow behind it.

Using AI internally still needs policy, review and data governance. But the firm can keep human judgement between the AI system and the client. When the client operates the tool directly, the interface, model behaviour, data handling and support model become part of what the firm is selling. That is a much higher bar.

The client-facing test

Before turning an internal AI tool into something a client can use, ask whether the client knows AI is being used, has approved the data flow, can rely on the output, and has a clear support and escalation route. Also ask whether one client could ever see another client's data, whether the tool exposes firm IP, whether there is an audit trail, whether it can be switched off safely, and whether it needs contractual terms of use.

A tool can be excellent for internal acceleration and still be unsuitable for direct client use. That is not failure. It may be the right boundary.

There is a career point here.

The rise of Copilot Studio, Claude Skills, ChatGPT workspace agents and no-code workflow builders does not make coding irrelevant. It changes where coding matters.

In my view, the valuable person is not the one who refuses to use platforms. That person is likely to be too slow. The valuable person is also not the one who only configures platforms. That person often hits a ceiling as soon as the workflow needs proper software.

That is a strong AI solutions engineer. Not someone who says "we should build everything". Not someone who says "the platform can do everything". Someone who can look at a messy process and say: this is a prompt, this is a shared agent, this is a workflow, this is now a product.

And then build the smallest responsible version of the thing.

I would ask ten questions before choosing the tool.

1. Where does the work naturally happen? If the answer is Teams, Outlook, SharePoint and Office, Microsoft often has a strong advantage. If the answer is Slack, code, documents, local files and reusable methods, Claude may be a better fit. If the answer is a browser app with its own workflow, chat may be the wrong interface.
2. What exactly needs to be shared? A prompt? A method? An agent? A workflow? An app? Be precise. "Sharing" is not one thing.
3. Who experiences the tool? A personal assistant, an internal delivery accelerator and a client-operated product need different boundaries.
4. What data does it touch? Check source ownership, client boundaries, confidentiality, derived data, retention, deletion and whether outputs become business records.
5. Are we allowed to use this tool in this way? Check client commitments, data processing terms, retention rules, model-training terms, regional requirements and output ownership.
6. Who controls access? If access is just "whoever has the link", be careful. For internal data, you need identity, permissions and source-system alignment.
7. What happens when it goes wrong? Can you see what the agent did, which sources it used, whether a change can be rolled back, and whether a new version can be tested?
8. How will we know it still works later? Important workflows need evaluation cases, quality monitoring, feedback loops and review dates.
9. Will people actually use it? Check where the work happens today, what behaviour must change, which workaround is being replaced, and what evidence shows the work is better.
10. Who owns it after launch? A productivity tool can be enabled by IT. A workflow needs an owner. An internal product needs a product owner, a technical owner, a governance owner and a support model.

If it is a task, use the assistant. If it is a repeatable workflow, use the workflow builder carefully. If it is a reusable method, package it as a skill. If it is becoming operationally important, give it product discipline; sometimes that means an app, and sometimes it means a governed platform workflow with clear ownership.

The more sensitive the data, the more important the boundary. The more client-specific the workflow, the more important the commercial permission. The more repeatable the process, the more important the ownership. The more consequential the output, the more important the audit trail. The longer the tool will live, the more important the lifecycle. The harder the behaviour change, the more important the adoption design.

The stronger pattern is a layered operating model: productivity tools for individuals, agents for workflows, skills for reusable expertise and small custom products where the work needs a proper home.

The organisations in the strongest position are not simply the ones with the most AI licences. They are the ones that know which agents deserve to exist, who owns them, how they are tested, who will actually use them, when they should become apps and when they should be switched off.