The Challenge
The hard part of deploying AI inside a professional services firm is not the model. It is everything around the model: who can reach it, what it can reach, where the data travels, whether anyone can reconstruct what happened afterward, and what it costs when usage grows.
BRIO works inside client systems across legal, financial services, healthcare, and eCommerce engagements, which raises the stakes on all five questions. Before the firm could deploy anything broadly, it had to be able to:
- Grant and revoke access centrally, through the same process as every other corporate system.
- Connect AI to systems of record without copying client data into a second place.
- Keep sensitive workloads off public network paths.
- Produce an audit trail attributing every automated action to an identity.
- Make cost predictable rather than discovering it in arrears.
The Approach
BRIO sequenced the deployment deliberately: identity first, then connectivity, then controls, then cost. Each layer depends on the one before it. Connecting an AI assistant to live client systems before access is governed produces a capability nobody can safely turn off, and building automations before there is an audit trail produces work nobody can explain to a client later.
The rollout ran through a dedicated internal channel where friction surfaced in the open, from connector re-authentication behavior to local shell path exceptions. Support questions got answered publicly and the answers became the documentation.
The Solution
Identity Before Anything Else: Access is granted through Microsoft Entra ID application assignment. An unassigned user is blocked at sign-in with a clear error, and access follows the same joiner, mover, and leaver process as any other corporate application. This is unglamorous and it is the single highest-leverage decision in the whole deployment, because it means the answer to "who has access" is a query rather than a survey.
A Connector Layer, Not Copy and Paste: Rather than pasting data between systems, the firm connects AI directly to its stack using Model Context Protocol (MCP) connectors, an open standard for exposing tools and data to AI assistants. BRIO connected its project tracker, time and resourcing systems, customer platform, document storage, messaging, and meeting platform. Work happens against live records, which removes both the transcription step and the transcription error. Connectors are scoped deliberately, with read access granted broadly and write access granted narrowly.
A Service Identity for the AI Itself: Automation gets its own account rather than borrowing a person’s. It is provisioned as a member, never an administrator, and added explicitly to the specific channels, projects, and repositories it needs rather than granted organization-wide access. Every action it takes then lands in the audit log under its own name, which is what makes "what did the AI do last Tuesday" an answerable question.
Keys Nobody Holds: Cloud managed identity acts as the handshake that unlocks a password manager, which in turn supplies the credentials for third-party services. Secrets exist only in the memory of the running environment. Nothing is committed to source control, and no human ever handles the values.
Private Paths for Sensitive Work: For workloads touching sensitive client data, model access runs through a cloud-hosted endpoint inside the corporate tenant, reached over a private link rather than the public internet, authenticated by managed identity rather than a portable API key. The existing application logic stays where it is; only the endpoint it calls changes.
Decisions Worth Settling First: Several questions are cheaper to answer before deployment than after. Whether to run a single company-wide instance or isolate per client, which is a direct trade between simplicity and blast radius. Whether any client contract restricts AI usage or requires disclosure. Which categories of data are off limits entirely, and what scrubbing happens before anything else. Where logs go, and who owns reviewing them.
Cost as a Design Constraint: Model selection is a per-task decision rather than a standing one. Interactive work that a person is waiting on runs against real-time endpoints; heavy analysis, large migrations, and scheduled reporting run as batch jobs, which cost roughly half as much and carry separate, higher throughput limits so overnight work cannot starve the assistant a person is talking to.
Technical foundation
- Enterprise identity provider application assignment for access control
- Model Context Protocol connectors across the delivery stack
- Dedicated service account with least-privilege, explicitly scoped membership
- Managed identity to password manager chain for runtime secret retrieval
- Private network endpoints for sensitive model workloads
- Centralized log aggregation for audit
- Tiered model selection with batch processing for non-interactive work
The Impact
Sequencing identity and controls ahead of capability is what made broad deployment defensible:
- One approved platform, with access controlled by the same system as every other corporate application.
- Automated actions attributable to a distinct identity in every system they touch.
- Client data on private network paths, inside the corporate tenant, for sensitive workloads.
- Redundant AI licensing consolidated once the platform decision was settled.
- A single, answerable story for clients about which AI tools touch their systems and under what controls.
None of this is the interesting part of AI, and that is rather the point. Getting it right first is what buys the freedom to move quickly on everything after.
