Starting enterprise AI
Use BROCS as an enterprise AI onramp: set requirements for a first tool, pilot, supplier, or platform across Build, Run, Observe, Control, and Secure.
BROCS can be used before the first AI deployment. The five scopes provide a requirements set for selecting a tool, approving a pilot, designing a platform, or reviewing a supplier.
Plans can define requirements before launch. Assessment points require current operating evidence, so a planned control remains unchecked until the organization can demonstrate it.
Custom model development is one possible entry route. Organizations may begin with a ready-made assistant, an AI feature in existing software, a vendor application, a low-code workflow, or an API-based system. Microsoft's Cloud Adoption Framework separates ready-to-use Copilots, low-code SaaS development, managed PaaS development, and Azure infrastructure into distinct adoption models.1
Set the operating requirements early
| Scope | Requirement before approval |
|---|---|
| Build | Identify who may use or configure the system, which data it can reach, and how changes will be reviewed and released. |
| Run | Record where the workload executes, where state and secrets live, and which runtime duties belong to the organization or supplier. |
| Observe | Define the service signals, quality measures, cost data, traces, and action records required after launch. |
| Control | Name the identities and mechanisms used to change configuration, routing, access, prompts, and rollback. |
| Secure | Set permissions, retention, spending boundaries, incident evidence, and applicable compliance requirements. |
The depth of each requirement should match the system. A personal productivity assistant and an agent that can change customer records carry different data, action, and evidence needs. Both can be reviewed through the same five scopes.
Choose the entry route
| Entry route | Early BROCS focus |
|---|---|
| Licensed assistant | Identity, data access, retention terms, audit records, and approved use |
| AI inside existing software | Supplier responsibility, feature configuration, telemetry, and change notices |
| Vendor AI application | Integration, runtime dependency, data movement, operating evidence, and exit work |
| Low-code workflow or agent builder | Publishing rights, connected tools, evals, action limits, and rollback |
| API or custom application | Delivery path, runtime, secrets, state, model routing, telemetry, and production ownership |
| Fine-tuning or custom model work | Data lineage, experiment tracking, model artifacts, deployment, performance, and lifecycle ownership |
Google's AI Adoption Framework helps organizations assess current capability and desired ambition.2 BROCS adds an operating test to each technical route. The buyer questions can be used during procurement, and the assessment can be completed as soon as evidence exists.
Carry the same scopes into operation
Requirements become useful when the running system produces evidence that they hold. The same Build, Run, Observe, Control, and Secure scopes continue after approval, so the onramp and the operating review use one vocabulary.
For active tools or workloads, use enterprise AI operations, operational coverage, or the delivery guide.
Microsoft, "AI strategy - Guidance to set your organization's AI strategy", Cloud Adoption Framework, updated June 26, 2026. ↩︎
Google Cloud, AI Adoption Framework, 2020, accessed August 27, 2026. ↩︎