We're trying to give more employees access to useful internal AI tools without assigning each person a separate ChatGPT, Claude, or Microsoft 365 Copilot license. Everyone with an E3 plan already has the basic Copilot features for tasks such as proofreading, but the client does not want to pay an additional $30 per user each month for the full Microsoft 365 Copilot experience. We currently have a limited number of Claude Enterprise and ChatGPT Enterprise licenses, mainly for selected users who are building internal skills and workflows. The long-term goal is for IT to own and govern these company-wide tools while allowing employees to use them through an internal frontend or API, rather than giving every employee an individual AI subscription. Some workflows may eventually be converted into regular scripts without an AI component. I'm investigating whether we could rebuild the AI-based skills using models deployed through Azure AI Foundry, such as Claude Sonnet or Opus, and pay based on API usage instead of per-user licenses. Has anyone compared this approach in terms of licensing, governance, security, and total cost?
4 Answers
Think of this as building an internal product rather than bypassing licenses. Foundry can centralize governance and make the user experience consistent, but you become responsible for the frontend, identity integration, data-loss controls, abuse prevention, evaluation, support, and ongoing model changes. A small pilot using real request volumes from the existing Claude users would give you a much better cost comparison than comparing a monthly license directly with token pricing.
For generic capabilities such as proofreading, summarization, and drafting inside Office, using the AI features already included with the applications may be simpler and easier to govern. Premium Copilot features can still require a separate per-user license, so an internal Foundry application would be more relevant for workflows that are not covered by the standard E3 experience. The comparison should include model-token charges, application hosting, storage, monitoring, support, security reviews, and development—not just the API price.
The economics depend heavily on usage. A shared API can be cheaper when most employees use the tools occasionally, especially if you route simple requests to a less expensive model and reserve stronger models for complex tasks. It can become more expensive if usage is heavy or uncontrolled. Put authentication, quotas, rate limits, prompt and output logging, cost attribution, and approval workflows in front of the models from the beginning. Also be careful about letting everyone invoke an expensive model through one unrestricted endpoint.
Foundry is a reasonable fit when you’re building domain-specific workflows, exposing AI through an internal application, or need IT to control the prompts, data access, logging, and deployment. The users would interact with your application rather than directly using a separately licensed Claude or ChatGPT workspace. That said, this doesn’t automatically make access free or eliminate all licensing concerns. You still need to review the model provider’s Azure terms, any applicable Microsoft licensing requirements, and how your application authenticates and meters users.
That’s the direction we’re considering: IT would own the shared tools, and employees would use an internal interface instead of receiving individual premium licenses.