BROCS: The framework for enterprise AI enablement

Build / Run / Observe / Control / Secure 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 Procurement questions Failure library Example BROCS Score: 13/25 The five capabilities B Build Provide approved tools and delivery paths. Tooling Access Keys and models Data access Idea to production R Run Operate AI workloads reliably. Runtime Data and state Secrets Provisioning Portability O Observe Measure system behavior and quality. Metrics Traces Alerts Useful signals Model behavior C Control Manage change and access. Configuration Ingress Identity Storage and backups Routing Remote access S Secure Enforce policy and produce evidence. Governance Agents Shadow AI Cost Compliance Assess all five capabilities together because a gap in one can constrain the rest. 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 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. 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. 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. 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. 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. 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. Stay on the list Occasional email about framework changes and new field notes. Subscribed addresses are stored in this site's Cloudflare KV account and are not sold. Reply to unsubscribe, or use the RSS feed without providing an address.