BROCS

BuildRunObserveControlSecure

BROCS: The framework for enterprise AI enablement

Enterprise AI requires more than model access. BROCS organizes the capabilities needed to develop systems, run them reliably, monitor behavior, control change, and manage security.

BROCS is a vendor-neutral framework for assessing enterprise AI enablement. It organizes the work under Build, Run, Observe, Control, and Secure. Use it to assess commercial and homegrown platforms before procurement or implementation.
Get your BROCS Score Read the manifesto

The five capabilities

Assess all five capabilities together because a gap in one can constrain the rest.

Build

Provide approved tools and delivery paths.

  • Tooling
  • Access
  • Keys and models
  • Data access
  • Idea to production
 Run

Operate AI workloads reliably.

  • Runtime
  • Data and state
  • Secrets
  • Provisioning
  • Portability
 Observe

Measure system behavior and quality.

  • Metrics
  • Traces
  • Alerts
  • Useful signals
  • Model behavior
 Control

Manage change and access.

  • Configuration
  • Ingress
  • Identity
  • Storage and backups
  • Routing
  • Remote access
 Secure

Enforce policy and produce evidence.

  • Governance
  • Agents
  • Shadow AI
  • Cost
  • Compliance

Before and after deployment

Before deployment, BROCS sets requirements for a first tool, pilot, supplier, or platform. Once AI is in use, it assesses the delivery paths, production services, telemetry, change mechanisms, and enforced requirements behind that work.

Starting enterprise AI

Use the five scopes as an onramp for tools, pilots, and platforms.

Enterprise AI operations

Apply an operating model to AI systems already in use.

Operational coverage

Assess current evidence and locate the capability limiting scale.

Delivery acceleration

Reduce delivery delays through shared capabilities and bounded change.

Working assumptions

Design principles behind BROCS. The framework assumes tools change, data constraints shape deployment, integration costs compound, and all five capabilities are mutually dependent.

01

Tools will change

Keep identity, data access, runtime, telemetry, policy, and portability independent of any assistant or model provider. Replacing a tool should not require rebuilding the services beneath it.

Vendor independence
02

Deployment follows data constraints

Support the locations and legal boundaries that govern the data, including private infrastructure and approved cloud accounts. A separate stack for each location creates uneven controls and duplicate work.

Data sovereignty
03

Sovereignty shapes architecture

Some workloads require local models or endpoints covered by specific contractual terms. Those paths belong in the core design and should receive the same operational support as hosted models.

Architecture
04

Integration cost compounds

A separate integration and control set for each vendor raises cost and fragments evidence. Shared services reduce the work required to add or replace tools.

Cost
05

Assistants cover part of Build

A coding assistant helps people create software. Enterprise enablement also covers deployment, data connections, runtime operations, monitoring, policy, and incident response.

Scope
06

The capabilities depend on one another

Build relies on approved runtime paths. Observe supplies evidence to Control and Secure. Treat the capabilities as one operating model when assigning ownership and evaluating coverage.

Dependencies