LibreChat, Copilot, and the Enterprise AI Boundary Problem

Most conversations about enterprise AI platforms start with features and price. The governance conversation should start somewhere else: who controls the data path, who owns the failure modes, and who gets the call when something goes wrong.

Two approaches dominate right now. One is a managed assistant embedded in your existing productivity suite, with Microsoft 365 Copilot as the obvious example. The other is a self-hosted interface that sits in front of the models of your choice, with LibreChat as a common open-source example. This post isn’t a product review. It’s a look at how your governance obligations change depending on which side of that line you land on, and where the line is blurrier than it looks.

What Each Approach Actually Is

Copilot is embedded in Microsoft 365 and grounded in your organization’s existing data and permissions. Microsoft runs the infrastructure, and the assistant works inside your tenant.

LibreChat is an open-source chat interface you host yourself. It connects to one or more language models, either commercial APIs or models you run locally, and it ships with enterprise identity options like SAML, OIDC, and LDAP along with role-based access controls. You run it, you secure it, you decide what it connects to.

Both can be governed well. They fail in different ways.

Managed: What You Inherit and What You Don’t

With a managed assistant, Microsoft operates and patches the platform. You don’t maintain servers, and identity integration is largely handled inside your tenant. That’s a real advantage for organizations without deep engineering capacity.

What you don’t inherit is clean data. Copilot works on whatever a user can already reach, and it will surface it in responses. If your access hygiene is poor, the assistant doesn’t fix that. It exposes it faster. Your governance work lives in data classification, sensitivity labels, DLP policy, and access reviews, and the quality of that work determines whether the deployment is safe.

The other limit is scope. Governance is strongest when your data lives inside the Microsoft ecosystem and weaker when critical data sits in other SaaS platforms or custom systems. Model choice and product roadmap are also largely the vendor’s decision, which is worth naming in your third-party risk assessment.

Self-Hosted: What You Gain and What You Now Own

Self-hosting gives you control that a managed product can’t. You choose the identity provider, the logging detail, the retention period, and which models are available to whom. You can audit prompts centrally. For organizations with strict data handling requirements, that control is the whole point.

It also moves a long list of responsibilities onto your team: infrastructure, patching, uptime, secrets management, and vulnerability response. If that last item sounds familiar, it should. The NetScaler incident covered in the November 3 post was a lesson in what happens to internet-facing systems that nobody patches fast enough. A self-hosted AI front end is another application in your attack surface, and it needs the same emergency patching discipline as anything else you expose.

The Data Path Is Where Boards Get Misled

Here’s the point that matters most for governance reporting. Self-hosting the interface does not by itself keep your data inside your walls.

If your self-hosted platform calls an external model API, prompts still travel to that provider. What self-hosting changes is who controls access, logging, and policy at the front door. It does not change where inference happens unless you also run the models locally. So the provider’s retention terms, training-use terms, and breach notification commitments still belong in your risk assessment.

“Self-hosted” tends to get heard as “private” in board conversations. Sometimes it is. Often it isn’t, and the difference should be documented, not assumed.

The Cost Conversation Needs Honest Math

Managed assistants are typically priced per seat, with list pricing commonly cited around $30 per user per month. Self-hosted options generally carry no license fee, which is why you’ll see comparisons claiming savings of ten times or more at scale.

Be skeptical of those comparisons. Many come from vendors selling alternatives, and they tend to leave out engineering time, infrastructure, security operations, and the cost of owning an incident. Build your own model, and include the people who will run it.

Five Questions That Apply Either Way

Whichever approach you choose, the governance questions are the same:

Where does the data go? Map the full path, including every external model provider.
Who can access what? The assistant inherits permissions, so permission quality is the control.
What is logged, and for how long? You need enough to investigate an incident and few enough that logs don’t become their own exposure.
Who can turn it off? Every deployment needs a tested way to disable it quickly.
Who owns it when it breaks? A named owner, not a team name.

What the Board Actually Needs

The board doesn’t need to pick a product. It needs to see an inventory of AI platforms in use, a clear statement of which data classes may go where, and a named accountable owner. Many organizations end up hybrid, using a managed assistant for general productivity and a self-hosted platform for sensitive workloads. That’s a defensible design, but it doubles the control set you have to maintain, and it creates a shadow AI risk if the approved options frustrate people enough that they go around them.

The platform decision matters less than the boundary decision. Know what can cross it, know who approved that, and write it down.

Discussion Questions

Can you map the full data path for every AI platform your organization has approved, including external model providers behind any self-hosted interface?
If your organization uses a managed assistant, how current is the data classification and access hygiene it depends on? Who verified that?
If your organization runs or is considering a self-hosted platform, does it have the same patch SLA and monitoring as your other internet-facing systems?