One approach. Put together your way.
This is how we approach enterprise AI: two entry points, one authentication layer, separate gateways for models and tools, and the user's identity flowing through to the target system. This is an architectural approach, not a diagram of one application. We can deliver it as an integrated foundation or compose it from your tools.
Our approach to enterprise AI
Team reference modelOne approach. Two equal ways to deliver it.
Users, identity, models and business systems stay the same in both forms. What changes is how many roles the integrated AI//BRO covers and how many we compose from your tools. Neither is a higher tier.
Together. AI//BRO as an integrated foundation, adapted to your operations.
Identity, business systems, model provider choice and your deployment environment.
Interface, agents, automation, knowledge, model and tool access, roles and audit.
ERP/CRM integration, company procedures and templates, source configuration and permissions.
Your way. We select the necessary parts and compose a solution with your tools, from Git to gateways.
Identity, Git, an orchestrator or another tool you already use, business systems and models.
AI//BRO capabilities that we reuse or adapt, and the principles we use to compose them.
Gateways, a tool catalogue, MCP adapters and identity propagation (OBO) for selected systems. We agree on scope and responsibilities.
Where each call goes and whose identity it uses
A frequent question from IT. We answer for each path instead of offering one blanket claim about private deployment.
| Path | Destination | Identity used | What it means |
|---|---|---|---|
| Model call | Configured provider: Azure OpenAI, OpenAI, Bedrock, Gemini or local Ollama | Application access to the provider | Data sent to a cloud model leaves your installation boundary. With Ollama it stays inside. |
| MCP tools and API connectors | Remote MCP server or your API | Usually application credentials | Gateway roles control operations and objects. They do not automatically reproduce each user's permissions in the target system. |
| Personal Microsoft 365 connections | Mail, Teams chats, OneDrive and files accessible to that user | The user, after their own consent | A separate mechanism with its own scope and consent. Personal authorization is available today. |
| Scheduled and automated jobs | Configured sources and tools | Service identity | A scheduled job does not act as a currently signed-in person. |
| Custom solution with OBO | Selected business systems through gateways and adapters | User identity through to the target system | We design this for selected systems and supported protocols as part of the architecture delivery. |
AI//BRO runs in your environment. This website does not.
Deploy with Compose or Helm in your environment and with your branding. Hosting this presentation is separate.
The deployment boundary and information flow differ: anything sent to a cloud model or connected service leaves that boundary. We make this clear up front.
Four things you decide
Model providers
Which models and providers to use. You can combine cloud models for everyday work with a local model for sensitive data.
Data sources
SharePoint, Google shared drives, Confluence, file stores, Czech data boxes and mail, with access rules for each.
Tools
Approved MCP tools and API connectors with individually selected allowed operations.
Operational controls
Roles, limits, model cost overview and activity records under the agreed retention policy.
How we describe audit
Activity records and administrator audit support investigations within actual retention and deletion rules. We do not claim they are immutable. Agent history can disappear with a conversation. For audit requirements, we describe the retention of the chosen deployment.
Who operates what is part of the design
The design includes agreement on who operates, maintains and takes over the solution. This is not a fixed package; we promise neither an SLA nor a numeric saving in advance.
Deployment and updates
Who deploys new versions and monitors the environment.
[agreed during design]Procedures, agents and connections
Who manages company procedures, agent definitions and connectors.
[agreed during design]Monitoring and handover
Who reviews costs and records and how handover works.
[agreed during design]What we measure in the first process
We select one process and validate the result on your data. We track processing time, corrections and traceability to sources. Your results determine the next step.
How long one case takes now and with the solution.
How many outputs needed correction and what changed.
Whether an output can be traced to a specific document or record.